Ruble David-Analisis y Diseno de Sistema PDF

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
— M odelo de contexto ............................................... 437
— M odelo de e v e n to s ................................................. 439
— M odelo de inform ación ........................................ 442
—Prototipo de in te r fa z ............................................... 454
—M odelo arquitectón ico .......................................... 459
— Diseño de la base de datos ................................. 461
— Diseño de la interfaz externa .............................. 463
— 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ôs 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.
" í 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,
¿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.
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
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?"
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.

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

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

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
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
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 âra 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.
“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.

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

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.
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.
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.
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
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.
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-
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
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.
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
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.
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).
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.
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é.
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
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.
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-
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.
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.

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.
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
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
Zí
<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-
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.
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.

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
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.
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
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?”
“¿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.
Eventos de cliente:
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.
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.
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.
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.
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-
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.
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.
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.
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

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

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.
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
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.
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.
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
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
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íâí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.
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
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ê-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
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.
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ûnydó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 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.
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.
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
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.

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

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.
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.
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).
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”.
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.

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

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

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.
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.
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îira, .}

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

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

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

¿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 :
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!
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.
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
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.
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 r h a rd w a re al p ro b lem a. U na solución obvia, pero frecuentem ente sobrestim ada
para el bajo desem peño, es ponerle más hardware al problem a. A ctualm ente el hardware es, por
lo general, m ucho m enos caro que el costo del desarrollo del software que se ejecuta en él. Fre
cuentem ente cuando un negocio se rehúsa a gastar el suficiente dinero para el hardw are ade
cuado gastará mucho más dinero tratando de hacer que su softw are se ejecute a una velocidad
aceptable.
El problem a parte de la ley de m igración de costos1* que establece que cl dinero tenderá
a fluir desde un presupuesto estrictam ente m onitorcado hacia un presupuesto pobrem ente rno-
inloreado. La adquisición de hardw are es un caso clásico de presupuesto estrictam ente moni-
toreado. El hardw are es, por lo general, un gasto de capital controlado y proporcionado
cuidadosam ente por la alta gerencia de la com pañía. Los excesos en gastos de capital son con
siderados frecuentem ente delitos mayores. La m ayor parte del ajuste dcl desem peño sucede en
un sistema después de que se ha entregado el software inicial. Esto hace que sea un costo de man
tenimiento de software, pagado por lo general por la m asa amorf a del presupuesto de operación
de la IT, Hl presupuesto de operación casi nunca es m o«horcado en forma tan cuidadosa eomo
cualquier proyecto de capital. Gran parte del costo en que se incurre en el m antenim iento se
debe sim plem ente al financiam iento insuficiente de la adquisición del hardware o de los pre
supuestos de capital de desarrollo de software, que hacen difícil ensam blar un sistem a ade
cuado desde el principio.
Otro costo que se considera rara vez, es la perdida de productividad de la gran cantidad
de usuarios que se la pasan sentados enfrente de las pantallas inertes de com putadora esperan
do que d sistem a responda. Los problem as de desem peño basados en cliente pueden resolverse
frecuentem ente m ediante la com pra de una m áquina de escritorio más poderosa. N o tiene sen
tido tener a un grupo caro de contadores sin hacer nada ante PCs antiguas y lentas cuando se
pueden com prar nuevas por una cantidad m enor al presupuesto que el departam ento ocupa
para el café. Los gerentes que vienen de los días en que había que ser muy tacaño con el h ard
ware necesitan volver a pensar sus prejuicios a la luz de los cada vez más elevados costos del
desarrollo y m antenim iento del software. O btenga el hardw are más grande, más rápido y más
poderoso que pueda.
OTRAS RESPONSABILIDADES DEL ADMINISTRADOR

DE LA BASE DE DATOS
D ependiendo del tam año y la estrategia de im plem entación del proyecto, la base de datos
puede instalarse de una sola v e / o en partes. Junto con cl diseño e im plem entación del esquem a
de ia base de datos, el adm inistrador de la base de datos tiene otras responsabilidades que
incluyen ver los grupos de autorización de usuarios para im plem entar la autoridad CRUD
especificada por el modelo esencial en la m atriz CR U D de autorización de usuario/entidad.
A dem ás hay actividades que necesitan realizarse y que salen del alcance de este libro.
Incluyen (pero no están lim itadas a) la im plem entación de procedim ientos de registro, estrate
gias de bitácora de base de datos y planes de respaldo y recuperación, instituir los m ecanism os
de replieaeión, cl establecim iento de procedim ientos de carga y descarga de datos físicos y con
cebir el plan de conversión de los datos heredados.
RESUMEN
Sin im portar que sea un partidario de las bases de datos relaciónales o añore los viejos tiempos
del archivo plano, la base de datos relacional llegó para quedarse, al m enos por un tiempo. Su
fortaleza reside en la habilidad para guardar la inform ación en una forma cercana a su form a
en el mundo real y posponer las decisiones acerca de la m anera de acum ularla hasta el
m om ento de ejecución, Conform e pasa el tiempo es probable que las bases de datos rela
ciónales tom arán cada vez m ás de los conceptos de orientación a objetos, proporcionando un
acoplam iento m ás estrecho entre los datos y procesos que hacen cum plir las reglas del nego
cio. Tam bién es probable que las bases de datos orientadas a objetos llegarán a ser m ás rela
ciónales, proporcionando lenguajes de consulta flexibles que perm itan que los datos se agrupen
en form a no prevista por los diseñadores de las clases.
Una base de datos relacional está com puesta de tablas. Cada tabla tiene una serie de
columnas que representan los elem entos de datos individuales. Los registros de datos actuales
de la tabla form an los renglones. Cada tabla tiene una clave primaria. Las tablas están rela
cionadas entre ellas m ediante la incrustación de la clave prim aria de una tabla en otra como
clave externa para im plem entar la relación. Las claves externas perm iten que cl sistem a de
adm inistración de bases de datos relaciónales haga cum plir la integridad refercncial. La inte
gridad referencia! asegura que ningún renglón de una tabla madre pueda ser borrado si todavía
está referen ciado por un renglón hijo.
H1 diseño de una base de datos relaciona! deberá verse muy sim ilar a la disposición del
modelo de inform ación. Ll modelo de inform ación puede ser traducido directam ente en un
prim er diseño de base de datos relacional. Cada entidad se convierte en una tabla. Cada atri
buto se convierte en una colum na. Las relaciones son im plem entadas colocando la clave p ri
maria deí lado de "uno” de la relación en la tabla del lado de "m uchos” de la rcíación.
La selección de las claves prim arias es una consideración de diseño importante. La clave
puede ser un >olo atributo lógico que es perm anente y único. También puede ser más de una
columna. Si no se puede encontrar un buen identificado!' lógico, se puede generar un identifi-
cador arbitrario para que sirva com o clave primaria.
Las entidades de supenipo y subtipo pueden im pleinentarse en alguna de tres maneras.
El método más directo es crear una tabla para cl supertipo y tablas adicionales para cada sub
EJERCICIOS
tipo. Otra opción es com binar los subtipos de vuelta en el supertipo e im plem entar una sola
tabla. L a últim a opción es elim inar al supertipo e im plem entar tablas de subtipo separadas.
Las bases de datos relaciónales están bajo constante presión para ejecutar a velocidades
cada vez mayores. Cuando se trata de afinar el desem peño de la aplicación hay un viejo dicho de
la industria que dice “Es mucho m ás fácil hacer rápida a una aplicación que funciona que hacer
funcionar a una aplicación rápida” . A plicado al diseño de base de datos esto significa que hay que
com enzar con un diseño que mapee la estructura lógica y luego ver si hay algún problema.
H ay una am plia variedad de técnicas que pueden usarse para hacer que una aplicación
ejecute m ás rápido. La clave del éxito es prim ero identificar y m edir el problem a, antes de
com enzar a dar soluciones. A lgunas de las soluciones que se han proporcionado en este capí
tulo incluyen la adición de índices adicionales, la reestructuración de los enunciados SQL, la
optim ización del alm acenam iento físico en el disco, la replicación y distribución de datos o
la redistribución de procesos a través de la arquitectura cliente/servidor. La m ejora de) hard
w are es una solución que deberá estar al principio de la lista de todo mundo.
C uando se trata de ju g a r con la estructura de ja base de datos, algunos niveles de desnor
malización son m ás seguros que otros. L a adición de claves externas redundantes en tablas de
subdetalle es un m étodo de bajo riesgo para la elim inación de uniones. El alm acenam iento de
valores calculados traslada el costo del cálculo de las funciones de lectura hacia las funciones
de creación, actualización y elim inación de la aplicación.
L as vistas aplanadas o extractos de los datos son los niveles más extrem os de desnor
m alización y deben ser tom ados con gran precaución. L as tablas aplanadas son particularm ente
útiles para reducir la sobrecarga de la unión de m uchas labias para los reportes de alto volu
men. Las tablas de extracto pueden reunir inform ación que de no hacerlo así tendría que ser
derivada, o relaciones uno a m uchos aplanadas transportando inform ación de encabezado
redundante con el detalle.
E l aplanado am plio de la estructura norm alizada es un a técnica que debe usarse para
potenciar las tablas norm alizadas pero no para reem plazarlas. La base de datos es un activo cru
cial de la com pañía que contiene inform ación que es com partida por m uchas áreas de la orga
nización. La m ejor m anera para asegurar el valor continuo de ese activo es m antener la
inform ación tan norm alizada com o sea posible para que pueda ser utilizada fácilm ente por
otras aplicaciones.
EJERCICIOS
1. F enw ick Prescott fue contratado para diseñar un nuevo sistem a de inform ación para
u n taller de reparación de autos. U no de los requerim ientos fue que los m ecánicos te
nían que anotar la presión de aire y condición de cada una de las llantas de cada v e
hículo al que se le daba servicio. Fenwick. colocó cuatro pares de colum nas en la
tabla visite de servicio del vehículo {presión delantera izquierda, condición delante
ra izquierda, presión delantera derecha, y así sucesivam ente). Kn la pantalla de cap
tura acom odó ingeniosam ente los datos sobre un diagram a del vehículo con los datos
de la llanta izquierda arriba a ta izquierda, los datos de la llanta derecha a la derecha,
y los datos de las llantas traseras abajo de ellas. Fenw ick instaló el nuevo sistem a en
una tarde de dom ingo. E l lunes en la m añana el prim er cliente entró al taller con una
cam ioneta m odificada que usaba pares dobles de llantas traseras. Fenw ick había
com etido un grave error en su diseño de base de datos. ¿Puede sugerir una m ejor
solución de diseño que la que dio Fenwick?
266 Capítuio 9 / EL DISEÑO DE BASE DE DATOS
2. ¿Bajo qué circunstancias se debe evitar que una clave prim aria lógica se use como
clave prim aria en vez de una clave prim aria generada por el sistema?
3. Su sistem a de captura de pedidos bellam ente norm alizado está ejecutando dem asia
do lento. La prim era irritación se da en la ventana de selección de pedidos en la que
los usuarios recuperan grandes listas de pedidos. El sistem a debe ejecutar una unión
de varias form as para reunir los datos de varias tablas para su presentación. Uno de
los de sarro Uadores sugiere la creación de una tabla aplanada que se m apee en forma
m ás cercana a la disposición de ventana desde la que pueden ser recuperadas más rá
pidam ente las listas de pedidos. Las transacciones de pedido serán guardadas en las
tablas norm alizadas, y las tablas aplanadas serán actualizadas por medio de procedi
m ientos alm acenados. Si toda solución tiene un problem a, ¿cuál es el problem a po
tencial de esta solución?
RESPUESTAS
1. Fenwick ha supuesto que todos los vehículos a los que se les da servicio en e¡ taller tie
nen solamente cuatro llantas. Si hubiera hecho un trabajo más profundo de análisis h a
bría encontrado que el taller da servicio a todo tipo de vehículos, desde camionetas
modificadas a vehículos recreativos y autobuses escolares. En vez de incrustar la infor
mación de llantas en la tabla visita de servicio de vehículo, debería haberla norm aliza
do para separar la tabla condición de llantas (una entidad atributiva de visita de servicio
de vehículo). Con un poco de trabajo adicional en la interfaz, todavía hubiera podido
presentar al usuario un diagrama inteligente del vehículo permitiendo que el usuario se
leccionara entre una variedad de configuraciones de ruedas cuando captura los datos
básicos acerca dcl vehículo. Luego la pantalla mostraría ia cantidad adecuada de cam
pos condición de llanta, dependiendo de qué tantas llantas hay en el vehículo.
2. A lgunos adm inistradores de base de datos le dirán que siempre use claves generadas
por el sistema. En general, un identificador único lógico no debe usarse com o clave
prim aria si es que representa inform ación que puede cambiar, por ejemplo, un códi
go m nem om eo que es una abreviatura de la descripción del producto. Cualquier cam
po que pueda ser cam biado por el usuario debe quedar descalificado com o candidato
para la clave prim aria, debido a que la clave puede quedar incrustada en otras tablas
com o clave externa. '
3. La idea de recuperar ventanas de selección a partir de una tabla física aplanada, agiliza
la recuperación de la ventana de selección debido a que elim ina uniones costosas en la
recuperación. Sin embargo, como las tablas aplanadas tienen que mantenerse en sincro
nía con las tablas de transacción normalizadas de las que se derivan, el esquema sim
plem ente desplaza el costo de la unión de tablas de la recuperación hacia el guardado,
doode procedimientos almacenados deben ejecutar la unión para mantener en sincronía
a las tablas aplanadas. La clave para decidir si un esquema m ejorará el desempeño es
pruebas del sistema de administración de la base de datos para ver si el sistema
se desempeña mejor cuando se mantienen tablas de extracto por medio de proced-
in s m o s almacenados o cuando se unen los datos durante la recuperación. También se
necesita un estudio de los hábitos del acceso a los datos del usuario, ya que si ejecuta
más guardados que recuperaciones la propuesta podría, de hecho, hacerlo más lento.
C a p ít u l o
10
CONCEPTOS DE INTERFAZ
DE
INTRODUCCIÓN
Los capítulos 10 y Ü están dedicados al diseño de la interfaz gráfica de usuario. El capítulo 10

presenta los conceptos principales que están tras lo que hace que una GUI sea una interfaz más
agradable y am able que las antiguas pantallas verdes, lin esta sección trataré algunos criterios
estándares para cl buen diseño aceptados por la Industria, y proporcionaré algunos consejos de
mi propia experiencia en relación ai control, responsabilidad, personalización, dirección, con
sistencia, claridad, estética, indulgencia para el usuario y la tom a de conciencia de las fortale
zas y lim itaciones de los humanos. En la segunda mitad dcl capítulo he aplicado términos que
se han utilizado tradicinnalm ente para describir el nivel de cohesión de m ódulos en un sistema
estructurado hacia la forma en la que están agrupados en una ventana los eventos dcl negocio.
El resultado es un vocabulario fam iliar para la “cohesión de ventana”, que es una medida apro
xim ada de la com plejidad, facilidad de uso y facilidad de m antenim iento a largo plazo del di
seño de la ventana.
288 Capítulo 10 / CONCEPTOS DE INTERFAZ GRÁFICA DE USUARIO
LA APARICIÓN DE LA INTERFAZ GRÁFICA DE USUARIO
La interfaz gráfica de usuario representa un avance trem endo en la form a en que la gente se co
m unica con las com putadoras. Las prim eras investigaciones en e! Palo Alto Research Center
de X erox produjeron en 1980 la prim era interfaz gráfica de usuario de apuntar y hacer clic. La
interfaz m anejada por ratón fue com ercializada com o el X erox STAR®, pero el éxito com ercial
del concepto no llegó hasta que A pple lo adoptó en 1984 en las com putadoras personales M a
cintosh® y Lisa®, Las pistas visuales intuitivas, la facilidad de uso y las capacidades gráficas
de la A pple la hicieron muy popular entre personas que anteriorm ente no habían utilizado n in
gún tipo de com putadora. La M acintosh de A pple fue un gran éxito y pronto fue un aparato co
mún en los negocios, escuelas y casas.
M ientras tanto, el sistem a operativo MS-DOS® de M icrosoft Corporation para la com
putadora personal IBM estaba ganando la guerra en la participación del mercado, debido al ge
neroso acuerdo de licencia que perm itió que el D O S se instalara virtualm ente en cualquier clon
IBM. L a interfaz del M S-DOS era basada en caracteres y am enazadora para todos, a excepción
de los más aventurados de los usuarios no técnicos. Fue el poder de los paquetes de software,
tales com o el Lotus 123®, y los prim eros procesadores de palabras los que aseguraron la p e
netración del M S-D O S en el mercado. Fue obvio para M icrosoft que para m antenerse a la ca
beza debía sacar un sistem a operativo GUI. E l resultado fue el Windows®, que se lanzó por
prim era vez en 1985.
M ientras sucedieron los juicios inevitables entre M icrosoft y A pple sobre quién era pro
pietario de la apariencia y sensación de la interfaz, la interfaz gráfica m ism a quedó grabada en
la psicología de com putación del m undo entero. La tecnología de interfaz gráfica había gana
do la batalla sobre la tecnología basada en caracteres. El debate sobre si conviene usarla ya ca
rece de sentido. El reto es ahora encontrar la m anera de elaborar interfaces gráficas de usuario
que estén bien diseñadas, satisfagan las necesidades del negocio y satisfagan las expectativas
cada vez m ayores de los usuarios.
M uchas de las m iles de aplicaciones GUI que ya se utilizan en el mundo, están brillan
tem ente diseñadas. O tras son com pletam ente horribles. P or lo tanto, ¿qué hace que un diseño
sea “m ejor” que otro y en qué m anera son diferentes de los antiguos diseños de term inal de
m ainfram e?
Para los desabolladores que han pasado un tiempo significativo de su carrera en el m un
do de las mainframes, el cam bio a una interfaz con ventanas puede ser un poco incómoda. Los
recién llegados a la industria, que fueron criados con sus propias M acintosh desde la cuna, pue
den preguntarse a qué se debe tanto alboroto. Este capítulo pretende explicar los puntos básicos
acerca de lo que hace a una “buena” GUI. En m uchos casos, puede poner nom bres a conceptos
que ya se han interiorizado. Cada vez que sea posible trataré de m ostrar la diferencia de las ca
pacidades de la GUI con respecto a las venerables “pantalías verdes” de antaño, y explicaré tan
to las diferencias culturales com o las capacidades técnicas que nos persuaden actualm ente para
diseñar cosas en forma diferente de com o hubiera sido en el mundo de las mainframes.
¿QUÉ ES LO QUE HACE QUE UNA GUI SEA DIFERENTE

DE UNA PANTALLA VERDE?
Demos un paseo po r el recuerdo de los viejos tiempos cuando la vida era sim ple, las pantallas
eran verdes y los usuarios no estaban arm ados con un ratón. La “ pantalla verde” recibió este
¿QUÉ ES LO QUE HACE QUE UNA GUI SEA DIFERENTE? 269
nom bre por el color esm eralda de los caracteres en el m onitor m onocrom ático, aunque algunos
modelos tuvieron caracteres ám bar o blancos en la pantalla negra. La ‘pantalla verde” típica
de mam tram e estaba basada en caracteres. Esto significa que la pantalla estaba dividida en una
cuadrícula de 80 caracteres de ancho y 24 líneas de alio. Cada celda de la cuadrícula era capaz
de desplegar un solo carácter. El program ador tenía que declarar cuál carácter iba a aparecer
en cada intersección de cada colum na y posición de línea. Algunos caracteres se usaban para
rótulos de cam pos y otros podían usarse com o cam pos de datos tecleados por el usuario.
Debido a que sólo podía desplegarse una cantidad lim itada de caracteres de tam año fijo,
la pantalla proporcionaba muy poco espacio para com unicar inform ación al usuario. E sta lim i
tación condujo a los diseñadores a abreviar muchos de los rótulos de los dalos de la aplicación
para ahorrar el precioso espacio. Los valores de datos también eran abreviados para ahorrar e s
pacio en la pantalla y para ahorrar espacio de disco (ílgura 10-1). Como el espacio de disco era
caro, entre m enos caracteres se guardaran era un ahorro m ayor en dólares de hardw are.
r ID :: QK0G2
id ORDEft fiNTRY
P SS ¡03> : XSXXSXX
ORDEfí._NBR: 12-Q Ü 3 4 ORDE5R DATE; ± 2 / 2 1 / fifi 5 T O R g _ N B P .:_ L 0 ItJV_CD: 3!rwr
CUST_NBR: 83~3421~H [J A V A TS T1UT COFFÜE SHOfc] SLSPR SNi B3T tWTTPJí: N30
A D D R _ L I : 700 JJ O R D TYPE: D X fi D LV M P H : p r .p
Á £ D R I íIN B 2 : Û X Ê ¡LOO_______________________ D IS C _ C D : 4M 5 CRB. CD:
CITY; S T : jSA 2XP: 9S 01Ü -Q 123
L lí í f i PRD CD PRD DE3C OTV USfXT PRICE S2T PRICE
ÜL WHOLS SEAN- - 20 I B B£ 10 D E¡A § 9 5 .0 0 9 5 0 0 .0 0

Ü2. FAÍ'ÉR F I lT E f t 1 00 0 CT 50 EA % 25,aa £50.00
D3 PAPER CÍJPS S 0 2 / 2 0 0 CT _10. EA S 6 ,5 0 __ 6 5 .0 0
SUS_TOTAt» 9 8 1 5 .0 0
TAS_C<XE: TAS 0,00
TOTAL 9 8 1 5 ,OD
SM IT CD: £7. RCPT: Y
P F l HEÍliF P r? F IR S T P F 10 SACX S F lJ . NEST PF12 IlAST
Figura 10-1. El espacio limitado forzó cl uso de abreviaturas y códigos.
Para finales de los setenta, casi lodo en la vida em presarial tenía una abreviatura, nu
mero o código m nem ónico. M uchos de estos códigos y abreviaturas quedaron literalm ente
“cincelados” en la cultura em presarial. Este tipo de folklore ha sentado sus reales en la m a
yoría de los sistem as heredados del m undo com o un lenguaje em presarial secreto. El cambio
a los sistem as cl i entc/scr vidor G U I nos da la rara oportunidad de relar la necesidad de tal co
dificación (figura 10-2). Los tipos de letra dim cnsionables, las ventanas em ergentes y las lis
tas desplegables han increm entado en gran form a el espacio disponible en la interfaz, y el
cada vez m enor costo del hardw are ha hecho innecesario que se caiga en tacañerías con el e s
pacio de discu.
F ig u ra 10-2. La misma pantalla en un ambiente GUI
Las term inales basadas en caracteres también tenían capacidades gráficas limitadas. La
mayoría de nosotros recuerda con algún grado de nostalgia los intentos de representar un logo
tipo respetable de la com pañía hecho con ceros, guiones y líneas verticales. A ctualm ente los grá
ficos sólo están limitados por la resolución cada vez m ayor de pixeles en el m onitor de color.
En las term inales de m ainfram e las pantallas se presentaban al usuario de una en una. Se
escribía código procedurai para “poner” la pantalla en la term inal. El procesador, incapaz de
detectar teclazos individuales, tenía que esperar hasta que el usuario oprim iera la tecla E n tr a r
o una tecla de función antes de que despertara pitra “obtener” el contenido de la pantalla y pro
cesar los resultados. E sto difiere dram áticam ente con respecto a la PC, donde el objeto venta
na contiene un código para detectar eventos cuando succdcn. Cada teclazo y clic de ratón tiene
la capacidad de com unicar inform ación al procesador. Se necesita una gran potencia de proce
sam iento local en cada term inal para que esto sea posible.
CRITERIOS PARA EL BUEN DISEÑO GUI
\ia ciK ti de los principios que están tras el buen diseño GUI no son necesariam ente nuevos. La
m v e r ú de t e usuarios preferiría usar una pantalla verde bien elaborada en vez de una GUI
pobrem cnic diseñada. Entonces, ¿qué es lo que hace que un diseño sea mejor que otro? Estos
principio* generales soo descritos brevem ente por M icrosoft (1992),- y más am pliam ente por
Galitz i 1994-l; Para tener uniform idad he tom ado prestada su term inología, pero he orientado
1 M icrosoft, 1992.
2 Galitz, 1994.
CRITERIOS PARA EL BUEN DISEÑO GUI 271
mi definición hacia los de sarro 11adores que están diseñando aplicaciones em presariales funda
mentales en vez de aplicaciones de uso general para el mercado de paquetería.
I.o s c riterio s p a r a n n b u e n diseño G U I son:
C ontrol del usuario

Sensibilidad
Personalización
D irección
Consistencia
C laridad
Estética
Retrual ¡mentación
Indulgencia
C onciencia de las fortalezas y lim itaciones de los hum anos
Control de usuario
M ucho ruido se hace acerca de darle al usuario control com pleto en una interfaz gráfica de
usuario. La retroal¡mentación inm ediata y obvia para cada acción mejora el sentim iento
de control del usuario y reduce la frustración con el sistema. A unque el usuario tiene mucho
más control que el que tenía en una pantalla verde, dem asiado de algo bueno puede ser peli
groso. Llevado al extremo, el usuario tiene la habilidad para m overse librem ente de ventana a
ventana y hacer cualquier cosa que desee.
H1 ratón haee que sea irrelevante el control del orden de tabulación, debido a que 110 hay
garantía de que un cam po sea dado antes que otro. O bviam ente, en una aplicación de negocios
la integridad seria de los datos em presariales se puede ver am enazada, y al usuario ¡10 se le pue
de dar sim plem ente el dom inio libre que se podría esperar en, digamos, un paquete de proce
sador de palabras. D ebido a que el am biente de ventanas perm ite que se “haga cualquier cosa” ,
la tarea del diseñador de aplicaciones de negocios es frecuentem ente el restringir a dónde no
puede ir el usuario en cualquier m om ento dado. El usuario debe tener control, pero no a tal gra
do que pueda hacer un desastre total de los datos empresariales.
A lgunos usuarios adorarán su nuevo ratón y otros discretam ente lo aborrecerán. El ratón
es muy bueno para la selección y navegación de apuntar y disparar, pero puede degradar la ve
locidad de m ecanografía de un hábil usuario de teclado. Una buena aplicación GUI debe tener
facilidad de uso para un “ratonero” o para un “buen m ecanógrafo” con la habilidad de un pia
nista de concierto. Por esta razón, siempre hay que incluir el orden de tabulación y las teclas
aceleradoras,1 para que cualquier acción que pueda realizarse con el ratón tam bién pueda lo
l,as teclas aceleradoras son las letras subrayadas de un elemento de menú o botón de comando que propor
cionan el equivalente de teclado de hacer clic sobre el elemento. Algunas herramientas GUI les llaman có
digas mncmónicos y usan el termino acelerador para combinaciones de lee]as de métodos abreviados que
proporcionan aeceso rápido para determinadas tarcas, tal como Ctrl+C [Jara Copiar.
grarse con el teclado sin ratón. La desventaja de esto es que la interfaz debe probarse ahora
tanto para las acciones de teclado com o para las de ratón, lo que aum enta en forma significa
tiva cl esfuerzo requerido de aseguram iento de la calidad.
1.a aplicación debe indicar claram ente si obtiene cl control a costa del usuario. listo se
logra frecuentem ente cam biando el apuntador dei ratón a un reloj de arena o a un indicador de
espera, y atrapando cualquier elic de ratón adicional que haga el usuario y que no sea atrapa
do por el am biente operativo.
U na vez tuve la desgracia de probar una aplicación en la que el program ador no había
evitado que el usuario siguiera haciendo clic m ientras la aplicación estaba procesando. Cuan
do guardé m i trabajo espere al reloj de arena que siem pre aparece. E n vez de ello m e apareció
un apuntador. Esto es algo con lo que siem pre se debe esperar: un usuario con un apuntador
continuará haciendo clic.
En ausencia de cualquier reloj de arena, jubilosam ente hice clic acá y acullá en la venta
na que no respondía. Cuando el control regresó del servidor a la m áquina cliente observé algu
nos resultados singulares. P or casualidad el primer clic de ratón no atrapado cerró la ventana
activa. El segundo clic no atrapado le dio al botón de elim inación de la ventana que estaba ba
jo ella, y el tercer clic no atrapado cayó cerca del cuadro de m ensaje de confirm ación. Con un
poco de suerte, adem ás de guardar mi actualización, fui capaz de borrar accidentalm ente un
conjunto com pleto de transacciones. K1 program ador reclamó que no podría hacer que la apli
cación fuera com pletam ente a prueba de idiotas, ante lo cual m e ofendí mucho y rápidam ente
fui arriba con los usuarios para reunir un grupo de voluntarios idiotas de alto calibre. D espués
de un poco de práctica fueron capaces de hacer clic por anticipado lo suficiente para salir de la
aplicación com pletam ente c iniciar un juego de solitario.
“lo sitfvrro, ackicej^L, ce n o q u e ú \c_e v o &le clic . acabam os de eumimais ca u sa s."

Sensibilidad
La generación de usuarios M TV ™ actual se aburre rápidam ente. Si la aplicación está proce

sando durante mucho tiempo, considere la adición de una escala deslizante para indicar el por
centaje del trabajo que se ha realizado, o distráigalos eon algún m ensaje inform ativo en la barra
de estado. Cuando el sistem a no responde rápidam ente, m uchos usuarios lo interpretan como
falla del sistem a y volverán a arrancar la com putadora a mitad del trabajo.
En uno de mis prim eros proyectos cliente/servidor los usuarios no estaban a gusto con el
tiempo que se necesitaba para registrarse en el sistema.'' Hicimos todos los intentos posibles pa
ra optim izar los procedimientos de registro en la base de datos y sim plem ente no pudim os agi
lizarlos más. En una noche uno de los de sarroll adores principales tuvo la brillante idea de añadir
una barra de estado a la ventana de registro. Rápidam ente codificó algunos mensajes de aparien
cia informal que eran cambiados cada cinco segundos por cl programa. D espués de que se libe
ro la nueva ventana, varios usuarios se tom aron la m olestia de agradecernos el “haber agilizado
la ventana de registro” . De hecho no c o m a m ás rápido que antes, pero les proporcionaba algu
na disfracción, la que evitaba que se im pacientaran y observaran cóm o transcurría el tiempo.
El sistem a debe proporcionar retroal i m entación tangible e inm ediata para cada acción
Hsto puede ser tan sim ple com o el cam biar un apuntador hacia el reloj de arena o resaltar un
renglón seleccionado. A veces la validación puede requerir soporte del servidor, por lo que pue
de ser que el usuario no encuentre que ha com etido un error sino hasta que la base de dalos re
chaza su actualización. Se usan los cuadros de mensaje para interrum pir al usuario e inform arle
que se ha detectado un error. Cuando añada el cuadro de m ensaje a la aplicación, convierta
cualquier m ensaje críptico generado por la com putadora en una rctroalim entación agradable
com prensible por el usuario (figura 10-3).
Figura 1í)-3. M ensajes de c iro r crípticos c o n tra com prensibles.
4 L1 problema real fue que nuestra primera versión de la herramienta de desarrollo GU f tenía grandes desa
cuerdos eon el sistema operativo Windows, lo que daba como resultado fallas del sistema inesperadas. I jjs
usuarios rápidamente aprendieron que el "volver a arranear" resolvía el noventa por cíenlo de sus proble
mas (un hábito desafortunado que persistió aún después d e q u e la causa fue remediada). Por lo tanto, la ra
tina de registro diario era llamada varias veees a! día en ve?, de sólo una vez en la mañana, y a eso se debía
la petición de "hacerla más rápida".
Personalización
La personalizacióti es una característica importante de las interfaces gráficas de usuario. No to

dos los usuarios tienen las mismas necesidades, y el program ador puede dejar muchas de las
tareas de personalización a los usuarios. H e encontrado que es muy útil permitir que los usua
rios reordenen y redim en sionen las colum nas en un conjunto de resultados grande. La figura
10-4 muestra una ventana en la que hay dem asiadas colum nas recuperadas para que se puedan
desplegar en pantalla. Se ha empleado un estilo de cuadrícula para la presentación de dalos, ei
cual perm ite que el usuario rcdiinensionc y reordene las columnas en el conjunto resultante, de
pendiendo de cuáles columnas le sean más importantes. Los usuarios son capaces de guardar
sus preferencias para que la siguiente vez que recuperen la ventana su Ordenamiento quede in
tacto. En cualquier momento pueden regresar el orden de las columnas a la posición predeter
m inada por el programador. E sta técnica es particularm ente útil en conjuntos de resultados de
sólo lectura. Le recomiendo tener precaución con el uso de cuadrículas para ventanas de cap
tura de dalos, debido sim plem ente a que el usuario puede elim inar de la vista alguna columna
crítica.
; Vessel Selection
jV e s ie tif
Vessel Í V m m eÁ
i OceanRideF V 24.... ..... B1036 Vancouver, BC 1-2020-4
Ür:ean Rider V24 B1096 Tacema, WA 1-2024-1
Ocean Rider V24 B1036 San Francisco, CA 2-5053-1
Ucean Seek-íi V28 *1*7 _ iVancouver, BC 11-2031 -1
Linean Seeker V2£¡ B147 Tacema, WA 4-2120-1
Ocean Vision V22 B12 ......... Vancciover, BC 1-2Ü63-1
Ocean Loaner V34 GC8 ;San Francisco, CA 2-5143-1
Hi-iean Loaner V34 E¡C6 Los Angeles, CA 2-5201 -1
Ocean Cruiser V39 EC12 San Diego,. CA Í3-5G65-::
■±l'J ■ iJ
- 'f f if o L Í '- A ên i C l o - ; e 1
F ig u r a 10-4, U n a ventana estilo cuadrícuia típica.
Muchos lineam ientes GUI publicados dicen que ios usuarios deben ser capaces de per
sonaliz-ar los colores de la interfaz. lie encontrado algunos problem as con esto. Pareciera que
todas las com pañías tienen un grupo de usuarios que participan en un concurso de día del co
lor feo", t-a persona que obtiene la com binación de colores más desagradable en su ínterlaz g a
na una dona. Hsto puede ser bueno para el sistem a operativo, pero no se le debe perm itir a las
personas que usan las aplicaciones m edulares del negocio que bagan menos visible a la infor
mación importante de la interfaz. i\le he encontrado usuarios que llaman al escritorio de ayu-
275
h S - ^ T r í T C SUS VentaaaS SS han PUt:St0 Cn b Ian c a súl° Para descubrir que han cara-
biado los rotulos de los cam pos al color de fondo.-
Para aplicaciones críticas bloquee los colores. Los colores pueden usarse com o pistas vi
suales para inform ar al usuario de si un cam po es opcional, requerido o prohibido. Un esque
ma razonable es hacer que los cam pos opcionales sean blancos, los campos prohibidos sean
t n s claro y los cam pos requeridos sean de un color reconocible pero pasivo, tal com o el cian
p á lid a Los cam pos de dalos son colocados sobre un fondo gris suave que es cóm odo para los
ojos. Bajo estas circunstancias, la m odiiicación de los colores cam bia cl significado de la apli
cación. Una v e/ 0 1 a un vendedor que exaltaba las virtudes de la personalización de color m ien
tras \e n d ia una aplicación GUI de respuesta a emergencias.
Dirección
El concepto de dirección es muy bien soportado por el paradigm a objeto-acción (capítulo 6)

■s m ucho m as intuitivo localizar el objeto que se desea y manipularlo directam ente que el em i
tir un com ando críptico y declarar el objeto al cual se aplica cl com ando. El ratón es una h e
rram ienta excelente para este upo de diálogo “apunte y dispare”. Considere la diferencia entre
borrar u n ,a rch.vo en cl viejo am biente del M S-DOS y el borrar un archivo con un sistem a ope
rativo O L I. Ln los viejos tiem pos se emitía un com ando ante el indicador C:\>, el cual tenía
que ser sintácticam ente correcto al cien por ciento:
D E L C :\D IR N A M H \F IL H N A M E .E X T
Hii un am biente GUI se encuentra al archivo en una lista, se hace clic cn él con el ratón
> se le arrastra al bote de la basura o a 1.a papelera de reciclaje (figura 10-5)
La estructura del com ando está exactam ente invenida con respecto a los viejos tiempos
■n v e / de dar el com ando primero, se le perm ite al usuario exam inar una lista de objetos en
este caso los archivos del disco duro. Cuando ha seleccionado el objeto deseado puede iniciar
u diversidad de acciones. Cada acción que puede realizar debe estar disponible ya sea en un
elem ento de menú o en un bolón de comando. La característica de arrastrar v soltar va un pa
so mas alia añadiendo una pista visual, el bote de basura, para que el usuario no tenâ que bíis-
cai el menú de la característica de eliminación. “
La dirección puede ser aplicada también en las aplicaciones de negocios. Una disposición
típica para una ventana objeto-acción es aquella en donde el usuario puede recuperar una lista
de objetos, digam os pedidos, facturas o archivos de personal, y aplicar acciones desde una ba
rra de botones o un mentí para cualquier renglón que haya seleccionado (llgura 10-6)
1,as pistas visuales, tales com o los iconos y barras de herram ientas, tam bién pueden aña
dirse a aplicaciones de negocios para m ejorar la facilidad de uso v dirección de las aplicacio
nes. len g a cuidado de no exagerar en el núm ero de iconos muy agradables cn el sistem a de
negocios. Los iconos muy coloreados pueden rápidam ente atiborrar a una aplicación I os ico
nos con ilustración y las barras de herramientas deben añadirse a una aplicación de negocios
' La mejor llamada ai escritorio de ayuda vino de un nuevo usuario GUI que llamó para informar que “se que
mo 0 ,0 fli™ de uno de ]<* bolo„,s". Kn v e , de tratar de explicar d activado y desael.vado del b o l ,
InrvLS tid lelcíuua, aJgmen ruc despachado rápidamente para “cambiar el
sólo cuando m ejoran la habilidad d d usuario pretendido para lograr sus tareas. N uevam ente,
se debe regresar a los vectores de calidad de cada parte de) sistem a para decidir si se está d ise
ñando para m ejorar la velocidad de entrada dcl usuario frecuente, \& facilidad de aprendizaje
dcl usuario casual o la flexibilidad del m aneja de la información para el usuario de escenarios
“qué tal si” , y así sucesivam ente.
F ig u ra 10- 5 . E lim in a c ió n d e a rc h iv o c o n a rra stra r y so ltar.
i O rd er S e le c tio n
zm . """
1 m m d -í s i í m O -----
9931 ;Acmé Beverage St Flocket Fitd, Inc.!112/21/96 : 527.50jTentative .
101 _ J
101 :3932 ¡JoeJoe's Pizza |1 12/21/96 ; SS.COjConHimed
101 ¡9933 iThe Slug Pit Bar & Giill 112/21/96 ; 465.15?Shipped
Toi I9934 Fem's Department Store ¡12/22/96 26,450.12jFi!led
101 9935 The Lobhy Shoppe 12/22/96. 1,126.8S Back-Qrdered
101 9936 :Washington Plaza A?sociation H
> 2/22/96 1G.2i; Canceled
101 :9937 ;The Metro Cafe ] l 2/22/96 654.78 Confiirried í?¡
101 Í9938 ■Aorne B 3vera ge ít Rocket Fue], Inc. Í12/2 2/96 * 391.21' T entative
101 " ¡9939 ' 37th Street Investors ¡12/22/36 1,654.00jCcinfi[rned
Figura 10- 6, Una ventana objeto-acción típica.

277
Consistencia
U na aplicación de negocios deberá .ser consistente con el mundo en que los usuarios viven v
trabajan diariamente. Cuando la tecnología cliente/servidor com ienza a invadir áreas de la
com pañía que no estaban previam ente automatizadas, éste puede ser un reto para el analista y
el diseñador. Las unidades de negocios que realizan la m ism a función a veces tienen un voca
bulario de la industria y term inología com pletam ente diferentes para esencialm ente las mismas
ideas. Las com pañías construidas m ediante fusiones y adquisiciones encuentran este problem a
particularm ente molesto. El analista tiene dos alternativas, personalizar la aplicación para m a
pear la cultura histórica de cada lugar o aplicar reingem ería al negocio para obtener un consen
so sobre la term inología y los procesos del negocio (llgura 10-7), Estos tipos de asuntos por lo
general requieren guía de un com ité de dirección.
F ig u r a 10-7. L a consistencia involucra el llevar a los usuarios a la obtención de consenso

sobre los térm inos.
1 ara lograr consistencia en los rótulos de los datos a lo largo de la aplicación, el proyec
to debe tener un conjunto de nom bres de rótulos estándar para cada atributo del modelo de in
formación. M uchas de las herram ientas de desarrollo GUI principales soportan estos tipos de
extensiones al modelado de datos. Incluya un rótulo estándar a usar: los rótulos pueden estar a
a izquierda del campo en un form ato libre y encim a del cam po en un form ato de colum na Pa
ra atributos tales com o dinero, porcentaje y núm eros telefónicos también se deben especificar
form atos y m áscaras predeterm inadas. Cuando se deba abreviar un rótulo se deberá usar una
lista de abreviaturas estándar para que los rótulos siempre sean consistentes en toda la apli
cación. *■
Otro aspecto importante de la consistencia es que las aplicaciones deben ser funcional
mente consistentes dentro de la aplicación. Esto se logra m ediante el apego a estándares para
el aspecto y sensación, nom bres de m ends, nom bres y colocación de botones de com ando y
uso racional y consistente de otras características GUI. M uchos de estos estándares GUI pue
den ser com prados actualmente de vendedores de terceras partes o sim plem ente tomados de otro
proyecto. Un proyecto G U I nuevo no debe perder tiempo argumentando sobre el tam año de
letra para la barra de título. Cuando se trata de los estándares recuerde los m andam ientos del
diseñador:
Deberás pedir prestado

Deberás tomar prestado
Deberás robar
Deberás desear la aplicación de tu prójimo
Las aplicaciones de negocios también deberán ser consistentes con el aspecto, sensación
y lenguaje de otras aplicaciones. Es mucho más fácil entrenar a un usuario para usar una apli
cación em presarial si es visual y funcionalm ente consistente con su procesador de palabras, ho
ja de cálculo y correo electrónico. Con la com putación cliente/servidor, la “aplicación’7 no es
solam ente el fragm ento que uno construye. Es todo lo que el usuario necesita en su escritorio
para realizar su trabajo.
Siem pre se puede ir a los paquetes populares, tales com o los procesadores de palabras y
hojas de cálculo, para buscar lincam ientos sobre la m anera de definir conceptos de m enú y b o
tones de com ando, sin embargo, encontrará que los proveedores no son siem pre consistentes
con sus propios paquetes. H an em ergido algunos estándares de facto que siempre deben seguir
se, tales com o las palabras reservadas y la colocación de determ inados conceptos de menú
tales com o A rchivo, V e n ta n a y A yuda.
L a violación de los estándares aceptados de 1a industria puede dar com o resultado apli
caciones extrañas. O bservé un proyecto en la G rim R eaper Life Insurance Com pany que esta
ba enfrascado en un gran debate sobre dónde colocar el com ando Guardar, bajo el menú
Archivo o el m enú Edición. D e hecho ganó la facción que sugería Edición, apoyada por la opi
nión de que, Guardar en realidad actualizaba un solo renglón de la tabla de la b ase de datos,
y no creaba un nuevo archivo físico, por lo tanto estaba realizando una edición. ¡Nunca olvide
que casi todas las aplicaciones G U I en el m undo tienen el com ando listado bajo el menú Ar
chivo! E l proyecto a final de cuentas cayó en la anarquía y la alta gerencia caritativam ente le
aplicó la eutanasia.
Claridad
La inform ación que se presenta en la interfaz debe ser inm ediatam ente com prensible, y el uso
de la aplicación debe ser visual mente evidente. La claridad puede ser un reto significativo pa
ra las aplicaciones G U I que están reem plazando tecnología de pantallas verdes. U na aplicación
GUI debe tener un uso lim itado y consistente de abreviaturas para valores de datos y rótulos.
A quí se encuentra nuestra oportunidad para com enzar a desm antelar la m ontaña de códigos
crípticos, abreviaturas y códigos m nem ónicos que se han estado juntando desde que las com
putadoras se introdujeron a la organización.
E l concepto de consistencia dice que hay que usar el lenguaje del m undo real de los usua
rios. El concepto de claridad tom a en cuenta que algunos de los lenguajes de los usuarios son su
rrealistas, y por lo general es resultado del diseño de sistemas heredados. Se debe tratar de alejar
a los usuarios de) vocabulario del sistem a antiguo, ya que no tiene sentido en el nuevo sistema.
Los desabolladores a veces encuentran usuarios que dicen cosas com o “el nuevo siste
ma debe incluir el reporte 4250”. ¿Realm ente se quiere usar este nom bre para cl nuevo repor
te? ¡Claro que no! El núm ero 4250 fue el núm ero de lote de reporte del sistem a antiguo que
algún program ador colocó al centro de la barra verde del reporte de papel. El núm ero llegó a
im buirse culturalm ente en la m anera de hablar de la organización durante generaciones de
usuarios que pedían el núm ero de lote diariamente. Cuando se profundiza se encuentra que
4250 es en realidad el “reporte de ventas sem anales por gerente” . El nuevo reporte debe usar
cl título del mundo real, y de paso, tal vez se les pueda dar acceso en linea para generar su pro
pia copia del reporte bajo pedido en v e/ de que sea una rutina por lotes.
hs probable que el sistema antiguo esté condim entado con códigos. M uchos de estos có
digos se han metido en el lenguaje diario del negocio. No todos ellos son malos, pero sí deben
ser cuestionados. Veamos un ejemplo de un sistem a de captura de pedidos de una em presa m a
nufacturera. La figura 10-8 es un fragm ento de la tabla pedido del sistem a antiguo. Si exam i
namos la estructura de la base de datos encontram os que núm ero da cliente, código de
transporte, número de planta y código de vendedor son referencias a claves externas de la ta
bla cliente, la tabla método de transporte, la tabla planta y la tabla vendedor, respectivam ente.
I-a vieja pantalla (encabezado de pedido Order Header) se m uestra en la figura 10-9.
PEDIDO
Núrn_p.edido Núm r;te Cód transp Fecha_ped Núm plañía Cód_pHr ven
102304 5S023 | 03 | 21-12-96 12 BST
-
F ig u ra 10-8. U n renglón parcial de la tabla de pedidos.
OPJDEP. HEABER 0 9 : 1 0 : 1 1 .
Of¡3EÍ;_ U S Í l:
C U S T JJE R : £. k 0 2 3 [M A H U PA C TU R IN 3 I N T L . rK T R P .]
TB A SiSííJilH : Q¿ OF.DEKJ.WSS: 1 2 / ; 1 / 9 6
PLANT__NSR: ¿¿ B L S _ E F .S H ¡ BST
ilE L P PFS F IR S T PP10 BACK P P I 1 Ü3XE p~ÍZ 1A SE

*
F ig u ra 10-9. L a pantalla verde de Order lleudar
No tengo ningún problem a particular con el número de pedido, pero me m olestaría si la

única form a para obtener uu pedido en pantalla fuera teclear el núm ero exacto. En un sistema
bien elaborado que soporta el paradigm a objeto-acción, los usuarios deben ser capaces de ad
quirir una lista de pedidos por una variedad de criterios de selección en caso de que no tengan
el lujo de un núm ero de pedido frente a ellos.
280 C apitulo 10 / CONCEPTOS DE INTERFAZ GRÁFICA DE USUARIO
Pasando al núm ero de d ie n te , parece que la form a de obtener un d ie n te en un pedido es

teclear su número. El nom bre de d ie n te, que está nial abreviado en el sistem a antiguo, se des
pliega a la derecha sólo cuando se teclea un núm ero valide. Esto causa que cl usuario consul
te una lista de núm eros de d ie n tes, o lo peor, los m em urice. N uevam ente, no tengo ningún
problem a en dar núm eros de d ie n tes por sí mism os, es un a forma cóm oda para protegerse de
que el cliente cam bie su nom bre. Sin embargo, en una interfaz m oderna el usuario debe tener
la habilidad para buscar el nombre de d ie n te para identificar al cliente. Un método razonable
es perm itir la introducción de una cadena p ard a l en el cam po nombre de d ie n te y regresar una
lista de clientes candidatos en una ventana de respuesta desde la cual el usuario puede escoger
uno (figura 10-10). Si el usuario teclea correctam ente el nom bre com pleto, y se encuentra en
la base de datos, no hay que m olestarlo con la ventana de respuesta, JR1 número de cliente pue
de usarse com o un cam po de captura alterno, sólo para presentarlo o elim inarlo com pletam en
te de la ventana.
*
t Selección d é l clie n te 0
« M a n ív ittir: T ra n s fe r I íV;* Jk,
Man * ttanheira 3 li**í& rc lle E Co.
Ma npcmrej: T ampo ¡ca r i es
k. , MaTVUÍ a cttt rjkn-cj I n t é t-jia îo
i 1M anutacturEC? N atLonal
Manwa Refuse Ccimpany
* / M anzatta staamworks
\ /
M anzatta T ra n sís*: Co»
F OK j iCancelarj
Figura 10-10. El método de búsqueda de nombre de diente.
El método de transporte es d código m ás sospechoso en la pantalla. Hay varias formas

en que esta em presa envía sus productos term inados. Si se busca la tabla de control para los
métodos de transporte se encontrarán los registros que se m uestran en la figura 10-11,
MÉTODO DETRANSPORTE
C ó d iao D escripción j|
01 C am ió n ¡
02 Ferrocarril |
03 C o n te n e d o r j
04 Carga a granel i
05 A é re o i
Figura 10-11. Tabla del método de transporte.

Las tablas de control que contienen solam ente un código y la descripción son buenos
candidatos para un estudio posterior. Antes de que desaparezcam os estos códigos debem os po
ner algunas reglas básicas. Para im plem entar un conjunto de valores de atributos restringidos
sin usar una tabla de control se deben satisfacer las siguientes condiciones:
1. Los valores deben ser perm anentes. Los códigos son am pliam ente em pleados en
lugares donde cl nom bre tiene alguna p robabilidad de cam biar dnrante el tiem po de
vida del sistem a. Si es extrem adam ente im probable que lleguen a cam biar los v a
lores. tal v e / no se necesite un código.
2. Los valores no d eb en ser dem asiado la rg o s. O tra razón por la que se em plean có
digos es porque la descripción ocupa dem asiados caracteres, haciendo que sea d i
fícil hacerla caber en ventanas y reportes. R ecuerde que ahora se ha expandido el
espacio de las ventanas y los tipos de letra dim ensionables en los reportes im pre
sos con láser, por lo que el lím ite superior de lo que es la longitud aceptable de un
cam po se ha elevado. En el pasado algunas organizaciones creaban un código para
cualquier descripción que fuera de m ás de seis o diez caracteres. A ctualm ente m u
chos proyectos han elevado ese lím ite hasta 20 o m ás. L a decisión debe tom arse de
acueido al espacio de las ventanas y los reportes y no al espacio en disco.
3. L os valores no deben tener otros atributos. Si el atributo en cuestión tiene atri
butos adicionales propios, es una entidad por sí y debe perm anecer en un a tabla se
parada. Sin em bargo, el que se use el valor literal del dato com o clave prim aria
dependerá principalm ente de los conceptos 1 y 2.
4. Hay código en la aplicación que depende de los valores. U na razón principal p a
ra la creación de tablas de control para valores de datos es perm itir que el usuario
pueda extender el conjunto de valores válidos. La extensibilidad definida por el
usuario funcionará solam ente si no hay código dependiente de los v a lo re s actuales.
Kn el caso de m étodo de transporte de nuestro ejem plo podríam os encontrar algo
de código en el sistem a que hiciera cum plir las siguientes reglas del negocio:
T T rr.étoco d e t r a n s p o r t e = "carr.i ó n ”
Se r e q u i e r e n o m b re á e c o r r p s fiia t r a r m p o r t . i = La
!'■i s e i r :nc tocio d e t r a n s p o r t e - " i e r r c - c a r r i l "
Se req-.r. e r e non¡brn d e com par i a Lrciiiívoorziñl.ü
Se r e q u i e r e p la n de r u t a d e l v e k 'c u lo
L¡_se j_f mée o c:.;:> e e t r a n s p o n c e = " c o n t e n e d o r "
Se r e q u i e r e regiG T.ro d e c o n te n e d o r-
H lse i:: ~ é t o d o cié t r a n s p o r t e = " C a r c a a g r a n e l "
Se r e q u i e r e r e g i s t r o ole C a r a a a g r a n e l
Se r e q u i e r e d i :nr:ns ior.eí; d e l em b arq u e :jll.:;ra , L c n g iu .id ,
¿nioVaira)
KI ejc i f m é to d o gc t.r¡m:;po?-te = " a é r e o "
p e s o r_o do-Pe e x c e d e r de p a r a m e nn-c; ¿ e s i : ; t e : r a Li i m i t e de
peao a é r e o |
Er±d i f
282 Capítulo 10 / CONCEPTOS DE INTERFAZ GRÁFICA DE USUARíO
Cuando se tiene este tipo de código dependiente de valores en el sistem a, no hay for
m a en que el usuario pueda añadir m ás valores a la tabla sin una intervención signi
ficativa del departam ento de IT para alterar el código de la aplicación.
5. El nuevo sistema no necesita conservar traducción de código para la comunica
ción con otros sistemas. Si el nuevo sistem a debe com unicarse con otros sistemas
antiguos que necesitan los códigos antiguos, entonces las tablas de traducción de có
digo tendrán que ser parte del nuevo sistema. A unque éste sea el caso, no m oleste a
los usuarios con los códigos antiguos. G uarde y despliegue los valores literales de los
datos y use una tabla de traducción para com unicarse con los sistem as antiguos.
Dado este conjunto de criterios, pareciera que podem os elim inar al código de m étodo de
transpone. U na lista desplegable en la interfaz perm itirá que los usuarios seleccionen el m éto
do sin tener que m em orizar el código. La lista desplegable no hará más lentos a los que teclean
por tacto, debido a que los conceptos pueden seleccionarse desde la lista sim plem ente teclean
do la prim era letra del cam po. La lista de valores puede cargarse a partir de una tabla y ser m an
tenida por el adm inistrador de sistem a o, si es com pletam ente perm anente, codificada
directam ente.6 O tra ventaja de este m étodo es que los renglones de pedido contienen ahora el
valor literal, lo cual hace que sean más fáciles los reportes y las consultas de usuario final al
elim inar la unión de tablas.
Regresando a nuestra pantalla de captura de pedidos, el uso de un núm ero com o clave
prim aria de la tabla planta es un hecho com ún. Puede ser que en el mundo real las personas
hagan referencia a la planta que está en Hum ptulips, Washington, com o planta núm ero 12, d e
bido a que cn realidad fue la doceava instalación que se construyó. A dem ás, puede haber un 12
gigante pintado en la fachada del edificio. En el nuevo sistem a GUI se esperaría al m enos que
cl nombre de la planta se desplegara junto con el número de la planta y, al igual que el nom
bre de cliente, perm itiera que se seleccionara desde una lista. Dos de las desventajas del uso de
núm eros es que los nuevos em pleados tienen que m em orizar la lista y se tienen huecos m oles
tos cn la secuencia conform e las plantas son cerradas o vendidas.
El últim o código de nuestra pantalla verde es el código de vendedor. Pareciera com o sí
el diseñador del sistem a antiguo hubiera usado las iniciales de los vendedores com o clave pri
maria. “B ST” significa Betty Sue Thompson. D esgraciadam ente, el finado esposo de Betty
Sue, el señor Thom pson, un rico petrolero, murió en su suite nupcial a bordo de un crucero. Su
hcrcncia está todavía sujeta a un litigio debido a reclam aciones ilegítim as de parientes distan
tes y la renuencia de la com pañía de seguros para desem bolsar fondos. M ientras tanto, Betty
Sue se ha vuelto a casar y ahora es Betty Sue LaCrosse, esposa de T. H arm ond LaCrosse, un
m agnate de los bienes raíces de noventa y siete años de edad con problem as cardiacos. El nom
bre de Betty ha sido cam biado en la base de datos, pero su código de vendedor no puede ser
actualizado debido a que está por todos lados del sistem a cóm o clave externa cn cada uno de
los pedidos que ha colocado.
Habiendo sido un fanático de ía normalización durante muchos años, nunca pensií que las palabras ‘'codifi
cado direeâirienie" calieran de mis labios, pero hay algunos casos en que en los proyectos se ha exagerado
haciendo ¡ab!as de tixio lo que está a la visia. El peor caso que he visto sobre locura de códigos fue un sis
tem a en donde una labia de referencia guardaba códigos para los valores “sí” y “no” . “Sí” era "01", y “No"
era "02". Presumiblemente eí programador usó un código de dos dígiios para dejar la puerta abierta para al
menos noventa y ocho maiices de “tal vez".
Los códigos m ncm ónicos basados en nom bres hacen terribles claves primarias para cual
quier tabla en donde es probable que cam bie el nom bre. En el nuevo sistema, el personal de
ventas deberá tener identificado res aleatorios que nunca son desplegados ante los usuarios. É s
tos pueden ser generados por el sistema de adm inistración de base de datos cuando se inserta
un nuevo renglón. La interfaz debe perm itir la selección entre una lista de nom bres actual. P a
ra los reportes cn donde los nom bres son muy largos se puede usar una concatenación de sus
iniciales actuales (figura 10-1.2).
VEN D ED O RES
ID d ü v e n d e d o r A p e l li d o N o m b re S e g u n d o n o m b re In ic i a le s i
9
D V001X L a C ro ss e B e tty Sue BSL &
i
:*3
D V023X G a rn ro d R u s s o ll D a v id RDG
1
D V104X B u t t e r f ie ld A rth u r Ja m e s A JB
i
DV05bX W o n r o t t le W endy Ann W AW
¡
1
l
1
F igura 10-12. La nueva tabla vendedores.
La figura 10-13 m uestra la nueva ventana O trie r H eader (encabezado de pedido) como
aparecería en una interfaz gráfica de usuario. La claridad es m ejorada mediante el lenguaje del
mundo real para conceptos que previamente requerían la memorización de códigos. Hemos ocul
tado los códigos de la vista en lugares donde no hay razón para que el usuario los vea. Con el m é
todo de, transporte liemos eliminado el código com pletamente y almacenado el valor literal en la
base de datos, debido a que encontramos que los valores de los datos no cambian a través del
tiempo, no son muy largos, no tienen otros atributos, hay código dependiente de Jos valores y no
tenemos que mantener una tabla de traducción hacia otros sistemas que usen los códigos antiguos.
Order Headei
,- v;; ,t
j Sue LaCíoss
F ig u ra 10-13. La nueva ventana Order lleader.

Estética
La com posición y disposición de una ventana debe ser visual mente agradable. D eberá atraer la
vista hacia la información que es más importante. Estudios sobre la fijación y movim iento del
ojo humano muestran que la mayoría de la gente ve primero la parte izquierda superior del cen
tro de la pantalla y rápidam ente hace un barrido en una dirección eti sentido del reloj.7 Por me
dio de investigaciones amplias los expertos han derivado principios que definen un sentido de
estética agradable para las culturas occidentales.8 listos principios incluyen una sensación de ba
lance, el uso de elementos espaciados y alineados con regularidad, simetría, patrones predeci
bles, econom ía de estilos, colores y técnicas, arreglos secuenciales de elem entos para guiar ía
vista, unidad de ideas relacionadas, un sentido de proporción, sim plicidad y el agrupam iento de
elementos relacionados.^
Mucho de lo que se aprendió con estos estudios lo han sabido desde hace años los artis
tas y fotógrafos. I .as escenas que son estéticam ente agradables a la vista colocan al sujeto más
im portante cerca del centro del cuadro. lü espacio negativo, o espacio en blanco, es el área de
la com posición que está vacía (figura 10-14). Dé una vista a las pinturas de la exposición del
más próxim o artista m uerto de ham bre de su pueblo. O bservará que la forma del espacio ne
gativo así com o de los elem entos periféricos de la com posición tienden a apuntar la vista co
mo si fuera una ílecha hacia el sujeto principal. '
F ig u re 10-14. F! espítelo negativo es donde no está 1.a im agen y es el que puede

dirigir ía vista hacia la im agen.
I a figura 10-15 m uestra una disposición de ventana muy am ontonada que tiene espacio
negativo mal definido y mal balanceo y alineación. Esto hace que sea difícil dirigir la vista ha
cia lo que es más importante. El gran volumen de inform ación que se presenta al usuario ha
creado un re \o 1lijo visual en la pantalla.
" Sttvdor. \\a>scnnan. 19S4.
^ Taylor. 1%0 > 1973.

;t Para un estudio a fondo ¿obre estos principios, vea tialitz, 1994.
Figura 10-15, Una ventana con m uy poca estética.
Cuando las ven Lanas com ienzan a estar muy atiborradas, hay varias buenas técnicas p a
ra lim piarlas. Se puede recurrir al modelo de inform ación para ver si hay una división lógica
entre dos entidades diferentes que com parten la ventana. Una relación, tal com o la clásica de
encabezado/detalle, es un lugar obvio para dividir una ventana.
Si la ventana m aneja más de un evento del negocio tal vez pueda ser dividida en venta
nas separadas. Puede ser que la ventana m aneje diferentes perm utaciones del mismo evento de
negocios. Revise para ver si todos los datos se necesitan para una transacción normal. Los da
tos que se requieren para el evento de excepción, en vez de los norm ales, pueden separarse en
otra ventana.
S¡ el usuario realm ente debe tener todos los datos residentes en pantalla, tal vez puedan
ser divididos en dos ventanas sincronizadas, pero traslapantes, con los datos más im portantes
ubicados en la ventana superior. Un uso cauto de lincas gráficas también puede crear marcos
alrededor de grupos de datos en una ventana atestada. Esto reduce la cantidad de elem entos que
debe percibir el ojo a prim era vista (figura 10-16).
Los artistas y fotógrafos también aprendieron a través de los años que el color, al igual
que la com posición, puede dirigir la vista. Ningún color llam a m ás la atención que el rojo° Hs
probable que una ventana con una diversidad de iconos coloreados repartidos por todos lados
cree tensión visual. Use el color en form a económ ica y sensata, y reserve los iconos para las
áreas en donde realm ente se necesitan pistas visuales.
- ; S a le s R ep íesen tative M aintenanci;
■■—í-
. . . . . .. ....
¡' -■*' 'Ig í¿ ^Ía ¡6 -5 5 5 í4 3 2 ^'Éí il s^K' pf ii lm

tn '<-®TteBest ................f i g J . ^ g Í Í Í g p S
'! ; .=■,. - y ■■, V..v^L* Ücnes &Jone» á | 2 -5 * * P Í '
^ " - - i i r r 1” ".r^'77Ts''T[;^"'V^7’'^rT^.7;^5ir’í ^fo*' • 4.r-í.ft’>!.■$-•¿■K■-'•3"'".' ’•'^,Ll •' ; ‘l?
F igu ra 10-16. Soluciones posibles para m ejorar la disposición.
Algunas de las ventanas m ás locas que he encontrado son aquellas en donde el progra
mador ha tratado de usar todas las características disponibles en la herram ienta GUI. Aunque
esto puede proporcionar una experiencia de aprendizaje fascinante para el programador, puede
crear pesadillas estéticas y navegacionales para el usuario. E l diseñador GUI necesita poner lí
mites a la cantidad de características diferentes que coloca en una aplicación, y usarlas consis
tentem ente.
Indulgencia
Un buen diseño de interfaz debe m otivar la exploración. El usuario debe sentirse libre para hus
m ear por la aplicación y dar vistazos rápidos en las diversas ventanas y características, hslo es
bastante fácil de lograr, pero requiere un puco más de trabajo que el que están acostum brados
a reali 7iir la m ayoría de diseñadores de aplicaciones de negocios.
El nivel de acceso del usuario está gobernado, por lo general, por un conjunto de tablas
en el servidor. Cuando la aplicación está ejecutando se consultan estas tablas para determ inar
si un usuario esLá autorizado para realizar diversas acciones, tal com o colocar un pedido o crear
una factura. Una forma para que se cum plan estas reglas es perm itir que el usuario intente una
acción y lueao rechazarla u aceptarla cuando la transacción es enviada al servidor de base de
datos. A unque este esquem a es fácil de programar, es muy poco cortes para el pobre usuario
que es castigado mucho después de que ha iniciado la acción.
287
esquem a es leer las tablas de autorización de usuario cuando el usuario se

^ i s t i a en el sistem a y usarlas para activar o desactivar conceptos en el m enú principal duran
■ r ' ; * "* « a » » ■» * « « . a a q u e t a p a , L * ,a
y es u n S k a f S de m ^ ' ^ 01, 68 1” tran esU) perfectam ente aceptable
. , p"L , d 1 d maneJ.aT- La unlca desventaja es que desm otiva la exploración de áreas
que están hiera de la descripción de trabajo actual del usuario. R ecuerde que el em pleado de
f T H - l í t o “ >« perm itir q„ « J
■ ana, pero sim plem ente desactivando los botones y conceptos de menú para impedirles oue
i e alie en acciones en ventanas en donde no tienen autorización. A ^ u n o s Z 2 ^ n ^ Z
apartaran de los cam inos trillados, pero otros explorarán el sistem a com pleto v aprenderán m u
cho mas acerca del negocio y las actividades que se realizan alrededor de elfos
Siempre se querrá dar al usuario una forma de salida agradable por si decide abandonar
“ L“ « * “ * 10- 17 « l « « c M M o f d . n Z m . ¡ n 5 ú t í,e
Caracterísiica I Descripción
La c a ra c te rís t ic a : : ^ ; L , , £:a , e s tá , p o r 'lo g e n e ra l, c o lo c a d a b a j í ^ T

m e n u ..r. , or . E n la s a p lic a c io n e s do n e g o c io s se u s a c o m ú n m e n -
| te para regresar un s o lo c a m p o a su va lo r o r ig in a l, s ie m p re y c u a n
do c l u s u a r io n o h a y a g u a rd a d o su tra b a jo . E s m u y a g ra d a b le te n e r
| I .t .v .'.d c e r a m v e l c a m p o , p o ro n o e s u n a c a ra c te rís t ic a o b lig a to ria
____ ____ ____ _|__ ^ ap lica cio n es de negocios.
; S e C i .i n c i - la r en v e n t a n a s d e re s p u e s ta en d o n d e e l s is t e m a "
j p re g u n ta a l u s u a rio si s e d e b e c o n t in u a r co n la a c c ió n s e le c c io n a d a
, O a b a n d o n a rla , c a r : : - , ; - se c o m b in a , p o r lo g e n e ra l, con u n botón
n eS 'i ;T Y ; 'C:' E s '/íta[ q u c s e a ,o s u s u a r io s u n a

| o p o rtu n id a d para cancelar estos tip o s efe acciones.
Í S nv ' = =
gom ando ■'■^s e u sa p a ra a b a n d o n a r u n a a p lic a c ió n
:ía l ¡ y c o m p le ta . C u a n d o el u s u a rio h a c e c lic en C c - v a r o : el s is t e
m a s ie m p re d e b e re v is a r p a ra v e r si h a y c a m b io s no g u a rd a d o s S I
h a y c a m b io s q u e no h a n sid o g u a rd a d o s el s is te m a d eb o p re q u n ta r-
| le al u s u a r io s, d e s e a g u a rd a r su tra b a jo a m e s de c e rra r la v e n ta n a
j___ n se Jrr de la a p lic a c ió n .
C
..,o n firm
. a ra n ¡ El com a n d o ;'¡ :■'i.-v
.... se
btl u w n
Uhtí an m
para q urit-
ita rr n ^ in r ^de im u
datos base ^de datos
.
1 - U1^ a i 1 °n fo rm a perm anente. Cuando el usuario hace che en * : í .t e’l
I sistem a siem pre debe p re g u n ta r "¿Está usted se g u ro ? " y p e rm itir
le c o n tin u a r o cancelar la e lim in a ción .
exDJiciLo
expncuo
I • M
CatlaMacción --datos debe ser
de C i;í í:5;i ■' en la basn de
Via. Nunca auardta Hatnc
cci explícitaLdyyUU-
ob-
vía. Nunca gu a rd e datos con un co m a n d o .A.-pp; ¡.ir u "•* Ei usuario
■ sie m pre debe estar conséjenlo de que está actualizando el registro
| e m p re sa ria l perm anente.
^ i s u r a 10-17. C aracterísticas de una GDI indulgente.

E l Guardar explícito es una consideración im portante. M uchas herram ienta GUI perm i
ten, o hasta m otivan, que se realicen cam bios a la base de datos cada vez que se cam bia el en
foque de un registro. A l usuario se !e perm ite actualizar una v en tara tipo hoja de cálculo, y
cada vez que el cursor abandona un renglón, ese renglón es actualizado perm anentem ente sin
notificación explícita ai usuario. Esto viola el concepto de un Guardar explícito.
L a técnica puede ser útil para reducir la cantidad de teclazos de una aplicación de escri
torio, pero deja a la base de datos totalm ente abierta a los errores en una aplicación em presa
rial seria. Falla ante lo que llamo “la prueba de ham burguesa con queso” . E l usuario debe
ser capaz de dejar caer una ham burguesa con queso en su teclado en cualquier m om ento y
tener capacidad de recuperación. Si se deja caer una ham burguesa con queso en un a ventana
actúa üzable que escribe (ejecuta un cornrmt) el trabajo en cada cam bio de enfoque de renglón,
no se tiene idea de qué tantos datos se han dañado perm an en teniente,
LJn m étodo mucho más perm isivo es permitir que el usuario actualice tantos elem entos de
la ventana com o quiera y luego hacer que guarde su trabajo explícitam ente, realizando los cam
bios a todos los renglones de una sola vez. Esto le perm ite cerrar la ventana sin guardar en
caso de que se arrepienta en cualquier momento.
Conciencia de las fortalezas y limitaciones humanas
U na de las consideraciones más im portantes a recordar es que las com putadoras están diseña
das para ser usadas por gente real, y siendo personas todos tenemos lim itaciones. Hl reconocer
es más fácil ue recordar. Es m ucho m ás fácil reconocer u na pista visual o com ando que el me-
m orizar cóm o se debe teclear. Por esta razón, la línea de com ando es una cosa del pasado. La
línea de com ando de la pantalla verde forzó a los usuarios a m em orizar docenas de com andos
crípticos y códigos m nem ónicos para usar el sistem a en efectivam ente. En un a interfaz gráfica
de usuario no se requiere tal m em orización. Cada com ando o acción posible debe estar dispo
nible ante el usuario por m edio de un botón, elem ento de menú o icono. L a m icroayuda, la ayu
da en línea y el uso efectivo de la barra de estado pueden servir para ayudar al usuario a
navegar por el sistem a sin tener que m em orizar códigos de acción.
También se debe respetar el lím ite hrair hum ano. H rair es una palabra usada por R obert
A dam s en Watership D o\vn]0 para describir la m anera en que cuentan los conejos: uno, dos,
tres, cuatro, hrair. C ualquier cantidad superior a cuatro es dem asiado grande p ara qu e la pue
da im aginar nn conejo. Sucede que tam bién Jos hum anos tienen un lím ite hrair. Los estudios
han colocado el lím ite hrair hum ano alrededor de siete, m ás m enos do s." Sucede que la m en
te hum ana contiene cerca de siete “registros” en donde puede m anejar conceptos o temas dis
pares. Para m eter otro se debe sacar tem poralm ente a otro. U na aplicación con seis conceptos
en la baria de m enú será mucho m ás fácil de usar que una con once elem entos. U na ventana
con cinco botones de com ando será m ucho más fácil de entender qu e una con trece.12
10 A ría im . 1974
1! Dependiendo de si se está teniendo un buen día hrair o un mal día hrair,

1- Hasta ahora, el premio para la transgresión del límite hrair pertenece a un proyecto que colocó veintidós bo
tones de comando en una sola ventana, junto con docenas de campos de captura. La ventana requirió al m e
nos dos conjuntos de barras de desplazamiento horizontales y verticales para poder ver esta obra de arte
COHESIÓN DE VENTANAS 289
Kn form a similar, la cantidad de eventos de negocios que pueden ser reconocidos por una
sola ventana también debe respetar cl lím ite hrair humano. Conform e se increm enta la canti
dad de temas diferentes m anejados por una ventana, dism inuye la habilidad de la persona p a
ra usarla en forma efectiva. La com plejidad de la ventana tam bién es inversam ente
proporcional a la habilidad del program ador para m antener y probar la aplicación a lo largo del
tiempo. En la siguiente sección se exam ina ía forma en que el diseñador aglutina los eventos
de negocios en una aplicación, im pacta tanto la facilidad de uso eom o el m antenim iento del
sistema.
COHESIÓN DE VENTANAS
En 1979, Larry Constantine y Ed Yourdon publicaron su libro Slructured D esign, en el que es
tablecieron los criterios para los m ódulos de program a bien diseñados.n Prom ovieron especí
ficamente la idea de que los m ódulos que ejecutan una idea altam ente cohesiva tienden a ser
más fáciles de com prender y más baratos de mantener a lo largo del tiem po, que los m ódulos
que contienen m uchas ideas diferentes. También descubrieron que una m ayor cohesión interna
tiende a reducir la com unicación o acoplam iento entre m ódulos. La alta cohesión y el bajo aco
plam iento llegaron a ser la m eta para los módulos bien diseñados. Esto tam bién increm entó la
probabilidad de la reutilización de código.
Estos conceptos todavía son aplicables en el am biente orientado a objetos de una inter
faz de ventanas. H e descubierto cn mi experiencia que la cohesión de una ventana puede afec
tar dram áticam ente la habilidad del usuario para com prenderla y usarla, y la habilidad del
program ador para mantenerla. La cohesión de ventanas puede ser evaluada por la cantidad y
tipo de eventos de negocios que son reconocidos y manejados dentro de una ventana o juego
de ventanas cn una aplicación.
Con un gran reconocim iento a mis predecesores, he adaptado los térm inos originales
de C onstantine sobre la cohesión de m ódulos para describir cl nivel de cohesión de un a v en
tana. Los niveles de cohesión en orden aproxim ado desde el m ás deseable hasta el m enos d e
seable son:
Funcional
Secuencial
C om unic ación ai
Procedural
Tem poral
Lógico
Coinciden tal.
l * Yourdon, Constantine, 1979

Cohesión funcional
U na ventana o conjunto de ventanas función alíñenle cohesivas manejar? un evento a nivel n e

gocio. Tomemos un ejemplo de un sistem a de punto de venta. Tidy Tiin's H ousehold Supply
Com pany vende artículos de lim pieza en sus instalaciones y por m edio de una cam paña agre
siva de correo directo. Cuando un cliente com pra artículos en su tienda, el em pleado real i/a los
siguientes eventos:
El em pleado registra/actualiza el nom bre y dirección del cliente

El em pleado coloca el pedido del cliente.
El cliente puede pagar en efectivo o eon cheque, o lo puede cargar a su tarjeta para que
se le cobre después. Dependiendo del método del pago del cliente, los eventos finales son:
h l em pleado aplica el pago de efectivo/cheque al pedido, o

E l em pleado carga el pedido a la cuenta del cliente.
lla y muchas formas para diseñar un conjunto de ventanas para manejar esas transaccio
nes. Usando el concepto de cohesión funcional podríam os diseñar una ventana para cada uno
de los eventos, listo probablem ente daría com o resultado cuatro ventanas, una para m antener
cl nom bre y dirección del cliente, otra para capturar el pedido, una tercera que sirve com o una
ventana de recepción de efectivo de punto de venta y una cuarta para capturar la inform ación
de cargo a la cuenta del cliente (figura 10-18).
La ventaja de las ventanas funcionalmente cohesivas es que se tienen ventanas eficien
tes y especializadas que son m enos com plejas y, por lo tanto, más fáciles de usar, Hl código in
terno existe para ejecutar una sola idea, lo que hace que sea más fácil de com prender y más
fácil de mantener. Ll potencial de la reutilizaeión también se increm enta en gran medida. Ln
nuestro ejemplo, m ediante la división de las funciones de la ventana de recepción y de la de
cargo a la cuenta en ventanas separadas, estas ventanas pueden ser icutilizadas con muy poco
esfuerzo en virtualm ente cualquier sistem a de punto de venta. La ventana de mantenimiento
del cliente puede ser re útil izada en cualquier otra parte del negocio en donde puedan necesitar
ser corregidos el nom bre y dirección del cliente.
La desventaja de la cohesión funcional es que frecuentem ente increm enta la cantidad de
ventanas de la interíaz. Esto requiere que el usuario navegue entre ventanas para realizar el
conjunto com pleto de tareas.
Se debe tener cuidado de establecer que, debido a que la definición de un evento a nivel
de negocios deja m ucha amplitud, una ventana puede m anejar varias perm utaciones muy rela
cionadas del mismo evento de negocios y todavía ser considerada com o que se apega a la co
hesión funcional. Por ejemplo, cl evento el em pleado registra/actualiza el nombre v dirección
del cliente podría incluir funciones para la creación de un nuevo cliente y la actualización de
algún Chente existente. Yo calificaría esto cotilo un conjunto de actividades funcionalm ente co
hesivas. aunque se podría argum entar que podrían estar establecidas com o eventos separados.
No quiero que ningún lector llegue a la conclusión de que debido a que las ventanas funcional
mente cohesivas con "buenas’', uno debe diseñar ventanas separadas para crear, leer, actualizar
y elim inar todo. D ada la tecnología actual, esto sería excesivo.
! C u s ió m e i M a in l e n a n e e
Figura 10-18. Cuatro ventanas funcionalmentc cohesivas.
Cohesión secuencia!
Lna ventana sccuencíalmcnte cohesiva es aquella cn donde los eventos están ai'rapados debido
a que suceden cn secuencia, hl primer evenlo sucedc como predecesor del siguiente, y ese del si
guiente, y así sucesivamente. Regresando a nuestro ejemplo de Tidy Tim's Household Supply
Company, tomemos los mismos eventos de punto de venta y agrupémoslos en una sola ventana.
El em pleado registra/actualiza cl nom bre y dirección del cliente

h l em pleado coloca el pedido del cliente
E l em pleado aplica el pago de efectivo/cheque al pedido
o
h l em pleado carga el pedido a la cuenta del cliente.
Primero, el em pleado se asegura de que el nombre y dirección del cliente estén actualiza
dos. luego captura el pedido y después aplica el pago o el cargo. M ediante la agrupación de e&-
Í ü s eventos en una sola ventana obtendríamos los resultados que se muestran e n la figura 10-19.
292 Capítulo 10 ! CONCEPTOS DE INTERFAZ GRÁFICA DE USUARIO
Figura 10-19. Vina ve rilan a secuencia! mente cohesiva.
La recom pensa de la cohesión secuencia! es que se m apea muy de cerca con el ñ ujo de
trabajo manual. L a aplicación conserva el tecleado de navegación poniendo todos los eventos
relacionados en una sola ventana. La cohesión secucncial es adecuada para las ventanas que
m anejan tareas altam ente repetitivas en donde la velocidad de captura y la econom ía de teclea
do son los principales vectores de calidad.
L a desventaja de este tipo de ventana es que ahora es una m ezcla muy com pleja de có
digo no relacionado. La parte superior de la ventana debe manejar la creación de nuevos clien
tes o la recuperación y actualización de los existentes. La sección media crea nuevos pedidos
y la parte inferior aplica cl pago o captura la inform ación de la cuenta a donde hay que hacer
el cargo. El diseñador debe decidir si la acción de G uardar se aplica tanto al cliente y al pedi
do o si se requieren dos com andos Guardar,
L a ventana es m ucho más com pleja de usar y m ucho más costosa de mantener. E stética
m ente la ventana está m ucho m ás am ontonada, y es poco probable que cualquier parte de ella
sea reulilizable sin que necesite algún grado de cirugía reconstructiva. La cohesión secucncial
supone que la secuencia de eventos siem pre es ordenada. Cuando suceden excepciones el d i
señador debe proporcionar una ventana diferente o el usuario estará forzado a hacer la secuen
cia normal que iia sido codificada directam ente en el sistema.
Cohesión comunicativa
Una ventana com unicativam ente cohesiva es aquella en la que los eventos han sido agregados
porque afectan al m ismo objeto. Se podría tener una ventana función al m ente cohesiva o hasta
una seeucneialm ente cohesiva en donde todos los eventos afecten al mismo objeto. La diferen
cia con la cohesión com unicativa es que el com partir de datos es la razón principal para agru
par los eventos.
La recom pensa de tener cohesión com unicativa es que los eventos com parten el mismo
código de acceso de datos y las m ism as reglas del negocio basadas en cliente. Dichas ventanas
tam bién se adaptan muy bien en el paradigm a objeto-acción de seleccionar un objeto y luego
desplegar una selección de acciones ante un am plio público de usuarios.
Hl problem a con la cohesión com unicativa es que las ventanas frecuentem ente sirven a
más de un amo. Varios grupos de usuarios diferentes, responsables de diferentes aspectos del
m ismo objeto, son forzados a com partir una m isma aplicación que trata de satisfacer a todas
las partes. Esto da com o resultado ventanas muy com plejas en las que ningún usuario tiene la
autoridad para hacer todo. Para cada usuario de la aplicación puede ser irrelevante un subeon-
junto de los cam pos, y algunas partes de los botones o conceptos de menú están siempre
desactivados.
L a figura 10-20 m uestra una ventana de selección de pedido (Order Selection) eon boto
nes activados para los eventos que puede ejecutar un vendedor.
L a i i gura 10-21 m uestra la m ism a ventana activada para un gerente de crédito. Interna
m ente el program a debe llevar cuenta de las diversas funciones, y m anejar individualm ente la
activación de botones y conceptos de m enú para varios grupos de autorización de usuarios.
Cohesión procedural
U na ventana proceduralm ente cohesiva organiza las tarcas de acuerdo a la descripción de tra
bajo de un usuario particular. Los eventos son agregados para dar al usuario todo lo que nece
sita en una ventana.
Im agine una ventana en la cual un usuario puede iniciar los siguientes eventos:
fül coordinador de producción aprueba un pedido

Hl coordinador de producción program a el transporte para el pedido
lil coordinador de producción transfiere el pedido de una m áquina a otra
El coordinador de producción abre una aplicación de m ensaje telefónico
Los prim eros tres eventos están altam ente relacionados. Tomados solos no pasan la prue
ba para cohesión funcional y probablem ente cohesión secuencial, debido a que ni los arreglos
para el transporte ni la calendarización de máquinas necesitan suceder en secuencia. Si la ven
tana solam ente m anejara los primeros tres eventos, probablem ente calificaría para cohesión co
m unicativa, debido a que cada evento actualiza algún aspecto del pedido.
El cuarto evento sim plem ente no cuadra. La única razón por la que está en la ventana es
que el coordinador de producción tam bién hace el papel de recepcionista en esta pequeña ofi
cina, y el diseñador decidió alionar un teclazo perm itiendo que el usuario abriera la aplicación
de m ensajes telefónicos desde la ventana que utiliza más frecuentem ente.
¡ D i d e i S e íe c tio n - S a íe s P e í son M sü E S
1101 iffira/íi/ffi ^ |o ^ Ñ n ^ b S 3 ^ S Í |s ^ ¥ > V > .yk"- ■

'
;> fi1r¡:L::%J.;Sii.iíí : f:WfcT*I'.0 f Xii'í f S 'S i - J i j f « í i ,■.
ÍSfíSMÍ ÍS ÍSÜV^'WSrSmSÍ Í B M jK tó p 'f f e i ! ííSiSíMf!
........ .■?.:r'-:-^LqJ;,;r|'r'l|,^','‘^jJ'Ti jy
101 9931 Actvie Gev?iage ¡i Flocl-et Fue!, kic. 12/21/96 527.50 TetiUiiivé Requestecf
j 101 ‘9932 ÍJoe Joe's Pizza 12/21/36 : BS.ffijConfirmed ¡Requested
i 'iqtT !9933 ¡TheSlugPíBffiM jrill 12/21/36 465.15ÍShipped lAuthorijed
101 9934 Ifetrh Department Store 1 2 /2 2 /* 26,450.1 ¿¡Füted ’Authorized
. , ,
3935 _|The Ubby Shoppe 12/22/96 1,12£.8E(Back-0 fdered (Requeíted
i 101 J
E 101”" 9336 ¡Washington Plaza Assoeraibrt 12 / 22/se 16.21 [Cancelad ¡Caneced
= 101 ;3937 'The Metro Cafe 12/22/% _ 654.7EjConfirmed iRequested
; 101 9938 ¡Acmé Beverage & Rocket Fue!, Inc. 12/22/36... 991,21¡Ter¡tative IRequested
F igu ra 10-20. L na ventana com unicativam ente cohesiva activada para un vendedor.
! O id e t S e tc c tío n C fedtf M a n a y e t
''Mmaawitssâit *i-? í*«í^j«-s?¡>its««Kw»«an»iiHa*srt»«M

L-.. IJJI.-!r fi-ijí.UBif;!■; ¿ T - i ; : r v i í m ¿ c ✓- v s '•-<: * w « / f a n e r ' . - . * * ¿ > ¿ 5 ^*^K,>M<*;-íj34l&i^:#in4fc*-•■wggax-jxjj&yr.tí:Viga3^S:-¿¿fr/AiLaA¿Ja¿-«:
Figura 10-21. L a m ism a ventana activada para un gerente de crédito.
La cohesión procedural com ienza a llevarnos hacia terrenos peligrosos. Los usuarios que
están acostum brados a las viejas pantallas verdes frecuentem ente presionarán al equipo de pro
yecto para m antener el mí m ero de ventanas “al m ínim o posible” .14 El intento de “tener todn en
14 Esta situación pide un entrenamiento GUI inmediato para la comunidad de usuarios, a fin de eiiininar el fac
tor de miedo de su entrada al diseño.
COHESIÓN DE VENTANAS
295
un solo lugar’ llevado a una sola ventana puede conducir a una cohesión sorprendenIem ente
extraña de temas no relacionados. Esto da com o resultado ventana* que son com plejas, atibo
rradas, lentas en responder y extrem adam ente sensibles a los cambios organi/acionales dentro
del negocio.
Una m ejor Turma para lograr “m antener todo en un solo lugar” para los usuarios, es po
ner juntas a las ventanas en un grupo funcional, secuencial o hasta com unicativam ente cohesi
vas en un menú personalizado. Bajo este escenario, las ventanas individuales serán menos
com plejas, más fáciles de reutilizar y tendrán m ayores oportunidades de resistir los cambios en
la descripción del puesto del usuario. Es mucho m ás fácil cam biar la estructura de menú de las
aplicaciones que dividir ventanas individuales.
Cohesión temporal
L a cohesion tem poral sucede cuando los eventos están agrupados en una ventana sim plem en
te porque suceden al mismo tiempo. Por ejemplo:
Se registra en el sistem a em presarial

R evisa el correo electrónico
Im prim e cl reporte de ventas del día anterior.
El desarrollador puso estas actividades en una sola ventana por que son “cosas que cl
usuario hace cuando llega en la m añana”. El hilo que une estas tareas es extrem adam ente d é
bil. La ventana también podría incluir un botón que solicitara un café en el expendio local de
la recepción.
La cohesión tem poral es rara. Por lo general aparece en sistem as de negocios sólo para
iniciar actividades de contabilidad de cierre de mes, y están relacionadas sólo porque se nece
sita que sucedan cu un momento específico. Estas ventanas tam bién son casi imposibles de
reu tili/ar y existen para la conveniencia de un pequeño grupo de usuarios en un m om ento en
particular.
Cohesión lógica
La cohesión lógica sucede cuando los eventos están agrupados para com partir el mismo códi
go. La figura 10-22 m uestra una ventana de cnterios de selección para un reporte de propósi
to general. La ventana contiene casi todos los cam pos que podría llegar a necesitar un usuario
para dividir y repartir los datos para diversos reportes. El usuario indica primero el reporte que
desea entre una gran lista de reportes disponibles. Los criterios de selección le perm iten estre
char el conjunto de resultados antes de iniciar el trabajo de repone. El propósito de la ventana
es prevenir la proliferación de ventanas de selección de reporte sim ilares por toda la aplicación,
y se pretende que reduzca el efecto de propagación de onda de los cambios que puedan afec
tar varias ventanas,
Hl problem a en este ejemplo es que 110 todos los cam pos de criterios de selección se apli
can a todos los reportes. A quellos que son irrelevantes son sim plem ente descartados por el pro
grama. Si el diseñador encuentra que esto es inaceptable, la aplicación tendrá que manejar
cuáles cam pos se aplican activando y desactivando las capacidades de actualización para cada
reporte que use la ventana de criterios de selección.
F igura 10-22, Cohesión lógica: una ventana de selección de reportes

de propósito general.
La cohesión lógica puede crear com portam iento heterodoxo en la interfaz y molestos
problem as de m anteoim íento. El program ador de m antenim iento deberá evaluar constante
mente el efecto de cualquier cam bio solicitado contra cada uno de los eventos que es m aneja
do por la ventana para asegurarse que el cam bio no cree resultados indeseables debido al
código com partido. En m uchos casos, esta com plejidad adicional niega el beneficio pretendi
do de la reducción del efecto de propagación de onda. Frecuentem ente es más fácil hacer cam
bios claros y simples en más de un lugar que desenm arañar y volver a probar una m araña de
código com plejo.
Cohesión coincidental
A unque las dem ás medidas de cohesión tienen al m enos algún objetivo de diseño discem ible,
la cohesión coincidental es sim plem ente caprichosa. Cualquier relación que aquí se encuentre
entre eventos en una ventana coincidcntalm cnte cohesiva existe solam ente en la mente dcl pro
gram ador que la creó.
A unque la cohesión coincidental es afortunadam ente rara en los sistemas de negocios,

no es difícil de encontrarla en Internet. Tomemos un ejemplo de nuestros am igos de Tidy Tim's
H ousehold Cleaníng Supply Company. Sucede que el sobrino de Tidy Tim se está graduando
en ciencias de la com putación en cl colegio de la com unidad local y diseñó una página local
para su tío com o parte de sus prácticas de verano. La figura 10-23 m uestra la disposición de la
página de inicio de Tidy Tim.
TIDY TIM'S
w pM epAG E . .
NEW Ír«(íüets! Tips from TIM
■ : ■Sports : Weather
Figura 10-23. Cohesión coincidental: la página de inicio de Tidy Tim.
Los prim eros dos botones, New Products y Tips from Tim son razonables. Los otros dos,
Sports y W eather están incluidos solam ente debido a que el program ador pensó que sería con
veniente perm itir a los usuarios saltar a alguno de sus sitios Web favoritos. La cohesión resul
tante puede ser resum ida eom o “cosas que el sobrino de Tim pensó que eran interesantes''.
El sobrino de Tim también ha violado un principio crucial en el diseño de páginas de ini
cio. L a página em presarial equivale al anuncio luminoso de los establecim ientos com erciales.
Se quiere que sea atractiva y fácil de acceder, pero no se debe querer que motive a la gente a
que la abandone. El m ensaje com ercial de Internet de Tim ha sido fatalm ente com prom etido al
nivel de un absurdo tal com o, ‘'Pruebe nuestra nueva cera de p iso s jijfy, ¿qué hay acerca de
los Yankees ? ¿ Cree usted que lloverá1}".
Valorando los niveles de cohesión
Cualquier aplicación em presarial grande va a tener una mezcla saludable de niveles de cohe
sión entre las diversas ventanas. La mayoría de las ventanas en una aplicación de negocios bien
diseñada caerán en los tres niveles superiores de cohesión. La cohesión funcional produce las
mejores ventanas reutilizables, com prensibles y mantenibles de todas, pero daría com o resul
tado dem asiadas ventanas si se usara exclusivam ente. La cohesión secuencia! es un m étodo ex
celente para diseñar ventanas en donde el usuario ejecuta una serie de tareas regularm ente. La
cohesión com unicaeional hace un buen trabajo al m antener cl acceso a los datos y las reglas
del negocio visualm ente evidentes en un solo lugar, pero increm enta la com plejidad del m ane
jo de la activación y desactivación de la interfaz.
Las ventanas con cohesión proccdural engendran d riesgo adicional de ser inflexibles
ante los cambios de la descripción dcl puesto del usuario. Esto 110 hace que lo proccdural sea
malo por sí mismo. El dcsarroilador puede estar bajo muy fuertes presiones de los usuarios p a
ra. usar cohesión proccdural. Aníes de agregar eventos muy poeo relacionados con base en la
descripción del puesto del usuario, considere cuidadosam ente las consecuencias tanto para el
usuario com o para el program ador de m antenim iento de la com plejidad resultante.
Los dos siguientes niveles de cohesión tienen utilidad lim itada. La cohesión tem poral es
adecuada para ventanas que inician rutinas de cierre de mes o tareas similares relacionadas con
el cliente. Para otras áreas dcl sistem a debe evitarse. A unque la cohesión lógica se inicia
con la m ejor intención de com partir código, por lo general da com o resultado un com porta
miento problem ático de la interfaz y term ina siendo más m olesto que lo que vale. Una venta
na lógicam ente cohesiva probablem ente deberá ser rediseñada hacia varias ventanas, donde
cada una de d ía s tenga cohesión de un m ayor n iv d .
Kl últim o nivel, la cohesión incidental, no tiene cabida en una aplicación de n ego
cios seria.
RESUMEN
Este capítulo trata de establecer términos y definiciones para los aspectos m ás esotéricos del
diseño de interfaz de usuario, Hl propósito es proporcionar algunos lineam ientos contra los
cuales evaluar las diversas alternativas con las que se enfrentará com o diseñador.
La siguiente v e / que esté probando una aplicación y no le guste la disposición de venta
nas de sus com pañeros, ya no tiene que volver a decir “¡no m e gusta porque no es la manera
en que ye lo haría!”. En vez de ello puede proporcionar un com entario m ás constructivo tal co
mo, “la ventana, aunque es estéticam ente agradable, viola los conceptos fundam entales de
claridad e indulgencia, y parece ser proceduralm ente cohesiva. Si se elim inan los códigos
crípticos, se añade un cuadro de m ensaje de confirm ación y se pasa este evento a una segun
da ventana, se tendrá una ventana secuencialm em e cohesiva que es clara, indulgente y agra
dable a la vista”. (Después de lo cual el equipo del proyecto lo cargará en hombros
proclam ándolo el zar de todos los diseños de ventanas y le encargará la com postura de todas
las disposiciones durante el siguiente fin de sem ana festivo.)
Los elem entos de un buen diseño de interfaz siem pre han estado con nosotros, basta en
los días de la pantalla verde. I -a interfaz gráfica de usuario expande am pliam ente su conjun
to de herram ientas disponibles para el diseñador a fin cíe satisfacer las m etas de un sistema
am igable ai usuario. Al hacer la transición de un sistem a em presarial desde un am hiente de
pantalla verde a una GUI, se crea la rara oportunidad de elim inar abreviaturas, códigos y p a
labras especiales que se han producido debido a las lim itaciones históricas de los sistem as an
tiguos.
En este capítulo se proporcionan varios criterios generalm ente aceptados para el buen
diseño de interfaces. Hl concepto de control de usuario establece que el sistem a siempre d e
be indicar cuando le ha quitado el control al usuario. La sensibilidad increm enta cl sentido de
control del usuario dando un acuse de recibo inm ediato para cada acción tom ada. La perso
nalización es útil en m uchos aspectos de la interfaz gráfica de usuario, pero debe ser cuida
dosam ente dism inuida cuando los usuarios están tecleando inform ación crítica del negocio.
RESUMEN 299
L a dirección soporta cl manejo de objetos. Los departam entos que sólo se dedicaban a
la captura de datos frecuentem ente fueron soluciones organización a les para ía falta de capaci
dades técnicas para la captura de la inform ación cn sus orígenes. La tecnología cliente/servi
dor m ueve la frontera del sistem a de inform ación más allá de la frontera del negocio. El
paradigm a objeto-acción reconoce que los eventos suceden en un patrón mucho más aleatorio
en el mundo real, y perm ite que los usuarios seleccionen elem entos antes de indicar la acción
o evento que quieren que se ejecute.
Las aplicaciones deben ser internam ente consistentes en su aspecto y sensación. También
deben ser consistentes con otras aplicaciones em paquetadas existentes en el escritorio del usua
rio. La consistencia requiere de estándares. A fortunadam ente están em ergiendo muchos están
dares de facto en la industria, pero cada proyecto necesita definir los asuntos de estándares
antes de tratar de construir la interfaz.
La claridad se logra m ediante el lenguaje del m undo real y la elim inación de com andos
crípticos y códigos m nemónicos. Las disposiciones de ventana que son estéticam ente agrada
bles atraen la vista a la inform ación que es más importante. E l agrupam iento espacial y el uso
cuidadoso de líneas y marcos puede separar ventanas que son densas en contenido en bloques
agradables de datos que pueden ser mejor percibidos por el ojo humano.
Una buena interfa/ proporciona retroalimentución am able e informativa. L a exploración
se motiva haciendo que ei sistem a sea indulgente. Siempre dé a los usuarios una forma para
abandonar su trabajo si es que no lo han guardado explícitam ente.
Pero lo principal, es que una buena interfaz está diseñada para las personas, quienes tie
nen determ inadas fortalezas y limitaciones humanas básicas. El reconocerlo es m ás fácil que
recordarlo. No haga que los usuarios tengan que m em orizar el sistema. M antenga la cantidad
de ideas dispares en una ventana dentro del lím ite hrair humano. La habilidad de la mente p a
ra asim ilar lemas diferentes se degrada significativam ente cuando !a cantidad de ideas es m a
yor que siete, más o m enos dos.
La cantidad de eventos diferentes m anejados por una ventana afecta la habilidad del
usuario para com prender la interfaz y la habilidad del program ador para dar m antenim iento a
la ventana conform e el sistem a se mejora. Los niveles de cohesión, definidos en principio p a
ra calificar el diseño de m ódulos de program a internos, pueden adaptarse para calificar ia adi
ción de eventos en las ventanas, s
L a cohesión funcional lim ita a la ventana a que maneje solam ente un evento del nego
cio. La cohesión secuencial agrupa eventos predecesores/sucesores en una ventana. La cohe
sión com unicativa agrupa eventos que se com unican con el mismo objeto. La cohesión
procedural agrega eventos en una ventana debido a que son iniciados por el mismo usuario co
mo parte de su descripción de puesto.
La cohesión tem poral agrupa eventos que en sí no están relacionados, pero que suceden
al mismo tiempo. La cohesión lógica pone juntos en la interfaz, a los eventos que com parten
código. Por últim o, la cohesión incidental es un térm ino am able para algo absurdo. Uno sólo
puede tratar de adivinar qué estaba pensando el desarrollador cuando codificó una ventana
coinciden! aliñen te cohesiva.
E ste capítulo pone las bases de los principios generales de diseño de interfaz. El si
guiente capítulo proporciona técnicas específicas para la creación de la especificación de di
seño externo.
EJERCICIOS
1. ¿C uándo puede ser m ás adecuado un diseño acción-objeto que una G U I objeto-ac
ción?
2. A lgunas herram ientas GUI prom ueven el Guardar en un cam bio de foco de ren
glón. ¿Q ué conceptos transgreden esto?
3. N elson fue contratado para crear un sistem a de seguim iento de pedidos de com pra
para una tienda de artículos de oticina. Los usuarios estaban acostum brados a su
viejo sistem a m ainfram e, y le dijeron que m antuviera a un m ínim o la cantidad de
ventanas del nuevo sistem a. H aciéndoles caso, creó una ventana de selección de p e
dido de com pra y colocó 24 botones de com ando en ella (en dos renglones de 12
botones). C ada botón representa una acción que puede realizar el usuario sobre uno
o m ás pedidos de com pra seleccionados. ¿Puede nom brar al m enos un concepto
GUI que ha violado N elson?
4. ¿Puede adivinar cuál nivel de cohesión debe ser el de la ventana de selección de p e

dido de com pra de N elson?
RESPUESTAS
1. D urante actividades repetitivas, tales eom o la captura de datos continua, puede ser
m ás adecuado declarar un “m odo” , tal com o “m odo de actualización’7, y capturar
transacción tras transacción, hin su m ayor parte, en vez de ello las personas se es
tán acostum brando cada vez m ás al paradigm a objeto-acción, y conform e los siste
mas de inform ación em pujan cada vez más las fronteras del negocio, la naturaleza
aleatoria de los eventos del negocio tiende a favorecer la selección de un objeto p ri
mero y luego la aplicación de una variedad de acciones válidas para él.
2. Los guardados subrepticios (cuando la aplicación guarda el trabajo sin que el u su a

rio ordene explícitam ente el Guardar) transgrede los conceptos GUI de indulgen
cia, control de usuario y consistencia. La interfaz no es indulgente debido a que es
difícil deshacer una transacción que tal vez no se sepa que se guardó. Q uita el con
trol del usuario y realiza actualizaciones a la base de datos en una form a inconsis
tente con respecto a la m ayoría de aplicaciones G U I estándar.
3. Con 24 acciones disponibles eo una ventana N elson ha fallado en respetar la co n

ciencia de las fo rta leza s y lim itaciones hum anas. E1 cerebro hum ano puede proce
sar siete, m ás o m enos dos, conceptos a la vez. E s probable que su ventana de
selección de pedido de com pra sea difícil de com prender para el usuario prom edio
sin m ucho entrenam iento y práctica. U na solución posible podría ser que N elson
agrupara acciones sim ilares bajo m enús en cascada para que la ventana tuviera m u
chas m enos acciones disponibles en el nivel superior. N elson debe determinar- cuá
les botones se oprim en m ás frecuentem ente y dejarlos en el nivel superior, y
agrupar com andos que se solicitan m enos frecuentem ente bajo un m enú en casca
da. Por ejem plo, cl botón N u e v o o A brir puede perm anecer en la ventana, pero los
RESPUESTAS 301
diversos reportes de fin de raes pueden agruparse y enlistarse bajo un solo botón o
elem ento de m enú Reportes.
4. Probablem ente es cohesión com unicativa, debido a que parece que N elson agrupó
todos ios eventos del negocio que afectan a los m ism os datos en una ventana, es
pecíficam ente, el pedido de com pra.
EL DISEÑO DE INTERFACES
EXTERNAS
INTRODUCCIÓN
El capítulo 11 trata sobre el diseño de la interfaz externa del sistema. Hl capítulo proporciona
tres conceptos valiosas. Hl primero es la disposición sugerida de la especificación de diseño ex
terna para la interíaz gráfica de usuario. Entre m ás grande sea el proyecto, m ás crítica será la
necesidad de un diseño detallado por exento, (Desgraciadamente, el código GUI no se autodo-
cumenta.) Este capítulo le da un formato a seguir para la docum entación del sistema y una p a
norám ica de la aplicación, navegación, disposición, descripciones y mi ni especificaciones de
ventanas y especificaciones a nivel campo. El segundo punto valioso importante de este capítu
lo es la sección sobre la diagramación de la navegación en las ventanas. D e todas las técnicas
de este libro esta es probablem ente la menos cara, y produce un rendim iento extrem adam ente
alto. Con unos pocos rectángulos y flechas usted y sus com pañeros pueden tener una discusión
sustancial sobre la m anera de navegar en la aplicación com pleja antes de tratar de codificarla.
303
304 Capítulo 11 / EL DISEÑO DE INTERFACES EXTERNAS
Finalm ente, el tercer punto de este capítulo es acerca de los id o s de la prueba de una interfaz
gráfica de usuario. Las pruebas adecuadas com ienzan con un huen plan de pruebas, y este se d e
riva de un diseño escrito detallado.
¿CÓMO SE DIFERENCIA EL DISEÑO EXTERNO DEL INTERNO?
E l diseño de un gran sistem a cliente/servidor puede ser muy com plejo. Para proporcionar es
tructura y orden al esfuerzo he escogido la división del diseño de la aplicación en dos catego
rías amplias. La prim era categoría es el diseño de la interfaz externa, que es el tem a de este
capítulo. La segunda categoría del diseño de la aplicación es la especificación de los com po
nentes internos, que se tratan en el siguiente capítulo.
FJ diseño de la interfaz externa especifica el aspecto, sensación y com portam iento de la
parte del sistem a que ve el usuario. Es un refinam iento del prototipo de interfaz que incluye
elem entos tales com o el tipo de ventana, navegación, especificación de botones y definición de
la unidad de trabajo adecuada para el usuario, til diseño externo del sistem a depende en gran
m edida de las convenciones de la industria para la tecnología de interfaz seleccionada.
En e! siguiente capítulo verem os que la estructura y las técnicas em pleadas para crear la
especificación de los com ponentes internos dependen en gran m edida del paradigm a y las ca
pacidades del lenguaje de destino. El diseño de com ponentes internos puede ser orientado a ob
jetos, basado en formas 4GL, 3G L o una mezcla de todo lo anterior. La estructura de la
especificación de diseño inlerna es el m odelo m ás vulnerable al cam bio conform e evolucionan
las herram ientas de desarrollo cliente/servidor.
¿POR QUÉ HACER UNA ESPECIFICACIÓN DE DISEÑO ESCRITA?
[.a especificación de diseño escrita sirve a varios propósitos. Proporciona un m étodo para do
cum entar y revisar las ideas con los com pañeros que es m ucho m ás rápido y más barato que la
codificación. Aun ia especificación de diseño más breve proporciona un gran avance hacia el
cum plim iento de estándares para la apariencia y sensación a lo largo de la aplicación, y es m u
cho más barato m odificar un m odelo que un sistem a parcialm ente term inado.
La disposición, descripción y diagram as de navegación de las ventanas son herram ien
tas excelentes para la validación de la propuesta de diseño con la com unidad de usuarios. La
m ayoría de los usuarios que ya se han familiarizado con sistemas GUI son m uy capaces de abs
traer el com portam iento de las páginas de un diseño externo breve y bien escrito.1
La especificación de diseño tam bién es una herram ienta de adm inistración poderosa.
Perm ite que la aplicación se divida entre varios program adores para su construcción a un nivel
de detalle que es m ucho m enor que la división requerida para lograr un diseño coherente. En
1 Muchos partidarios del RAI3 argumentan que los usuarios son incapaces de comprender un sistema a me
nos de que puedan operar un prototipo animado. Sólo he encontrado que esto es cierto con tos usuarios que
están comp le Lamente desacostumbrados a las GUIs o a las computadoras cn general. Se debe hacer un es
fuerzo para capacitar a las personas, en ve/ de elaborar una metodología de diseño completa para un míni
mo común denominador.
¿POR QUÉ HACER UNA ESPECIFICACIÓN DE DISEÑO ESCRITA? 305
este libro suponem os que la m ayoría de proyectos de sistemas de negocios grandes se diseña
rán y entregarán en fases. Kn el capítulo 6 vim os que la lista de eventos es una herram ienta útil
para determ inar la división del sistem a, en general, en unidades lógicas o aplicaciones. M e
diante la división de sistemas grandes en api icac iones separadas (tales com o captura de p ed i
dos, facturación, asignación de precias, pronósticos de ventas), el trabajo de diseño puede
asignársele a m ás de un diseñador. Cada diseñador puede concentrarse en su área lógica, y los
resultados de los diseños respectivos pueden ser revisados para asegurar un producto consis
tente con el sistem a completo.
Una vez que existe una especificación de diseño escrita, el esfuerzo de program ación
puede seguirse dividiendo, aun dentro de la m ism a aplicación, para asignarlo a más de un p ro
gram ador (figura 11-1). Con un diseño escrito se pueden asignar varios program adores para
que construyan ventanas específicas y sus funciones subyacentes dentro de la m ism a aplica
ción. El código se integra fácilmente, debido a que están trabajando a partir de una especifi
cación coherente. El resultado final es una entrega m ás rápida de un producto term inado de
alta calidad.
F igura 11-1. Un diseño de aplicación grande puede distribuirse entre vanos

programadores para ser codificado.
Sin especificación escrita, el desarrollador debe diseñar y codificar al mismo tiempo, for
zando al adm inistrador a dividir el esfuerzo de program ación en fragm entos más grandes. E s
to puede causar cuellos de botella serios, debido a que el diseño de la aplicación perm anece en
la cabeza del programador. Sin una especificación escrita, el adm inistrador es incapaz de aña
dir más program adores al equipo para agilizar la construcción en un punto en que se está aca
bando el tiempo del proyecto. Si el adm inistrador trata de dividir la carga de program ación a
nn nivel de detalle menor que el adecuado para el diseño, sin tener especificación escrita, el có
digo resultante puede requerir la participación y cl esfuerzo de todos los recursos disponibles
para volverlo a ensam blar y obtener una aplicación coherente.
La especificación de diseño escrita permite que la aplicación sea probada en forma inde
pendiente. Sin la especificación, cualquier intento para probar el producto term inado está en
gran desventaja. U na buena especificación de diseño no requiere ninguna herram ienta CASE
novedosa. B astará cualquier procesador de palabras y una herram ienta de dibujo sim ple. Una
buena herram ienta CASTi puede hacer más fácil la vida, pero una que no se adecúe correcta
m ente a las tareas específicas puede hacer que el proyecto sea un infierno.
PRODUCTOS DEL DISEÑO DE LA INTERFAZ EXTERNA
Los com ponentes de un diseño de interfaz externa para una interfaz gráfica de usuario inclu
yen (vea también la figura 11-2):
P anoram a del sistem a: U na descripción escrita que orienta al lector sobre cl objetivo
y la función del sistem a com pleto.
P anoram a de la aplicación; U na descripción escrita para cada aplicación que está
contenida dentro dcl sistem a (por ejem plo, captura de pedidos, facturación, reporte de
ventas, m anejo de inventarios) que define las características disponibles dentro de la
aplicación.
D iagram a de navegación de ventanas: Para cada aplicación dentro del sistem a, un
diagram a de navegación de ventanas declara cuáles ventanas están disponibles y m ues
tra las rutas de navegación posibles entre ellas.
D isposición de ventanas: Para cada ventana del diagram a de navegación, una dispo
sición de ventana m uestra la m anera en que esta aparecerá ante cl usuario.
D escripción de la ventana: í ¡I texto que acom paña a cada disposición de ventana d e
fine claram ente la fu n d ó n y características de ésta, en form a tal que un usuario poten
cial pueda com prender el com portam iento del diseño.
M iniesp ecificación de ventana: L a especificación técnica de la ventana define cl
com portam iento para la apertura y cierre de la v entana y la activación y ejecución de
cada botón, control y elem ento de m enú.
Especificación de cam po: D efine los cam pos y ediciones asociadas para todos los d a
tos que aparecen en la ventana. La especificación de cam po debe incluir una m iniespe
cificación sobre la m anera en que se adquieren los datos, listando nom bres de tablas,
nom bres de colum nas, indicando cóm o unir tablas y describiendo la m anera de aplicar
cualquier critcrio de selección.
El diseño interno, que se trata en el siguiente capítulo, incluye las especificaciones para
todas la.s cla_ses, funciones y procedim ientos internos y los com ponentes que m anejan la com u
nicación entre el sistem a de m anejo de base de datos y la interfaz.
PRODUCTOS DEL DISEÑO DE LA INTERFAZ EXTERNA 307
Para cada aplicación...
Para cada ventaría...
Diagrama Disposición
do navegación de ventana
de ventanas
_L
í z
Descripción Miniespecifrcación ® Especificación
de ventana da ventana de campo
F ig u ra 11-2. R1 diseno de la ínter l a / cexterna.
Panoramas del sistema y aplicación
El panoram a del sistema es una descripción escrita del objetivo del negocio y alcance d d sis
tem a com pleto. Incluye una descripción breve de la necesidad del negocio, los usuarios preten
didos y cóm o se acom odará la aplicación en la estrategia general para satisfacer esa necesidad.
Si se está diseñando un sistem a grande que está dividido en varias aplicaciones, se deberá es
cribir un panoram a de la aplicación para cada sub sección del sistem a que sea im plem entada co
mo una aplicación identificable.
ü ra n parte del material necesario para escribir el panoram a ya existe. El plan general del
proyecto incluirá las metas, objetivos y enunciados de alcance para cada sección del sistema.
El m odelo de eventos incluirá descripciones para todos los eventos de negocios principales m a
nejados por la aplicación. Sólo se necesita un breve resum en de eventos en el panoram a de la
aplicación. Las descripciones de evento detalladas se incluyen al nivel de descripción de ven
tana de la especificación d d diseño.
Por lo tanto, la mayor parle dcl panoram a puede recopilarse a partir de docum entos exis
tentes, en vez de escribirla a parur de cero. La única inform ación nueva es una descripción bre
ve de la estructura de la aplicación en línea y una revisión de algunas de las características
técnicas que contiene. Los panoramas deben escribirse para un público amplio. Serán revisados
por los usuarios antes de la construcción. Serán leídos por el programador para familiarizarse con
el tema. Frecuentemente, los panoram as son cl primer lugar en donde buscan quienes hacen las
pruebas para com prender el objetivo del sistema.
E l panoram a del sistem a, los panoram as de las aplicaciones y las descripciones de ven
tanas también llegan a ser herram ientas de docum entación importantes después de que se ha
instalado el sistema. Estas descripciones escritas del sistem a pueden incluirse en la ayuda en
línea y en la docum entación im presa del sistema, tanto para los usuarios com o para los progra
madores de m antenim iento subsecuentes. Por lo tanto, la estructura del panoram a debe ser con
sistente a través de todos los docum entos de diseño del sistem a. Se puede crear una plantilla
del proyecto para que la usen los diseñadores y de esta m anera se logre consistencia y exhaus-
tividad en la escritura, y hacer m ás fácil que el texto del diseño se use com o docum entación
adecuada para los usuarios finales.
Diagramación de la navegación por ventanas
La diagram ación de la navegación por ventanas es una form a del prototipo. F n el capítulo 6 se
postuló que la prim era iteración de ajuste de la creación del prototipo en la fase de análisis no
debe preocuparse por definir la navegación entre ventanas. Ln vez de ello, cl principal objeti
vo fue el descubrim iento del contenido correcto de las ventanas y las políticas del negocio.
También se sugirió fuertem ente que un prototipo no anim ado era el medio más eosteable para
lograr el objetivo de aprendizaje en ese momento del proyecto.
D urante la fase del diseño externo, tom am os las disposiciones de ventanas de com o es
tán en sus prototipos iniciales y las ref'inamos. i vi ob jetivo de esta iteración dcl prototipo es d e
term inar el tipo de ventana correcto y las rutas de navegación, y defim r la unidad de trabajo
adecuada para el usuario. Estos objetivos tam bién pueden lograrse en una form a muy costea-
ble sin teclear una sola línea de código. Un diseñador de interfaces, arm ado con algunas dis
posiciones de ventanas, el modelo de eventos y el modelo de inform ación, puede usar el
diagram a de navegación para m apear rápidam ente un plan para la construcción de la interfaz.
D e todas las técnicas de modelado tratadas en este libro, ésta es tal vez la más barata, y las
recom pensas pueden ser trem endas.
Notación del diagrama de navegación por ventanas

D espués de años de prueba y error, un com ité internacional de los principales especialistas m un
diales en m etodología concluyó por fin que una ventana debe ser representada com o un rectán
gulo en ei diaaram a de navegación.2 Cada ventana que existe dentro de la aplicación se coloca
Los 'r- i\'i desacuenlo fueron los de ía dcícgación de la universidad de Mulvania, ■j1 apoyaron jervien
tem erle al máugiiki. que fue un tema de gran debate en la conferencia del año anterior. Sólo puede atribuir
se su extraña posición, a sn aislamiento del resto de la comunidad de ingenien a de software fluíante el t¿irgo
invierno múlvico.
309
El T brC * k V“ U " » “ ,0“ * ■ » * Se pue de el nom.

í a v? " T V J ° c,mbre 1 “' aPare“ “ la h™ d= Ululo, dependiendo del cúol:
o a que va dirigido. A algunos equipos de proyecto Ies gusta poner am bo/en el d i a g r a m f ™
do las v ™ , 7 por la' ?;aÉ-anadores como por los usuarios Cuan
do las ventanas de la aplicación son demasiadas para que quepan en un diagrama se ti vldc el
diagrama p ara m estra r las rutas de navegación para un conjunto de eventos S p S k c o
La rata de navegación entre dos ventanas se m uestra trazando una flecha de una venta
n a la siguiente (figura 11-3). U na flecha con una sola punta indica que no se r í u i é r e el c
g r e » a la ventana que lia,na. Se usa una flecha de doble ¿unta para mostrar que él usuario e tí
o.ligad o a regresar a la ventana que llama después de terminar su tarea.
F igura 11-3. Notación de diagramación de navegación entre ventanas.
A veces el diseñador permitirá al usuario abrir varias instancias de la m isma ventana Fa

ostrar estilen un diagram a de navegación se anota sobre ¡a punta de Hecha de la linca la can
dad m axuna de instancias que pueden abrirse en cualquier m omento (leído en forma dc¡ sentido
d d reloj, al igual que la notación de cardinalidad KRDJ. Si „o hay límite Iónico ^ a ltra
l a v i t d ^ r hT " a * ñgUra ' ^ dedUC,mOS ^ ^ varias Lis tan ci as de

tana B desde la ventana A sin tener que cerrar instancias anteriores de la ventana 13
Si „ T ° traS ? lCT,SK,neS lítilt;s Puedetl facerse a la notación básica (figura 11 -4)
d i *™ 011 r abnr 01ra VCTtaiKt- se pUCde coloc- el en d ^ a g ra m a y la ílecha
de navegación puede iniciarse en el botón. Si la navegación es el resultado de una selección de
■ ,a ^lccha pUL' l)e lmcl;ffse cn el mareo d d rectángulo. Otra convención útil es rotular la lie
cha con d nombre d d botón o elemento de menú desde d cual se ejecuta la n a v e g ó A W
nom
no m n í ^nii hbotones
mostrar r ° gen
ni manIen"!’
rotulos deSUS dlagramUS dc n e g a c i ó n lo menos amontonados, y e% cn
flechas.
Tipos de ventanas
U na anotación en la esquina de la ventana indica d Upo de ventano (figura 11 - Y) F1 tipo de
ntana define el com portam iento del mareo de ventana en d am biente GUI de desttno (sí es
movible, red.m ensionable o si puede traslaparse con otras ventanas). La mayoría de t a i e í
Capítulo 11 / EL DISEÑO DE INTERFACES EXTERNAS
310
las de desarrollo GUI vienen con un com portam iento predefinido para diferentes tipos de ven
tanas. M ediante la sim ple declaración se puede hacer que ana ventana sea m im b ro de un tipo
de ventana particular, heredando, por lo tanto, todas las caractensUcas predefinidas de ese
tipo de ventana. La m ayoría de herram ientas de desarrollo GUI perm ite, ademas, que se sobre
pongan características individuales para hacer que determ inadas ventanas se com porten en fo r
m a diferente del resto de sus ancestros de tipo de ventana.
F ig u r a 11-4. D iversa notaciones W N D .
Ventana A
__ Ventana B
R
A
T
i
Ventana C
F ig u ra 11-5. A notaciones W N D para tipo de ventana.
üsin en tes definiciones son del am biente W indows de M icrosoft y específicam ente
para paquetea de desarrollo G U I, tales com o el PowerBuilder. Los térm inos actuales y cl com
portam iento de la_s ventanas varían ligeram ente entre los paquetes GUI y a través de platafor
m as de desarrollo, pero los conceptos son bastante consistentes. No m e ofenderé si se elim ina
estos térm inos y se sustituyen con una palabra que sea m ás significativa para cl lenguaje de d e
sarrollo particular.
V en tan a p rin c ip a l o d e aplicación: U na ventana principal (M ain), también conocida

com o ventana de aplicación, es la variedad de ventana más com ún (figura 11-6). Existe en la
pantalla en form a independiente de cualquier otra ventana. Puede traslapar y ser traslapada por
otras ventanas. Es movible, lo que significa que puede ser arrastrada a un lado para que reve
le lo que se encuentra bajo ella. Es redim ensionable por el usuario y puede ser m inim izada co
mo un icono en el escritorio. Las ventanas principales, por lo general, tienen un menú, aunque
esta característica puede suprimirse con la mayoría de las herram ientas de desarrollo.
§ § I S § r ......................... ' ' i
.Figura 1'1-fi. Ventanas principales o de aplicación.
V en tan a d esplegable o de a p a ric ió n sú b ita: Una ventana desplegable (Pop-U p) reci

be su nom bre debido a que aparece por encim a de la ventana que la llam a (figura 11-7). Una
ventana desplegable se abre desde una ventana existente, a la cual se le m enciona com o ven
tana madre. A diferencia de una ventana principal, no puede ser traslapada por su madre. Si se
necesita ver la ventana madre que está bajo ella se puede arrastrar la ventana de desplegable
hacia un lado. Por ejemplo, en la figura 11 -7 se puede ver que si se arrastra la ventana despSe
gable en una dirección sureste, alejándola de su m adre, perm anece encim a de ella, pera poe-
de ser arrastrada com pletam ente a un lado de la ventana madre perm itiendo que se vean am
bas sim ultáneam ente.
F igura 11-7. Una ventana desplegable.
Cuando la ventana desplegable es m inim izada se convierte en un icono en cl escritorio,

separado del icono de la ventana madre. La ventana desplegable también puede existir después
de que se cierra la ventana madre. Esto puede ser problem ático cuando la ventana desplegable
contiene cualquier dato que no se ha guardado y que es requerido por la ventana madre. F re
cuentem ente cl desarrollador añadirá algo de código a ¡a ventana madre para elim inar cualquier
ventana desplegable huérfana.
V en tan a h ija : U na ventana hija (Child) es muy sim ilar a una ventana desplegable pero
es un poco m ás restrictiva (figura 11 -8). También se abre a partir de una ventana m adre, y al
igual que la ventana desplegable, una ventana hija no puede ser traslapada por la ventana m a
dre La principal diferencia entre ellas es que una ventana hija no puede ser arrastrada afuera
de ios confines del m arco de la ventana madre. Por ejemplo, si se arrastra la ventana hija en di
rección sur esle para, revelar a l a ventana m adre que está bajo eUa, parece deslizarse bajo el
marco de la ventana madre, pero no em erge por el otro lado.
Cuando se m inim iza una ventana hija se convierte en un icono cn el espacio de trabajo
de la ventana madre y no cn cl espacio del escritorio de la pantalla. La ventana hija no puede
existir después de que la ventana madre se haya cerrado. Cuando se cierra una ventana madre
también se cerrarán todas sus ventanas hijas.
Figura 11-8. Una ventana hija.
V en tan a de re sp u e sta : El tipo de ventana con com portam iento más restrictivo es la ven
tana de respuesta (Responso) (figura 11-9), ya obtiene el enfoque cuando es ahierta y no lo li
bera sino hasta que se cierra. N o es m inim izable ni redim ensionable. Un diseñador em pleará
una ventana de respuesta en la aplicación cuando quiera forzar al usuario a través de una ruta
particular sin desviaciones. Los cuadros de m ensaje y de diálogo que se usan para desplegar
m ensajes de error y de confirm ación también presentan este com portam iento restrictivo.
M a rc o M D I/h o ja M D I: U na de las estructuras de ventana m ás útiles en las aplicaciones
de negocios grandes es c) marco de interfaz p ara docum entos m últiples (M D i, múltiple docu-
m ent intcrí'ace frame) (figura 11 -10), El m arco M D I es un espacio de trabajo redim ensionable
y auto conten ido que opera en una form a m uy sim ilar a la ventana principal, pero tiene integra
das algunas características especíales. En form a muy sim ilar a una ventana principal, el marco
M D I viene eon un menú. Las ventanas que se abren dentro del m arco son llam adas hojas M DI.
Las hojas MDI se com portan com o ventanas hijas. No pueden ser arrastradas fuera de los con
fines del m areo M D I y se m inim izan a un icono dentro del marco. E l m arco M D I m ism o se mi
nimiza a un icono en el escritorio. Los m arcos M D I contienen funciones integradas opcionales
para ponerse en mosaico, en cascada, en capas y acom odar iconos para las hojas abiertas que
están dentro del marco.
F ig u r a n - 9 . U na ventana de respuesta.
Hl diseñador también tiene la opción de perm itir al usuario que abra varias instancias de
la m isma hoja dentro del marco. E sta característica frecuentem ente es desactivada en aplica
ciones de captura de datos corporativas, pero es com ún en software de paquetes. Ejemplos de
aplicaciones bien conocidas que están alojadas dentro de marcos M D I son WORD® y EXCEL®
de M icrosoft.
Los marcos M D I son particularm ente útiles para dividir sistem as grandes en aplicacio
nes separadas. Debido a que las hojas M D I no pueden ser arrastradas fuera del marco, éste for
m a una barrera adecuada alrededor de un conjunto de ventanas que pueden ser agregadas para
servir a una función com ún, tal com o la captura de un pedido. Alojando diferentes partes dcl
sistema en sus respectivas aplicaciones M DI, el usuario es ca p a/ de tener varias aplicaciones
abiertas al m ism o tiempo, sin tener peligro de entrelazar ventanas no relacionadas; las venta
nas de facturación no pueden m ezclarse con las ventanas de captura de pedidos o las ventanas
de perfil de cliente. ÍJ marco M DI es una herram ienta organizacional poderosa que impide que
el usuario juegue a recoger las 52 cartas con un m azo de ventanas dispares.
Figura 11-10. U n m arco MDT y una hoja M D I.
C a rp e ta con fichas o p estañ a s: La carpeta con fic h a s (Tab Folder) es un tipo de venta
na especial que se com porta en form a muy sim ilar a un conjunto cn capas de hojas MDI o ven
tanas hijas. La apariencia d d marco de ventana ha sido m odificada para que se parezca a una
carpeta de archivo antigua con una pestaña saliente sobre la cual está escrito el nom bre. Las
carpetas con ficha son particularm ente útiles cuando hay dem asiados elem entos de datos a des
plegar en una ventana y el tem a a presentar se divide en forma lógica en áreas de temas distin
tos. La figura 1 1 -il m uestra una carpeta con lengüeta alojada dentro de un marco MDI. La
carpeta puede usarse para representar el expediente que conserva el negocio acerca de un clien
te dado. Cada área de tem a com o calificación de crédito, preferencias de productos y dirección
de envío pueden ser accedidos haciendo clic cn la lengüeta adecuada, lo que lleva a la hoja se
leccionada a la parte superior de la piia.
Unidad de trabajo
El diagram a de navegación de ventanas es extrem adam ente útil para la exploración de las fron
teras de la unidad de trabajo adecuada de los usuarios. Esta se define com o qué tanto se decide
perm itirles avanzar antes de que deban guardar su trabajo en la base de datos. E l diagram a
de navegación perm ite que se juegue con la colocación de Guardar y discute los méritos de las
diversas opciones con los usuarios y con los demás miembros del equipo.
Guardar puede m arcarse en el diagram a de navegación de varias formas. Si se aplica só
lo a una ventana, puede ser anotado directam ente en la ventana. Si se aplica al trabajo realiza
do en varias ventanas abiertas, se puede trazar una línea punteada alrededor del conjunto
F ig u ra 11 -11. Una carpe la con fichas en un marco MDI.
com pleto de ventanas cuyo contenido es registrado eon Guardar, Para aplicaciones en las que
la unidad de trabajo abarca varias ventanas a la vez, frecuentem ente las ventanas están aloja
das dentro de un marco de interfaz para docum entos múltiples (M D I) y el Guardar se coloca
en la barra de m enú del marco. Un m arco M D I se anota en el diagram a de navegación como
un marco continuo trazado alrededor de un conjunto de ventanas. Un Guardar colocado en el
marco se supone que guarda el contenido de cualquier ventana abierta del m arco en la base de
datos. En algunos diseños esta unidad de trabajo puede ser dem asiado tolerante, y el com ando
Guardar se m overá del menú del m arco MDI a ventanas individuales dentro del marco. La fi
gura 11-12 m uestra la notación para las cuatro opciones.
Ejemplo de diagrama de navegación por ventanas

Ahora que ya se han visto las definiciones dcl tipo de ventana, tom em os un ejem plo de un sis
tem a de m antenim iento de tabla de precios sim ple y veamos cóm o un requerim iento esencial
de m antener precios puede producir diseños de interfaz muy diferentes.
E specificación : N uestro negocio hipotético requiere una aplicación de m antenim iento
de precios que perm itirá que el departam ento de m ercadotecnia establezca nuevas listas de
precios para sus productos en el futuro. D espués del m odelado de datos de inform ación, m o
delado de eventos y sesión de creación de prototipos para determ inar la disposición de la v e n -
equipo ha llegado a la estructura de tabla de base de datos que se encuentra en la figura
Guardar su aplica a la ventana única. Guardar se aplica a todas las ventanas

que están dentro de la linea punteada.
Guardar se aplica a todas las hojas Guardar se aplica a hojas específicas

abiertas en el marco MDI. dentro del marco MDI.
Figura 11-12. Cuatro notaciones para Guardar.
l,a sesión de creación de prototipos produjo al menos tres ventanas para la aplicación en
línea (figura 11-14). La ventana, .selección de lista de precios, perm ite que el usuario exam ine
la lista de preeios que ya se encuentra cn el sistema. Otra ventana, mantenimiento de lista de
precias, despliega todos los detalles de la lisia de precios que están asociados con la lista de
precios. Una tercera ventana, com entario detallado del precio , puede necesitarse para actuali
zar el com entario sobre un renglón de detalle de la lista de precios. Algunos del equipo del pro
yecto argum entaron que tal vez se necesitaría una cuarta ventana para establecer una nueva
lista de preeios antes de llenar los precios y otros argum entaron que podría com binarse con la
ventana m antenim iento de lista de precios.
T area : D adas la disposición de tablas, la disposición de ventanas y lo poco que sabemos
del negocio, ¿qué tantos m odelos de navegación diferentes se pueden obtener? ¿Cuál es el ti
po de ventana adecuado para cada ventana del m odelo y dónde va el Guardar? ¿Cuáles son
los puntos fuertes de cada diseño? A sum iendo que cada solución tiene un problem a, ¿cuáles
son las debilidades de cada diseño?
Estas son algunas ratas de navegación posibles. Cada diseño tiene sus méritos y sus li
mitaciones.
D iseño # 1 : En el primer diseño (figura 11-15) el usuario abre la ventana de M anteni
m iento de lista de precios directam ente desde el menú principal. Cuando se abre, los campos
están vacíos. Para recuperar una lista de precios el usuario selecciona Archivo y Abrir y se atoe
la ventana de Selección de lista de precios, presentando presum iblem ente todas las listas d e
precios que han sido guardadas anteriorm ente en e¡ sistema. Fl diseñador ha hecho que m an
tenim iento de lista de precios sea una ventana principal y selección de lisia de precios una ven
tana de respuesta. I,a ventana de com entarios de detalle de precios se abre desde un botón que
está en la ventana de m antenim iento. Podem os suponer que el botón está activado solamente
cuando el enfoque está en un solo renglón de detalle de precios.
Nombre de tabla: LISTA DE PRECIOS

Descripción: La labia de lista de precios especifica ia región geográfica para la que son
efectivos los precios más la fecha de entrada cn vigor y la fecha de expiración de la
lista de precios.
Nombre de columna Tipo de dato ¿No nulo? ¿CP o CE?
ID d e jis ía de precios iD identificador No nulo ' CP
Rcgión_de mercado CharílO} No nulo CÉ apunta a fa tabla de región de mercado
Füchi) en_vigor Fecha No nulo
Fecha_df: expiración Fecha No nulo
Estado_activo CharfS) No nulo Valores = ACTIVO, INACTIVO |
N o m bro de tabla: DETALLE DE LISTA DE PRECIOS

Descripción: La tabla de detalle do lista de precios especifica e¡ p recio en v ig o r para ca
da p ro d u c to de la lista do precios. La tabía tiene una restricció n única sobre
ID lista_de precios + ID d c_ p ro d u cto , de ta l fo rm a que n in g ú n p ro d u cto pueda
estar e n listado más de una vez en una lista de p re cio s dada. El dep arta m e n to
de m ercadotecnia ha ped id o un ca m p o de c o m e n ta rio al nivel de d etalle de
lista de precios para q ue pueda exp lica r la m anera en que llegaron a d e te rm i
nados precios o p o n e r notas en relación a los precios que pretenden revisar an
tes de q ue ia lista llegue a e n tra r en vig o r.
Nombre de columna Tipo de dato ¿No nulo? CP
1D_de_deta 11e_de_iista desprecios (::D de identificador) Nu nulo CE apunta a la tabla de lisia de precios
ID d e J is ta de_precios (ID do identificador) No nulo CE apunta a la tabtade productos
D_de_prociucto (ID de identificador) Mo nulo
Precio_unita rio Decirnal(9,2} No nulo
Comontario._de_detalle de_precio Varchar(200)
F ig u r a 11-13. D e fin icio n e s de tabla de mantenimiento de lista de precios.
L a aplicación parece estar favoreciendo la fa c ilid a d de capacitación v la consistencia en

tre otras aplicaciones com o los vectores de calidad principales, debido a que la navegación se
parece m ucho a otras aplicaciones em paquetadas com únm ente usadas. Ks probable que cual
quier usuario que esté fam iliarizado con el paradigm a de W indows* no necesitará capacitación
adicional para aprender la m anera de navegar en esta aplicación.
Monten ¡miento ite lista de precios _________
Región de mercado En vigor: Expira: Estado activo
Lista ríe precios:

Código Descripción Precio Comentario
ríe producto de producto unitario de detalle
Selección dé fista de precios

Com entario efe de t a He de precio
Regiórr de mercado: En vigor: Expira:
Escriba- las notas relativas al precio seleccionado
F ig u ra 11-J 4. D isposiciones de ventana para selección de lista de precios, mantenimiento de lista de

precios y comentarios de detalle de precios.
Selección de lista
ríe precios
Figura 11-15. E l diseño #1 abre prim ero la ventana de m antenim iento.

320
~ ^ precios
'“ » ■ * * > » * » p m o b t o .
la navegación no eslá optimizada para sn larca más °“
selección de lista de precios rccunera cim I m ^ r lid. a ' P mi1 es ût; ía ventana
sistema. Ksto puede dar com o r e s u lta n . d c PrüC10s Que se haya dado alguna vez al
: íá S
de selección es {* p r i i L f q u e se
# S 1 '1^ ^
H ^ ’=
ha *Ído La ventana
dor necesitará decidir si esta v e n t e a H e J U5>UÍiri° ™trar a la aPlicaclón- El diseña-
p legado de todas l a s c a s de ‘ T * " ^ - des
cíe selección a Ja ventana para perm itir ™k- e\ ■ ^ ° ° ^ SC rá ^ a d i r algún criterio
ción bajo dem anda P ^ - ^ rcdu2ca k Iista y se ejecute la recupera-
Menú principal
Guardar
M antenim iento de lista

ae precios Selección de lista dp, precios
Detalles A
A
Com enlarios de detalles

de precios
Figura 11-16. E l diseño #2 abre primero la ventana de selección.

Hste diseño se apega m ejor al paradigm a objeto-acción, perm itiendo que el usuario ad
quiera un conjunto de listas de precios y luego decida cuáles acciones desea aplicar. Para ac
tualizar una lista do precios, el usuario sim plem ente selecciona una desde la lista y abre la
ventana de m antenim iento. La desventaja de este diseño es que el usuario debe hacer clic más
allá de la ventana de selección para teclear una nueva lista de precios, mientras que en el d ise
ño anterior podría com enzar a teclear inmediatam ente.
En el segundo diseño, al igual que en el primero, el diseñador nuevam ente ha definido
que la unidad de trabajo dcl usuario sea una lista de precios com pleta al colocar el Guardar en
la ventana de m antenim iento de lista de precios. A unque creo que esto es muy sensato, explo
remos nuestras otras opciones.
Hl diseño puede extenderse fácilm ente para perm itir que el usuario m odifique varias lis
tas de precios a la vez colocando una “M ” en la flecha que se encuentra entre la ventana de se
lección y la de m antenim iento (figura 11-17). Esto podría crear una capacidad de actualización
extrem adam ente tolerante en donde el usuario podría tener varias transacciones abiertas con la
base de datos para una cantidad indefinida de listas de precios.
F ig u ra 11-17. U nidad de trabajo = varias listas de precios.
Si la unidad de trabajo más tolerante perm ite la actualización de varias listas de precios, exa
m inem os los méritos y m ecánica del extrem o opuesto. Podríam os declarar que la actualización
de precios es un asunto de negocios serio y que el usuario debe guardar individualm ente cada
uno de los renglones de detalle de precios. Hsto puede lograrse desactivando la habilidad para
actualizar los detalles de precios en la ventana de m antenim iento y obligando al usuario a que
dé cada precio en la ventana com entarios de detalla de precios y la guarde antes de continuar.
(Cam biem os el nom bre de esta ventana a m antenim iento de detalle de. precios para reflejar su
nuevo objetivo cu ia vida.)
La figura 11-18 m uestra nuestro nuevo diseño restrictivo, el cual coloca el Guardar en
el nivel más bajo posible. El usuario debe ahora hacer elic en un renglón de detalle de precios
en la ventana m antenim iento de lista de precios para abrir la ventana de edición m antenim ien
to de detalle de precios. Bn este m om ento puede teclear un precio y un com entario de detalle
y luego debe guardar su trabajo antes de continuar con cl siguiente precio. El diseño más res
trictivo sería hacer que m antenim iento de detalle de precios fuera una ventana de respuesta,
forzando al usuario a cerrarla después que la usa. Podría ser un poco más am igable hacer que
ésta fuera una ventana hija o desplegable, lo cual podría perm itir que los usuarios hicieran clie
detrás de ella en el siguiente renglón de detalle de precios de m antenim iento de lista de p re
cios, después de guardar, para refrescar su contenido con el siguiente detalle de precios.
f ig u ra 11-1K. Unidad de trabajo - un solo detalle de precios.
Un experimento interesante
Si aún no lo convence cl poder del diagram a de navegación de ventanas para ahorrarle tiempo
y dinero, pruebe este pequeño experim ento. Q uite la parte de especificación del ejem plo ante
rior y déselo al m enos a tres program adores de GUI. Pídales que construyan las tablas y codi
fiquen una interfaz usando las disposiciones de ventanas. A cabarán con su propio mecanismo
de navegación y decidirán donde colocar los botones o elem entos de menú. Pueden usar cual
quier tipo de ventana que consideren apropiado. También pueden añadir ventanas, cuadros de
diálogo y de m ensaje adicionales conform e los necesiten. La única regla es que no se les p er
mite ver el trabajo de los demás o platicar acerca de sus ideas entre ellos. (Esta regla es muy
sim ilar al decreto no mire y codifique”, frecuentem ente dado por gerentes aterrorizados, cuan
do se acerca el fin del proyecto.)
No tiene que realizar, de hecho, este experim ento para im aginar ios resultados. E s muy
posible que le presenten tres interfaces con diferencias que van desde lo sutil hasta lo drástico.
A hora imagine que estos tres des arrolladores talentosos son abandonados sin lincam ientos en
un proyecto grande, siendo responsable cada uno de Ja producción de la interfaz para diversas
áreas del sistema. La cantidad de diferencias de navegación y de estilo en la aplicación term i
nada podrán ser enormes. El modesto diagram a de navegación de ventanas es una herram ien
ta de com unicación poderosa que perm ite a los des arrolladores evitar mucho de este tipo de
divergencias.
L a navegación de ventanas m uestra la m anera en que el usuario puede navegar entre ven
tanas en una aplicación, h s una técnica poderosa de diseño y com unicación que ayuda a los de
s arrollad ores a declarar las rutas de navegación adecuadas, los tipos de ventanas y la unidad de
trabajo adecuada para el usuario antes de traducir sus ideas en código.
Ll diagram a de navegación es uno de los m odelos más costeables. Dedicando sólo unos
cuantos m inutos para dibujar el m odelo, el diseñador puede rápidam ente hacer una reunión con
sus com pañeros y discutir sus méritos.
Establecimiento de modelos de navegación estándar

Cada proyecto deberá tener varios m odelos de navegación estándar establecidos para diversos
tipos de actividades en línea. Puede ser que una plantilla de navegación sea muy adecuada pa-
ía áreas donde preocupe reducir la mecanografía. Otra plantilla puede estar muy adecuada pa
ra adherirse a las normas de la navegación de los paquetes de software. Para cada nueva área
de la aplicación que necesite una interfaz en linca, el diseñador puede investigar entre patrones
preexistentes y seleccionar el que se ajuste m ejor a su problem a. A la m ayoría de jas aplicacio
nes se les pueden aplicar m odelos de navegación estándar, dejando abiertas al debate solam en
te las áreas com plejas o poco usuales del sistema.
Las plantillas de navegación de ventanas deben incluir los estándares del proyecto para
el nom bre del título de la ventana, los nom bres de objetos internos de ventana, los nom bres de
botones estándar, los nombres de tipos de ventanas y las recom endaciones sobre dónde colo
car el Guardar. M uchas herram ientas de desarrollo GUI soportan la herencia de objetos para
la presentación de objetos, tales com o las ventanas y botones. Gran parte del com portam iento
de navegación puede ser codificado directam ente en la biblioteca de clases madre.
Técnicas para la revisión de navegación de ventanas

Los diagram as de navegación de ventanas también pueden usarse para sim ular la navegación
con los usuarios. La diagram ación de la navegación es otra forma de prototipo. Ll objetivo de
aprendizaje es determ inar las rutas de navegación adecuadas, la unidad de trabajo y el tipo
de ventana. La técnica está diseñada para lograr el objetivo de aprendizaje sin incurrir en el
costo de la codificación.
Para presentar el diseño a la com unidad de usuarios tal vez quiera adornar un poco la pre
sentación. He hecho esto de varias formas, y cada una con gran éxito. Usando una herrarme ti
la de dibujo basada en W indows, rápidam ente he pegado ilustraciones de m apa de bits a mis
disposiciones de ventanas sobre los cuadros del diagram a de navegación. D e esta form a los
usuarios pueden ver al mismo tiem po la disposición de ventanas y las flechas de navegación.
(Por lo general, esto no es necesario para un público técnico que está acostum brado a la lectu
ra de especificaciones abstractas.) En ausencia de una herram ienta de dibujo adecuada, un
enfoque de tecnología básica es reducir las disposiciones de ventana en una copiadora y pegar
las en una versión gráfica de pared del diagram a de navegación.
Iin una sesión m ás creativa, adherí con cinta las disposiciones de ventana a un pizarrón
blanco grande. ) -e di un m arcador de diferente color a cada usuario dcl público y le pedí que
se aproxim ara al pizarrón y trazara la m anera en que pensaba que debiera ser la navegación por
el conjunto de ventana para acom odar cada evento de la lista de eventos. Hl resultado fue muy
ilustrativo y muy divertido. En una hora se pudo ver claram ente el surgimiento de rutas. La ru
ta normal tom ada para la m ayoría de los eventos se parecía a una autopista psicodélica en cl
pizarrón, en donde las rutas de excepción se disparaban por los lados en líneas solas y aparea
das. ¡Nunca hubiéram os descubierto esta inform ación si hubiéramos codificado un prototipo
de interfaz para su aprobación!-’
Especificación de ventanas
Cada ventana dcl diagram a de navegación de ventanas requiere una especificación. La especi
ficación de ventana tiene un público técnico y otro no técnico. Los usuarios necesitarán revi
sar la disposición de ventanas y sus descripciones. Los program adores utilizarán el docum ento
com pleto, incluyendo las mim e spec i fie aciones. Los que prueban y los instructores deberán ser
capaces de obtener el com portam iento deseado de la especificación y com enzar a construir sus
acripts de prueba y m ateriales de capacitación sin tener que esperar al producto final.
El diseño de interfaz externa articula el com portam iento visible del sistema. La especifi
cación de diseño interna detallará la m anera en que se logra tras bam balinas. H ay cuatro partes
de una especificación externa de ventanas: disposición de ventanas, descripción de ventanas,
mi ni especificación de ventanas y especificación de campo.
Disposición de ventanas
Ya se ha dicho mucho acerca de la disposición de ventanas. Hn este m om ento del proyecto ya
han sido revisados los prototipos de disposición de ventanas por los usuarios y el equipo de di
seño. Se deberá tener bastante confianza en que cl contenido es correcto y que el acom odo de
los datos en la ventana cabrá dentro del m arco y será estéticam ente agradable. El program ador
hará ajustes tíñales a la longitud y posicionam lento del campo cuando forme la ventana.
La disposición puede hacerse con una herram ienta de dibujo o hasta un procesador de
palabras- El diseñador deberá indicar los rótulos de cam po adecuados y sus posiciones relati
vas. También deberá finalizarse la posición de todos los botones y elem entos de menú. Las ba
rras de título deberán decir exactam ente lo que se desea y se deberán anotar todas las partes
dinámica.s de la barra de títulos. He encontrado útil el indicar los cam pos requeridos y los cam-
■ ; m e jora im portante en las herram ientas CASF. podría ciertam ente inclinarm e a reliram ie de ios prototi
pos en papel, pero sólo si la herram ienta fuera a! m enos tur) rápida y efectiva com o las técnicas que he em
pltJÉLtlO.
pos no actualizables con un esquem a de colores. También se marean cam pos que requieren lis
tas desplegadles o 1unciones de las que se puede elegir m ediante la colocación de un carácter
especial en el cam po en la disposición y proporcionando un rótulo al usuario. La figura 11-19
m uestra una disposición de ventana creada rápidam ente con una sim ple herram ienta de dibujo
de escritorio.
C a p tu ra de p e d id o - [n ú m e ro de pe d id o ]
Cliente: Fecha de pedido:
Dirección:
Ciudad: "~| Estado; r jT l C.R:
Conceptos del pedido:

Número Código de Descripción Unidad de Precio
de línea producto |"y de producto Cantidad medida unitario Subtotal
m
▼
Impuesto | ■ . 1
Toral I j
G u ard a rj j C errar
F ig u r a 11-19, D iagram a de la d isposición de una ventana.
Descripción de ventanas
Al igual que cualquier otro objeto que se haya creado en el modelo, se tiene la obligación de
definir la disposición de la ventana en texto claro para que cualquiera que vea la ilustración
com prenda lo que se está tratando de presentar. La descripción de ventanas debe incluir un p a
noram a del objetivo de la ventana y una descripción del o los eventos de negocios que son m a
nejados por esta interfaz. G ran parte de este texto ya existe en el modelo de eventos y en las
descripciones iniciales que acom pañan a los primeros prototipos en papel. Todo lo que se n e
cesita es añadir descripciones de los botones, m enús y decisiones ergonóm icas que se han to
m ado en la fase de diseño, La íigura 11 -20 m uestra una descripción de ventana para la ventana
de la figura 11-19. No he incluido descripciones de campo detalladas pitra cada uno de los cam
pos de la ventana debido a que esta inform ación ya se encuentra docum entada en el modelo de
inform ación. Tal vez quiera incluir definiciones para algunos cam pos sí es que se com portan
en una form a poco usual que m erece una explicación adicional, o anexar las definiciones de
atributos.
Descripción de ventana
Barra de título: Captura de pedidos |núm ero de pedido]

Menú: ninguno
Tipo de ventana: Aplicación
La ventana captura de pedidos es usada por el personal de ventas de ACME CORPORA

TION para capturar pedidos cn sus oficinas de ventas (también conocidas dentro de la
compañía como "tiendas'1). La ventana es abierta desde la ventana selección de pedido.
Sí el usuario ha abierto un pedido capturado anteriormente, el pedido seleccionado se
desplegará en la ventana, apareciendo en la barra de títu lo e¡ número de pedido. Si el
usuario está colocando un nuevo pedido, la ventana se abre vacía con el cursor posicio
nado en el campo de cliente.
El campo de cliente es una búsqueda que utiliza una cadena parcial sobre el nombre del
cliente, usando la función de búsqueda de cliente estándar del sistema. Cuando el clien
te es seleccionada se llenan su dirección, ciudad, estado y código postal predeterm ina
dos a partir de la labia da clientes. El vendedor puede cam biar cualquier parte de la
dirección en el pedido si es que el cliente desea que el pedido se envíe a otro lugar. El
sistema llena la techa del pedido, pero el usuario puede alterarla si está tecleando pedi
dos que se tom aron manualm ente en o tio día. El número de tienda toma un valor prede
term inado a partir de la estación de trabajo de la tienda indicada, pero el usuario
tam bién puede cam biarlo en caso de que esté capturando una venta a nombre de otra
tienda.
La sección inferior de la ventana contiene un listado tabular de conceptos cíe pedido. El

sistema asignará autom áticamente el número de línea de concepto de pedido. El usuario
puede teclear rápidam ente el código del producto o hacer una selección por cadena par
cial para escogerlo de una lista. Algunas tiendas estarán equipadas con escáneres para
leer directam ente cl código del producto desde el artículo. Para borrar un concepto de
pedido, el usuario sim plem ente elim ina el código del producto. El sistema llena la des
cripción del producto, unidad de medida, precio unitario y calcula el total de la linea con
base en la cantidad tecleada por el usuario. Se calcula el impuesto de ventas con base
en el estado de exención de impuestos en la tabla de clientes y se muestra el total riel
pedido en la parte inferior.
El botón Guardar rem ite el pedido a base de datos. El botón Cerrar regresa al usuario a
la ventana selección de pedido.
Figura 11-20. Un ejemplo de descripción de ventana.
Miniespecificación de ventana
La m iniespecifieación de ventana se enfoca en el com portam iento d d m arco de ventana y de
todos los botones, elem entos de menú y controles que se hayan colocado en esa ventana. Por
lo m enos se debe especificar lo que sucedc cuando se abre ta ventana y lo que sucede cuando
se le cierra. Para cada botón, elem ento de menú, botón oprim ible de la barra de herram ientas
o cualquier otro control se deben indicar las condiciones bajo las cuales está activado y lo que
sucede cuando se ejecuta, (i -os controles estándar que son heredados del tipo de ventana, tales
com o m axim izar y m inimizar, no necesitan ser vueltos a especificar.) La figura 11-21 muestra
una m iniüspeciiicación para la ventana de nuestro ejemplo.
M iniespecificación de ventana
Ventana: captura He pedidos

Parámetros de entrada: m odo [valores ■ insertar, actualizar), requerido
fd . de_pedido, requerido si modo = actualizar
Abrir: If modo = actualizar,

recupera dw_pedido usando id de pedido
recupera dw concep 1o_de_p[¡didc> usando ¡d_dc...pudido
Else (modo = insertar)
muestra campos (en blanco}, posiciorta el cursor en el cam
po cliente
End if
Boíones/elementos de menú
í Rótulo Activado Al hacer Clic
G u a rd a r Cuando concepto cambiado es If modo = insertar

cierto y obtener siguiente número de
E! usuario es m iem bro del g ru pedido
po de personal de ventas auto insertar dw pedido
rizado insertar dw..concepto_de_pedido
mostrar número de pedido en la
barra de título.
Else (modo = actualizar)
actualiza dw_pedido
actualiza dw_concepto_despe
dido
End if
Cerrar Siempre If concepto cambiado,

confirm ar guardar
Else '
Cerrar vemaiui
End if
i*KT!s5>asaéíf?í5 ¡ i j s sí& j » ( í m -.v-'VWí í ssff
Figura 11-21. Un ejem plo de m iniespecificación de ventana.
Las reglas que se refieren a la activación de botones y elem entos de menú están deriva
das de dos fuentes principales, las reglas de autorización de usuarios y los modelos de c ven tos-
transición de estados. La matriz de evento/ autorización de usuario muestra cuáles grupos de
usuarios están autorizados para ejecutar cuáles eventos de negocios (figura 11-22). Ésta es una
de las m uchas matrices que se pueden construir cuando se crea prim era el modelo de eventos.
Como diseñador necesitará decidir si perm ite a un usuario que entre a una ventana en la
que sus eventos están reconocidos, pero en la que no tiene autoridad de ejecución. En casi
todos los negocios, la mayoría de los usuarios tendrá acceso sólo a lectura a la mayor parte de
la base de datos. En vez de construir ventanas de "sólo vista” especiales, es m ucho más fácil
sim plem ente sólo dejar leer a los usuarios en las ventanas de m antenim iento normales, y d e
sactivar todo a excepción de los botones de selección. Lsta táctica m otiva a los usuarios a en-
plorar el sistem a com pleto y conduce a una mayor com prensión de las diversas tareas que hay
alrededor de ellos.
Gerente de producción
o
c
Representante
de producción
‘2? ‘G
_a> o ra
de vfinlas
Asistente
£ *•322CJ
c
2
Evento/autorización de usuario E GJ
5 LU T3
8
El cliente coloca pedido X
El departamento de crédito aprueba pedido X i
El departamento efe producción asigna pedido
La planta surte el pedido del cliente
X
X
X
X
i
La planta envía el pedido del cliente X X
Contabilidad factura cl pedido del cliente
Mercadotecnia envía catálogo por correo X
X
i1
issd::i
F ig u ra 1.1-22. M atriz de cvento/autorización de usuaria.
Las ventanas que em plean coherencia com unicadonal requieren frecuentemente la activa
ción de un botón o d em ento de menú de acuerdo con la autorización del usuario. Con la cohe
rencia com unícacional se agrupan diversos eventos debido a que comparten los misinos datos u
objetos del negocio, pero pueden ser ejecutados por partes diferentes. En las ventanas comuni-
cacionalm ente cohesivas se tendrán que activar y desactivar botones y elementos de menú de
acuerdo con la autorización com pleta del usuario registrado. Esto se logra, por lo general, me
diante la lectura de los niveles de autorización del usuario desde el sistema de adm inistración de
base de datos o m edíante un conjunto de tablas mantenidas por el adm inistrador de sistem a cuan
do se arranca la aplicación y guardadas en la m em oria de la m áquina cliente durante la sesión.
Junio con la m atriz de evento/ autorización de usuario, las otras fuentes principales para
la activación de botones son los m odelos de transición de estados. Los diagram as de transición
de estados y sus eventos acom pañantes indican cuáles transiciones son legales de un estado af
siguiente (los diagram as de transición de estados son tratados en el capítulo 5). En la figura
11-23 vem os el diagram a de transición de estados para el atributo estado del pedida.
!â figura 11-24 m uestra una ventana de selección de pedido que incluye los botones de
com ando que se usan para ejecutar estos eventos. Conform e el usuario hace clic por los con
ceptos enlistados en el conjunto resultante de la ventana, los hotones se activarán y desactiva
rán de acuerdo con d estado d d pedido que haya seleccionado. Por ejemplo, si el usuario
selecciona un pedido que es “tentativo”, estarán desactivados los botones Fill (.Surtir), Ship
(Enviar) y Back-Order (Pendiente de surtir), debido a que estas acciones no son legales para
un pedido tentativo. Ei m odelo de transición de estados es una fuente invaluable para el dise
ñador OL I. Proporciona un m apa para la m araña de reglas com pleja que puede resultar cuando
están representados uno o más estados en la interfaz.
Figura li'23. D iag ram a de transición de estados p a ra estado de pedido.
9933 jlhe Slug Pit Bar !<Grill 12/21/3E

9934 Fein's Department Slore 12/22/96 2E,450.12Fil!ed
101 9935 The Lobby Shoppe 12/22/9S 1.126.88 Elack-Uidered
101 9936 Washington Plaza Associal ion 12/22/96 15.21 Caneeled
101 9937 iThe Metro Cafe 12/22/96 654.7S Carifirmed
;9938 :Acmé Beverage &Rocket Fue!, Inc. >12 / 2 2 m 991.21:Tentative
F igu ra 11-24. D isposición de una ventana para la selección de pedido.

Especificación de campo
Hasta ahora nos hem os concentrado en la navegación, el tipo y com portam iento de la ventana
y el com portam iento de los controles colocados en la interfaz. A hora es tiem po de volver nues
tra atención al objetivo primordial de la aplicación. D em os una vista a lo que necesita especi
ficarse para el contenido de los datos actuales presentados por la interfaz externa.
La mayoría de herramientas de desarrollo GUI proporciona métodos mediante los cuales
el des arrollador puede definir las características de presentación, ediciones y funciones asocia
das con eada uno de los elementos de datos de la interfaz. E sta parte de la especificación puede
representar a un com ponente interno tal com o un objeto de negocio, una forma 4G1 - o una Da
ta’W indow™ que maneja las características de un dato presentado externamente en la ventana.4
Las ventanas com plejas frecuentem ente son divididas en varias áreas de presentación. Kn
algunas herram ientas de desarrollo, éstas constituyen objetos separados en la interfaz, cada uno
con sus propias características de presentación. Por ejemplo, la ventana de captura de pedidos
que se m uestra en la figura 11 -25 tiene un área de fo rm a to Ubre en la parte superior, la cual es
recuperada de una instancia del pedido. D ebido a que sólo una instancia de pedido puede ser
presentada en la ventana, al diseñador se le perm ite colocar los campos de datos en cualquier
posición que guste, y de ahí el nom bre “form ato libre” . La parte inferior de la ventana desplie
ga los conceptos de pedido asociados eon el encabezado de pedido. Esta sección de la ventana
es capaz de m ostrar varias instancias de concepto de pedido. El estilo de desplegado tabular
acom oda los datos en renglones y colum nas fijos. El estilo de desplegado de cuadricula tam
bién acom oda los datos en columnas y renglones, pero perm ite que el usuario rcacom ode el or
den de las colum nas y altere el tam año de las columnas para adecuarlas a sus necesidades.
F igura 11-25. U na disposición de ventana con dos estilos de presentación
Las características generales de cada área de presentación de la ventana deben especifi

carse primero, seguidas de un listado de los cam pos contenidos. El térm ino técnico para cl área
■' D ata W indow es un objeto inform ado sobre la base de datos dcl P ow erB uilder que m aneja el a tc e s o a la ba
se de datos para los cam pos presentados en ia ventana.
de desplegado variará de herram ienta a herram ienta. Los desarroMadores de Pow erB uilder re
conocerán esto com o una IJ ata W indo w y los desarrollad ores de A C C IíS S '1pueden llam arlo
formulario.
Para cada área de presentación distinta de la ventana, la especificación debe incluir lo
siguiente:
E stablecer el nombre del objeto de desplegado interno, en caso de que esté soporta
do por la herram ienta.
Declarar el estilo de presentación (form ato libre, tabular, cuadrícula, gráfico, m apa de
bits, etcétera.).
Para la presentación tabular o de cuadrícula definir las características aplicables:
Ordenamiento (si hay m ás de una opción de ordenam iento, definir cada una).
Filtros (condiciones bajo las cuales pueden ocultarse determ inados renglones).
Supresión de valores repetidos (por ejem plo, si el renglón 2 tiene el m ism o
nom bre de producto que el renglón 1, m ostrar un espacio).
M é to d o de selección (selección única, selección múltiple).
Agrupamiento (m étodo por el cual los renglones pueden ser seleccionados
únicam ente com o grupo).
Para cada elem ento de dato presente en la ventana, la especificación de cam po deberá in
cluir lo siguiente:
Nombre del rótulo que va a aparecer en la ventana.

Incluir el nombre de la tabla y el nombre de la columna para todos los cam pos de
base de datos.
Indicar si cl cam po es requerido u opcional, y anotar las circunstancias bajo las que
puede cam biar la opcionalidad (por ejem plo, si. m odo de transporte. - “contenedor” , se
requiere p uerto de descarga, en caso contrario, puerto de descarga es opcional).
indi caí' si el cam po es visible o no visible, y anotar las circunstancias bajo las cuales
puede cam biar la visibilidad (por ejem plo, com pañía de ferro ca rril es visible solam en
te si m odo de transporte = ' ‘ferrocarril” ).
indicar si el cam po es actualiza ble por el usuario y anotar las circunstancias bajo las
cuales puede cam biar la habilidad que tiene el usuario para m odificar el cam po (por
ejem plo, el cam po gerente de crédito es desactivado después de que el pedido está
aprobado).
D efinir cualquier cálculo, ediciones y reglas especiales que se aplican a nivel cam po
(por ejem plo, ventas netas = ventas brutas m enos costo de em barque).
A notar las dependencias de campos cruzados, ediciones que dependen de otros valo
res (por ejem plo, fe c h a de inicio <=fe c h a de te.rminación).
La figura 11 -26 muestra un ejemplo de la especificación de cam pos para la ventana de

la figura 11-19.
Especificación de campos
: Nombre de objeto: dw pedido

Estilo de presentación: Formato libre
Campos:
Nombre de columna Nombre de tabla Requerido Visible Actúa lizable Reglas
ID_de_pedido Pedido (cp) S N N Obtiene siguiente ID en NUEVO

Número de pedidc Pedido S TB N Obtiene siguiente# en NUEVO
lD_de_cliente Pedida (ce) s N N Puesto por í_clien.. selec
No mbre_de_cl lente Cliente s S S f_clien. selec
Dirección Cliente N S s Puesto por f_clien_selec
Ciudad Client 3 N S s Puesto por f. clien selec
1Código de. estado Clienta {cej N s s '' / Código. de_estado DDL
{Códige_postal Cliente N s s Puesto por f_ciien_selec
Fecba de pedida Pedido S s s Fecba actual predeterminada
Número de tienda Pedido (ce) s s s Tienda del usuario oredetermircada
Nombro de objeto: dw concepto de pedido

Estilo de presentación: Tabular
Ordenamiento: Núm. de línea, ascendente
Filtros: Ninguno
Supresión: Ninr uno
Método de selección: Sóln una celda
Agrupamiento: Minguno
Campos:
] Nombre de columna Nombre de tahla Requerido Visible Actuaíizable Reglas

11D_de_co nce pto_d e_p edld o Concepto_de..pedido (cp) S N N Obtiene siguiente ID en nuevo renglón
ID de .pedido Concepto_de_pedido (ce) s N N CE hacia íabla de pedidos
Número_de_línea Concepto_de _pe d¡do s S N Número automático
Cód igo_de_produ cto Concepto_de_pedido (cej s s S Selección de f_prod_código
Descripción de. producto Producto s s N Puesta por t_prod_código_selección
Cantidad Concepío_de_p ed :do s s S 0 < cantidad < = 1000
Unidad_de_mcdida Concepto de ped'do s s N Puesto por f_prod_código_selec
Precio_unitario Concepto...de ..pedido s s N Puesto por f prod código selec
Totaljinea Concepto de .pedido s s N Precio unitario x cantidad
Impuesto Pedido s Ftr N F_ca¡c_ventas impuesto
Total Pedido s Ftr N Suma (tota IJÍnea) + impuesto
Figura 11-26. Un ejemplo de especificación de campos.

PRUEBA DE UNA INTERFAZ GRÁFICA DE USUARIO 333
La especificación de campos com pleta cl diseño extem o. Cuando esto está term inado ya
se ha definido adecuadam ente cl com portam iento observable de la interfaz. La tarea de diseño
restante es la especificación de los com ponentes internos que harán todo esto posible. Para m u
chas herram ientas de desarrollo d iente/servidor que se co mullican con el servidor, principal
m ente por m edio de SQL, esto será sim plem ente la especificación de la recuperación para cada
ventana de la base de datos y cualquier procedim iento alm acenado residente en el servidor.
A unque la especificación de acceso de datos cae técnicam ente en cl tema de diseño in
terno, yo prefiero incluir la especificación de ios requerim ientos de acceso de dalos de cada
ventana ju n to con la especificación de cam po de cada ventana en la especificación de diseño
externo. La m iniespecificación para recuperación de datos para una ventana debe expresar el
suficiente detalle para describir adecuadam ente los m étodos y accesos de datos ante el progra
m ador y quienes hacen pruebas. No necesita estar sintácticam ente perfecta. Para esto se puede
usar el generador de SQ L de la herram ienta G L I. La mi ni especificación de los requerim ientos
para la recuperación de datos de cada ventana debe incluir:
U n listado de todos los argum entos de entrada

U na lista de todos los cam pos y tablas a partir de los cuales son seleccionados.
D irecciones sobre la m anera de unir las tablas
Instrucciones sobre la m anera de aplicar cualquier argum ento de entrada para obtener
cl conjunto de resultados deseado
Kl objeto de la m iniespecificación es validar que la base de datos sea capaz de la selec

ción, identificar cualquier problem a de desem peño potencial, y guiar al program ador a través
de uniones com plejas. También perm ite que el gerente del proyecto divida el esfuerzo de co
dificación entre program adores de diversas habilidades y les da a quienes planean las pruebas,
un m apa de los datos necesarios para probar adecuadam ente la recuperación de ventanas.
Algunas herramientas de desarrollo GUI fusionan estrecham ente el código de acceso a
datos con la ventana mism a. La siguiente generación de herram ientas de desarrollo cliente/ser
vidor están llegando a ser m ucho más avanzada y más orientada a objetos. Hn estas herram ien
tas el diseñador tendrá la oportunidad de elaborar un grado de separación más elegante entre
los objetos que contienen las políticas del negocio de aquellos que adm inistran la presentación,
com unicaciones y acceso a la base de datos.
PRUEBA DE UNA INTERFAZ GRÁFICA DE USUARIO
Por ultimo, unas cuantas palabras acerca de la prueba de una aplicación GUI. Una interfaz
gráfica de usuario es mucho más difícil de probar que las pantallas tradicionales basadas en ca
racteres. La diferencia más obvia entre ellas es que en una aplicación GUI el usuario está ar
m ado con un ratón. Casi toda acción que puede ser realizada con el ratón también tiene un
equivalente en cl teclado. Ksto increm enta seriam ente la cantidad de pruebas individuales que
necesitan ejecutarse. No es raro encontrar errores en donde el ratón ejecuta adecuadam ente un
botón de com ando o elem ento de menú, pero falla la acción de teclado equivalente.
Otro asunto que com plica las cosas en los am bientes de ventanas es que los usuarios pue
den tom ar rutas que no han sido anticipadas p or el des arrollador, h ie d e n cerrar ventanas en for-
míi inesperada o cam biar el foco a otra aplicación. Los usuarios pueden ejecutar ei software en
forma sim ultánea con su procesador de palabras, hoja de cálculo o cualquier canüdad de otras
aplicaciones de PC que pueden estar com pitiendo por los recursos del sistema.
La especificación de diseño externo es un docum ento crucial para quienes hacen las
pruebas. U na aplicación que tiene una especificación de diseño escrita es mucho más fácil de
probar que otra que haya sido construida sin una. Ll diseño externo le dice a quien hace prue
bas exactam ente la manera en que se supone debe com portarse el sistema. Le da una base pa
ra la escritura de scripts de prueba que se usan para com parar el com portam iento esperado con
el com portam iento actual de la aplicación term inada. Sin una especificación de diseño, quien
hace pruebas puede ejecutar el software repetidam ente para determ inar si la aplicación se com
porta en forma consistente, pero no será capaz de determ inar si es correcta.
Cada program ador dehe ser responsable de probar su código individualm ente. Después
de que cada uno está convencido de que la aplicación satisface las especificaciones, el código
deberá ser enviado a un personal de aseguram iento de calidad (QA) independiente para prue
bas adicionales. Hl personal QA puede estar com puesto por especialistas en pruebas o hasta por
otros program adores, analistas o diseñadores. La única regla establecida y rápida es que toda
aplicación debe ser probada por alguien diferente al program ador original antes de que sea li
berada para los usuarios. Es muy im portante que se pruebe rigurosam ente la interfaz gráfica de
usuario. É sta es la parte del sistem a que ven los usuarios. H asta la más pequeña anom alía de
la interfaz puede hacer perder la confianza del usuario en la integridad del sistem a completo.
H ay m uchas formas de estructurar los scripts de prueba. Mi método preferido es crear
una tabla que contiene cuatro columnas (figura 11 -27). ES título de la tabla indica el propósito
de la prueba. La prim era colum na describe brevem ente la acción a realizar. La segunda colum
na lista cualquier dato específico que deba ser dado o hace observaciones que establecen si
quien hace la prueba puede usar los que quiera. La tercera colum na describe el resultado espe
rado de la acción. La cuarta colum na está disponible para que quien hace la prueba anote si el
sistem a actual se com portó en forma diferente de lo que se esperaba.
Prueba: recuperación de clientes
Acción í-u-.lia Resultado esperado Resultado actual
Llenar el crite rio Nombre de El sistema debe Error: el sistema

de selección en la cliente parcial, regresar un listado regresó clientes sin
ventana selección región de ventas de todos los clientes tom ar en cuenta la
de cliente y hacer (opcional). cuyo nombre comienza región de ventas
clic en con las primeras letras especificada.
tcc.cadas en el campo
nombre de cliente. Si
tam bién se da una
región de ventas, sólo
deberán recuperarse
los clientes de esa
región.
F ig u r a 11-27. Un guión de prueba de ejem plo

PRUEBA DE UNA INTERFAZ GRÁFICA DE USUARIO 335
Cuando se deriva un sc n p t de prueba a partir de una especificación de diseño me gusta

enfocar el problem a en varias fases, imaginando pruebas en cuatro niveles diferentes, cl nivel
de pixel, el nivel de cam po, e! nivel de ventana y el nivel de evento de negocio. Los niveles de
prueba avanzan en una am pliación de alcance cada vez m ayor desde el exam en de caracteres
y gráficos individuales al cam po de datos, luego hacia la ventana y, por último, al evento de
negocio. Unas palabras para quienes hacen pruebas: aunque piense que puede concebir el script
de prueba en esta forma, por favor ejecute la prueba en orden inverso. Pruebe prim ero las tran
sacciones principales y luego póngase quisquilloso acerca de la ortografía y la punmación. Los
program adores lo apreciarán más si encuentra una falla del sistem a principal en e! prim er día
de las pruebas que en el último.
L a prueba a nivel de pixel es realm ente la revisión para ver si la interfaz se apega a los
estándares del. proyecto en relación con la presentación, aspecto y sensación de la aplicación.
Este tipo de prueba puede realizarla casi cualquiera del equipo. Cada proyecto debe tener una
lista de verificación de conceptos estándar que pueden ser verificados por inspección visual
de las ventanas. Estas son cosas com o tam año de letra, el uso del color, la alineación horizon
tal de los rótulos, la alineación horizontal de los datos, la ortografía, el uso adecuado de los dos
puntos, la alineación vertical de campos, la alineación vertical de los rótulos, colocación de
botones, tam año de botones, teclas aceleradoras y colocación estándar de los nombres de ele
mentos de menú y los botones de com ando.
Pasando del nivel de pixel al nivel de cam po, las cosas se ponen un poco más interesan
tes. Todo cam po de dato debe probarse por lo que yo llamo propiedades y ediciones “aisladas” .
A quí es donde se trata de hacer fallar cam pos individuales probando caracteres válidos contra
inválidos, longitud de cam po, mayúsculas y m inúsculas, rangos num éricos, valores restringi
dos, campos requeridos contra opcionales contra prohibidos, valores predeterm inados y m ás
caras de edición. Este tipo de pruebas son cosas com unes para cualquiera que alguna ve 2 haya
probado sistemas en línea.
Lo que hace que la interfaz gráfica de usuario sea m ás com pleja que sus contrapartes de
pantalla verde es lo que yo llamo “dependencias de campos cruzadas” . Este tipo de prueba re
visa todos los campos de datos que pueden cam biar sus propiedades, ediciones, opcionalidad
o capacidad de actualización de acuerdo con los valores de otros campos. El procesador de la
com putadora personal permite que la aplicación GUI cam bie instantáneam ente las propiedades
de los campos cuando el usuario da un teclazo o hace un clic con el ratón. Los campos pueden
aparecer y desaparecer. Los valores de listas pueden cambiar. Los campos que fueron opciona
les en un caso pueden ser requeridos en otro, lista característica hace que la interfaz de la PC
sea mucho m ás dinám ica que la pantalla verde estática. También hace que la prueba sea más
retadora. Sin una especificación de diseño que determ ine el com portam iento pretendido, quien
hace la prueba queda a su suerte en estas características y no tiene forma de saber si el com
portam iento de la aplicación es correcto o hasta intencional.
Algunos ejem plos com unes de dependencias de cam pos cruzadas son:
Rangos de validación cruzados: El cam po fe c h a inicial debe ser m enor o igual al

cam po fe c h a fin a l. La fe c h a fin a l debe ser m ayor o igual a la fe c h a inicial.
Cambios en opcionalidad: El núm ero de autorización de crédito se requiere para los
pedidos de más de $_í,000.00, poro es opcional para los pedidos m enores a esa cantidad.
Cambios en visibilidad: El cam po ruta de vehículo es visible y actual izable si el m o
do de transporte, es “carro de ferrocarril” , pero no es visible si el m odo de transporte
es "cam ión” .
Cambios en lista de valores restringidos: L a lista desplegable para c la sifica ció n de

clien te cam bia dependiendo de si tip o de clien te es d ie n te “interno” o “externo” .
l lenados predeterminados: Cuando se selecciona el nom bre d e l cliente, la d irecció n
p re d e te rm in a d a llena autom áticam ente los cam pos de d irecció n de envío.
La prueba a nivel de ventana revisa el com portam iento de la ventana m ism a y de cada uno
de los controles de la ventana contra la especificación de diseño. E l diseño externo debe incluir
una especificación sobre lo que sucede cuando la ventana se abre y cuando se cierra. Por ejem
plo, la ventana puede recuperar datos autom áticam ente cuando se abre o, en vez de ello, posi-
cionar el cursor en un campo vacío específico. Cuando la ventana se cierra, puede ser que se
requiera revisar por cambios no guardados y preguntar al usuario si quiere guardar su trabajo.
Además, quien prueba debe revisar el com portam iento del tipo de ventana contra cl tipo
de ventana que se encuentra en el diseño. Si el program ador sustituyó una ventana de respues
ta en donde la especificación pedía una ventana hija, quien hace la prueba deberá hacer la pre
gunta de qué es lo correcto, ¿el program a o el diseño? Las rutas de navegación tam bién deben
ser probadas contra el diagram a de navegación. Quien hace la prueba debe tratar de hacer fa
llar la aplicación cerrando ventanas madre, tratando de dejar huérfanos a los cam bios no guar
dados de cualquier ventana desplegable.
Cada control de la ventana también debe probarse. El diseño externo contiene una mi
nies peci fie ación para cada botón y elem ento de menú, indicando las circunstancias bajo las
cuales están activados y lo que sucede cuando se hace elic en ellos. N uevam ente, sin una es
pecificación de diseño, quien hace la prueba quedaría a oscuras sobre el porqué determinados
com andos se activan y desactivan.
El nivel final de la prueba es concebir pruebas para cada uno de los eventos de negocios
identificados en el modelo de eventos. El m odelo de eventos es una herram ienta maravillosa
para la prueba, debido a que ya está organizado para hacer concordar las entradas del sistema
con las salidas deseadas. Usando al diccionario de eventos com o guía se tiene la capacidad de
rastrear cada evento de negocios hacia la ventana en la que se ejecuta y escribir scripts de prue
ba para verificar que el sistem a satisface el plan general.
Estas no son las únicas pruebas que se ejecutan sobre una aplicación. U na vez que se es
tablecen los scripts de prueba pueden ser cargados en una variedad de herramientas de prueba
de registro y de reproducción autom atizadas y usarse muy efectivam ente para la prueba de
regresión en cualquier m om ento en que se hace un cam bio a la aplicación.
Una de mis colegas usa cl término “prueba del huracán” a partir de un escenario en donde
trata de em ular al “usuario del infierno” . Literalmente hace clic en cualquier lugar que puede, tan
rápido com o puede, tecleando por adelantado, ejecutando varias aplicaciones, dejando abierto el
correo electrónico, el procesamiento de palabras y las hojas de cálculo para tratar de hacer que
falle la aplicación o el sistema operativo. La idea es ver qué tan bien se recupera la aplicación en
las peores circunstancias, cuando se exige a los recursos dcl cliente m ás allá del límite lógico.
Otro escenario de pm ebas intrincado es reunir a cuatro o cinco usuarios en PC separadas
y hacer que intenten la recuperación del m ism o registro a la vez o que ejecuten el mismo tra
bajo de reporte. El objetivo es ver qué tan bien adm inistra cl servidor las lecturas sim ultáneas
del mismo registro. N o olvide que hay que hacer las pruebas en las m ism as m áquinas exactas
sobre las que se ejecutará la aplicación. No tiene sentido que en la prueba de desem peño se
usen las estaciones de trabajo más grandes y recientes del departam ento de la IT si las PCs de
los usuarios son lentas y poco poderosas.
RESUMEN 337
Cuando se tiene una especificación de disefiú extem a, la preparación del xcript de prue
bas puede hacerse en form a sim ultánea con la codificación de la aplicación. El diseño se pasa
a los program adores y a QA al m ism o tiempo. Con esta estrategia, quien hace la prueba com
prende com pletam ente el propósito de diseño y está listo para probar ia aplicación desde el m o
mento en que se term ina el código.
RESUMEN
Una gran cantidad de tiempo y costo del desarrollo de un sistem a cliente/servidor está concen
trado en la parte GUI de la aplicación. El diseño de interfaz externa es una técnica para la re
ducción de este costo resolviendo m uchos de los detalles de ía aplicación antes de la
codificación. En la práctica, he encontrado que el paso del diseño no consum e tanto tiem po co
mo la codificación actual. Yo creo que esto se debe a la com plejidad abrum adora de los len
guajes de desarrollo CUJI y las herram ientas con que se enfrentan los program adores. Al tener
un diseño escrito, el gerente del proyecto puede dividir el esfuerzo de program ación entre va
rios des arrolladores con la seguridad de que las diversas parles van a poder ser ensam bladas
rápidam ente en una aplicación coherente que puede ser probada en form a independiente. Un
diseño escrito tam bién perm ite que quienes prueban, capacitan y hacen la docum entación téc
nica com iencen a trabajar en sus productos respectivos sin tener que esperar el código final.
El diseño de interfaz externa especifica el aspecto, sensación y com portam iento de la
parte del sistem a que el usuario puede ver. Refina al prototipo de interfaz y continúa utilizan
do los m odelos de la fase de análisis, tales com o los modelos de eventos, de transición de es
tados y de inform ación. L a especificación de diseño externa incluye panoram as escritos del
sistem a com pleto, además de cada área de aplicación separada dentro del sistema.
Para cada área de aplicación se dibuja un diagram a de navegación de ventanas, cl cual
m apea las rutas de navegación entre ventanas y perm ite que el diseñador y sus com pañeros d e
term inen el tipo de ventana correcto. K1 diagram a de navegación se usa luego com o una herra
m ienta de com unicación para discutir la unidad de trabajo adecuada para el usuario y decidir
dónde deben registrarse en la base de datos los cambios hechos por cl usuario en la interfaz.
Para cada ventana del diagram a de navegación, el diseñador tiene obligación de definir
la con una disposición y descripción de ventana. La disposición es un refinam iento dei proto
tipo de ventana, mostrando el contenido y posición de los cam pos de datos, así com o los
botones, elem entos de menú y otros controles que se requieren para usar la ventana. La des
cripción explica la m anera cn que la ventana permite a los usuarios el m anejo de los diversos
eventos de negocios de los que son responsables.
La parte restante del docum ento de diseño de interfaz externa constituye la especifica
ción técnica. La m iniespecificaeión de ventana incluye texto estructurado al estilo de pseudo-
código para describir lo que sucede cuando la ventana se abre y se cierra. También incluye una
breve especificación para cada botón, elem ento de menú y control que detalla las circunstan
cias bajo las cuales está activado y lo que sucede cuando se hace clic en él,
1,a especificación de cam po redondea el diseño de interfaz externa definiendo las carac
terísticas de desplegado de cada paite de la ventana, incluyendo el ordenam iento, los filtros, la
supresión, la selección y cl agrupam iento de características para las listas desplegadas. Cada
campo de la ventana se enlista al nivel de elem ento de datos, ju n to con las reglas en relación
con su opcionalidad, visibilidad y la habilidad del usuario para actualizarlo. La especificación
de cam po también debe incluir cualquier algoritm o de cálculo y ediciones de cam pos solos y
cam pos cruzados. Los requerim ientos de acceso de datos de la ventana también deben ser de
tallados com o parte de la especi fie ación de campo.
La especificación de diseño de interfaz exlem a es un docum ento flexible y negociable,
til nivel de detalle a que se llega en la especificación puede variar con la com plejidad de la apli
cación que se está tratando de construir. Aun con la aplicación de escritorio más pequeña, es
interesante saber qué tanto valor se puede obtener sim plem ente gastando unos cuantos m inu
tos para dibujar los pensam ientos propios en mi diagram a de navegación. C ada especificación
de diseño también debe incluir algún nivel de control de versión. Éste puede ser tan sim ple co
mo un registro de cam bios al inicio del docum ento o tan rigorista com o procedim ientos de re
gistro/despedida formales.
1 ,‘d especificación de diseño de interfaz externa establece la manera en que la aplicación
debe com portarse, pero todavía deja la puerta abierta al program ador para que tom e muchas
decisiones acerca de la manera de lograr ese com portam iento. El diseño no es el código. Si la
especificación de diseño está m uy cercana a la com pilación, ¡se ha llegado dem asiado lejos! K1
program ador hará frecuentem ente ajustes estéticos a la disposición que son dem asiado peque
ños para que merezcan la actualización del docum ento de diseño. Sin embargo, m uchas veces
cl program ador saldrá con una idea que m ejora la navegación o la ergononüa del diseño m ien
tras codifica la aplicación. Estos tipos de cambios deberán ser puestos a consideración del di
señador y actualizados en la especificación. U na vez que el diseño ha sido pasado a la
codificación, se deberá llevar un registro de cambios para que quienes prueban, capacitan y ha
cen docum entación técnica puedan m antenerse enterados de cualquier alteración.
La prueba de una GUI puede ser extrem adam ente difícil. La tarea se facilita cuando se
tiene un diseño externo detallado sobre el cual basar las pruebas. Se pueden derivar scrípts
de prueba a partir de la especificación de diseño en varios niveles. El nivel de pixel consiste de
una lista de revisión a partir de la cual quien prueba puede verificar que la aplicación satisfa
ce los estándares de aspecto y sensación deí proyecto. El nivel de campo verifica las propieda
des de cada cam po de datos. Las pruebas a nivel cam po necesitan verificar tanto los atributos
aislados de un cam po com o cualquier dependencia de cam pos cruzados que puedan hacer que
cambie el com portam iento del cam po bajo determ inadas circunstancias. La prueba a nivel ven
tana verifica el com portam iento de ta aplicación cuando la ventana se abre y luego cuando se
cierra. También verifica el tipo de ventana y prueba las rulas de navegación contra cl diseño,
lodo botón, elem ento de menú y control de la ventana también es probado contra la especifi
cación para la activación y la ejecución. A l nivel de evento de negocios los scrípts de prueba
están organizados para verificar cada uno de los eventos de negocios especificados en el m o
delo de eventos.
He presentado este m aterial a suficientes personas para ser capaz de predecir que algu
nos lectores pensarán que he ido dem asiado lejos con el diseño de interfaz detallado. Otros di
rán, “E sto seria muy bueno, ¡pero nunca sucederá en mi negocio!” Mi respuesta para quienes
dicen eso es, “Pruebe alguna de estas técnicas en su siguiente aplicación” . H ay m ucha proba
bilidad de que la claridad de pensam iento que se logra al hacer el diseño ahorrará horas incon
tables de repetir cl trabajo a la larga y producirá un producto m ucho más cercano a ias
especificaciones que lo que se hubiera entregado de no hacerlo así. Todo proyecto que he vis
to que abandona la especificación de diseño escrita ha pagado por ella posteriorm ente, ya sea
en una entrega retrasada, costos de prueba astronóm icos o un torrente de mejoras solicitadas
después de que se ha instalado cl sistema.
RESPUESTAS 339
EJERCICIOS
1. Enliste algunas m aneras en las cuales el diagram a de navegación de ventanas p u e
da usarse efectivam ente eti la fase de diseño externa de un proyecto.
2. ¿Cuáles son los dos aspectos de com portam iento principales de un bolón de com ando
o un elem ento de menú que deben incluirse en la especificación de diseño?
3. ¿Q uién es el publico para la especificación de diseño externa?
4. A N d so n se le ha pedido que adapte un pequeño sistem a de recepción de alm acén

en una aplicación clicntc/servidor para soportar varios usuarios. E l antiguo progra
ma de un solo usuario fue construido a principios de los ochenta usando al “D odo
U asc” , un producto de base de datos relacional ahora extinto p ara la PC. L a
estructura de base de datos del sistem a antiguo está bieu definida, pero la interfaz
antigua es u n caos. E l gerente de Nelson le ha asegurado que no hay una justifica
ción de negocios para aplicar reingeniería al proceso de negocios o integrar su sis
tem a cu otras aplicaciones. A dem ás, quiere qu e N elso n h ag a su trab ajo
rápidam ente. M ediante las técnicas que se describen en este libro, haga un esquem a
rápido de los pasos que debe tom ar N elson para adaptar este sistema.
5. ¿C uál m odelo o m odelos son una gran ayuda para establecer la activación de boto
nes adecuada?
6. E dgar desarrolla aplicaciones GUI usando una herram ienta que se com unica con la
base de datos casi exclusivam ente m ediante SQL, en donde los enunciados de se
lección para recuperar ventanas están íntim am ente asociados con cada ventana en
el código final, i ’dgar ha dicho en una reunión del personal que no cree que nece
site una especificación de diseño externo, él es lo suficientem ente bueno para sim
plem ente codificar el enunciado de selección p ara cada ventana usando su
generador de SQ L de su herram ienta GUI, de acuerdo con el conLenido de los cam
pos de la ventana y a la disposición de la base de datos. A hora que ya ha leído la
m ayor parte de este libro, ¿puede pensar algunas razones por las cuales a Edgar, o
a cualquier otro diseñador, se le deba solicitar que escriba una m iniespecificación
para la recuperación de cada ventana antes de que codifique, y de ser así, a qué ni
vel de detalle deberá especificarse la recuperación?
RESPUESTAS
1. La diagram ación de navegación de ventanas puede usarse para:
M odelar y discutir las rutas de navegación entre vanas ventanas de u na aplicación

antes de la codificación.
D iscutir el tipo de ventana adecuado para cada ventana.
D eterm inar la unidad de trabajo adecuada para el usuario decidiendo la m anera en

que el usuario guardará su trabajo y el alcance de la operación de guardar.
D iscutir si el usuario debe ser c a p a / de abrir varias instancias a la vez de cualquier

ventana dada.
C rear plantillas de m odelo de navegación estándar que puedan ser usadas a lo lar
go del proyecto.
2. Para cada botón de com ando y elem ento de m enú de una v entana se debe estable
cer: bajo qué circunstancias se activa o desactiva el control y lo que sucede cu an
do se ejecuta (se hace clic).
3. La especificación de diseño externo tiene m uchos públicos:
Los usuarios leen los panoram as, los diagram as de navegación, las disposiciones de
ventana y las descripciones de ventana p ara aprobar el diseño o sugerir cam bios al
diseño antes de la codificación.
Los program adores usan la especificación ju n to con cualquier especificación in ter

na que se proporciona para construir el código final.
Q uienes prueban usan la especificación de diseño externo para concebir escenarios

de prueba para la interfaz.
Los escritores técnicos y los instructores usan la especificación p ara crear materia!
de capacitación, ayuda en línea y docum entación del usuario p ara el sistem a final.
Los gerentes de proyecto usan la especificación para dividir el trabajo de codifica

ción entre varios program adores y com o una base para la revisión de las estim acio
nes de proyecto para cl trabajo restante del proyecto.
4. Lo prim ero que debe hacer N elson es pasarse unas cuantas horas reunido con los
usuarios del sistem a y el patrocinador del proyecto p ara determ inar los problem as
que se tienen con el sistem a actual y los objetivos de su reem plazo. Tam bién debe
recolectar algunos vectores de calidad que reflejen las expectativas sobre cl nuevo
sistem a (por ejem plo, deberá soportar varios usuarios, la interfaz deberá ser intui
tiva, etcétera). A partir de esta inform ación deberá escribir una pequeña especifica
ción de proyecto y presentarla a su gerente y usuarios para obtener un consenso
claro sobre lo que va a hacer. D eberá contar la cantidad de tablas y la cantidad de
ventanas que espera diseñar para que le ayuden a hacer una estim ación del esfuer
zo requerido para term inar cl proyecto, lom ando en cuenta que es un proyecto de
ajuste y la base de datos actual está en buena form a, N elson debe aplicar ingenie
ría inversa al m odelo de la base de datos y luego pasar la m ayor parte de su tiem
po concibiendo una nueva interfaz. N elson puede com enzar enlistando todo los
eventos de negocios soportados por cl sistem a actual y revisar la m anera en que la
interfaz antigua acom oda cada evento. D eberá escribir un registro de diccionario de
eventos para cada evento y hacer referencia a cualquier modo específico de código
del sistem a existente que tendrá que replicar cn el nuevo sistem a. Una ve/, q ue com
prenda los eventos soportados po r cl sistem a, deberá hacer un prototipo que recoja
algunas disposiciones y revisar sus ideas con los usuarios. Podría usar la diagram a -
ción de navegación cn pizarrón blanco para perm itir que los usuarios le ayuden a
diseñar la navegación en el nuevo sistem a. U na vez que están determ inadas la d is
posición y la navegación del nuevo sistem a puede escribir una especificación de d i
RESPUESTAS 341
seño externa, incluyendo el com portam iento ele cada botón y elem ento de m enú y
u na especificación interna en donde se establezca la recuperación para cada v en ta
n a y cualquier procesam iento interno requerido po r cl sistem a. D espués de una re
visión final de la especificación por los usuarios, pu ed e com enzar la codificación
(y si se dispone de otros program adores, tam bién pueden ayudarle a codificar).
M ientras está codificando, su gerente tiene la opción de poner a alguien para que
im agine planes de prueba y crcc m ateriales de capacitación para el diseño.
5. El diagram a de transición de estados, que enlaza los m odelos de eventos e in fo rm a

ción, le dice cuáles eventos son válidos o prohibidos, dependiendo del estado del
objeto sobre el que se aplica la acción. Tam bién se puede crear una m atriz de even
to / autorización de usuario para el proyecto a fin de que ayude a determ inar cuáles
grupos de usuarios (por ejem plo, personal de ventas, gerentes de crédito, em plea
dos de facturación, etcétera) están autorizados para realizar eventos específicos.
fi. E dgar debe escribir una m iniespeei fie ación para los requerim ientos de acceso de
datos de cada ventana. El propósito de la especificación es validar qu e la base
de datos sea capaz de seleccionar, identificar cualquier problem a de desem peño
potencial, guiar al program ador (que puede ser alguien diferente a tidgar) a través
de uniones com plejas, perm itir que el gerente del proyecto divida el esfuerzo de
codificación entre program adores con diversas habilidades y dar a los planeadores
de pruebas u n m apa de los datos necesarios para probar adecuadam ente la recu p e
ración de ventanas. C ada m iniespecificación de recuperación de datos debe incluir
una lista de todos los argum entos de entrada, una lista de todos los cam pos y ta
blas a partir de los cuales son seleccionados y cualquier instrucción sobre la m a
nera de un ir las tablas y aplicar cualquier criterio de selección.
C a p ít u l c
12
EL DISEÑO DE
COMPONENTES INTERNOS
INTRODUCCIÓN
El último capítulo técnico de este libro trata sobre la tarea del diseño de los com ponentes in
ternos que determ ina la organización del código dentro del sistema. La m anera en que se esco
ja la organización do las entrañas de la aplicación dependerá cu gran m edida de las capacidades
de los lenguajes de desarrollo que se escojan. No todos estarán creando estructuras orientadas
a objetos en los sistemas, pero com o los lenguajes están tendiendo rápidam ente hacia esa di
rección, dedico la m ayor parte de este capítulo a ese tema. En este capítulo trato los conceptos
principales de la orientación a objetos, incluyendo la ene ap su 1ación, el o cuitam iento de la in
form ación/im plem entación, la persistencia, la identidad de objetos, las ciases contra los obje
tos, los m ensajes, ia herencia y el polim orfism o. D espués de los puntos básicos, prom uevo la
idea de la creación de dominios separados de clases en la aplicación para separar las clases fun
dam entales de las que están en los dom inios arquitectónicos, de negocios y de aplicación.
344 Capítulo 12 / EL DISEÑO DE COMPONENTES INTERNOS
Nuestra panorám ica de orientación a objetos concluye con una discusión sobre la derivación
de clases de los dom inios de negocios y de aplicación a partir de los m odelos de inform ación
y de eventos. El capítulo term ina con un breve panoram a del tipo de docum entación de diseño
que debe existir para los activadores de base de datos y procedim ientos alm acenados, así co
mo una referencia rápida sobre las técnicas de diseño estructurado que pueden em plearse en
los com ponentes m ás tradicionales del sistema.
¿QUÉ ES EL DISEÑO DE COMPONENTES INTERNOS?
El diseño de com ponentes internos es el plano para el código de la aplicación. La forma del
plano estará influida en gran m edida por el paradigm a y capacidades de los lenguajes de des
tino que se em plearán para construir el sistema. A ctualm ente es muy probable que un sistema
grande d iente/servidor pueda incluir algo de código orientado a objetos, algo de S Q 1 a lg o de
procedim ientos alm acenados y hasta un poco de buen código procedural estilo 3GL. El dise
ñador deberá escoger la m ezcla de técnicas de diseño que defina m ejor la estructura del siste
m a que pretende construir.
Hsto significa que un diseñador en los am bientes cliente/servidor actuales necesita com
prender la orientación a objetos, el acceso a bases de datos relaciónales (SQL), los activadores
y los procedim ientos alm acenados de bases de datos, así com o el diseño estructurado tradicio
nal. D ebido a que cl acceso a bases de datos relaciónales, los activadores, los procedim ientos
almacenados y el diseño estructurado ya son am pliam ente com prendidos y están bien docu
m entados en nuestra industria, enfocaré este capítulo principalm ente hacia ios conceptos orien
tados a objetos.
PANORAMA DE LA ORIENTACIÓN A OBJETOS
No pretendo tratar de cubrir todo lo que se necesita saber acerca de los objetos en un solo ca
pítulo. Me tendría que poner en cola detrás de cien autores que han dedicado volúm enes com
pletos al tema. Tam poco pretendo prom eter que la 0 0 resolverá todos los problem as de
negocios m im plicar que los objetos pueden ayudar a conseguir una cita un viernes por la no
che, En vez de ello, el propósito de este capítulo es tratar algunos de los conceptos básicos de
la orientación a objetos y m ostrar los modelos que se han presentado anteriorm ente en este li
bro que son utilizados en el diseño de un sistem a orientado a objetos.
A lo largo de los últimos treinta años, los lenguajes de programación para sistemas de n e
gocios han evolucionado hacia dos especies distintas, aquellos que hacen el procesamiento
(por ejemplo, COBOL) y aquellos que m anejan el alm acenam iento y recuperación de datos (por
ejemplo, SQL y los sistemas de manejo de bases de datos relaciónales, tales como Oracle® o
SY B A SE51). Estas criaturas han sobrevivido mientras otras se han extinguido debido a su espe-
cialización sobre un aspecto particular del software de negocios. Aunque puede polemizarse
sobre la “supervivencia d d más apto”, probablem ente estaremos de acuerdo en que la “ super
vivencia del m ejor com ercializado” crea su propia forma de darwimsm o. Esta dicotom ía en la
especializaeión de los lenguajes ha creado una grieta paralela en los establecimientos de IT. Los
equipos tradicionales de program adores hacen código y los adm inistradores de bases de datos
tienden hacia el repositorio em presarial de todo el conocimiento. Los dos cam pos rara vez se
encuentran juntos, excepto durante la fiesta de N avidad o los días de campo de la compañía.
PRINCIPIOS BASICOS DE LA ORIENTACION DE OBJETOS 345
La orientación a objetos fuerza a que estén nuevam ente juntos el proceso y los datos. R e
conoce que el procesam iento existe solam ente para m anejar los datos y que los datos sólo exis
ten para dar soporte a los procesos. Principalm ente, los procesos y los dalos sólo son necesarios
para perm itir que el sistem a responda adecuadam ente ante los eventos del negocio. Tal vez la
orientación a objetos pondrá juntos a los fanáticos del proceso y a los fanáticos de los datos p a
ra que trabajen juntos h a d a un objetivo com ún. La falla de esto lleva el riesgo de crear una
nueva clase de fanáticos de objetos, convencidos de que los otros dos grupos son un montón
de dinosaurios que desaparecerán con la eaída de un asteroide venidero..
Los lenguajes orientados a objetos han estado con nosotros desde haee muchos años. Las
prim eras investigaciones en los años sesenta y setenta hicieron de los lenguajes orientados a
objetos una realidad com ercial antes del final de los ochenta. M uchos de quienes los adopta
ron desde el principio encontraron una aplicabilidad instantánea en sistemas de tiempo real en
donde cl softw are está orientado hacia cl m anejo de objetos del mundo real, tales com o brazos
de robots en plantas de ensam blaje o en alerones y trenes de aterrizaje de aeronaves. No fue si
no hasta que hubo una gran aceptación y dem anda para la interfaz gráfica de usuario que la 0 0
hizo su gran entrada en los sistem as de negocios.
Una ventana es uno de estos objetos naturales. U sém osla para ilustrar algunos de los
principios básicos de la orientación a objetos y luego dem os un vistazo a la manera en que es
tos conceptos pueden ser generalizados para aplicarse a objetos que son más aplicables a la ad
m inistración del negocio.
PRINCIPIOS BÁSICOS DE LA ORIENTACIÓN A OBJETOS
Por ahora ya deberá estar fam iliarizado con el concepto de ventana. Ignorando al contenido del
área de presentación de la ventana, la ventana m ism a tiene un com portam iento definido obser
vable. La mayor parte de este com portam iento está disponible ante uno por los buenos oficios
de la herram ienta de desarrollo GUI. cuyos creadores se han tom ado el tiempo para codificar
las clases de ventana básicas. Sólo piense sobre ¡as cosas que se pueden hacer con una venta
na. L a puede abrir. La puede cerrar. La puede m axim izar o m inimizar. También puede elegir
m overla o redim ensionarla.
Poniéndonos nuestro sombrero de programador, podríam os pretender que se nos hubie
ra pedido codificar la prim era ventana del mundo. Podríamos fácilm ente ver que tendríamos
que escribir algo de código para las siguientes funciones: abrir, cerrar, maximizar, minimizar,
m over y redim ensionar. Habiendo practicado el diseño estructurado a través de los años, tal
vez hubiéram os supuesto, en form a natural, que deberíam os crear m ódulos separados para es
tas funciones a fin de dism inuir la problem ática de la com prensión y m antenim iento de cual
quier función y para increm entar la probabilidad de que las funciones pudieran ser reutüizadas
por otros programas que pudieran tener requerim ientos similares (figura 12-1).
N ecesitaríam os algún tipo de dato para representar nuestra ventana, sus dim ensiones, su
estado (si está m axim izada o m inim izada o si está activa o inactiva) y su ubicación en el m o
nitor de presentación. Hay muchas formas para representar las dim ensiones y posición de la
ventana. Una forma perfectam ente adecuada es recordar las coordenadas x y y de dos esquinas
diagonales. Otra alternativa es recordar las coordenadas de una esquina y las dim ensiones de
altura y anchura de la ventana (figura 12-2). A quí entra el poder de la orientación a objetos. Su
poniendo que una ventana siem pre va a ser un rectángulo, en realidad no im porta cuál se use.
346 Capítulo 12 i EL DISEÑO DE COMPONENTES INTERNOS
A b r ir Cerrar M a x i m iz a r
v e n ta n a ventana v e n ta n a
Minimizar M over R e d im e n sio n ar

v e n ta n a v e n ta n a ven tan a
F ig u r a 12-1. M ódulos de las funciones de ventana.
(x,y) (x,y)
(xry)
Figura 12-2. Al m enos dos buenas form as para representar una ventana.
Encapsulación
Hn los lenguajes 0 0 , a los datos de un objeto se le llaman variables. Los procesos que yo re
presento com o m ódulos pequeños son llamados métodos. Hn la orientación a objetos los m é
todos están agrupados alrededor de las variables del objeto. Los métodos pueden ser llamados
directam ente por otros objetos, pero las variables sólo pueden ser m anejadas por los m étodos
dei objeto mismo. A esto se le llam a encapsulación (figura 12-3). Hn nuestro ejemplo, los pro
cesos que tal vez quiera llam ar en una ventana son métodos, agrupados alrededor de las varia
bles que se usan para representar internam ente a ia ventana. Por lo tanto, los datos de la ventana
han sido encapsulactos por los métodos a los que se les perm ite un aeeeso directo a los datos.
Ocuttamiento de la información/implementación
La siguiente cosa que hace que una estructura de program ación sea un objeto es el hecho de
que kft nom bres, contenido y organización de las variables dei objeto no son visibles para el
mundo externo.- lâ inform ación contenida dentro de ellas está oculta. A unque sospeche la in-
1 !:.n este capítulo habiendo ia suposición de que las variables son privadas y los métodos son públicos,
aunque m achi» loriûaics soporten c l concepto de variables públicas y métodos privados.
form ación que está contenida dentro de un objeto, nunca se podría estar seguro de su implc-
m ent ación específica. A esto se le llam a acuitam iento de. la Inform adón/im plem entación.
M ientras sepam os cóm o pedirle a nuestra ventana que se redim ensione o m ueva por sí misma,
podem os vivir en la feliz ignorancia sobre la m anera en que representa su tamaño o posición
internamente. La encapsulación, com binada con el ocultam iento de la in fo n nación/i mp le m en
tación, hace que las clases de objetos bien elaboradas sean mucho m ás elásticas para absorber
al devastador efecto de propagación de onda del m antenim iento y los cam bios de m ejoram ien
to que com o lo es el código procedural tradicional. El pelotón de métodos que rodean a la v a
riable resguarda a los dalos de las insurrecciones el mundo externo.
F ig u ra 12-3. L os m étodos de ventana que eneapsulan a las variables de ventana.
Estado persistente
Tai vez se pregunte, “¿Q ué es lo que es tan diferente acerca de los objetos? ¡Podría hacer lo
mismo con código tradicional!” . Podría usted estar com pletam ente en lo cierto eon esta aseve
ración, pero aquí es doride los objetos com ienzan a divergir de los programas tradicionales.
Cuando se hace una llamada a program a o subrutina en un lenguaje tal com o el COBOL, se le
pasan algunos parám etros de entrada, entra en acción, ejecuta su procedim iento y regresa al
gunos parám etros de salida antes de que muera. A unque el módulo sea llamado nuevam ente a
servicio, 110 recuerda el haber sido llamado antes.
Si el perro de su fam ilia se com portara com o la subrutina, cada noche cn que regresara
a casa lo saludaría un perro diferente. Podría actuar igual, ladrándole, tirándolo al suelo y la
miéndole la cara, pero no recordaría haber hecho algo así en ninguna encarnación anterior.
D espués de que hubiera term inado de saludar al perro se desvanecería, y un nuevo perro se le
proporcionaría al inicio del ritual de bienvenida de la tarde de mañana.
A diferencia del módulo de subrutina o program a tradicional, un objeto se queda por ahí
y recuerda quién es mucho después de que ha term inado su ejecución. A unque este es un com
portam iento deseable en los perros, es particularm ente conveniente en las ventanas, para que
cuando decida salir de la aplicación de captura de pedidos y ponerse a jugar Solitario, la ven
tana original no desarrolle un caso fatal de am nesia m ientras está ausente.
IDENT1DAD DE LOS OBJETOS
Para que un objeto sepa quién es debe tener una identidad única. La tarjeta de identidad del ob
jeto (o placa del perro) es llam ada controlador del objeto (figura 12-4). Los controladores de
objeto son asignados por la aplicación cuando se crea un objeto. En lo referente a cóm o se g e
nera el controlador, sólo lo sabe la com putadora. El program a asignará una variable para repre
sentar al controlador del objeto, el cual nos proporciona la com odidad de una identidad única
sin preocupam os con la im plem entación. D os m anipuladores de objeto nunca son iguales, y un
objeto conservará su controlador durante toda su vida.
perrol
Figura 12-4. Control íLdores de objeto.
Clases contra objetos
Los objetos son las cosas que existen al momento de ejecución. Las elases son las plantillas a
partir de las cuales se crean los objetos. Las clases es lo que se diseña y codifica. E l patrón p a
ra la creación de la ventana está guardado en la clase Ventana. Si se fueran a crear dos instan
cias de la cla.se Ventana, el sistem a asignaría dos controladores de objeto distintos, uno para
cada objeto. Los siguientes enunciados darían com o resultado Ja creación de dos nuevas ven
tanas. ventanal y ventana2, apuntando cada una a controladores de objeto únicos en memoria
(figura 12-5).
tot -.r-ins 1 : VENTANA : VKNTANA. 1U c rv o ;
var • .• . :".“EÍÍTJ\NA : • V K M T 7 \N A .n u c v ;;;

Figura 12-5. ventanal y ventana2 con sus controladores de objeto.
Nuestras dos instancias de la clase Ventana, los objetos ventanal y venlana2, están equi
pados con todas las variables y m étodos que vienen con la clase. Sin em bargo, pueden llevar
vidas com pletam ente separadas. Los valores del conjunto de variables de ventanal están com
pletam ente separados de los de ventana2. A unque contienen un conjunto de métodos idéntico,
cl código se ejecuta independientem ente sobre cada objeto.
Com o instructor de seminarios a veces m e pregunto con un grado de tem or lo que recor
dará un estudiante después del adoctrinam iento y pequeños ejercicios de una semana. Un día
me encontré a un com pañero de trabajo que acababa de regresar de un sem inario sobre diseño
orientado a objetos. Anunció jubilosam ente que ‘" los objetos son como galletas y las clases son
los m oldes de galletas” , Por dentro tuve una sensación de descanso de que hubiera regresado
a casa con ambas cláusulas del enunciado intactas. M e espanta el pensar lo que hubiera pasa
do si sólo hubiera recordado la prim era m itad.- El instructor tuvo éxtto al dar la diferencia en
tre objetos y clases.
Mensajes
Hasta ahora hemos creado estructuras de procesos y datos hábilm ente encapsulados que pue
den ser creados sobre pedido a partir de las clases y pueden desarrollar vidas satisfactorias en
form a independiente, sin em bargo no hem os dicho nada acerca de la m anera en que se com u
nican los objetos. Com o puede suponer, se requiere cl trabajo en equipo de m uchos objetos p a
ra realizar cualquier actividad significativa en un sistem a de software. Los objetos colaboran
al m om ento de ejecución enviándose mensajes entre ellos.
Un mensaje es la form a en que un objeto le pide a otro objeto que ejecute alguno de sus
métodos. Para que un objeto envíe un mensaje a otro objeto debe conocer la identidad (nom
bre de variable o controlador) dcl objeto de destino, el nom bre del m étodo deseado y. o p cio
nalmente, cualquier argumento que deba ser incluido en cl m ensaje (argum entos de entrada y
salida, tam bién conocidos com o firm a del mensaje). A unque las variables internas del objeto
están ocultas a la vista, el nom bre del método y el protocolo del m ensaje debe ser conocido
com pletam ente por todos los objetos que desean com unicarse con él.
1 Un estudiante menos atento podría haber recordado “los objetos son eomo galletas. Las galletas san huenas.
I’or lo (.auto, los objetos son buenos”. Su gerente hubiera salido y contratado :i un chef de repostería para el
proyecto.
Para decirle a nuestra ventana que se m ueva por sí misma, el objeto que envía el m ensa
je (tat v e/ un ratón) debe saber el nom bre dei objeto (ven ta n a l), el nom bre del m étodo (m o
ver) y los argumentos requeridos (digamos, nuevas coordenadas x, y para la esquina superior
izquierda). K! resultado podría ser un mensaje:
v t:n t.filia l ..Tuve ¡x , y )
El que el método de m over requiera nuevas coordenadas x,y, o tal vez un vector y una
distancia, debe ser conocido por todos los objetos que pudieran pedir a la ventana que se mo
viera. Por lo tanto, los cambios hechos a los argumentos requeridos de un método pueden te
ner un dram ático efecto de propagación de onda en un sistem a orientado a objetos.
Los m ensajes entre objetos también pueden m ostrarse en el diagram a objeto-com unica
ción que m uestra gráficam ente los m ensajes entre los m étodos de diversos objetos al m om en
to de ejecución (figura 12-6). Variantes sim ilares de i a com unicación de objetos son
m encionadas en algunas m etodologías OO com o el modelo de objeto dinám ico o diagrama
evento-rastreo.
F igura. 12-6. Un diagram a objeto-com unicación.
Para este libro he escogido la OODN (notación de diseño orientado a objetos) hecha por
Page-Jones, Constantine y Weiss debido a su expresividad, sim plicidad y consistencia con los
sistemas de diseño tradicionales.3 Las clases se m uestran en el diagram a com o rectángulos con
la parle superior en forma de domo. El sím bolo que es cn parte círculo y cn parte rectángulo
refleja el hecho de que los objetos son en parte proceso y en parte datos. La forma de “lá p id a ’
también es fácil de trazar y es claram ente distinguible del sím bolo de tipo de entidad. I ,os m é
todos se enlistan en i'orma vertical en la parte rectangular de la clase. La clase se puede dibu
jar con o sin sus métodos enlistados, o se puede escoger y m ostrar solam ente los m étodos que
son relevantes para el diagram a. A l enlistar los métodos en la clase, las flechas que indican
mensajes pueden trazarse directam ente desde el método que envía el m ensaje hacia el método
que recibe el mensaje. Los argumentos del mensaje pueden m ostrarse en la flecha del m ensa
je o en cl método de destino. La especificación interna para una clase es texto y debe incluir
un listado de todas las variables y una m iniespecificación de proceso para cada método.
I’agc-Joncs. Constantine. Weiss, 1990. Para una revisión más completa de la. OODN, vea Pag «-Jones, 1995.
Herencia
D igam os que mientras analizamos nuestra ventana descubrimos; algunas pequeñas diferencias
entre diversos tipos de ventanas. A lgunas ventanas necesitan verificar si ha sido cam biado al
go del contenido mostrado, para que cuando el usuario trate de cerrar la ventana, ésta pueda
preguntar si se desea guardar el trabajo. A unque esto es un com portam iento razonable y cortés
para una ventana actualizable, no es un eoinportam iento que se requiera para una ventana no
actualizable.
En vez de clonar todo el código de ventana y duplicarlo en otro tipo de ventana, pode
mos explotar la herencia para m antener el código residente en una clase de objeto y, a la vez,
ponerlo a disposición para otras clases de objetos. En este ejem plo podem os hacer que nuestra
ventana actualizable sea una subclase de nuestra ventana genérica (la supe reíase). M ediante la
declaración de que la supcrclase Ventana es el predecesor o m adre de la subclase Ventana A c
tualizable, todos los métodos y variables definidas en la su per cía se se ponen a la disposición
de la subclase sin tener que replicarlos en el código.
Si este concepto le parece familiar, debe serlo. Los m ism os principios subyacentes que
guian los supertipos y subtipos de entidades en el modelo de inform ación tam bién se aplican a
las superclases y las subclases de objetos. A unque los supertipos y subtipos de entidad se en
focan a los datos, concretam ente en cuáles atributos y relaciones se aplican en la jerarquía de
tipo, las superclases y subclases de objetos añaden la com plejidad de determ inar cuáles m éto
dos deben residir en los diversos niveles de ía jerarquía de clases.
F ig u ra 12-7. H erencia.
El sím bolo O O D N para la herencia es una flecha ancha trazada desde la parte superior
de la clase descendente y que apunta hacia arriba a la parte inferior de su madre, lin la figura
12-7 vemos que la clase Ventana A ctualizable hereda de la clase Ventana. La clase genérica
fentana puede tener un método llamado Cerrar. La subclase Ventana Actualizable no necesi-
a tener un método correspondiente para Cerrar. Cuando cream os un objeto, ventana3, como
m iem bro de la clase Ventana A ctualizable, hereda autom áticam ente todas las capacidades de
finidas previam ente por la clase Ventana.
v a r veilLim;:.'! . VEXTANA_.ACrJAL.: /ALÍLE : VyNT?^._ACTi;A; .■I/ARLE. rv.:c:VO ;
Si se ie dice a Ventana A ctualizable que se "cierre” , puede ejecutar el método Cerrar de

su madre. Sin embargo, si se quiere que la clase Ventana Actualizable se com porte en form a
diferente, se puede añadir un método C errar a Ventana Actualizable que revise para ver si el
usuario ha hecho cam bios y detenga el cierre de la ventana hasta que el usuario haya guarda
do su trabajo o haya manifestado su intención de cerrar de cualquier forma (figura 12-8).
F ig u ra 12-8. El m étodo Cerrar de Ventana Actuaüuible se sobrepondrá

¡il m étodo Cerrar de la m adre.
Si Ventana Actualizable tiene su propia versión del método Cerrar, cl método de la sub
clase se sobrepondrá a cualquier m étodo que tenga el mismo nom bre en la supere lase/’ Hn es
te ejem plo la herencia nos ha perm itido extender las capacidades de la aplicación m ediante la
creación de subclases que se com portan en una forma ligeramente diferente a la superclase, sin
alterar el código de la clase madre.
La herencia com o facilidad para la extensibilidad, com binada con su habilidad para ex
traer el com portam iento com ún, hace que sea una de las características m ás pregonadas de la
orientación a objetos. Al igual que cualquier concepto poderoso, tiene sus retos. La reutiliza
ción rara vez sucede por accidente, y las extensiones sin control a una jerarquía de clases pue
den rápidam ente dar nna apariencia de un diseño razonable y m antenible “fuera de la ventana”.
■' Algunos ¡engTiáioi proporam iac a] proara ni ador la opción de anadir código en el método de subclase para
cl código en la l', ‘ apernaseis).
¿PORQUÉ OBJETOS? 353
El supertipcado y el subtipeado se encuentran cutre las habilidades m ás difíciles de dom inar cn

cl modelado de inform ación. El modelado de las superclases y las subclases no es nadü fácil.
Polimorfismo
Imagine que un usuario trata de salir de una aplicación que tiene m uchas ventanas abiertas. El
código de Salir envía un m ensaje a todas las ventanas abiertas dándoles instrucciones para que
se c ia re n por sí mismas. Q uien envía el mensaje no necesita saber si las ventanas de destino
son de la variedad actu alizab a o no actualízable. El com portam iento del método Cerrar de ca
da ventana será determ inado al m om ento de ejecución por la posición del objeto de destino en
la jerarquía de clases. La habilidad de los am bientes orientados a objetos para determ inar el
fragmento de código exacto que debe ejecutarse al m om ento en vez de hacerlo cuando el pro
gram a se com pila es llamado enlace dinámico. El resultado es que el m ism o mensaje hacia el
objeto puede dar com o resultado un com portam iento diferente de acuerdo a los m étodos que
se ejecutan realm ente. E sta característica es conocida com o polim orfism o, un térm ino deriva
do del griego y que significa “muchas form as’7.
¿POR QUÉ OBJETOS?
Un objeto es una com binación natural entre procesos y datos en una sola estructura de progra
mación que tiene una identidad única, presenta una interfaz definida hacia cl mundo extem o, y
que oculta su im plem entación interna, Hl propósito de la técnica es separar las alternativas de
im plem entación, del servicio que proporciona cl objeto. A través de ocultar las decisiones
de diseño podem os reducir cl efecto de propagación de onda potencial al hacer cambios al sis
tema. Un conjunto de clases de objetos bien elaborados puede prom over la reusabilidad al ex
traer la factorización del com portam iento com ún. La separación de clases en dom inios de
proveedores de servicios, tales com o clases de presentación, de servidores de datos, de comu
nicaciones y de negocios, prom ueve la esp ecial^ ación e increm enta la oportunidad de que las
clases puedan ser reutilizadas por otras aplicaciones que requieran la m isma funcionalidad. La
habilidad de un objeto para conservar su identidad hace que los lenguajes orientados a objetos
sean especialm ente muy adecuados para sistemas distribuidos que tienen gran cantidad de m en
sajes entre com ponentes de software físicam ente remotos.
Por favor, no olvide que en ningún m om ento he afirm ado que la orientación a objetos sea
fácil. No es una panacea para todos los problem as de software y llega eon una curva de apren
dizaje muy em pinada y dem anda diseño y docum entación rigurosos.
En la sección anterior traté brevem ente los principios básicos de la orientación a objetos
para que pudiéram os pasar a una discusión sobre la derivación de clases de negocios a partir
de nuestros m odelos esenciales. Para una discusión detallada sobre los términos orientados a
objetos y una referencia excelente sobre los conceptos y notación de diseño recom iendo en
gran m edida el libro de M eilir I’age-Joncs, What Every Program m er Should Know A b o u t O b
ject-O riented D esign?
354 Capítulo 12 / EL DISEÑO DE C O M P O N E N T E S INTERNOS
¿QUÉTAN ORIENTADO A OBJETOS ES SU PROYECTO?
] in esta sección trataré de poner la orientación a objetos en perspectiva haciendo preguntas que
se plantean com ún m ente cuando los des arrolladores pasan de un am biente m ainfram e al m un
do cliente/servidor.
"Nuestra aplicación tendrá una GUI. ¿Esto hace que esté

orientada a objetos?"
N o necesariam ente. I -as ventanas, botones y menús son objetos naturales de la interfaz. La ló
gica de la aplicación de negocios que reside tras las ventanas puede o no ser orientada a obje
tos. D epende com pletam ente de la capacidad del lenguaje de desarrollo y la m anera en que se
le diseña. Por lo general, la generación actual de herram ientas de desarrollo cliente/servidor cae
en dos grandes categorías, aquellas que tienen capacidades orientadas a objetos lim itadas y
aquellas que son am bientes de desarrollo orientados a objetos com pletos. E sta distinción 110
siempre está en la apariencia. Si la herram ienta adopta cualquiera de los principios que he m en
cionado en este capítulo o contiene cualquier cosa que se parezca vagam ente a un botón o a
una ventana, es probable que el vendedor ponga las palabras “orientado a objetos” en la caja.
M uchas herram ientas GUI populares primero fueron escritas para aprovechar los obje
tos de la interfaz gráfica de usuario, pero la lógica del negocio se ejecuta eon tina m ezcla bas
tante estándar de guiones SQL y tipo 3GL. Estas herram ientas están adoptando cada vez más
los principios 0 0 , haciéndolas m ás orientadas a objetos en cada versión subsecuente.
La segunda ola de herram ientas de desarrollo cliente/servidor han sido escritas desde sus
cim ientos específicam ente para el desarrollo orientado a objetos. Ellas incluyen lenguajes com
pletam ente orientados a objetos que perm iten una separación com pleta de los objetos del ne
gocio con relación a la mecánica de la interfaz. En lenguajes realm ente portátiles esto permite
al diseñador que cree clases de objetos que son independientes de la plataform a y que pueden
ser m ovidas del cliente al servidor o a cualquier nivel (tier) intermedio para lograr un desem
peño óptimo.
"¿Somos orientados a objetos aunque tengamos

una base de datos relacional?"
Si se usa un lenguaje orientado a objetos sobre una base de datos relacional se está viviendo
en ambos m undos. Los objetos existen en el am biente del momento de ejecución, pero cuando
se guarda inform ación los objetos descargan sus datos en una base de datos relacional. La com
binación de ambos modelos es conocida com o discordancia de im pedancia, un térm ino que se
tom ó prestado de la ingeniería eléctrica. M uchas de las herram ientas de desarrollo cliente/ser
vidor actuales manejan esta discordancia de im pedancia habilidosam ente, proporcionando cla
ses de objetos de servicio de datos que m anejan la com unicación entre la aplicación y la base
de datos, aliviando al program ador de este problema.
El tener una base de datos relacional no hace que un proyecto sea inferior a otro que usa
una base de dalos orientada a objetos. La base de datos relacional es muy popular en sistemas
de negocios, debido principalm ente a que permite que la organización recolecte un amplio ran
go de inform ación y posponga muchas de las decisiones sobre cóm o usarla posteriorm ente. A un
SELECCIONE EL DESTINOY LUEGO MAPEE LA TÉCNICA 355
que esto tiene menos sentido para los sistemas en tiempo real, es una realidad en ios sistemas de
negocios debido simplemente a la naturaleza com petitiva siempre cam biante del propio negocio.
SELECCIONE EL DESTINOY LUEGO MAPEE LA TÉCNICA

HACIA EL DESTINO
Si tuviera que resumir mi filosofía del diseño sería, "Seleccione los lenguajes de destino más ade
cuados para satisf acer el plan general y luego mapee la técnica de diseño hacia cl destino’7. El do
cum ento de diseño es el plan para cl sistema que va a ser construido, y al igual que un plano
arquitectónico, se quiere que el plano se vea muy similar a lo que se pretende construir. Lo que
todo esto significa para usted actualmente com o desarrollador de sistemas de negocios es que ne
cesitará estar bien afianzado en los conceptos del modelado de la información y el diseño de ba
ses de datos relaciónales, y también com prender los principios de la orientación a objetos.
He escogido cl modelado de inform ación y el modelado de eventos com o los principa
les modelos en este libro específicam ente por que el am biente de destino cliente/servidor sigue
siendo una bolsa de trucos mezclada. Los modelos son adecuados para el modelado de los tres
aspectos del sistema, datos, procesam iento y com portam iento. Las técnicas también proporcio
nan al analista la capacidad para posponer la declaración de las clases del negocio hasta la eta
pa del diseño y basar el diseño en las capacidades del am biente de destino. U na de las
diferencias principales entre cl modelado de inform ación y el modelado de objetos es que en
el modelado de objetos el analista debe también encontrar la única m ejor m orada para los m é
todos y, en cambio, eon el m odelado de inform ación los requerim ientos de procesam iento del
sistem a están alojados en el modelo de eventos y no se com binan con los datos sino hasta que
se com ienza a declarar a las clases del negocio.
Para los proyectos que estarán utilizando bases de datos relaciónales com binadas eon
lenguajes orientados a objetos yo creo que es un enfoque adecuado el em plear el modelado de
inform ación para llegar a un diseño de base de datos sólido. Un buen m odelador de clases
de objetos también puede llegar a un diseño de base de datos similar, mas no idéntico, pero ten
drá que hacerlo extrayendo la estructura de los datos que necesitan ser alm acenados a partir del
m odelo de clase estático. M ientras el am biente del m om ento de ejecución continúa su tenden
cia hacia la orientación a objetos y si los sistemas de negocios continúan apoyándose en gran
m edida en un depósito de datos relaciónales, los analistas, diseñadores y desarrolíadores nece
sitarán m antener sus pies firm em ente plantados en am bos campos.
Para m uchos establecim ientos ia orientación a objetos se está colando en los sistemas de
negocios por la puerta trasera en vez de inundarlo todo com o una m arejada. La 0 0 requiere un
cam bio de m entalidad tan dram ático al nivel de codificación de líneas que se lleva tiempo p a
ra que un equipo de program ación se vuelva, a entrenar. U na vez que están dominadas las es
tructuras de program ación, el desarrollador puede pasar a niveles de abstracción más altos
sobre los principios del diseño orientados a objetos. Todo esto lleva tiempo, y está afectando a
m uchos establecim ientos de IT en forma sim ultánea con el cam bio a bases de datos relacióna
les desde la tecnología de archivos planos, y con el cam bio hacia GUIs y arquitecturas clien
te/servidor. La OO debe ser tom ada cuidadosam ente, con sobriedad y con una clara
com prensión de la curva de aprendizaje requerida y el costo contra los beneficios esperados.6
■' Sce T'age-Jones, 1992, “The Importance of Bcmg Bm cst”

356 Capítulo 12 / EL DISEÑO DE C O M P O N E N T E S INTERNOS
DOMINIOS DE CLASES DE OBJETOS
liti el capítulo 8 se presentó el concepto de capas de software que separan com ponentes en
áreas de especialidad, presentación, lógica del negocio y m anejo de datos. A unque la noción
del pastel de softw are de tres capas es útil para el m odelado arquitectónico, los com ponentes
internos requieren una taxonom ía m ás granular.
Las clases de objetos también pueden agruparse en dom inios de acuerdo al papel que d e
sem peñan en el sistema. Los niveles de dom inio son los dom inios fundam entales, arquitectó
nicos, de negocios y de aplicación (figura 12-9).
Aplicación
^CalendarizadofS R ec o n o c e d o r d e e v e n to s
de pedidos
M a n e ia d o r d e e v e n to s
Baja
reusabilidad
Negocios
Papel 1
R e ía rió n
: A trib u lo
Arquitectura "
Interfaz humana
Administración de base
de datos
Cirn teñios
C o m p o n e n te s básicos A lta
reusabilidad
F igura 12-9. Dominios de clases.
El dominio fundamental
Las clases del dominio fundam entales forman los bloques o com ponentes básicos a partir de los
cuales se construyen todas las aplicaciones. E n lenguajes orientados a objetos puros, hasta
los tipos de datos tradicionales son clases (por ejemplo, entero, booleano, hora, dinero)- Las
ciases del dom inio fundam entales gozan de un nivel de reusabilidad mayor que cualquier otro
dominio. Son am pliam ente em pleadas para realizar tareas por los m iem bros de dominios más
altos. Para casi todos ios proyectos, el conjunto com pleto de clases fundam entales deberá ser
adquirido listo para usarse can el proveedor de herram ientas de desarrollo.
DOMINIOS DE CLASES DE OBJETOS 357
El dominio arquitectónico
El dom inio arquitectónico incluye clases que se com unican con el hardw are y que administran
ia interfaz hum ana (incluyendo todos los objetos de la interfaz gráfica de usuario, tales como
ventanas, botones, iconos y menús). También están agrupadas en el dom inio arquitectónico las
clases que adm inistran el alm acenam iento y recuperación de inform ación de la base de datos,
la com unicación m áquina a m áquina a través de la arquitectura cliente/scrvidor y la com unica
ción con periféricos tales com o faxes, im presoras y otras interfaces electrónicas. Las clases del
dom inio arquitectónico frecuentem ente son específicas para el hardw are seleccionado. El m an
tener reunido todo cl código específico del hardw are en el dominio arquitectónico permite que
se aprovechen los rápidos avances en tecnología cam biando la caja de hardw are sin tener
que reescribir el código de las clases de negocios o de aplicación.
A la m ezcla de com ponentes de diferentes dominios en una sola clase se le llam a cohe
sión de dom inio m ezclado (o envenenam iento de dom inio, com o me gusta llamarlo). Se debe
rá ser capaz de llam ar a una clase de negocios, tal com o factura, y decirle que se im prim a por
sí m isma. La clase de negocios es responsable del conocim iento de cuál inform ación debe im
prim ir, pero no deberá preocuparse en nada por el tipo de im presora que se va a usar. El pro
tocolo para la com unicación con la im presora debe ser manejado por una clase de dom inio
arquitectónico, digamos, impresora. Las dos clases separadas deben trabajar juntas para lograr
el trabajo de impresión.
M uchas de las clases del dom inio arquitectónico también llegarán al proyecto por corte
sía de los proveedores de las herram ientas de desarrollo. Estas com pañías se han tom ado el
tiempo para codificar ventanas, botones de com ando, vistas prelim inares de im presión y con
troladores de dispositivo, por lo que uno ya no tiene que hacerlo.
El dominio de negocios
KI dom inio de negocios incluye clases que son inherentes a la conducción de los negocios
dentro de una industria específica. Los dom inios de negocios incluirán clases que m uchos de
los com petidores encontrarán útiles. Cla-ses com o límite de crédito de cliente, facturas, p e d i
do de pizzas y envío calendarizado residen en el dom inio de negocios. H ay un m ovim iento en
tre varios proveedores em presariales para crear clases em paquetadas de negocios específicas
de la industria que pueden com prarse y extenderse para satisfacer las propias necesidades. E s
to se basa en la observación de que aparecerán patrones en una com pañía que tenderán a apa
recer en otras com pañías de la m isma industria. Los patrones a un nivel más alto de
abstracción aparecerán incluso en com pañías de diferentes industrias, listo tam bién es cierto
en el m odelado de inform ación. El reconocim iento de patrones com o éstos ha sido la base p a
ra cl éxito de m uchos paquetes de fabricación relaciónales a nivel em presarial actuales. C o
mo verem os en la siguiente sección, las clases de dom inio de negocios tienen un a fuerte
correlación con el m odelo de inform ación. La reutili/ación de las clases de negocios rara v e/
sucede sin una planeación cuidadosa. Si la reutilización de las clases de negocios es im por
tante para su establecim iento, deberá quedar indicado com o un vector de calidad principal
desde el inicio del proyecto.
El dominio de la aplicación
Las clases de objetos del dominio de la aplicación rara vez son reutilizables. D esempeñan p a
peles que están lim itados a un tipo específico de aplicación. M ientras las clases dcl dominio de
negocios tienden a centrarse alrededor de los datos fundamentales del negocio, las clases del do
m inio de aplicación tienen m ucho más procesamiento. Las elases de este dominio frecuente
mente son extraídas del modelo de eventos, desem peñando cl papel de reconocedores de
eventos o manejadures de eventos. Hn el capítulo 4 vimos que algunos eventos requieren que el
sistema determ ine que el evento ha sucedido. Para estos eventos se tendrán que construir algu
nos tipos de clases reconocedoras de eventos. En los sistemas de negocios el rceonocedor de
eventos más com ún es temporal. Se podría esperar encontrar clases como monitoreo de cuentas
delincuentes en un sistem a que revisa periódicam ente la antigüedad de las cuentas por cobrar.
Las ciases son creadas para desem peñar cl papel de m anejado res de eventos para aque
llos eventos que requieren la coordinación de varias clases para poder ejecutar las políticas del
negocio, Hjemplos de un sistem a de transporte de exportación podrían incluir separador de em-
bar¿jues\ el cual m anejaría los requerim ientos altam ente especializados de responder a las p e
ticiones del cliente para dividir sus pedidos pendientes en dos em barques separados. Aunque
esta actividad puede ser crítica para proporcionar un servicio a clientes com pleto, es muy po
co probable que sea reutilizable en cualquier otra aplicación.
DERIVACIÓN DE LAS CLASES DE LOS DOMINIOS DE

NEGOCIOS Y DE APLICACIÓN
El diseño orientado a objetos no es una actividad independiente de mucho de lo que ya se ha

tratado en este libro. En la sección de análisis estudiamos el com portam iento esperado del sis
tem a y docum entam os las regias del negocio usando el modelo de eventos. Registramos los re
querim ientos de datos usando el modelo de inform ación y especificamos los requerim ientos de
procesam iento en la sección de actividad dcl diccionario de eventos. Procesos, datos y com por
tamiento observable, ya hemos definido al sistema com pleto en forma muy sim ilar a un objeto.
Los modelos esenciales de la fase de análisis proporcionan el material para tejer los hilos
dcl problem a de negocios a fin de obtener un diseño adecuado basado en las capacidades de
los lenguajes de desarrollo escogidos. El modelo de inform ación es vital para el diseño de la ba
se de datos relacional. Hl modelo de eventos y el modelo de información son cruciales para im a
ginar la interfaz. N uevam ente, encontrarem os que los modelos analíticos proporcionan la veta
de m ateria prima a partir de la que pueden fabricarse las clases de objetos.
En la siguiente sección veremos que algunas elases de un diseño orientado a objetos pueden
derivarse del modelo de información. Éstas incluyen las clases de papeles, las clases de relacio
nes y las clases de atributos. Además de éstas, se derivan clases adicionales del modelo de even
tos que incluyen a las clases reconocedoras de eventos y a las clases manejadoras de eventos.
Derivación de clases de negocios a partir

del modelo de información
Las fuentes más obvias para las clases de objetos son las entidades del m odelo de inform a
ción (aunque no son las únicas fuentes, com o veremos en un m omento). Si se consulta el dic
DERIVACIÓN DE LAS CLASES DE LOS DOMINIOS DE NEGOCIOS 359
cionario W ebster7 encontrará fuertes .similitudes entre la definición de entidad y la definición

de objeto:
entidad, n. 2. una cosa que tiene una existencia individual y definida en la realidad o
en la m ente.
objeto, n. 5. cualquier cosa que puede ser conocida o percibida por la mente.
Las definiciones del diccionario son un poco vagas para nuestras propósitos. Pareciera
que cualquier nom bre que pueda ser conceptual izado por la m ente hum ana pudiera calificar co
mo un objeto. Tomando un enfoque literal podríam os invitar a un grupo de program adores al
salón de conferencias para encontrar "nom bres en el dom inio del problem a” y enlistarlos co
mo clases potenciales. A unque el grupo probablem ente descubriría m uchos de los mismos
nom bres que adornan el modelo de inform ación, se ha sabido que la técnica tam bién genera
candidatos tales com o “tapete del ratón’7, “trueno” y “alm uerzo” .
Un enfoque más razonable para el descubrimiento de clases de negocios es examinar me
tódicamente el modelo de información para ver la manera en que los tipos de entidad (para los
que ya se han determinado las necesidades del sistema de recordar algo) pueden traducirse hacia
clases de objetos adecuados para operaciones del momento de ejecución. Aunque hay una fuerte
correlación entre entidades y objetos encontrará que no es necesariamente un mapeo de uno a
uno. También veremos posteriormente en esta sección que un modelo de clases orientadas a ob
jetos incluirá muchas clases que no tienen ninguna representación en el modelo de información.
Las entidades como clases de papeles

í .as entidades forman la base de lo que se conoce com o clases de papeles. Estas clases desem
peñan papeles principales en el sistem a de negocios que incluyen clases com o cliente, pedido,
producto y factura. Hay algunas diferencias fundam entales entre modelado de entidades y ob
jetos que necesitan ser respetadas, f-’n el capítulo 5 se dijo que el modelado de inform ación es
tá basado en el concepto de normalización de datos. Elim inam os todos los grupos repetidos de
datos de nuestras entidades hasta que el modelo de inform ación represente un conjunto de da
tos bien normalizado.
En la orientación a objetos el concepto de ocultar inform ación/im plem entación propor
ciona al diseñador un perm iso para desnorm alizar si así lo escoge. Los objetos no necesitan
contener sim plem ente un solo “renglón7’ de datos. En vez de ello, variables internas del obje
to pueden estar representadas por arreglos com plejos. A unque esta noción puede aierrorizar a
los puristas de la norm alización, se debe recordar que los lenguajes com pletam ente orientados
a objetos no están restringidos por el paradigm a relacional.
Para ilustrar este punto digam os que M arcia, Jan y Cindy piden cada una tres conceptos
de control de plagas del catálogo de pedidos por correo de Lilly & Vcrmin (figura 12-10). En
unos cuantos días, M arcia recibe una gran caja de cartón en su puerta, la cual contiene los tres
conceptos pedidos em pacados en espum a de plástico. M arcia es una program adora profesional
en CO BOL y da m antenim iento a un sistem a que utiliza el alm acenam iento de datos en archi
vos planos. E lla visualiza su pedido com o un solo registro de envío que contiene un grupo re
petido de conceptos de envío que sucede tres veces. Los pedazos de espum a de plástico
representan el “relleno” .
7 W cbstcr's New World Dicrionaj-y of'thc American Laiiguagc, 2nd College Editkin, .1978.
Jan, por otro lado, ha pasado toda su carrera diseñando bases de dalos relaciónales. Ella
es una experta en norm alización de datos y SQL. E l pedido de Jan llega de la m isma form a,
tres artículos em pacados en una sola caja. Jan visualiza su pedido como un a instancia de em
barque que contiene de una a m uchas instancias de concepto de embarque. Para ella cl em bar
que de la caja y el contenido de la caja son entidades separadas distintas, aunque reconoce que
para cada concepto de em barque debe haber una unión de regreso hacia em barque para saber
la fecha de embarque y si el artículo fue enviado por prim era clase.
Cindy ha estado desarrollando aplicaciones orientadas a objetos usando SmallTalk™ du
rante m uchos años. Cuando llega el pedido hace una pausa para reflexionar sobre el hecho de
que puede ver a la caja com o un solo objeto que es capaz de enum erar su contenido bajo pedi
do o puede visualizar la caja com o un contenedor que transporta tres instancias distintas de
concepto de pedido, su ratonera para el ático, su veneno para ratas y un tapete para puerta de
corativo con m otivos de arañas. Ella se sonríe m ientras im agina el debate que podría provocar
este problem a en su equipo de proyecto en el trabajo.
M A R C ÍA JAN
01 Linea-de-embarque
05 Núm-embarque
05 Fecha-embarque
05 importe-postal
05 Ciase-postai
05 conceptos ocurr 3 veccs
10 Código-producto
10 Desc-producto
10 Precio
etc... Concepto
de embarque
f-igura 12-10. Marcia, Jan y C-indy imaginan cada una su pedido en forma diferente.
K1 asunto es que los m odeladores de objetos no están sometidos a las leyes de la norma
lización, Cindy puede representar su pedido com o un solo objeto, embarque, que contiene un
arreglo interno de su contenido, o puede m odelar su pedido corno una instancia de embarque
que contiene los controladores de objeto hacia conceptos de em barque, que son objetos separa
dos que pueden ser llam ados en form a independiente, Ks muy probable que escoja este últim o
escenario, pero lo im portante es que no tiene obligación de hacerlo. Las consideraciones que
podrían guiar el diseño incluyen el si alguna otra parte de la aplicación necesita llamar directa
mente a métodos de concepto de embarque sin tener que preocuparse con el embarque o si la
inclusión de conceptos de embarque con embarque, degrada la reusabilídad de cualquier clase.
Se pueden tom ar dos enfoques para cl m odelado de clases. Se puede tratar a la norm ali
zación como irrelevante y m odelar a los objetos com o se les percibe en sus estructuras innatas,
o se puede com enzar con un modelo norm alizado y tom ar decisiones para agregar entidades
conforme a razones de diseñe específicas. Yo prefiero esto último. Al com enzar con un m ode
lo de inform ación bien norm alizado todas las decisiones para desnorm alizar la inform ación en
el modelo de clases se hacen eu forma deliberada por consenso informado, en vez de ser por ac
cidente. Las aplicaciones orientadas a objetos que operan sobre bases de datos relaciónales exi
gen el trabajo adicional de tener que descargar sus datos en tablas normalizadas, lo cual también
puede causar que se favorezcan las estructuras norm alizadas dentro de las clases de objetos.
Ya hem os visto que la orientación a objetos puede conducir a que se agregue más de una
entidad en una sola clase. También puede ocurrir a la inversa. Se puede decidir la división de
una sola entidad en varias clases. La situación más com ún es cuando el m odelador de objetos
decide introducir más niveles de herencia de clase que los que escogió el m odelador de infor
m ación para m ostrar la jerarquía de subtipo/supertipo en cl modelo de inform ación. Veamos un
ejemplo en donde esto puede aparecer en un sistem a de negocies real.
Un el capítulo 8 visitam os a la Nihilist Toy Company, proveedores internacionales de ju
guetes violentos y ofensivos. Si fuéramos a examinar su modelo de inform ación podríam os en
contrar una entidad, tal com o pedido, vagando por ahí. Como sucede, hay diferencias distintivas
entre los pedidos colocados por dien tes para em barcarse dentro de los Hstados Unidos y para
aquellos que se exportan. Hay unos cuantos atributos adicionales que se requieren para un p e
dido de exportación que no se tienen en un pedido nacional, y varias relaciones hacia entidades
de registro de navios de exportación que están prohibidas para los pedidos nacionales. La figu
ra 12-11 muestra un ERD (diagram a entidad-reí ación) con la notación de subtipos para los pe
didos de exportación y nacionales en un modelo de información.
Figura 12-11. Un ERD mostrando a pedido con subtipos da pedido de exportación

y pedido nacional.
Ahora, ¿qué pasa si cl m odelador de inform ación escoge no separar en subtipos la

entidad pedido hacia pedido de exportación y pedido nacional, sino que, en vez de ello, repre
senta los pedidos nacionales y de exportación com o una sola entidad pedido y los distingue con
un atributo de tipo de pedido y un conjunto de reglas del negocio que gobiernan la opcionali-
dad para determ inados atributos y relaciones?
Antes de que cualquiera de los puristas de modelado de datos le envíe correo electrónico
para que me envíe una majadería, recuerde la aseveración del capítulo 5, de que 4la normaliza
ción es una solución sintáctica hacia un problem a semántico .-U n m odelador de información
inteligente tendría todo el derecho de poner juntos estos dos subtipos si adivinara que el acceso
diario de los datos dentro del negocio no justifica la com plejidad adicional de hacer una distin
ción estructura!. _
Entra en escena el m odelador de clases de objetos. El m odelador de clases de objetos tie
ne la responsabilidad adicional de valorar el uso del negocio tanto de ios datos com o del pro
cesam iento que sucede alrededor de los datos. Viendo el código que se necesitará escribir para
la clase pedido, puede determ inar que hay diferencias significativas en procesos y com porta
mientos en el sistem a entre los pedidos nacionales y de exportación que justifican la creación
de la jerarquía de clases. Los m étodos y variables com unes son prom ovidos a l a superclasc p e
dido y las singularidades que distinguen a ios pedidos de exportación de los nacionales (tal co
mo la habilidad para nom brar a la em barcación en donde se enviarán) pueden ser transferidas
a las subclases pedido de exportación y pedido nacional, respectivam ente (figura 12-12).
Las conclusiones divergentes a las que llegan el m odelador de clases de objetos y el m o
delador de inform ación se deben a los conjuntos de reglas ligeram ente diferentes en que basan
sus decisiones. Ll m odelador de inform ación m odera su norm alización con la valoración de las
necesidades de acceso de datos y, en cam bio, el m odelador de clases de objetos está luchando
por extraer código reutilizable, tener un acoplamiento^ limpio entre objetos y reducir los estor
bos10 innecesarios.
Las entidades de supertipo/subtipo como superclases/subclases

Tal vez haya observado cn la últim a sección que hay un paralelismo obvio entre el modelo de in
formación y la jerarquía de clases 0 0 cuando se trata de supertipos y subtipos de las entidades, til
modelador de información distingue entre tipos de entidad que comparten algunos, pero no
todos, de los mismos atributos o que pueden participar en algunas, pero no en todas, las relacio
nes. Esto puede conducir a estructuras de supertipo/subtipo tales como el ejemplo que vimos en el
capítulo 5 sobre el supertipo vehículo con subtipos de aviones, ¡renes y automóviles (figura 12-13).
- Paê-Joncs, 19 9 1.
' l-l acoplamiento es una medida de la dependencia de un componente de software con respecto a otro. Pre-
por primera ve/. en Structured Design (Yourdon, Constantine, : '■: cl concepto ha sido expandi
do por M edir Page-Iones hacia un concepto llamado connascencc, que es una medida mucho más robusta
de saín; estructuras encapsuladas. (Vea Page-Jones, ¡995).
L :^-i V leneumbrance) es una medida del conjunto de re tere nc ias de clases indirecta de la clase. (Vea
P¿=.v -Jcsk>- í !- En otras palabras, si se rastrean todas las demás clases hacia tas que una ciase puede ha
cer Tí:Vri.--cii d u p la m e n te (ya sea por herencia, envío de m ensajes o conservando las
variables ¿e o e s l y luego de todas las clases a jas que aquellas clases pueden hacer referencia, \ así
sucesivamente. ot*oene 1 - medida de lu esfera de influencia y dependencia de una clase a través de to
do un sistema. f:.l otyaáculü es un elemento importante cn el rastreo del efecto de propagación de onda del
hacer cambios a una im eria/ de cíase.
Figura 12-12. Un diagrama de elase que muestra la herencia de superclasc/subclase.
ID de vehículo
Compañía Capacidad de pasajeros
Velocidad máxima
Puede estacionarse
legalmente en
Tren Espacio de
Avión Autom óvil ■10................o<3 estacionamiento
Está reservado
Envergadura p a ra
A ltitud máxima
Figura 12-13. Un ERD dei supertipo vehículo y sus subtipos.
Hl m odelador de clases de objetos em plea el milagro de la herencia para expresar la re

lación entre la superclase genérica vehículo y las subclases avión, tren y automóvil. También
debe preocuparse con la colocación de métodos en su m ejor lugar dentro de la jerarquía de cla
ses (figura 12-14),
N uevam ente, cl m odelador de clases de objetos puede enfrentarse con las com plejidades
que fueron fácilm ente encubiertas por el m odelador de inform ación. Por ejemplo, ¿qué tal si
nuestro sistem a ficticio fuera responsable de llevar cuenta tanto de los vehículos de pasajeros
com o de los vehículos de carga? Los em picados de la com pañía pueden com prar pasajes en la
flota de vehículos de pasajeros de la em presa, pero ios aviones de carga, los trenes de carga y
los camiones de reparto tienen expresam ente prohibido el transporte de pasajeros.
El m odelador de inform ación podría simplemente poner un atributo en la entidad vehícu
lo, el cual indicará si al vehículo se le perm ite transportar pasajeros. Bajo este esquem a el m o
delo de eventos podría contener la política dcl negocio para cualquier evento que necesitara
discrim inar entre vehículos de pasajeros y de no pasajeros. Hn un sistem a no orientado a obje
tos, el diseñador de la aplicación podría añadir un procedim iento alm acenado que hiciera cum
plir las reglas del negocio correspondiente a que los vehículos de carga no pueden participar
en relaciones con cl transporte de pasajeros. Ha interfaz pudiera ser codificada en forma tal que
sólo los vehículos de pasajeros aparecieran en !a lista de vehículos disponibles del usuario pa
ra la reservación de viajes de pasajeros.
l ’ig u r a 12-14, Un diagrama, de clase de la supere lase vehículo y sus subclases.
tin un sistema, orientado a onjetos esto puede hacerse más com plejo. !■! diseñador puede
querer aislar esos com portam ientos de los vehículos de pasajeros o de los vehículos de carga
en el ases reutilizables. M ediante la herencia múltiple (la habilidad de heredar directam ente de
más de una clase),11 el diseñador de clase puede acabar con un a estructura en la cual los m éto
dos de cada clase se apliquen a todas las instancias de la clase o subclases (figura 12-15),
Ft£Era 12-15. Vehículo con subclases para diferenciar entre vehículo de pasajeros
y vehículos de carga.
11 No IíxJoí los l/Tiíii-xr? iiriciiiaiks a objelos soportan la herencia múltiple.

Por encima, esto pudiera parecer un caos. Si el transporte de pasajeros y carga es la parte
m edular del negocio pudiera ser com plétame rite razonable la creación de tal estructura com ple
j a . 12 Sin em bargo, si el transporte es sólo una adición pequeña a un sistema de negocios mucho
más grande, el diseñador de clases puede decidir que tal com plejidad no se justif ica y colapsar
la estructura de la jerarquía de clases de regreso a la original de vehículo, avión, tren y autom ó
vil (figura 12-14). Esta jerarquía mucho más simple necesitará una variable de “tipo” en vehícu
lo, la cual distinga si a una instancia de vehículo se le perm ite llevar carga o pasajeros, así corno
se hizo en el modelo de información. Los métodos reservados para cada tipo necesitarán respe
tar la variable para que no permitan una operación que viole la política del negocio.
La lección, nuevam ente, se encuentra en la distinción entre el m odelado de datos solo y
el modelado de datos y procesos juntos. El m odelador de inform ación está preocupado en gran
medida con la creación de una estructura de datos flexible y no redundante que reduzca el efec
to de propagación de onda de hacer cam bios a la base de datos. El m odelador de clases de ob
jetos también está preocupado con la creación de estructuras flexibles y no redundantes, pero
debe considerar tanto al proceso com o a los datos con el objetivo de aislar el efecto de propa
gación de onda al hacer cam bios a la aplicación com pleta. El diseñador de base de datos pue
de tom ar decisiones de acuerdo a la eficiencia del acceso de datos. El diseñador de clases puede
llegar a conclusiones diferentes conform e a la reusabilidad, m antenibilidad, com plejidad y efi
ciencia del código de la aplicación.
Sólo hem os exam inado algunas de las sim ilitudes y diferencias que hay entre los tipos
de entidad y sus contrapartes orientadas a objetos, las clases de papeles. Pasemos a las clases
en donde la orientación a objetos parece apartai-.se mucho más del m odelado de inform ación
tradicional.
Relaciones en los modelos de clases

Los objetos participan en relaciones de una forma muy sim ilar a eomo los datos están relacio
nados en el modelo de inform ación. 1,as relaciones entre clases están agrupadas en tres catego
rías: herencia, agregación y asociación.
La herencia es sim ilar a la relación supertipo/subtipo dei modelo de inform ación. E l ob
je to de subclase hereda autom áticam ente todas las variables y métodos disponibles en la super
clase. La notación para herencia se m uestra en la figura 12-16.
La agregación es sim ilar al tipo de relaciones de encabezado/dctalle que son bastante co
m unes en la mayoría de los sistemas de negocios. Un ejem plo es pedido y concepto de pedido
en un negocio en donde un cliente puede pedir varios productos al mismo tiempo. Estas elases
estarán muy conscientes de cada una de ellas. Para im plem entar una relación de agregación un
objeto conservará el controlador hacia los demás objetos en sus variables. Un objeto de la cla
se pedido puede guardar los controladores de todos sus conceptos de pedido, o los conceptos
de pedido pueden guardar cl controlador de su pedido. En algunos casos el diseñador puede es
coger la im plem entación de la relación con referencias en ambas direcciones. La relación de
agregación se m uestra en un O O D N mediante una flecha delgada normal trazada entre los ob
jetos. La dirección de la flecha apunta desde el objeto que conserva los controladores hacia el
otro objeto al cual hacc referencia. U na flecha bidireeeional indica que ambos objetos conser
van los controladores de los otros. Los usuarios del OODN han encontrado conveniente colo
12 Para quienes esién, de hecho, en cl negocio de transportes, me he dado cuenta que he simplificado excesi
vamente este ejemplo.
car cl nom bre de la variable asignada para guardar cl controlador del objeto diréclám ente en la
flecha de referencia, aunque esto viola lu idea de que las variables internas de un objeto están
ocultas. L a cardinalidad de la relación puede anotarse en cualquier extremo de la línea (0..1,
1..L 0..M , 1..M). Listo se lee en el mismo orden que en el diagram a entidad-reí ación. Kn la fi
gura 12-17 se podría leer, el pedido agrega uno a muchos conceptos de pedido.''-
F ig u r a 12-16. L a notación de herencia.
F ig u ra 12-17. Relación de agregación.
l:! Ei lado ! .1 do ta reladón írcciK nienKutt se omite en cl diagrama debido a que es muy común.
La últim a categoría de relación de clase es la asociación. La asociación es el tipo de en

lace más débil entre clases. En la figura 12-18 se m uestra un ejemplo de asociación, nuestro
venerable ejemplo de “persona posee actualm ente p e r r o A partir de la cardinalidad podem os
deducir que a nuestro sistema se le requiere que recuerde al propietario actual del perro y no la
historia com pleta de la propiedad de! perro, que hace que esta relación sea de “uno a muchos” .
La OODN no hace distinción entre la agregación y la asociación en su notación. La m ism a fle
cha delgada se usa para anotar la dirección de la referencia.
PERRO puede guardar el m anipulador de su propietario PERSONA
PERSONA puede guardar los m anipuladores de sus PERROS
F ig u r a 12-1N. R elación tic asociación.
Kn una base de datos relacional la colum na ID de persona podría estar incrustada en la ta
bla perro com o clave externa para im plem entar la relación. En un sistem a orientado a objetos se
podría usar un enfoque similar, haciendo que el objeto perro guardara e! controlador persona de
su propietario o haciendo que el objeto persona guardara los controladores de sus perros. Pode
mos descartar con seguridad a la herencia com o una forma para im plem entar la propiedad. Las
personas no son subclases de perros y los perros 110 son subclases de personas.14 La relación no
es de agregación. Los perros no son una parte com ponente de las personas, pero hemos imple-
mentado a la relación en una forma muy similar. ¿Es ésta la única solución'/
(Ü mezclar manipuladores de perro con persona o manipuladores de persona con perro
degrada la reusabilidad de ambas clases, en especial si las personas o los perros tienen otras
apariciones en el sistem a cu donde no están relacionados. Otra solución es crear una clase de
relación especial, llam ém osla propiedad de perro, que m aneje toda la política para la posesión
de perros (figura 12-19).
El concepto es sim ilar al tipo de entidad asociativa en el m odelado de inform ación, a ex
cepción de que aquí se em plea también en relaciones de uno a muchos. M ediante una clase
de relación, tal com o la de propiedad de perro, la clase perro ya no se preocupa con asuntos
,!t Aunque, he conocido varios perros que se molestarían con este último enunciado.
de personas y la clase persona ya no está contam inada con cosas de perros, y esto incrementa
la rentabilidad de am bas clases.
Figura 12-19. Propiedad de perro es una. dase; de relación.
Se puede ver que el modelo de información proporciona gran parte de las clases que apa
recen en el modelo de clases, pero no es siempre una transform ación directa. 1.as entidades se
convierten en clases de papeles. 1-as relaciones supertipo/subtipo son indicativas de herencia, la
cual puede incluir o no todos los m ism os niveles articulados en el. modelo de inform ación. Las
relaciones también pueden ser promovidas para que se conviertan en clases para m anejar las po
líticas de la relación y para aislar a las clases participantes de tener que saber dem asiado acerca
de cada una de las demás.
Hasta los atributos pueden convertirse en clases. Por ejemplo, un atributo, tal com o sal
do de crédito del diente, puede ser im plem entado com o una clase, acoplando las reglas del ne
gocio que se refieren a ¡os clientes que han excedido sus límites con el propio dato.
Derivación de clases de aplicación a partir del modelo

de eventos
El modelo de inform ación no es suficiente por sí solo para derivar un modelo de clase para un
diseño orientado a objetos. El diseñador orientado a objetos puede tomar en cuenta sistemática
mente todos los datos del m odelo de inform ación asignándolos al lugar que mejor les correspon
da en el diseño de la clase. También debe tomar en cuenta todos los requerimientos de
procesam iento que se han indicado en la sección de actividad de cada entrada del diccionario
de eventos asignándolos al lugar más adecuado como métodos en et modelo orientado a objetos.
Cada enunciado de la sección de actividad representa algún fragm ento de procesam ien
to que necesita suceder dentro del sistema para transform ar el estím ulo del evento en las res
puestas adecuadas. El modelo de inform ación le da el lado de los datos y cl modelo de eventos
articula las reglas del negocio y los requerim ientos de procesam iento. Vimos que muchas de
las transform aciones del modelo de inform ación hacia el modelo de clases fueron bastante di
rectas, como es el caso del tipo de entidad a la clase de papel. D e m anera similar, la asignación
de actividad de los eventos hacia métodos tiene transform aciones directas así com o asuntos de
diseño más com plicados.
Muchos de los procesas especificados en el diccionario de eventos son enunciados sim
ples para cre ar leer: actualizar y elim inar que son ejecutados sobre los lipos de entidad del sis
tema. La m ayoría de estos enunciados, pueden ser m anejados por métodos que se encuentran
ubicados directam ente en las clases correspondientes de papel, relación y atributo, las cuales
fueron derivadas del modelo de inform ación.
Por ejemplo, un evento tal com o el departam ento de mercadotecnia asigna nuevos p re
cios de produelo podría tener una actividad que incluyera el enunciado:
“crear nueva instancia de precio de producto.”
Las políticas para esta actividad de negocios es probable que sean lo suficientem ente
sim ples para que sean m anejadas com pletam ente con los métodos de la clase de papel precio
de producto, asignando el valor del precio y la fecha de entrada en vigor e insertando un nue
vo renglón en la base de datos.
Clases manejadoras de eventos

Demos un vistazo a un evento cuya actividad no se adapta claram ente a las clases derivadas del
modelo de inform ación. El evento el cliente coloca pedido en una com pañía lípitia puede tener
una sección de actividad parecida a la siguiente:
I í c l i e n t e no r a i s t e en b aso de d a to s
c r c a r m ieve a do c l .i e n te
E rd : f
C ro a r una m :;i.a rc i a de p e e : do
r'c r ea ch ÍP a ra cada) p ro d u c to s o ii c il .a d o -
C ro a r una iri£3r.ar.cia do c o n c e p to de p e d id o :
Rcívi sa r ü._;;pon i o l i d a r i de p re d ije re
: r p r o d u c to r.o e s t á di sp e n ib '. e
C re a r .■ i;in L an cia de c o n c e p to p e r d i e n t e do s u r t i r -
Krd i i
ünd : s r each
C a lc u la r im p u e sto de v e r.ta s
C a lc u la r p r e c i e Lora_
lis seguro suponer que el modelo de inform ación contiene, al menos, tipos de entidad
para cliente, producto, pedido, concepto de pedido y concepto pendiente de surtir, y que han
sido identificadas las clases de papel correspondientes para un diseño orientado a objetos.
N uestra misión es asignar la actividad de la actividad del evento a los métodos más adecuados
de las diversas clases. ¿Cuál m étodo debe m anejar las políticas para la colocación de pedidos?
¿Será C LlfiN T E .C olocar-Pedido?

o i P E D ID O .Nu evo ?
o ¿PR O D U C T O .PÍdem e?
La respuesta es ninguno de los anteriores. Hl proceso de la colocación de un pedido re

quiere una conspiración de muchos objetos al m om ento de ejecución para aplicar las políticas.
Tal vez se necesite crear una nueva instancia de cliente, se estará creando un nuevo pedido y
nuevas instancias de concepto de pedido, se revisará la disponibilidad de producto y posible
m ente se crearán conceptos pendientes de surtir. El objeto cliente no tiene nada qué hacer en
cl negocio con los pedidos pendientes de surtir, ni tam poco el objeto producto tiene nada que
ver con la creación de un nuevo cliente. La solución es crear un nuevo tipo de clase llamada la
clase manejadora de evento (o el m anejador de evento-actividad), la cual aetúa com o un direc
tor coordinando las actividades de m uchas otras clases para aplicar las políticas del negocio
para el evento. El resaltado puede ser expresado en un diagram a de objeto-com unicación (a ve
ces llamado diagram a de rastreo de eventos o m odelo de objeto dinámico), corno el de la figu
ra 12-20, el cual m uestra los m ensajes entre cl m anejador de evento y sus co-cómplices para cl
evento el d ien te coloca pedido.
Figura 12-20. diagrama objeto-comunicación para cl diente coloca pedido.
L a clase m anejadora de evento es muy similar al "m ódulo jefe" del diseño estructurado, el
cual puede ser que no tenga contraparte explícita en el modelo esencial, pero se requiere en
el diseño para hacer cum plir la secuencia de procesamiento de los módulos que aplican las polí
ticas del negocio. Por lo tanto, tenemos un grupo de clases que aparecen en el diseño orienta
do a objetos las cuales no son evidentes en el m odelo de inform ación. No todo evento requerirá
ia creación de un m anejador de eventos. Es probable que un huen núm ero de eventos puedan
ser manejados por los buenos oficios de los métodos colocados directam ente en las elases de
rivadas del m odelo de inform ación. Los m anejadores de eventos se em plean para eventos en
donde deben ser coordinados una variedad de objetos y no hay un mejor lugar único en ningu
na de las clases existentes para alojar las políticas de coordinación. Si la colocación de las po
líticas dei m anejo de eventos en una clase existente degrada la reusabilidad genérica de la clase
o com plica a esa clase con dem asiado conocim iento sobre sus vecinos, entonces probablem en
MODELADO DE ACT1VADORESY PROCEDIMIENTOS ALMACENADOS 371
te se deberá contratar una clase m anejadora de eventos para aliviar la problem ática de m anejo
de las clases del dom inio del negocio.
Esta técnica da com o resultado clases de dominio del negocio m ucho más limpias y que
es muy probable que sean reutilizables a través de aplicaciones dentro del m ismo tipo de em
presa o industria. Las clases m anejadoras de evento caen en el dom inio de la aplicación, debi
do a que aplican políticas específicas de la aplicación encargadas de adm inistrar ese evento del
negocio y son, por lo tanto, clases altam ente especializadas con muy baja reusabilidad.
Clases reconocedoras de eventos

Si recuerda el capítulo 4. se mencionó un tipo especial de evento llamado el evento temporal.
Los eventos tem porales son activados en función del tiempo, y el tipo más com ún de evento
reconocido indirectam ente que pueden suceder en los sistemas de inform ación de negocios.
Suceden con una program ación específica disparando su actividad ya sea de acuerdo a un re
loj absoluto o a un tiempo relativo a otro evento. Otros eventos reconocidos indirectam ente
incluyen aquellos que son disparados en los sistemas debido a cambios en el am biente tales co
mo la presión o la temperatura.
A diferencia de los eventos reconocidos directamente, que por lo general son activados por
el manejo humano de la interfaz, los eventos reconocidos indirectamente requieren algún meca
nism o que moni toree el ambiente para ver si el evento ha sucedido. No deberá sorprender que
en un sistema orientado a objetos estos procesos se asignen a clases reconocedoras de eventos.
Al igual que los manejadoras de eventos, las clases reconocedoras de eventos no tienen
contraparte en el modelo de información. Hn vez de ello, es la existencia de un evento recono
cido indirectamente en el modelo de eventos lo que dice que se necesita diseñar una clase capaz
de reconocer que el evento ha sucedido. Kl patrón resultante se m uestra en la figura 12-21. Un
reconocedor de eventos actúa como el monitor, observando el ambiente y revisando sus entra
das contra sus parámetros. Cuando el reconocedor de eventos decide que el evento ha sucedido,
lo notifica a) m anejador de eventos adecuado, el cual luego se encarga de la coordinación de las
clases del negocio requeridas para ejecutar la actividad del evento.
Dejemos por ahora a un lado la orientación a objetos y demos una vista a construcciones
más tradicionales que es probable que encuentre en los sistemas cliente/servidor actuales. La
prim era es el activador y los procedim ientos alm acenados de base de datos de una base de da
tos relacional. La segunda es el diseño estructurado, una técnica venerable para la organización
de código escrito en lenguajes 3GL tradicionales,
MODELADO DE ACTIVADORES Y PROCEDIMIENTOS

ALMACENADOS
Uno de los tipos más com unes de com ponentes internos en los sistemas cliente/servidor actua
les es el procedim iento almacenado. Los procedim ientos almacenados son procesos que son
ejecutados en el servidor directam ente por la aplicación o cuando se detectan acciones especí
ficas en la base de datos relacional. El m ecanism o que detecta que ha sucedido una acción re
levante es llamado un activador (t.rigger) o a veces una regla.
Los activadores y los procedim ientos alm acenados están am pliam ente soportados por la
m ayoría de sistemas m anejado res de bases de datos relaciónales. Ésta es la m anera en que tra
bajan. Un activador está definido en una tabla de base de datos o en columnas que están den
tro de una tabla para que detecte acciones específicas. Los activadores m oniíorean las insercio
nes, actualizaciones y elim inaciones en la base de datos esperando a que suceda la acción pre
definida para disparar procedim ientos alm acenados.
F ig u r a 12-21. El patrón re conocedor de eventos.
Los activadores y los procedimientos almacenados pueden usarse para una am plia varie
dad de las actividades establecidas en el modelo de eventos que pueden ser asignadas al sen a
dor. La Figura 12-22 muestra algunos ejemplos de activadores y procedimientos almacenados
que se usan en los sistemas de negocios. El primer ejemplo es un activador que detecta la inser
ción de un pedido para un tipo particular de producto que requiere la atención dcl gerente de la
línea de productos. Cuando ia base de datos detecta que se inserta cl concepto de pedido, cl sis
tem a envía una notificación al gerente adecuado. En el segundo ejemplo el activador se dispara
cuando una actualización al saldo del inventario causa que ei inventario caiga por abajo del pun
to de reorden. En este ejemplo el sistema tiene planeado colocar automáticamente un pedido pa
ra resurtir cl inventario. Hn el último ejemplo el activador está diseñado para m antener una
colum na calculada que está guardada en la labia de encabezado de plan de ventas actual cuando
cualquiera de los renglones de detalle que afecta al total es insertado, actualizado o eliminado.
Los activadores y sus procedimientos almacenados asociados deben com unicarse al dise
ñador con cl suficiente detalle para llevar a cabo con precisión la regla y las acciones asocia
das. El primer paso es recorrer la sección de actividad de) diccionario de eventos y determ inar
cuáles procesos son adecuados para que sean ejecutados por procedim ientos en la base de da
los. L a especificación debe incluir dos partes, las condiciones que detectan que requiere esa ac
ción y la acción que debe realizarse. En muchos establecim ientos el mismo texto que se usa
para especificar los activadores y procedim ientos en la especificación de diseño es copiado y
pegado directam ente en el código fuente como com entario para los futuros program adores de
mantenimiento, a fin de que puedan com prender rápidam ente lo que se pretende con el código.
O tra parte vital del diseño que debe ser conservada para el m antenim iento posterior dcl
sistema es un listado que relaciona a todos los activadores y procedim ientos instalados en el
DISEÑO ESTRUCTURADO 373
sistem a con las tablas y accioncs o llamadas a procedim ientos remotos que pueden activarlos.
Cuando se hacen m odificaciones a un sistem a se pueden encontrar algunas sorpresas desagra
dables si no se está consciente de cuáles activadores podrían estar acechando en las sombras
esperando entrar en acción con las nuevas inserciones, actualizaciones o elim inaciones. Para
evitar tai anarquía, cl diseñador y íos program adores siempre deben tener a la mano un listado
actual de los activadores disponibles. M uchos sistemas de m anejo de bases de datos relacióna
les pueden generar ese listado, tal com o el que se m uestra en la figura 12-23, o dar al menos
acceso a sos tablas de sistem a para que uno pueda recopilar la lista propia.
Activador (regla) Procedimiento (acción a realizar)
En la inserción de un eoncr:pto_de_pedido Notificar al gerente de la línea de productos

para cualquier producto en donde el tipo-
_de_producto - "especialidad"
En la actualización de inventario.saldo Generar resurtido de producto

cuando inventario.saldo caiga por abajo
d eí producto.punto. de_reorden
En inserción de deialle_de_plan de ventas Volver a calcular plan._de_verilas.ganancra_.proyec-

o en actualización de detalle de_plan_de tada toial
ventas.gananciasjoroyectódas o en e lim ina
ción de detalle_de_plsn de venías
F ig u r a 12-22. A ctivadores y procedim ientos de ejem plo.
Tabla Columna Inser Actual Flimina- Activador Procedimiento

ción ización ción
Clientes - X Nuevo Cliente Notificación a gerente
de crédito
Concepto Tipo de producto X Producto especial Notificación a gerente
de pedido de producto
Artículos Saldo actual X Inventario bajo Creación de pedido
de inventarío de inventario
Detallo Ganancia X X X Cambio de deLalle Recúiculo de ganada
de ventas Proyectaría de ventas total
Concepto Ca ntidad X Cambio de cantidad Notificación a gerente
de embarque de planta
jí™ ., '
/: r $
. . - v r í í i ^ ; J J/j'f-SÍÍÍJ: 3535?:“ ::
l ’ig u ra 12-23. T abla de base de datos, listado de activadores y procedim ientos.
DISEÑO ESTRUCTURADO
Los conceptos de diseño estructurado, concebidos por Larry Con.stant.ine a finales de los años
sesenta y presentado a un am plio público en los setenta y los o chenta,ls forman la base de los
principios de diseño que considero habilidades esenciales para cualquier diseñador o progra-
15 Yourdon, Consta mine, 197 9 y Page-Jones, 1(J8Ü.

374 Capítulo 12 ! EL DISEÑO DE COMPONENTES INTERNOS
m ador que esté trabajando en los noventa o posteriorm ente. Es imposible rcducír la amplitud
de este lema a un m ensaje de galleta de la suerte para term inar este capítulo, pero perm ítam e
dar una revisión breve a los conceptos principales. M ientras esté leyendo esta sección, si los
térm inos y técnicas no le son inm ediatam ente fam iliares le recom iendo que busque alguno de
los libros sobre diseño estructurado que se enlistan en la bibliografía y revise los principios
de un buen diseño de sistema estructurado.
Hl principio básico del diseño estructurado se centra alrededor de la idea de que los pro
gramas o el código proccdural puede ser dividido en unidades lógicas llamadas módulos, los
cuales ejecutan funciones específicas y pueden ser identificados y mencionados por nombre.
Todos conocem os esto com o la subrutina interna familiar o la llam ada a un programa extem o.
Los módulos operan bajo cl concepto de caja negra. Para llam ar a un módulo se deben cono
cer sus parámetros de entrada, sus parám etros de salida y la funcionalidad pretendida, pero no
es necesario saber la form a en que hace su trabajo.
L1 diseño estructurado sugiere que hay un m étodo que vence al caos cuando se trata de
ensam blar m ódulos para crear una aplicación funcional. Los módulos pueden usarse para divi
dir un procedim iento largo en unidades más pequeñas que son individualm ente más com pren
sibles que un grandísim o docum ento de código. Además, los procedim ientos que son
ejecutados m uchas veces o por varios program as dentro de la aplicación pueden ser movidos a
una biblioteca de módulos com ún y, por lo tanto, nace el código reutilizable.
La notación gráfica que se usa para el diseño estructurado es la gráfica de estructura (fi
gura 12-24). Las gráficas de estructura muestran a los m ódulos com o cuadros rectangulares
con el nom bre del módulo en el centro. Las flechas en la gráfica de estructura m uestran la di
rección de la llam ada a módulos. Una Hecha que va del módulo A ai módulo B indica que en
algún lugar del código del módulo A se encuentra un enunciado que le da al módulo A la au
toridad para llam ar al módulo B. Debido a que la llamada puede encontrarse dentro de un enun
ciado condicional, no se puede garantizar que el módulo A llamará al módulo B cada vez que
ejecute. Las “balas de cañón” con flechas indican los parám etros o uniones que pasan hacia cl
módulo llamado y regresan de él (ios parám etros de entrada apuntan hacia abajo a la izquier
da y los parám etros de salida apuntan hacia arriba a la derecha). Además de la estructura grá
fica, cada módulo del diagram a es acom pañado de una especificación da módulo interno, que
es una descripción en pseudocódigo del procesam iento requerido para convertir las entradas
del módulo en las salidas.
M ódulo A
Parámetros
de entrada
fríg u ra 12-24. N otación de diseno estructurado.

RESUMEN 375
Dos criterios cruciales que em ergen de la disciplina de diseño estructurado son acopla
miento y cohesión. Hl acoplam iento mide la com plejidad del tráfico que pasa entre módulos.
La cohesión mide qué tan bien están relacionadas las funciones dentro del módulo. La m eta es
lograr módulos con bajo acoplam iento y alta cohesión. El bajo acoplam iento es una indicación
de que los m ódulos son m enos interdep endientes y, por lo tanto, más “elásticos” a tos cam bios
hechos a la aplicación. Los módulos altam ente cohesivos que realizan una sola función defini
ble es mucho más probable que sean reusables. M uestran un m ayor grado de eneapsu]ación
procedural que reducirá todavía más el efecto de propagación de onda de hacer m odificaciones
al program a.
No es coincidencia que estas ideas suenen familiares conform e se exam inan los criterios
para el buen diseño orientado a objetos. La m eta de la gran encapsulación de objetos va mano
a mano con la dism inución del trálieo de m ensajes superfinos y el logro de definiciones de m é
todo que sean altam ente cohesivos tamo internam ente com o con la clase a la cual han sido asig
nados.
RESUMEN
La estructura de diseño interno debe reflejar la estructura del sistem a que se pretende. Los com
ponentes orientados a objetos requieren técnicas de diseño orientado a objetos. Los activado
res y procedimientos alm acenados de bases de datos requieren una especificación que mapee
muy de cerca su morfología. En form a si mil ai; la especificación para cl código procedural
tradicional debe utilizar una notación que sea relevante para su paradigm a del lenguaje.
Una especificación de diseño debe incluir estructuras que muestren la organización ge
neral de los com ponentes. Para diseños orientados a objetos esto es proporcionado por un m o
delo de d a se , el cual m uestra la herencia, agregación y relaciones de asociación de la clase. En
los diseños estrueturados esto es proporcionado por la gráfica de estructura. Para los procedi
mientos almacenados de bases de datos bastara un listado de las tablas, activadores y reglas.
La técnica de diseño tam bién debe ser capaz de m ostrar la colaboración de los com po
nentes al m om ento de ejecución. En el diseño estructurado esto se m aneja m ostrando los
parám etros que se pasan para el acoplam iento de m ódulos en la gráfica de estructura. En
los diseños orientados a objetos cl diagram a objeto-com unicación muestra los m ensajes que
suceden entre objetos para un evento de negocios específico de nuestro conjunto de eventos.
Para cada construcción que se m uestra com o un sím bolo abstracto en cualquier notación
gráfica, la especificación de diseño no estará com pleta sin una especificación escrita del códi
go interno. Esto perm ite que el equipo del proyecto revise la arquitectura y el detalle de un d i
seño dado antes de su construcción, y le da al gerente del proyecto la opción de dividir el
trabajo enlre varios program adores.
1 .as clases de ios dominios de negocios y de aplicación para un diseño orientado a obje
tos pueden ser derivadas del m odelo de información y del m odelo de eventos. Ll modelo de in
form ación se traducirá hacia clases de papel, clases de relación y algunas clases de atributos.
El modelo de eventos proporciona la especificación de procesos para los métodos que se asig
nan a las clases más adecuadas. A lgunos eventos requerirán la creación de clases manejadoras
de eventos para coordinar las actividades de varias clases. Los eventos reconocidos indirecta
m ente tam bién requieren los servicios de clases reconoced oras de eventos.
G ran parte de este capítulo está dedicada a los puntos básicos de la orientación a
objetos. Se puede ver que la 0 0 proporciona muchos nuevos conceptos a la m esa de diseño,
pero tam bién está arraigada fuertem ente en las gráficas de diseño del pasado. Los sistemas
cliente/servidor actuales son una m ezcla de paradigm as de lenguajes que luchan para presen
tar una cara lisa, sin fragmentos, ante el usuario. La m ayoría de los diseñadores tendrán que
adoptar las estructuras de diseño orientadas a objetos, relaciónales y tradicionales para reunir
todos los com ponentes presentes en los sistemas em presariales actuales.
EJERCICIOS
1. ¿Cuáles son las diferencias entre las clases del dom inio de negocios y las clases del
dom inio de aplicación? ¿A partir de cuáles m odelos es más probable que se deriven?
2. La reusabilidad del código es vista frecuentem ente com o el beneficio principal de

la orientación a objetos. ¿Puede usted pensar en un a situación de proyecto en don
de, en definitiva, la reusabilidad no deba ser u n vector de calidad principal? {Con
sejo; ei indicador de pregunta vaga esta vez en ia parto, “o n ".)
3. ¿Hn qué form a difiere una clase de un tipo de entidad?
4. J. R npert padre, fue un program ador C O B O L que tuvo fam a en la G eneral A d h e

sión Corporation a m ediados de los años setenta p o r la alteración de la rutina de
conversión de calendario fis c a l a gregoriano en la biblioteca com ún en una noche
sin decirle nada a nadie. M ientras sus propios program as ejecutaban m ás eficiente
m ente, sus acciones tam bién dieron com o resultado una declaración errónea en otro
program a sobre unas ganancias espectaculares del cuarto trim estre para la com pa
ñía que, una vez que fueron desm entidas públicam ente hizo caer el precio de las ac
ciones de la em presa en la bolsa. Su hijo, J. R upert Jr. ahora trabaja com o
desarrollador en un sistem a cliente/servidor orientado a objetos en la G eneral A d
hesión Corporation. Ln una noche alteró la clase calendario fis c a l cam biando la es
tructura en la que guarda sus variables internas, pero dejando iguales a los m ensajes
externos de la clase. Siguiendo la tradición familiar, volvió a poner cl código en
producción sin decirle a nadie. ¿Tendrá problem as J. Rupert Jr.?
RESPUESTAS
1. Las clases del dom inio de negocios se derivan principalm ente dcl m odelo de in
form ación. R epresentan estructuras que pueden ser reu tili/a b les dentro de 3a m is
m a industria, tales com o cliente, cuenta bancaria, concepto de inventario y
pedido. Las clases del dom inio de la aplicación son aquellas que desem peñan el
papel de m anejadores de eventos o reconocedores de eventos. E stán derivadas
principalm ente del m odelo de eventos y son m uy específicas p ara una aplicación
o tarca de negocios particular. Son las clases que tienen m enor probabilidad de
■solverse a utilizar.
RESPUESTAS 377
2, La reusabilidad no debe ser una preocupación si no se tiene tiempo, oportunidad o

intención de reutilizar cualquier cosa. R ecientem ente vi un proyecto cliente/servi
dor que trató de em plear principios orientados a objetos p o r prim era vez en su es
tablecim iento. Los m iem bros del equipo del proyecto eran desarrolladores
brillantes e inteligentes que estaban dedicados al concepto de crear com ponentes de
softw are reutilizables. Se pasaron m ás de un año creando una biblioteca de clases
elegante y un diseño orientado a objetos pero fallaron p ara entregar el sistem a cn
el tiem po previsto. P or consecuencia, el proyecto se acabó. Sucedió que el sistema
que iban a desarrollar estaba destinado a ser reem plazado dentro de tres años por
un gran sistem a cn paquete integrado. R egresando a la id ea del establecim iento de
los vectores de calidad en la especificación de proyecto, la inm ediatez de la nece
sidad del nuevo sistem a y su relativa corta esperanza de vida estaban en conflicto
directo con la idea de perder tiem po para crear com ponentes reutilizables. Los cos
tos adicionales de la creación de reusabilidad no se recuperan sino hasta que se rcu-
tilizan los com ponentes, ya sea posteriorm ente en el m ism o proyecto o en
proyectos subsecuentes. Ese proyecto hubiera servido m ejo r al negocio si los desa
rrolladores se hubieran enfocado sobre la obtención de una aplicación funcional en
tregada en ve 7 de tratar de lograr el diseño interno m ás elegante.
i . Los tipos de entidad contienen solam ente los atributos de datos de la persona, lu
gar, eosa o idea abstracta acerca de la cual el sistem a necesita recordar algo. Las
clases no tienen solam ente atributos, expresados com o variables de la clase, sino
que tam bién tienen m étodos que representan los procesos que han sido asignados a
la clase. Los tipos de entidad tam bién deben respetar los conceptos de norm aliza
ción, y en cam bio las clases no están tan obligadas.
4. G racias al m ilagro de la encapsulación y al oculíam iento de la infonnación/im ple-

m entación, es poco probable que la travesura nocturna de J. Rupert Jr. afecte a cual
quier otra parte de la aplicación. Sin em bargo, sus acciones son im perdonables. La
alteración indocum entada e incontrolada de las bibliotecas de clase en producción
es, en mi opinión, una ofensa penalizada con el despido, ya sea de quien lo hace o
del gerente poco vigilante que perm ite que suceda tal situación peligrosa. Parecería
que cl establecim iento del Sr. Rupert no está listo para la disciplina y el rigor req u e
ridos para m anejar un sistem a orientado a objetos. A dem ás, tal vez quiera J. R upert
Jr. m otivar a sus hijos para que em prendieran una carrera en danza interpretativa, en
donde el tipo de espontaneidad y creatividad de la fam ilia serian más apreciadas.
C a p ít u l o
13
DIEZ MITOS
DEL DESARROLLO
CLIENTE/SERVIDOR
INTRODUCCIÓN
Creo que es adecuado term inar este libro con unas cuantas palabras para los gerentes de los
proyectos dientc/scrvidor. Para todos los que están en la silla del gerente de proyectos vaya mi
corazón. Están realm ente atrapados a la m itad de la torm enta obteniendo consejos conflictivos,
presiones, instrucciones y coerción por todos lados. Los proveedores están tratando de vender
les su m arca particular de “ magia en una caja” . Los program adores están com pitiendo para
codificar su m ejor idea más reciente. Los analistas que se enviaron para m apear el escabroso
paisaje del negocio no han sido vistos ni oídos durante meses. Los usuarios están dem andan-
380 Capítulo 13 ! DIEZ MITOS DEL DESARROLLO CLIENTE/SERViDOR
do que el software se entregue ayer, sin embargo no pueden decir lo que quieren que haga. (L.o
sabrán cuando lo tengan.) Y el jefe... no olvidemos al tirano infernal que le dio sólo la m itad
de las personas y una Tracción del presupuesto que se necesita para salvar al negocio de la ani
quilación,
¿Q ué puede haeer un pobre gerente? Bien, no puedo hacer que adore a su jefe o garanti
zarle un lugar de estacionam iento al frente, pero puedo contribuir a la confusión con algunos
consejos propios.
Toda nueva tecnología trae su propio alboroto y promesas que rápidam ente se transfor
man en folklore y leyendas, lil caso del cliente/servidor ciertam ente no es inm une a estas con
versaciones alrededor de una fogata. En este capítulo proporciono m i respuesta a las
tergiversaciones más com unes que he oído en los venerables recintos del desarrollo de softw a
re a través de los últim os años. Algunos de estos mitos son nuevos y originales de la revolu
ción cliente/servidor. A otros los reconocerá com o las m ism as viejas promesas adornadas con
cada nueva tecnología.
Sin m ás tardanza, veam os a los Diez m ejores m itos del desarrollo cliente/servidor de
Dave.
MITO 1- "LATECNOLOGÍA CLIENTE/SERVIDOR HARÁ QUE LOS

USUARIOS SEAN MÁS PRODUCTIVOS."
Este tipo de prom esa vaga es el génesis de expectativas irrazonables y divergentes para cual
quier proyecto. L.a prom esa correcta es “la tecnología cliente/servidor puede ayudar a que los
usuarios sean más productivos". Los sistemas cliente/servidor son usados com únm ente para
llevar la captura de inform ación más cerca de la fuente y la salida de inform ación más cerca de
la gente que la necesita, increm entando, por lo tanto, la productividad. La tecnología que lo
perm ite puede llevar cambios al negocio, y con cualquier cam bio hay ganadores y perdedores.
Tenga cuidado de ser muy específico sobre quienes son los ganadores y quienes los perdedo
res en su proyecto.
He visto casos cn donde la tecnología cliente/servidor mal aplicada dism inuye la produc
tividad. Tomemos, por ejemplo, cl caso del departam ento de captura de datos (sin necesidad de
ver la pantalla). El reem plazo de la aplicación de pantalla verde m anejada por códigos mnemó-
nicos con una interfaz gráñea de usuario con varias ventanas repleta de listas dcsplegables y
elem entos de menú, probablem ente no le hará ganar ningún am igo en este grupo. Si su vector
de calidad principal es velocidad de captura, una GUI puede hacerlos m ucho más lentos. Hay
que preguntarse, ¿por qué existe la captura de datos en prim er lugar ■¿D eberá la aplicación tra
tar de capturar los datos más cercanos a la fuente, digamos, en las oficinas de ventas remotas ?
Si la respuesta a esta pregunta es “ sí”, se está entrando a responsabilidades significativas
de reingeniería en la organización. La tecnología cliente/servidor se em pleará ahora para per
m itir que las oficinas de ventas capturen datos directam ente en la com putadora, en vez de que
llenen grandes formas de captura de datos. Puede ser que se eleve, de hecho, la productividad
general de la em presa, ya que se ha elim inado por com pleto al departam ento de captura de da
tos. Sin em barso. en las oficinas de ventas la productividad individual del vendedor o del asis
tente adm inistrativo del vendedor puede parecer que dism inuye. ¡Está pasando mucho más
tiempo en su PC! Podría ser más rápido garabatear notas en un fon n ato de papel que tener, de
hecho, la responsabilidad de capturar la inform ación con precisión en el sistema. D esde el pun
MITO 2.1 381
to de vista dei depan amento de ventas, están gustando m ás tiem po eon cada pedido. Sin em
bargo, visto desde la cabeza, se observa una ganancia neta en eficiencia a través de toda la or
ganización.
Un gerente de proyecto necesita m anejar cuidadosam ente las expectativas del usuario.
Esto nos regresa a tener un firm e plan general de proyecto que sea el esfuerzo conjunto del de
partam ento de I I y de las partes afectadas en la organización. Con un plan general claro, cl ge
rente del proyecto puede continuar recordándole a los usuarios cuáles serán sus papeles y
responsabilidades futuras cuando esté instalado cl software. Sin plan general, el proyecto está
abierto al ataque político por parte de las personas que podrían estar perdiendo más tiempo en
cl nuevo sistem a que el que im aginaban, o lo que es lo peor, para quienes su próxim o cambio
de carrera será haccr ham burguesas en la cocina del restaurante local.
El segundo mito es, de hecho, tres mitos en uno.
MITO 2.1: "EL CLIENTE/SERVIDOR ES BARATO."
Otro error. El cambio a una arquitectura cliente/servidor no puede m edirse únicam ente por el
costo del hardware. H ay inm ensos costos de reentrenam iento para pasar a un establecim iento
de la program ación de m ainfram e hacia el desarrollo cliente/servidor. Se estim a que entre el
veinte y el cuarenta por ciento del personal de mainframe preferirá no pasar aí nuevo am bien
te y nunca hará el cam bio. Largas curvas de aprendizaje, habilidades locales insuficientes y el
prospecto de rotación de personal significativa y la pérdida de m uchos em pleados que llevan
m uchos años, pueden añadir nuevos costos sustanciales.
M ito 2.2: "Podemos usar el nuevo sistema para forzar mejoras

en el proceso del negocio."
Tal ve¿ el m ayor costo oculto de la introducción de los sistemas cliente/servidor es el costo de
la reingeniería del negocio. Casi todo sistem a cliente/servidor conlleva algún grado de cambio,
frecuentem ente ese cambio es significativo. Hace varios años, dos com pañías con líneas de n e
gocios sim ilares se em barcaron al mismo tiempo en sistemas cliente/servidor casi idénticos.
Cada sistem a proporcionó cambios significativos en la organización.
En una de las com pañías se habían preparado para el nuevo sistem a, haciendo reuniones
entre ellos m ism os y llegando a un consenso sobre la m anera de llevar el negocio, aplicar rcin-
geniería y docum entar su negocio antes de tratar de autoruatizarlo. En la otra com pañía deci
dieron dejar que el departam ento de IT negociara los cambios del negocio, si se necesitaban,
m ientras analizaban y diseñaban el software para eada área funcional.
¿A divine cuál proyecto term inó prim ero? ¿A divine cuál negocio quedó más satisfecho
con el nuevo software? I -as diferencias en el costo del desarrollo y la aceptación del software
fueron dramáticas. Ll negocio que se tomó tiempo para llegar a un consenso y definir su visión
futura estuvo tranquilo, preparado y listo para la automatización. Todos sabían cuál iba a ser su
papel futuro en la organización. El esfuerzo del desarrollo llegó suavem ente y los usuarios ob
tuvieron, por lo general, lo que esperaban del nuevo sistema.
MITO 4 383
M uchas com pañías han tomado control de la situación aplicando castigos cuando los
usuarios echan a perder sus PCs. Las sanciones pueden ir desde cargos m onetarios al departa
mento por la reparación o reinstalación del software em presarial hasta las sutiles fuerzas de la
hum illación publica. A lgunas em presas que no han sido capaces de controlar la situación han
ido tan lejos como elim inar las unidades de disco flexible de las com putadoras de escritorio y
lim itar severam ente el acceso a Internet. Aun con cl establecim iento de controles de configu
ración moderados, no es poco com ún encontrar dos PCs aparentem ente idénticas y que no es
tán separadas más de tres metros, que exhiben anom alías radicalm ente diferentes cuando
ejecutan las aplicaciones cliente/servidor em presariales. Los departam entos de IT que son in
capaces de ejercer su influencia sobre la adm inistración del am biente de escritorio pueden ver
cóm o cacn en la anarquía sus iniciativas cliente/servidor.
MITO 4: "ES FÁCIL CONSTRUIR VENTANAS USANDO

ESTAS NUEVAS HERRAMIENTAS RAD."
Lstc mito es parcialm ente cierto, lis muy fácil construir ventanas usando las herram ientas de
desarrollo RAD que hay en el mercado. El que estas ventanas logren algo significativo en el
negocio es un asunto com pletam ente diferente.
liste m ito es perpetuado continuam ente por m uchos de los proveedores de herram ientas
de desarrollo GUI. lin una conferencia reciente, tres proveedores de herram ientas de desarro
llo chente/servidor hicieron una “carrera" que involucraba a tres program adores expertos
usando cada uno de ellos una herram ienta GUI diferente. AI inicio de la carrera, el vendedor
que la dirigía le dio a cada uno una especificación idéntica para una aplicación de captura de
pedidos sim ple y tes dijo a los program adores que codificaran un conjunto de ventanas fun
cionales. El público observó el frenesí de clics conteniendo la respiración. M ientras tanto, el
vendedor alababa las ventajas del desarrollo rápido. Después de cuarenta m inutos el prim er
program ador se levantó cantando victoria, seguido rápidam ente por los otros dos.
Cuando el público exaltado se calm ó, el vendedor cam inó triim fantem ente hacia el p o
dio y dijo, “Por supuesto, es probable que no se pueda codificar una aplicación com pleta en
cuarenta y dos m inutos. Los problem as son ligeram ente m ás com plejos. Puede llevar todo un
día". Para evitar la estam pida de gerentes de proyecto abalanzándose para com prar su ejem
plar del softw are, mi colega se asom ó a las PCs de dem ostración. Lo que vio en las pantallas
fue curioso. N inguna de las aplicaciones se parecía. H abía diferencias dram áticas cn estilo,
tipo de letra, disposición y navegación entre ellas. Tam poco había ediciones en el lugar. Se
podía guardar el nom bre del cliente en el cam po de núm ero telefónico. Se podía salir de una
ventana sin guardar, dejando ventanas de aparición súbita huérfanas con datos sin guardar.
En otras palabras, esas aplicaciones nunca pasarían la prueba m ás rudim entaria. Lo que h a
bía probado la dem ostración era que se podía dibujar rápidam ente algo que parecía una ven
tana. La construcción de una aplicación de negocios funcional es totalm ente otra cosa.
382 Capítulo 13 / DIEZ MITOS DEL DESARROLLO CLIENTE/SERVIDOR
El negocio que no llegó a un consenso acerca de su estructura futura trató de usar el pro
ceso de desarrollo de softw are com o una excusa para los cambios, i-i equipo de desarrollo fue
visto eom o perpetrador y destructor del statu quo. Sus esfuerzos fueron recibidos con resisten
cia hostil en cada paso llevándose incontables meses de precipitadas retiradas y vuelta a co
menzar. Siendo iguales todas las demás cosas, el proyecto se llevó m uchos más años de los que
debiera.. Al fin a l los usuarios fueron incapaces de separar los problem as provocados por el
cam bio organización a! de los problem as provocados por el software. El resultado fue que m u
chos de ellos abiertam ente despreciaron y odiaron al nuevo sistema.
Mito 2.3: "Los costos de hardware bajarán."
Los costos de software no son la única sorpresa. Hasta los costos de hardw are pueden irse p a
ra arriba en ve/, de hacia abajo. Algunas de las prim eras promesas de las com putadoras de m e
nor tamaño al pasar a eliente/servidor no siem pre se han cum plido, Hn una organización se
pensó que la vieja m inicom puladora podría tener la suficiente fuerza para actuar com o nuevo
servidor de base de datos para su am biente cliente/servidor. Después de todo, casi todo el pro
cesam iento estaba siendo movido hacia el escritorio. Todo lo que quedaba era la base de datos,
¿no es así? Dos factores probaron que era errónea su suposición. El prim ero fue el hecho de
que cl nuevo softw are hacc peticiones a la base de datos con m ucha mayor frecuencia que las
viejas pantallas verdes, por lo que cada usuario individual colocaba m ayores dem andas en el
servidor central que antes. El segundo “problem a” fue que cl nuevo softw are era extrem ada
m ente popular. En los buenos viejos tiem pos del sistem a antiguo solam ente unas cuantas per
sonas de elite usaban la com putadora. A hora casi todos en ía organización solicitaban y
recibían cl nuevo sistem a en su PC. La cantidad de usuarios sim ultáneos se fue hasta cl cielo
y el negocio tuvo que hacer una mejora de em ergencia a la m áquina servidora para m anejar la
carga. Un poco de modelado arquitectónico habría ayudado a anticipar este problem a antes de
la crisis.
MITO 3: "PC SIGNIFICA COMPUTADORA PERSONAL."
PC significa ahora “propiedad de la com pañía". La com putadora personal no es tan personal
cuando alberga las aplicaciones m edulares de negocios. La com putadora de escritorio se con
vierte en parte integral del activo fijo de com putación em presarial com pleto, y su com pra y
configuración necesita ser controlada muy de cerca. Parece que cada organización tiene su pro
pia versión de “Rupert el adicto al softw are", un gerente de nivel medio o alto que no puede
evitar el bajar cualquier cosa gratis de Internet. Llega los fines de sem ana y carga a las “hor
migas com edoras de plasm a balísticas" en su PC para entretener a sus hijos mientras trabaja
sobre el presupuesto. Hl lunes llam a enojado al despacho de ayuda, debido a que parece que
ninguna de sus aplicaciones em presariales funciona y su im presora sólo im prim e hormigas.
Una rápida investigación de su disco duro m uestra que las horm igas com edoras de plasm a se
com ieron una buena parte de sus archivos dcl sistem a y controladores de im presora. Ningún
resano es suficiente para hacer que Rupert cambie su com portam iento. La siguiente semana se
produce un daño sim ilar con su nuevo protector de pantalla de lagartija bailarina.
ÍH£ (¿ E 6M F U W A V O T O D O S LOS QMFí.t.'MtMre iwscere í.tS uw '/letv H A S res?/

y o m - o e . c e c o w la s iM reef-A - v ja ;.£
fj . D '& r.o
r.e S pe c?.ícaí.ída9 vicnJA í. o u c CL íCAn¡-LíD...
La experiencia ha m ostrada que en proyectos reales se necesita un esfuerzo significativo

para codificar aplicaciones complejas en el ambiente GUI. Aun con una biblioteca de clases ro
busta de objetos reuíilizables y una especificación de diseño detallada y rigurosa, es usual que
para una sola ventana y toda su funcionalidad se necesite pasar de varios días a varias semanas
cn cl escritorio del programador. Cuando estime la fase de construcción de un proyecto, nunca
estime menos de un día para codificar la ventana de una sola tabla muy rudimentaria. M edian
te m ucha herencia puede ser que la ventana m ism a necesite solamente quince m inutos para pro
ducirla, sin em bargo la experiencia ha mostrado que es probable que sufra pruebas, ajustes y
modificaciones menores durante el resto del día. Las ventanas complejas eon muchos botones,
varias uniones de tablas y varias funciones de soporte pueden llevarse días y semanas para co
dificarlas, aunque se tenga una especificación de diseño concreta. Sin la especificación de dise
ño es casi imposible estim ar el es fuer/o de construcción.
Por lo tanto, ¿por qué difiere tan dram áticam ente la realidad de lo que prometen los pro
veedores? Pienso que la respuesta se encuentra en dos lugares. En prim er lugar, esas herram ien
tas GUI son fantásticamente complejas. Una v e/ que se avanza más allá de lo básico se
convierte en un trabajo de tiempo com pleto el dom inar la herram ienta y m antenerse al tanto con
las características que se acum ulan con cada nueva versión. Segundo, la mayoría de los nego
cios dem andan un alto nivel de sofisticación c integridad de sus aplicaciones GUI. Este softw a
re es la parte medular de su negocio. Se espera que se produzcan aplicaciones con un
presupuesto m ínim o y que se vean y com porten tan bien com o ios productos de paquetería que
cuesta millones desarrollarlos.
1.a m ejor form a para com batir este problem a es tener sus propias medidas. M ida el tiem
po que a usted le lleva hacer el análisis, diseño, construcción y prueba de cada área funcional
de la aplicación. Entonces tendrá una base sobre la cual podrá estim ar proyectos futuros. Por
ejemplo, puede dividir las horas que le lleva diseñar cada aplicación entre la cantidad de ven
tanas producidas. Entonces puede tener una m edida de “horas por ventana” para el diseño que
puede aplicar a proyectos sim ilares. H aga lo mismo con las horas de análisis, codificación y
pruebas para obtener sus prom edios respectivos. No está obligado a usar la cantidad de venta
nas com o base. Puede dividir entre la cantidad de entidades, puntos de función, clases de ne
gocios o cualquier otro producto relevante que sea indicativo del tamaño del sistema.
MITO 5
385
Luego la siguiente vez que alguien le prom eta “más rápido, m ejor y más barato” ,1 pue
de pedirle que le muestre sus medidas para problem as de negocios sim ilares a los que enfren
ta su establecim iento y qut; cuanti fique las mejoras esperadas en cada fase de ciclo de vida del
desarrollo. Para m ejorar la productividad en el análisis se debe increm entar la velocidad a la
cual la gente com prenda con precisión, se ponga de acuerdo y articule y docum ente la natura
leza del problem a. Para increm entar la productividad en el diseño se deberá ser capaz de incre
m entar la habilidad de una persona para concebir y com unicar una solución. La productividad
de codificación se logra, por lo general, 1) sabiendo qué código escribir, 2) escribiendo menos
código y 3) escribiendo código que funcione. Las pruebas llegan a ser m ás fáciles cuando quien
prueba tiene una indicación clara de lo que debe probar y cuando las pruebas producen pocos
errores.
MITO 5: "LA SIGUIENTE VERSIÓN DE LAS HERRAMIENTAS

DE DESARROLLO RESOLVERÁ NUESTROS PROBLEMAS
ACTUALES."
Aunque critico a los vendedores de herram ientas de desarrollo por la m anera en que com ercia
lizan sus productos, también debo decir algo acerca de la forma en que son desarrollados. P or
esto que digo, probablem ente cancelen mi tarjeta de m em bresía al Clickey M ouse Club, pero
los gerentes necesitan estar conscientes de este problem a.
Kn los gloriosos días de la m ainiram e, el desarrollo de lenguajes, bases de datos y siste
m as operativos era relativam ente estable. Por ejemplo, el CO BOL no se volvía a escribir cada
dieciocho meses. Tal vez vería regresar un com eta antes de la siguiente versión. Usted podía
estar seguro de que la nueva versión del lenguaje de desarrollo estaría bastante bien probada.
La integridad de los sistemas mainframe se apoyaba en la integridad de los am bientes de desa
rrollo.
L1 am biente elicnle/servitlor actual es un revoltijo de bases de datos, lenguajes GUI,
m iddlew are de red y varios sistemas operativos. No es poco común tener al menos tres siste
mas operativos diíeientes en la m isma arquitectura cliente/servidor. Hstos sistemas operativos,
sistemas de adm inistración de bases de datos, herramientas de desarrollo GUI y softw are de
com unicaciones sufren reescrituras y mejoras de versión constantemente. M uchos proyectos
c lien te/servidor instalados tienen en cuenta que cada dieciocho meses necesitarán m igrar algu
na parte de su sistem a hacia una nueva versión.
hl problem a yace en la integridad de las mejoras de versión. La aparición de problem as
en un proyecto y hasta en toda una com pañía puede ser significativa cuando errores inespera
dos se presentan en la versión “nueva y m ejorada” . Algunas mejoras de versión avanzan sua
vem ente, otras son una pesadilla. El concepto tiempo para llevar al m ercado parece haber
reem plazado a la tonfiabilidud com o vector de calidad principal para el lanzam iento de nue
vas versiones de las herram ientas de desarrollo. Los errores que aprendió a resolver en la ver
sión antigua son reem plazados por un nuevo grupo de anom alías en la nueva versión. F,1 “disco
de com posturas ( fix disk ) que proporciona los parches para los problem as de la versión
3.124 frecuentem ente vuelve a introducir problem as que estaban corregidos en la versión
Con las prom esas “m ás rápido, m ejor y m ás barato” , por lo general sólo se puede lograr dos de las
3.123. Los usuarios de las aplicaciones instaladas no tom an am ablem ente esas sorpresas. Ellos
no se ponen contentos cuando el software que trabajaba un día se descom pone al siguiente, y
no distinguen entre los errares introducidos por cl proveedor de los errores introducidos por el
personal de IT.
N o se debe culpar solamente a los proveedores por esta situación. La base de clientes es
tá perm itiendo que eso suceda. Los proveedores están enfrascados en una batalla a m uerte p a
ra hacer que se añadan las m ás recientes características a su softw are antes de la siguiente
ronda de exposiciones eom ereialcs. Los com pradores perm anecen ansiosos y deseosos de gas
tar m illones de dólares en los proveedores que proporcionan nueva funcionalidad, haciendo
que las com pañías que pueden proporcionar nuevos productos de desarrollo sean las más apre
ciadas en W all Street.
El problem a es que los sistemas de negocios fundam entales de todo el mundo están aho
ra ejecutando en esas plataform as. L l m ercado necesita com enzar a dem andar un nivel de in
tegridad de los productos que sea proporcional con el riesgo de falla o suspensión del servicio.
Hasta que llegue ese día se encontrará avanzando usted mismo a su propio riesgo si es que es
tá entre los prim eros que hacen la m igración de sus aplicaciones a las versiones más recientes
de los am bientes operativos y de desarrollo.
■-■'rSTA9E LA ñ£C~iEMr€ ^V&JC'D^D APV£E3A, TODAS LAS e.CFCQa\¡C\P-S> f-'lírUfiAñ PACÍA

’PSJHce.wxjc oeseeAw see í¿££mfí añapas cow el ve veesiów (¿cfa '.a'".
Demos un descanso a los proveedores y regresem os nuestra atención a las extrañas co
sas que suceden deutro del equipo de desarrollo de software.
MITO 6 387
MITO 6: 'EL GERENTE NO NECESITA CONOCER

LA METODOLOGÍA."
H e escuchado a gerentes que me dicen que no necesitan saber los detalles de la m etodología
de desarrollo. “Soy un gerente", dicen. “ Un buen gerente puede adm inistrar cualquier cosa. No
im porta qué es lo que se esté adm inistrando.” Cuando oiga este tipo de exclam ación no cam i
ne, corra hacia la salida más cercana y búsquese un proyecto en donde el gerente sepa qué es
lo que está sucediendo.
Es com o decir que un contratista general o un gerente de proyecto de construcción no
necesita saber cóm o construir una casa. A unque no es necesario que e! gerente del proyecto
sea un m aestro en la ejecución de las técnicas de la m etodología, lo m ejor es que tenga un buen
conocim iento del propósito y la secuencia de cada técnica. Un gerente necesita ser c a p a / de
determ inar si la persona a ia cual delega una tarea está calificada. N ecesita ser capaz de hacer
las preguntas adecuadas para adivinar si se está avanzando por cl cam ino correcto. El buen g e
rente también usa los m odelos para hacer estim aciones sobre el tam año del proyecto y el n i
vel de esfuerzo requerido. Luego adm inistra contra estos estim ados com parando el avance de
los modelos reales con el estimado. No olvide tam poco la lista de asuntos (vea el capítulo 7).
El gerente del proyecto tiene responsabilidad personal sobre los asuntos del negocio. Su papel
principal es quitar las piedras del cam ino y perm itir que su equipo avance lo más rápidam en
te posible.
Sin una buena com prensión de los puntos específicos del proceso de desarrollo, el geren
te del proyecto no tiene nada que hacer más que firm ar e im prim ir el calendario y anunciar el
paso del tiempo. Si cl proyecto necesita alguien que haga eso, está bien, pero no lo llame ge
rente. Lo que encontrará en estas situaciones es que alguien más en el proyecto, por lo general
el analista técnico, calladam ente ha tomado las responsabilidades de adm inistrar el proyecto
diariam ente. D esafortunadam ente no le están pagando por eso. El gerente, por su parte, decla
rará, generalm ente, que ha instituido un “grupo de trabajo auto adm inistrado” . lo que es fre
cuentem ente una frase hecha para “no tengo idea de lo que están haciendo todo el día” . Los
proyectos que tienen éxito bajo esas condiciones son, por lo com ún, el resultado de un geren
te que decide, atinadamente, no estorbar a su equipo.
MITO 7: "NO TENEMOS QUE HACER NADA DE ANÁLISIS

Y DISEÑO DEBIDO A QUE VAMOS A COMPRAR PAQUETES
EN VEZ DE CONSTRUIR SISTEMAS."
E ste mito es un fenóm eno reciente que parte de la noción de que lodos los grandes sistemas
de inform ación dei m undo ya han sido desarrollados y se encuentran disponibles en el
m ercado abierto. En vez de construir sistem as, la com pañía tom a la decisión estratégica de
com prarlos.
La idea de com prar sistemas es buena. “Debido a que vamos a com prarlo, no necesita
mos codificarlo”. É sta es una frase relativam ente inocua de sentido com ún. Sin embargo, lo
que sucede después, es un conjunto de aseveraciones que llevan a una falla en la lógica. “D e
bido a que no tenem os que codificarlo, no tenemos que diseñarlo’’ que conduce a “debido a que
no tenemos que diseñarlo, no tenem os que analizarlo” . Ahora ia m archa del razonam iento se
ha descarrilado.
Si no se tiene un docum ento que exprese con claridad las necesidades del negocio no se
tiene base para tom ar una decisión de compra. De hecho, para ser más precisos, las decisiones
de com pra se realizan cada día acorde a tío conjunto vago de puntos proporcionados por el n e
gocio y las prom esa repetida por el proveedor. Lo que falta es alguna forma para m edir la di
ferencia entre lo que el paquete hace y lo que el negocio requiere que haga.
Entonces, ¿qué tanto de este análisis y diseño se tiene que hacer cuando se com pra un
sistem a de negocios en vez de cuando se le construye? Revisemos algunas de las técnicas tra
tadas en este libro y veam os la m anera en que se aplican.
Todavía se necesita un plan general. Ei negocio debe definir el beneficio deseado de un
nuevo sistem a para que se tenga algo contra lo que se puedan m edir los costos. No olvide in
cluir este hecho a la m edia y statu quo en las opciones de solución. Puede suceder que ningún
paquete satisfaga Jas necesidades y después de todo sea más barato construir algo.
Un modelo de contexto es extrem adam ente útil para la com pra de software. El modelo
de contexto destaca todas las unidades de negocios afectadas y todos los demás sistemas con
los que tendrá que conversar el softw are com prado. El modelo de contexto le dirá si el paque
te pretendido es, en realidad, una aplicación aislada o si está altam ente involucrado con las de
más aplicaciones em presariales. La implicación de esto últim o es que la estructura interna del
paquete llega a ser extrem adam ente im portante si se requiere que trabaje en un am biente abier
to en donde otros sistemas necesitan acceso a los datos del paquete. El softw are em paquetado
ya no puede ser evaluado sim plem ente com o una caja negra, en donde no preocupa qué tan en
redado es su funcionam iento interno siempre y cuando realice su trabajo.
id m odelo de eventos es una forma excelente para organizar los requerim ientos de com
portam iento y procesam iento para un sistem a com prado. La lista de eventos proporciona al
negocio y al proveedor una lista de verificación detallada de todos los eventos de negocios so
bre los que está especificado que el paquete debe responder. El diccionario de eventos articu
la la inform ación que se espera que utilice el nuevo paquete y le dice al proveedor lo que el
negocio considera que sea una respuesta adecuada para cada estím ulo. L a sección de activi
dad del diccionario de eventos no necesita ser tan detallada com o lo sería para un desarrollo
personalizado, debido a que no se ha anticipado que se tendrá que codificar o alterar gran par
te del paquete.
Un buen modelo de inform ación es vital para la evaluación del paquete. El modelo de
información es un m apa de los hechos que necesita recordar el negocio. Si el paquete no re
MITO 8 389
cuerda los mismos hechos, o tiene diferencias de cardinalidad significativas, será m ás eviden
te cuando se com pare cl modelo de inform ación con el paquete. Las diferencias en contenido,
estructura y cardinalidad de los datos son algunas de ¡as cosas más caras y difíciles de cambiar,
tanto en el paquete com o en el negocio. Por ejemplo, si el paquete perm ite solam ente un em
barque por factura y los clientes están contentos recibiendo facturas que incluyen varios envíos
del sistem a antiguo, se estará enfrentado a decisiones dilíciles. Se puede elegir hacer m odifi
caciones personalizadas a! paquete y, por lo tanto, cancelar la posibilidad de recibir mejoras fu
turas del proveedor. Se puede tener el suficiente poder para persuadir al proveedor para que
haga el cam bio a su paquete estándar (y, por supuesto, los com petidores también obtendrán la
característica). F.n caso de que fallen estas opciones se puede valorar el impacto en el negocio
y en los clientes debido al cam bio en la forma de haccr negocios.
El modelo de inform ación define la form a actual del negocio. Al com pararlo con la for
m a del paquete se puede escoger cl paquete que se ajuste m ejor al. negocio. En donde haya di
ferencias tiene una base para la m edición del costo del cam bio del paquete contra el impacto
del cam bio en cl negocio.
Si se decide cam biar el paquete, los modelos de análisis esencial le dan una base para el
desarrollo de prototipos y la creación de una especificación de diseño externa e interna para los
cambios. El m odelo de eventos y los modelos de inform ación, com binados con la distribución
geográfica de los sitios del negocio, proporcionan la base para el despliegue del paquete a tra
vés de la organización y le perm iten valorar los com prom isos de diversas arquitecturas centra
lizadas o distribuidas que pueden estar disponibles.
Sin un análisis adecuado de las necesidades del negocio, y un diseño de los cam bios al
software o al negocio, la introducción de softw are em paquetado es frecuentem ente un campo
minado de sorpresas para todos los involucrados.
MITO 8: "LOS ENSAYOS ESTRUCTURADOS FUERON

SOLAMENTE PARA EL ANÁLISIS ESTRUCTURADO
Y EL DISEÑO ESTRUCTURADO."
No es así. 1,a necesidad de pruehas y revisiones es mucho más necesaria que nunca cn los com
plejos am bientes de desarrollo actuales.
Imagine que es un piloto de avión llevando a su jet de pasajeros sin escalas desde Seat-
tic a Boston a través de Estados Unidos. La prim era fase del plan de vuelo especifica que
pase sobre Billings, M ontana. Si está en curso y en tiempo, la segunda fase deberá llevarlo so
bre Chicago en las siguientes horas. Después de que Chicago esté a ¡a vista, se está libre en el
camino hacia Boston.
¡Ahora im agine que no tiene ningún instrumento de guía y cero visibilidad' Su radio le
permitirá ponerse en contacto eon Billings y con Chicago solam ente cuando esté muy cerca de
esas ciudades. Su única oportunidad de llegar a su destino es despegar de Seattle con cl avión
dirigido hacia Billings, Para cuando deba estar acercándose a Billings debe revisar la radio p a
ra ver si encuentra a Billings. Si hace contacto por radio, ya sabe que es seguro continuar h a
cia Chicago. Si no encuentra a Billings, deberá decidir si vuela en círculos, perdiendo valioso
tiempo y com bustible o si procede hacia el este bajo su propio riesgo.
Las revisiones de proyecto que suceden solam ente al final de las fases de análisis y di
seño son muy sim ilares a volar a ciegas durante un tiempo y luego encender la radio para ver
si se está cerca del punió de control. A unque las revisiones de “final de fase’7 son una delicia
para la celebración de m etas importantes en el proyecto, son extrem adam ente inútiles en lo que
se refiere a hacer correcciones de curso significativas. El tiempo permitido para la fase ya ha
transcurrido, y si se encuentra que el proyecto está fuera de ruta habrá que regresar perdiendo
tiempo y dinero o continuar hacía adelante con un gran riesgo.
Hn realidad los aviones casi siempre están fuera del curso por un pequeño margen. El
equipo de navegación a bordo hace ajustes constantes para m antener al avión volando hacia su
destino. D e m anera similar, un proyecto necesita un m edio para tom ar m edidas y hacer ajustes
constantes conform e avanza hacia su tiempo de entrega. Hstos ajustes se hacen m ediante la
adopción de una cultura de pruebas consistentes y continuas.
U na prueba ( o prueba estructurada, w alkthrough en inglés.2 Si fuera una obra de teatro
sería un ensayo entre com pañeros) es un conjunto de reglas y papeles que se usan para
rea li/a r revisiones en grupo entre com pañeros sobre cualquier producto del trabajo. Las prue
bas deben ser frecuentes, no am enazadoras e inform ales. D eben ser tan com unes en un pro
yecto de desarrollo que lleguen a ser parte de la cultura del desarrollo. Esta es la m anera en
que funcionan.
Todo producto del trabajo, desde el plan general, modelos de análisis y m odelos de dise
ño hasta el código term inado, necesita ser som etido a un nivel de prueba. Cualquiera del equi
po de desarrollo puede iniciar la prueba en cualquier momento. No im porta si el trabajo está
term inado o no. El propósito de la prueba es hacer resaltar los errores en el producto y validar
lo para ver si está correcto. La prueba N U NCA debe usarse para evaluar el desem peño del au
tor. Si el gerente del proyecto basa la evaluación del desem peño del personal en el resultado de
las pruebas, el establecim iento nunca volverá a tener otra prueba honesta.
Los participantes en la prueba incluyen a los com pañeros del autor y representantes del
público para el docum ento. Para las pruebas de análisis m e gusta incluir a otros analistas, d i
señadores, program adores y hasta algunos de los que hacen pruebas. Esto le da a los especia
listas de fases posteriores avisos previos del tipo de aplicación que les estará llegando. Yo
tiendo a separar a las revisiones de usuarios de las revisiones técnicas, debido a que el enfoque
de los dos grupos varía am pliamente. El gerente del autor sólo es invitado a la prueba si es que
puede perm anecer neutral. Si no puede, deberá ser dejado a un lado.
Las personas desem peñan papeles diferentes en la prueba. El autor es la persona o per
sonas que crearon cl producto que se está revisando. El presentador es la persona que leerá y
presentará el material ante el grupo. Hl autor no siem pre es el presentador. Tal vez se quiera
que alguien más presente el material del autor sim plem ente para probar que los docum entos
son claros y com prensibles sin em bellecim ientos de último minuto hechos por la im aginación
del autor. Se nom bra a un escribano para que anote cualquier error encontrado por el grupo y
se nom bra a un m oderador para m antener el rum bo de la reunión.
Los participantes deben recibir notificación de una prueba y una copia del material al
m enos un día antes. Esto no im pide que una persona haga un llamado para una prueba de em er
gencia, He estado en proyectos en donde el ritm o es tan rápido y vertiginoso que se acepta que
sea uno llam ado a una prueba con muy poca antelación.
Q uienes están involucrados siempre deberán estar inform ados del alcance de la reunión.
Por ejemplo, si la reunión es para revisar modelos de inform ación, no deberán estar enfocados
en asuntos de codificación. A unque la gente debe revisar el m aterial de antemano, he ericon-
2 Yourdon, 1987.
MITO 9 391
trado que esto rara v e/ sucede en la práctica, En un proyecto muy ajetreado casi nadie tiene
tiempo para realizar una revisión sena antes de la reunión. La idea de que la gente se llevará
el m aterial a casa para revisarlo en la noche es en gran m edida producto de buenas intencio
nes. A esto se debe que TODO el material debe ser tratado en la reunión.
Las pruebas no deben durar m ás de una o dos horas. Cuando los docum entos o modelos
requieren pruebas muy largas, es indicativo de que las pruebas no son lo suficientem ente fre
cuentes. D urante la reunión ios m ateriales se leen y discuten, lil escribano registra todos los
errores encontrados y asuntos planteados. Li propósito de la reunión es encontrar errores en
forma temprana para que se puedan hacer correcciones de curso pequeñas. Las soluciones no
deben ser discutidas extensam ente en la reunión. Si la corrección al modelo no es inm ediata
mente obvia se debe anotar el error para que el autor pueda encontrar una solución después de
la reunión. Al final de la reunión el grupo deberá decidir si necesita revisar las correcciones a
los errores en una reunión subsecuente o si el docum ento es satisfactorio, quedando pendiente
la resolución de los problem as encontrados.
Los ensayos deben ser parte de cualquier cultura de desarrollo en equipo, líi trabajo de
cada persona debe ser visto por otros ojos, al m enos una vez a la semana, 'teniendo revisiones
frecuentes, el equipo siem pre tiene una imagen actualizada de su avance contra el plan. E l ge
rente del proyecto puede hacer correcciones de curso inform adas antes de que sea muy tarde.
Las pruebas también ayudan a aum entar la productividad distribuyendo el conocim iento y
prácticas estándar a través del equipo.
MITO 9: "LOS ESTÁNDARES EMERGERÁN

CONFORME AVANCE EL PROYECTO."
El no tener estándares es un error fatal para cualquier proyecto que diseñe interfaces gráficas de
usuario. Hay dos formas para desarrollar estándares en un proyecto. U na forma es robarlos
de otro proyecto. La otra form a es permitir que evolucionen a través de una economía de libre
mercado, en donde los mejores estándares desechan a las ideas más débiles y fuerzan el cum
plim iento por medio de la mano invisible de la competencia. El primer m étodo es rápido y ba
rato. El segundo m étodo es atractivo para nuestra sensibilidad dem ocrática, pero es muy caro a
la larga.
L e sugiero encarecidam ente que adopte estándares que ya existan, ya sean propios de ca
sa o de otro softw are similar, en vez de tratar de inventar los propios. H ay varias com pañías
con bibliotecas GUI estándares en el m ercado que su establecim iento puede com prar o adqui
rir la licencia de uso. También se pueden tom ar ideas del softw are com únm ente usado en el
escritorio de los usuarios.
Los estándares proporcionan un mareo de trabajo para el desarrollo que elim ina gran par
le de las discusiones y polém icas que pueden suceder en su ausencia, listo no quiere deeir que
los estándares sean com pletam ente rígidos. Si el estándar no se aplica al problem a específico,
Úselo para justificar el porqué se debe haeer algo diferente. Si sucede que un estándar no es
bueno en ninguna situación, proceda a cambiarlo. Los estándares establecidos ' ‘sufrirán m uta
ciones” en un proyecto, pero no se debe dejar que “ surjan” de la nada
392 Capítulo 13 / DIEZ MITOS DEL DESARROLLO CLIENTE/SERVtDOR
MITO 10: "NECESITAMOS UNA METODOLOGÍA ESTÁNDAR

Y UNA HERRAMIENTA CASE ESTÁNDAR."
El últim o mito tiene que ver con la confusión entre técnicas, m etodologías y herram ientas C A
SE. Como se dijo en el capítulo 1, una técnica es un método estructurado y repetible para lo
grar una larca especifica (por ejemplo, el m odelado de eventos, el modelado de inform ación y
la diagram ación de navegación por ventanas). U na m etodología de ingeniería de software es
el acomodo ordenado de técnicas en un enfoque sistemático para la construcción o adquisición
de sistemas de inform ación. Una herram ienta C A lS E es una aplicación de ingeniería de soft
ware asistida por com putadora que perm ite que se practiquen técnicas específicas usando el po
der de la com putadora para que ayude a crear, organizar y presentar los modelos. Algunas
herramientas CASB tienen suficientes técnicas y herramientas de adm inistración integradas
para soportar un ciclo de vida com pleto de la metodología.
El apostar todo a cualquier m etodología única es poco sabio en el mundo actual de cam
bios rápidos. Las m etodologías que ganan prom inencia están, por lo general, atadas a un para
digm a de tecnología particular, tal com o la orientación a objetos o los sistemas m ainfram e
tradicionales. Mi punto de vista es que el am biente cliente/servidor actual es una m ezcla hete
rogénea de hardw are y software de diferentes paradigmas, y el establecim iento de desarrollo
inteligente necesita ser com petente en muchas técnicas diferentes para tener éxito.
Tenga cuidado cuando designe a una m etodología de desarrollo estándar. A unque m u
chas de las técnicas del libro son generales por naturaleza, son más aplicables al análisis y di
seño de sistemas de negocios que tienen interfaces gráficas de usuario y bases de datos
relaciónales, flay m uchos otros tipos de sistemas de com putación. Las técnicas para los siste
mas de tiempo real, aplicaciones con bases de datos orientadas a objetos y hasta sistemas por
lotes tradicionales varían. Cada establecim iento necesita prácticas de desarrollo com unes. E n
tre m ayor sea cl establecim iento de desarrollo, mayor será la necesidad de que sean com unes.
Si el establecim iento va a designar prácticas de desarrollo estándar, deberá incluir variantes cn
la m etodología que sean adecuadas para cada tipo de sistem a dentro de la compañía,
M uchas com pañías gastan cantidades exageradas de tiempo discutiendo la “mejor” tec
nología y no cl tiempo suficiente para elevar las com petencias principales de su personal. La
m ayoría de las m etodologías de desarrollo son m uy similares. Su popularidad aum enta y dis
m inuye con ¡os caprichos de la m oda de la industria. Lo que cuenta, en realidad, es si un equi
po de desarrollo ha dom inado las abstracciones principales del modelado del problem a de
negocios, sus datos, eventos y procesos, y si los puede traducir hacía un diseño escrito útil p a
ra la tecnología de destino.
A lgunas personas hacen la suposición de que una técnica debe estar soportada por una
herram ienta CA SE para que sea válida. Si se revisa la historia, las herram ientas CASE siem
pre han estado atrás de la introducción de nuevas técnicas. Muchas de las prim eras herram ien
tas CA.Sí;. se concentraron en el modelado de procesos, pero no en cl modelado de información.
¿Significa esto que el modelado de inform ación no era im portante? ¡Por supuesto que no! Al
m om ento en que se escribe esto, al m odelado de eventos robusto le están faltando productos
CASL. Espero que para cuando haya llegado a este capítulo del libro pueda ver que este des
cuido no hace que eS modelado de eventos sea una técnica m enos valiosa.
Los prov eedores de herram ientas CA SE rara vez inventan o presentan nuevas técnicas
por sí mism os, lin vez de ello, incluyen en sus herram ientas las técnicas que son populares en
MITO 10
393
el m o b a s a d o F-ueeow i lee ííAMtewrAS d c re p e e w íJ i, frs re A fro e s o e r c w r A a s u a

k,ÍJ£CjA$. ¿c'UAíV^G VAKJ A AVUDA£ C & T O 0 TrFOS AL ££_A.N A Í7A2AÉ?7
a prensa especializada y las que dem andan sus clientes. La inclusión de una técnica está de-
enm n ada por cl mercado. Su objetivo es vender más copias de la herram ienta CASI;.
[Nunca perm ita que la falta de soporte CASK lo detenga para practicar una técnica va-
íosa. Para todas las técnicas de este libro he realizado análisis y diseño con gran velocidad y
ixito sin usar m ás que un procesador de palabras y una simple herram ienta de dibujo. Yo pre-
íero, por lo menos, usar soporte CA SE para el m odelado de inform ación. La mayoría de las
lerramiuntas lo soportan bien y hacen mucho más fácil la vida para m odelos grandes y com-
ilcjos. Aparte de eso, use herram ientas autom atizadas si es que le ayudan. Sí le dan problem as
i no dan soporte a sus esfuerzos no deje que le estorben. La herramienta más importante que
icne a su disposición es su propia mente.
394 Capítulo*13 / DIEZ MITOS DEL DESARROLLO CUENTE/SERVIDOR
RESUMEN
El desarrollo de aplicaciones de negocios en los am bientes cliente/servidor actuales es una ta

rea com pleja. Puede ser retador y muy satisfactorio. Un gerente de proyecto necesita estar
consciente de muchos factores para haccr que el proyecto sea un éxito técnico y político.
La tecnología cliente/servidor puede perm itir que el negocio haga cambios en la iorm a
en que captura y procesa inform ación. Para cualquier esfuerzo de cam bio el negocio debe ser
un participante entusiasta. Sin el soporte e involucra miento de la com pañía, sin im portar qué
tan bueno sea técnicam ente el sistema, el proyecto estará enm arañado para siem pre en luchas
y controversias políticas.
lista tecnología no es algo barato para el presupuesto de compul ación de la com pañía. 1.a
curva de aprendizaje es em pinada. Los costos de re en tren am iento son significativos y mucho
personal de m ainfram e puede sim plem ente decidir no continuar. Til costo de volver a dar for
ma al negocio necesita ser reconocido. Siem pre es más barato autom atizar una visión futura es
tablecida por el negocio que negociar un cam bio en el negocio conform e el proyecto trata de
avanzar.
Con los sistemas cliente/servidor el personal de com putación se convi cite en parte integral
de la red de computación empresarial. 1il grupo de IT necesita demandar un control estricto so
bre cl am biente del escritorio para evitar el caos y la anarquía. Los negocios que están acostum
brados a la PC con libertad para todo de los ochenta, necesitarán hacer este ajuste cultural.
La generación de herramientas de desarrollo ac tu a les bastante compleja. Ks cierto que se
pueden construir ventanas eon m ucha mayor rapidez usando estos productos, pero las herra
m ientas no pueden hacer nada del razonam iento en vez de uno. La mejor defensa contra las pro
mesas de los proveedores y las expectativas de la adm inistración es establecer las medidas
propias. Lleve cuenta de qué tanto se necesita para analizar, diseñar, codificar y probar cada
segmento de la aplicación. ¡[.'se esas medias como una línea base para sus estimaciones y bus
que formas para m ejorar su desem peño m ediante la reutilización de modelos, estándares, códi
go y p erso n a s!
Tenga cuidado de la tram pa de las versiones. Un sistem a cliente/servidor sólo es tan fuer
te com o su eslabón más débil, y m uchos de estos eslabones son partes que se han com prado, a
veces a muy bajo costo. La industria necesita hacer que los proveedores sean responsables de
un nivel mayor de integridad para las m ejoras de versión. N uestra industria está reglam entada
actualm ente sólo por la presión del mercado. Si vam os a conservar esas libertades necesitam os
insistir en un nivel de calidad más alto por parte de nuestros proveedores de herramientas de
desarrollo. Ellos, a su vez, deben m otivar y esperar un mayor nivel de calidad de quienes usan
sus herram ientas para desarrollar el software de negocios del mundo.
Los gerentes son cl pegam ento que m antiene juntos a los proyectos. Los gerentes actua
les se encuentran a si m ism os ensam blando equipos de especialistas. Esto requiere que el ge
rente tenga una buena base sobre la m etodología y técnicas del proyecto. Un buen gerente usará
los modelos para hacer estim aciones y medir el avance a lo largo del camino.
Las técnicas de análisis y diseño de este libro no están limitadas al desarrollo de aplica
ciones. También pueden usarse para evaluar la com pra de paquetes de software. Los modelos
de análisis proporcionan el marco de trabajo que define el perfil dcl negocio. Esto perm ite que
se mida cada instancia en donde el perfil del paquete puede satisfacer o no sus necesidades y
le da una base para determ inar el costo, va sea de cam biar el paquete o de cam biar la form a en
que se hacen negocios.
RESUMEN 395
Una cultura de revisiones frecuentes es crucial para el éxito de cualquier proyecto. A na
die se le debe perm itir trabajar en el vacío. La técnica de las pruebas estructuradas es tan va
liosa hoy com o lo fue cuando se introdujo por prim era vez. Además, nunca se deberá dejar que
los estándares surjan en un proyecto. Los estándares deben establecerse tan pronto com o sea
posible para asegurar un producto de software uniforme.
Algunas de las técnicas descritas en este libro están am pliam ente soportadas por herra
m ientas CASE, pero otras no. Algunas de las técnicas ni siquiera requieren tal automatización.
Recuerde siempre que la herram ienta m ás im portante que tiene es su m ente, junto con la habi
lidad para escribir las cosas.
Por ultim o, este libro ha tratado acerca de una serie de técnicas que han probado ser
muy exitosas en el desarrollo de sistemas de negocios cliente/servidor. C ada práctica tiene uua
larga historia en la evolución de la Ingeniería de softw are com o disciplina. Espero sincera
m ente que haya encontrado algo en este libro que le ayude para desarrollar softw are m ejor y
m ás confiable.
A p é n d ic e
ESTUDIO DEL CASO McVET
NOTA DEL AUTOR
Se pretende que d siguiente caso de estudio sea una aplicación inform ativa, entretenida e
instructiva de los conceptos presentados en este libro. Espero que le proporcione una oportu
nidad de ejercitar algunas de sus habilidades de ingeniería cié softw are, y tal vez le proporcio
ne plantillas y patrones de análisis y diseño que pueda aplicar a sus propios proyectos. Ai igual
que cualquier caso de estudio, ha sido sim plificado en varias áreas p ara perm itir que quepa den
tro de los confines de este libro. Para proyectos más com plejos, la representación de, digamos,
cliente, estará m ucho más involucrada que la que se presenta aquí, pera los patrones y concep
tos siguen siendo aplicables a los proyectos reales. Hl diseño que se presenta es sim plem ente
una de muchas soluciones tecnológicas posibles. Com o sucede en el mundo real, hay pocas res
puestas correctas. La solución de diseño propia estará basada en las suposiciones propias acer-
397
398 Apéndice / ESTUDIO DEL CASO McVET
ca de las restricciones de la tecnología disponible y lim itada solam ente por su propia im agina
ción e innovación. El hccho de que podam os leer la especificación de diseño y estem os de
acuerdo o en desacuerdo con su corrección es el asunto fundam ental del proceso de análisis y
diseño. Sin más preámbulo, bienvenido al mundo de McVet.
NACE UNA COMPAÑÍA
Gerald Icabod Shedm ore tenía un m al día. Odiaba volar a casa en la m añana del sábado, pero
la conferencia se había alai-gado tanto el viernes que perdió su avión. En menos de cuarenta y
ocho horas estaba de regreso en cl aeropuerto en camino hacia otro sim posio sobre ingeniería
mecánica. La banda transportadora de equipaje se rom pió cuando apenas veía que su maleta
com enzaba a salir. Un solo asistente en overol gris com enzó a sacar el equipaje en la terminal.
Pronto se hizo obvio que el contenido com pleto del 767 sería recuperado m aleta por maleta,
antes de que la suya pudiera ser rescatada de la banda transportadora inerte.
incapaz de llamar la atención del asistente, Gerald encontró un teléfono público y llamó
a su casa. C ontestó su hijo Tim. “Hola papá, m am á te ha estado esperando. Molly necesita ir
al veterinario inm ediatam ente.”
M olly apareció por prim era vez en la vida de G erald cuando regresó de un viaje a Japón.
U no de los com pañeros de escuela de Tim llevó una caja llena de cachorros labrador dorados
para enseñarlos. La caja pronto se vació. Habiendo crecido com o m ascota de com pañía, Molly
nunca había tenido éxito com o perro de jardín. Por consccucncia, los que vivían en casa de
Shedm ore ahora poseían una vitrina sin vidrios, tres sillas de com edor en vez de cuatro y los
restos quem ados de lo que una vez fue una cobija eléctrica. En este día pareciera que la vida
de abandono de M olly al fin la atrapó. Astillas de la cóm oda de cedro tic la señora Shedmore
se le atoraron en las encías, causándole una infección. M olly trató de adm inistrarse el remedio
de perro casero de revolearse en el polvo fuera de la puerta del patio sin tener éxito.
Cuando dejó el teléfono, Gerald pudo ver que ya habían descargado todas las maletas de
los dem ás pasajeros con la notable excepción de la suya, la cual perm anecía sola en la banda
transportadora. Su equipaje fue recuperado al fin por un maletero m alenearado que expresó su
inconform idad cuando Gerald no le dio propina por sus esfuerzos. U na vez reunido con su ma
leta, Shedm ore se em barcó en un recorrido frenético contra el tráfico del fútbol del sábado p a
ra recoger a Molly. Viendo que la perra estaba dem asiado sucia para transportarla, Gerald y
M olly gozaron de un baño rápido y frío en la entrada d d garaje. Se estaba haciendo tarde y cl
estadio de fútbol estaba entre su casa y la clínica del veterinario. Llegaron cinco minutos antes
de que cerraran, quedando frente a la gélida m irada de la reccpcionista que les inform ó que la
oficina estaba cerrada los domingos, por lo que tenían que llevarse a la perra hasta el doctor
que regresara cl lunes.
Esa noche, Gerald se acostó pensando sobre los eventos del día. ‘7 ,Por qué sucede que
no se puede encontrar un veterinario en la ciudad que esté abierto cuando se 1c necesita? ¿Se
rá que va nadie cree en el servicio y en la eficiencia? ¿Y por que no pueden hacer un transpor
tador de equipaje que funcione?” Repentinam ente la inspiración le llegó a G erald Shedmore.
■;Lo tengo!", dijo, sallando de la cam a y yendo rápidam ente a su restirador.
TRES AÑOS DESPUÉS 399
TRES AÑOS DESPUÉS
Pendergast Sylnick estaba sentado en las oficinas con paneles de caoba de G. I. Shedmore, pre
sidente de McVet, la com pañía con crecim iento más rápido en la bolsa local. Pendergast, o
“Peo”, com o le decían sus amigos, estaba dándose de patadas silenciosam ente por no com prar
acciones de McVet cuando salieron al público por prim era ve*. Al m enos su em presa de inge
niería de software le había ganado a los grandes y consiguió el contrato para construir un sis
tema de inform ación para la cadena de establecim ientos McVet. Esta era su prim era reunión
directa con Shedm ore después de la caria de com prom iso que firm aron.
“Bienvenido a McVet, Pen.” Gerald se recostó en su sillón de cuero. “Tu em presa ha si
do escogida para diseñar nuestro nuevo sistem a de captura de pedidos y facturación autom ati
zada para McVet. Siendo yo mismo un ingeniero, quedé im presionado por el uso que haces de
métodos de desarrollo razonables. Las otras em presas tienen folletos engañosos, llenos de si
glas que no puedo entender. Tu personal m e im presionó por su habilidad para com unicarse cla
ram ente con mi personal. Creo que éste será un buen equipo".
“Gracias, Gerald” , contestó Pendergast. “ Una de las primeras cosas que producirem os es
un plan general dei proyecto. De hecho, tu organización proporcionará toda la inform ación que
irá en el plan general. N osotros seremos sim plem ente facilitadores. Antes que hagam os eso
quiero pasar un poco de tiem po conociendo McVet. Podernos com enzar platicando acerca de
tus operaciones, luego m e gustaría visitar los establecim ientos y ver cóm o funciona to d o /’
I-a com pañía que fundó era uno de los temas de conversación favoritos de Gerald. Inm e
diatam ente lanzó su discurso estándar. “McVet es una eadena en crecim iento que proporciona
cuidado canino rápido, diseñado para los propietarios de perros actuales siempre activos. N ues
tro enfoque está en proporcionar servicios básicos de veterinaria y de acicalam iento por abajo
de los precios dcl m ercado en lugares accesibles y durante las horas adecuadas. 1-os servicios
incluyen vacunación, diagnóstico y prescripción, cirugías y todo tipo de cuidados. De no ser
por las cirugías program adas, no se necesita cita.
“A ctualm ente hay cinco establecim ientos de McVet en la gran área m etropolitana, y hay
planes para añadir tres establecim ientos más en el siguiente año fiscal, lis probable que el pró
xim o año abram os operaciones en otra ciudad. Nuestras puertas están abiertas los siete días de
la sem ana de 7:00 a.m, a 9:00 p.m. También tenemos un servicio de em ergencia para después
de esas horas.
“Los clientes son atendidos por un especialista entrenado en el cuidado de los animales
que recibe a los clientes y maneja la caja registradora. L'no o dos módicos veterinarios titula
dos están asignados perm anentem ente a cada establecim iento y varios veterinarios son rotados
cutre establecim ientos. Hl acicalam iento es proporcionado por nuestro módulo sanitario Perro
Feiiz patentado, que tiene una alta tecnología. Cada ubicación tiene un em pleado de tiem po
com pleto que hacc la facturación y la contabilidad.
“Nuestra captura de pedidos es manejada actualmente por un sistema basado en PC que
com pramos cuando solamente teníamos un establecimiento. Todos los registros de los pacientes
se llevan en forma manual. El cargo de facturación a las cuentas se hacc en una hoja de cálculo.
La oficina central tiene un paquete bastante bueno de contabilidad general que m e gustaría
mantener, pero toda la entrada se realiza m anualm ente. Bspero que nuestro nuevo sistem a au
tom atice la captura y procesam iento de pedidos, los pagos en el punto de venta y la facturación
a las cuentas de crédito. También quiero que quede registrado en la com putadora el historial
400 Apéndice ! ESTUDIO DEL CASO McVET
m edico del paciente, Enviamos avisos de recordatorio a los propietarios cuando a sus perros
les tocan inyecciones o revisiones. A segúrate de que tam bién este cn cl nuevo sistema.
“Esto resum e todo por ahora. Te sugiero que com iences las entrevistas en nuestro esta
blecim iento más antiguo en el U ptow n M alí. Si tienes cualquier pregunta adicional para esta
oficina, ponte en contacto con D ick o Jane. Ellos te ayudarán en cl m om ento.’’
EL UPTOWN MALL
Pendergast se detuvo enfrente del establecim iento principal de M cVet en el Uptown M alí. Lo
prim ero que observó fue el am plio estacionam iento y el fácil acceso. Los clientes y sus perros
entran a través de dos grandes hidrantcs de bom beros dorados que hacen que el edificio sea re
conocido instantáneam ente y al m ismo tiem po ocultan inteligentem ente las puertas de seguri
dad por la noche (figura A -l).
McVet
©ver T müon s&vicecl
Figura A -l. McVeL en el U ptow n Mal!.
C am inando a través de las puertas se encontró en un cuarto de recepción agradable y lim

pio, Una pared com pleta separaba al cuarto del resto de las operaciones de McVet. D irectam en
te enfrente de la pared estaba un largo m ostrador que ocupaba la longitud del cuarto. Carteles
elevados instruyen a los clientes para que registren a sus perros del lado izquierdo y los reco
ja n del lado derecho. Ese día W anda Welcome estaba trabajando tras el mostrador, Pendergast
decidió com enzar su visita con ella.
EL UPTOWN MALL 401
Una entrevista con Wanda Welcome,

la agente de servicio a clientes de McVet
W anda mostraba am istad y eficiencia. Dejó cl m ostrador a cargo de Ben Venu, quien estaba re
cibiendo capacitación, y cam inó a un lado para explicar la operación mientras Ben recibía a los
clientes.
“Probablem ente ya observó el transportador que va por todo el mostrador. El Sr, Shed
m ore es un genio mecánico. Patentó cl sistem a basándose en el manejo de equipaje del aero
puerto. Los perros son transportados a través de McVet en nuestro sistem a de contenedor de
clientes patentado (figura A-2). Hay tres tamaños de jaulas. M ediante la opresión de un botón
puedo seleccionar el tam año m ás adecuado para el perro. La jaula se engancha autom áticam en
te a los rieles desde el depósito de jaulas que está tras el m ostrador y viene a detenerse justo en
la estación de recepción. El propietario coloca al perro en la jau la y pone los pasadores. Ilay-
una báscula abajo de la jau la que nos da una lectura del peso del perro, listo se anota para usar
lo después. Luego la jau la se engancha al transportador y se lleva al perro a la parte trasera p a
ra el servicio.” Pen observó divertido m ientras Ben oprim ía un botón y la m áquina transportaba
suavemente a un gran cockcr spaniel dando vuelta a la esquina y hacia los cuartos secretos del
establecim iento de McVet.
Figura 4 - 2 . Hl siste m a de c o n te n e d o r de d ie n t e s p a te n ta d o de M cV et.
Esta es la últim a vez en que veo al perro hasta que cl propietario regresa para llevárse
lo. W anda cam inó hacia cl lado de recepción del mostrador. Una ventana con vidrio a prueba
de sonido perm itía la vista hacia un área en donde los perros esperaban a los propietarios. “ lil
área de entrega opera com o una com binación de los percheros de una tintorería y un carrusel
de entrega de equipaje. Puedo rotar cl carrusel para ver cuál perro selecciono. Cuando selec
ciono la jau la da vuelta a la esquina y se desengancha en el m ostrador de entrega. El cliente
paga aquí o firm a por los servicios en caso de que tenga una cucnta con McVet. l.uego abro 1a
jau la y el propietario y su mascota son felizm ente reunidos, I -a jaula vacía continúa hacia esta
vía aparte hacia el área de lim pieza donde es desinfectada autom áticam ente y regresada al ca
sillero adecuado.” ^
Pendergast hizo una pausa para anotar todo esto. No había duda de porqué McVet había
sido tan exitoso. N o podía esperar a ver los m ilagros de autom atización que se encontraban tras
la pared. Pero prim ero dirigió su atención hacia una PC pequeña que estaba en la estación de
recepción. "Platícam e acerca de tu sistem a de com putadora” , ie pidió a W anda.
W anda bajó la vista y se lamentó. “Era algo adecuado cuando solam ente operaba un pe
queño establecimiento. Ahora está com pletam ente obsoleto. Verá, el Sr. Shedm ore es ingenie
ro m ecánico y bastante bueno, pero desgraciadam ente no sabe m ucho acerca de com putadoras.
Su enfoque siem pre ha sido mecánico. H e trabajado aquí desde que se abrió por prim era vez.
En ese entonces tom ábam os los pedidos m anualm ente. Los papeles eran difíciles de leer y fre
cuentem ente se m ojaban en la parte trasera. Pronto se hizo obvio que necesitábam os algún ti
po de sistema de com putadora para llevar cuenta de lo que había solicitado el cliente.
“El Sr. Shedm ore tenía un vecino que era consultor de com putación. Esta persona había
construido un sistem a de captura de pedidos para un taller m ecánico. Gerald lo contrató para
que m odificara el sistem a para McVet. D esafortunadam ente esta persona consiguió un trabajo
fuera dcl estado y se fue de la ciudad después de hacer solam ente lo indispensable. No hubo
docum entación y nadie supo cóm o modificarlo. Conform e se añadieron otros establecim ientos
sim plem ente copiamos el softw are para que tam bién lo pudieran usar.
“Yo lo he usado más que nadie. Es bastante simple. Cuando llega un cliente le pregun
tamos si alguna vez ha visitado este establecim iento de McVet. Cada establecim iento tiene su
propia base de datos en su propia PC. N inguna de ellas está interconeclada. por lo que si el
cliente ha estado en un establecim iento de McVet diferente, nuestro establecim iento no tiene
ningún registro de él. Si ha estado en este establecim iento de McVet, recuperam os su registro
anterior. En caso contrario, tenem os que llenar esta form a para que podamos com enzar un nue
vo registro.” Le dio una carpeta a Pendergast con un montón de formularios de pedido.
“N o estoy com pletam ente segura de que quien escribió este programa supiera lo que es
taba haciendo. Tal vez funcionó para el establecim iento de reparación de autos, pero con segu
ridad tiene problem as en McVet. hstoy muy segura de que todo lo que hizo fue revisar el
program a y cam biar las palabras “autom óvil” por “perro” , “kilom etraje” por “edad” y “marca/
m odelo” por “raza” . ¡Simplemente vea estos recordatorios que hemos estado enviando!” Le
pasó una tarjeta posta) burda generada por com putadora que había sido regresada por no haber
una dirección para reenvío (figura A-3).
“ ¡Ni siquiera actualizó la base de datos de servicios! Cuando hicim os nuestro primer en
vío por correo le dijimos a todo propietario de perro de E ast H am pton HÍ3.1 que trajera a su m as
cota para lubricación, cambio de aceite y filtro ’.
'¿Cóm o se recupera a un cliente existente desde la base de datos ? , preguntó Pen.
“M ediante el núm ero telefónico” , respondio W anda, mientras Bcn obtenía un registro de
la pantalla de m antenim iento de. clientes (figura A-4). “Éste es otro problem a. Es la única for
ma para identificar a un cliente, pero los d ie n tes se cam bian y sus números también. Si alguien
ya tiene ese número en la base de datos tenemos que añadir otro dígito. Tam poco podem os
cam biar el número, ix'r lo que si un cliente se m uda o cambia su número telefónico tenem os
EL UPTOWN MALL 403
que horrar su registro y capturar uno nuevo. Hl program a original para el establecim iento de
reparación de autos sólo perm itía que el cliente tuviera tres autos. Por consecuencia, un clien
te sólo puede tener tres perros. Si trae un cuarto perro tenemos que capturar un registro de
cliente duplicado con un núm ero telefónico m odificado, por supuesto".
A p : ti-:: L Ic a lie n te :
H'.: FRENCH POODLE 1992
c c :: 4 ANOS ú & r'rn . rj
u:'.,-- VACUNA CONTRA LA R A BIA
I
F igura A-3, Recordatorio de McVct.
^"JMîCjrZLEFír'IICO
BELLIDO: ^
DIRECCICT^; _1.00WEST HARKET
J i-:r _1 C ? : : PS1 19 1
yp^Rl KOr-'ÜKE: idJSKJ _| :-íí\ za_cíjAVJ\ 12 i FDK: 1 - 1 - 9 7 ! M|

11K:^2_NÍ)I-Í3R^: DUCTi: j :<AZA_c:rjAvn 03 ! K M : 1 - 1 - 9 5 i SRXQ: F|
_kc)vf?Rr;; __ i T?AZA_. C l ,AV71 K JM :________ } &FXC: _\
t-:t a 3T 3 ' i : s j c r j e s s e n s i b l e a l p ^ i v c a k t t p u l g a s - p i e l ¿ii r a _í

1'0Ií3I\T7i?sI0¿ : DUCIiLG£ AK'LIUTlii i-2i TAS PATAS Tj<ASi2<A.B
•:;cra\T?7iRiG3:
■■'ñ- CUATOAP F 5- S A L IR
F ig u ra A -4. L a pantalla de m anten i míenlo de clientes del sistem a actual de McVet.

404 A péndice / ESTUDIO DEL CASO McVET
Pendergast estaba com enzando a form arse una im agen mental de la supuesta base de d a
tos que debía estar tras esta cosa. “¿Cóm o capturan un pedido?", preguntó.
“ Una vez que se tiene el registro del cliente en pantalla se verifica el nom bre y la direc
ción, y el nombre, raza y edad del perro. Se guarda el archivo de clientes y se regresa al menú
principal. Luego se teclea ‘P ’, lo eual hace aparecer la pantalla de pedidos,
“Se debe teclear el núm ero telefónico del cliente y el nombre del perro exactam ente co
mo aparecen en el registro del cliente, ya que de no ser así no se puede guardar el pedido. I -ne
gó se avanza c o n 'la b por todos los campos y se pone una X junto a los servicios que solicita el
cliente. Por ejemplo, si quieren que el perro sea bañado a m ano y se le de pedieura se avanza
con Tab por la pantalla hasta que se llega a Lavado a mano y se teclea una X cu el campo. El
program ador codificó directam ente todos los servicios de McVet en la pantalla. En ese tiempo
no se proporcionaba pedieura, por lo que se pone una m inea ju n to al campo Otro y se teclea el
precio en el campo Otro precio, y se avanza con Tab a la sección ¡Volas y se teclea 'pedieura'.
Se teclea el peso del perro en el cam po Peso. Eso puede afectar el precio de algunos servicios.
Cuando se term ina de m arcar en la pantalla de pedido se oprime F8 para guardar y tener el
precio del pedido. El sistem a asigna precio autom áticam ente a todos los servicios marcados y
suma cualquier cosa que se haya tecleado en el campo Otro p r e c i o Pendergast observó que el
pedido que estaba capturando Ben también tenía cargos adicionales (figura A-5).
PANTALLA D i K A K T K M IK lE K T O r;7: PPDTDOÍ3
ÜQ: ÍHDHGA SNCvíTOFAD]

■wOHílS VISO'. .'I 'j_|KCrZ-í .
s f i r v t r: i (3£; de a c : . c a t .a m t f n t o : STmTTTOí; VETERiKARlüiJ:
X J L A V /O Ü FFM Z v a c : : : n a c :t ó m _ • ik t r ü va -"... í.’i a v k : _______ |

I T r _ A T /^ ] i^ \'r o A N T 'T P r r r ^ A j i fe r r o i- l i l i ¿ v a c : ; n a c .t óm _^ : r-rru o v a c l o w e : ______|
l a v a jo a m a no v a c :.:n a c t üm _ . i ik t r ü v al l’l a v l : ______|
TRA7AM [ j'jKTC >1AKI-AL AMTTPTTTÁIAS (. :ae / E STZ:R i L I ZAR
_j c:c j ; t e de pzn.o V IS IT A A T,A W i C i K A K Ü T 1V C L’L A V E :_____ [
r; T I\7 F P F p f il o
_ | L 1K P1E Z A JEN'l'AT. DESCRIPCIÓN r;!7.:. F710PT.F.KA
* | OTRÜi; :
LIííTA DL: r'EjjTCAt'FNTO q i: f . to m a a c :tu a l> u in te
OTRC PPT^CTIC'
at ,frct=aí ;
NOTA: ¿L, PEK7Í3 K7. HEVÜI.CÓ ¡’líSCALS KUIHTO, APT.TCAR 'l'JiKAPlA 1)^: CCLCN-A ?7P.T(:i
~S = S jA R D A S Fí S A L IS
m am m m & m
F ig u r a A -5. Pantalla de captura de pedidos del sistem a actual de McVet.
Ben Venu guardó cl pedido. U na vieja im presora de im pacto cobró vida tras el m ostra
dor durante unos cuantos .segundos y luego com enzó a em itir un sonido. “ ¡Caray! La im preso
ra se volvió a atascar", exclamó. W anda interrumpió cl diálogo para m ostrarle a Ben la m anera
de levantar la tapa de la im presora y volver a ajustar la form a continua de dos tantos en los trac-
EL UPTOWN M A LI 405
lores. “ La forma de pedido se imprim e en papel de varios tantos”, dijo. “La prim era copia se
pone en un soporte especial en la jaula del perro. Acom paña al perro por todos lados en M c
Vet. Eso le dice a todos en la parte trasera el trabajo que necesita hacerse. La copia al carbón
se 1c da al cliente com o acuse de recibo del pedido, Equivale a su talón para recogerlo.”
“Cuando el propietario viene a recoger al perro, saco la form a de pedido de su soporte.
O casionalm ente el veterinario ha prescrito m edicinas o realizado algunos otros procedim ien
tos necesarios, por lo que hay cargos adicionales marcados en la forma que se suman a! total
en la caja registradora” .
“¿Hay algún enlace entre la caja registradora y la com putadora'’” , preguntó Pendergast
esperanzado.
“ D esafortunadam ente no, — respondió Wanda- , La com putadora no sabe acerca de lo
que se cobra actualm ente o del trabajo que en realidad se llevó a cabo. Sólo sabe lo que se so
licitó.”
“¿Alguien actualiza los pedidos después de que se va cl cliente?” Pen ya sospechaba cuál
sería la respuesta, pero de todas m aneras preguntó.
“Simplemente no hay tiempo. Una vez que el pedido ha sido impreso, para lo único que
se usa la base de datos es para generar avisos de recordatorio. Hacemos avisos una vez al mes.
L a tabla de servicios contiene un cam po llamado intervalo de servicios, que está a la derecha del
precio de lista actual. Para procedimientos eomo aplicaciones de vacunas de refuerzo o baños
contra pulgas entramos y tecleamos la cantidad de meses que recomendamos para la repetición
del tratamiento. Cuando queremos generar los recordatorios prim ero cargamos la impresora con
el papel de tarjeta postal. Luego vamos al menú y seleccionamos ‘R : por Recordatorias, El pro
grama imprime un recordatorio para cualquier perro que no haya sido atendido dentro del tiem
po recom endado.”
“ ¡Van a ser m uchísim as tarjetas!”, exclamó Pen.
“Claro que sí, pero McVet es realm ente muy com petitivo para generar la repetición del
negocio. La idea dcl recordatorio fue dada por prim era vez por M ark Kcating, quien se encar
gó de nuestro departam ento de ventas los dos prim eros años. El Sr. Shedm ore acaba de nom
brar a M argc Inn para que sea la nueva gerente de ventas, y quiere expandir los envíos por
correo para que incluyan tarjetas de cum pleaños y de saludo durante la convalecencia. Puedo
decirle ahora que esta base de datos antigua no podrá manejarlas. Tenemos muchísim as tarje
tas regresadas por el correo porque la gente se ha cambiado. A lgunos regresan la tarjeta si el
perro se ha muerto. Marge es una mercado loga muy buena. Nos dijo en la reunión dcl perso
nal de la últim a semana que cuando encontráram os que un perro ha muerto, ella piensa que de
beríam os enviar un cupón de descuento para adquirir una nueva m ascota en la tienda de
mascotas local.”
“ Y los cachorros necesitan vacunas y baños” , concluyó Pen. “M uy inteligente. ¿A ctua
lizan el registro del perro cuando se muere o se cam bia?”
“De hecho, sim plem ente lo eliminamos. El disco de esta PC es en realidad pequeño. M u
chas veces he pedido uno nuevo pero nadie ha querido gastar dinero en hardware hasta que se
pan cómo va a ser el nuevo sistema. Por ahora sólo tenemos espacio para casi un año de
pedidos. Si no hem os visto a un cliente en un año, se elim ina su registro.”
“¿Lo elim inan?”, se sorprendió Pen,
“Sí. Si vuelve a venir sim plem ente tenemos que volver a capturar su nombre, dirección
y los datos del perro. Todos los archivos médicos están en papel y todavía tenem os la historia
del paciente en la parte trasera. Desafortunadam ente, si no está en nuestro sistem a no envia
mos tarjetas de recordatorio.
“ Y si son dientes de dos establecim ientos les envían dos tarjetas.”

“Ya está em pezando a darse una idea” , dije W anda sonriendo. “listo es todo por lo que
se refiere ai mostrador. Creo que ya está listo para ver lo que sucede tras ia pared. El día de hoy
no está muy atareado, por lo que todos tendrán tiem po para m ostrarle lo que hacen. Pero no
trate de obtener la atención de nadie en la m añana del sábado. A quí es una locura durante el fin
de sem ana”.
“Gracias, W anda” , dijo Pendergast.
“N o hay de que. Veamos... hoy están Maty, Sue y Bill en la parte trasera. D eberá hablar
cotí cada uno de ellos para tener la idea com pleta.”
Tras la pared en McVet
Después de eso le m ostraron a Pendergast lo que había detrás de una puerta m areada con el le
trero Sólo empleados. El piso de las instalaciones de McVet era algo nunca visto. Cada centí
m etro cuadrado del establecim iento había sido aprovechado. Directam ente detrás de la pared
de recepción observó dos carruseles rotatorios. Uno era la cola de espera de los perros a ser
procesados y la otra era la cola de term inados, que era visible a través del vidrio del área de
entrega. Rieles de transportador desde la cola de espera se ram ificaban hacia tres secciones
distintas del establecim iento. A su izquierda vio pasar autom áticam ente a los perros haeia una
sección dividida m arcada com o servicios veterinarios (figura A-6).
Kígura A-6. Diagrama de Ilujo de perras de la línea de producción de McVeL

EL UPTOWN MALL 407
La vía de enm edio directam ente e n fraile de cl llevaba haeia una m áquina cilindrica gi
gantesca en el centro del edificio, equipada con indicadores, luces y que em ilía ocasionales rá
fagas de vapor. Pendergasl supo que esto era el infam e módulo sanitario Perro Feliz. Observó
adm irado con la boca abierta cóm o una procesión de perros mugrosos trepaba sin parar en sus
jaulas en el transportador hasta un punto alto en donde desaparecían en la boca de la gran má
quina. Una línea de perros mucho m ejor presentados em ergía del otro lado de la m áquina a ni
vel dcl piso, viéndose limpios y esponjados.
L a tercera vía a su derecha conducía hacia cl área de acicalam iento a mano, donde un
equipo de hombres y m ujeres estaban trabajando en forma de línea de ensamble. A quí las ja u
las de los perros podían ser abiertas parcialm ente para tener acceso a cualquier parte del perro
que requiriera atención. U na m ujer en bata blanca, que obviam ente era la supervisora, cam inó
hacia él para saludarlo. Pendergast pudo ver el rótulo con su nombre. Decía “ Maúlela Cote, su-
pervisora de acicalam iento."
“Hola, soy M aty", dijo cordial mente, “T lj debes ser Pendergast, bienvenido al departa
m ento de acicalam iento.”
Una entrevista con M aty Cote, supervisora

de acicalamiento de McVet
Varias personas se asomaron desde las m esas de acicalam iento para ver quién era el nuevo vi
sitante. Sonrieron am igablem ente a Pen y continuaron con su trabajo. M aty lo condujo al cen
tro dcl área de acicalam iento con las mesas de trabajo frente a ellos y el gran m ódulo sanitario
Perro Feliz elevándose tras de ellos. “Tal ve/, haya observado qué tan calm ados se ven todos
los anim ales”, dijo con voz pausada. “N uestras investigaciones han descubierto una frecuen
cia, inaudible para el oído humano, que produce un electo tranquilizador y casi hipnótico en
los perros. La tenem os por todo el establecim iento. M úsica celestial para los canes. Dieen que
no tiene efecto en los humanos, pero he observado que estoy salivando m ás que antes.”
“ Nuestro acicalam iento más popular es el baño y cl tratam iento contra pulgas usando
nuestro m ódulo sanitario Perro Feliz.” Pen observó la enorm e m áquina ronroneando tras de
ellos. M aty continuó, “Cariñosam ente le llamamos la lavadora de perros. Sin embargo, le re
com iendo que no use este térm ino delante del Sr. Shedmore. Como puede ver, de hecho, los
perros nunca salen de las jaulas especialm ente diseñadas. El acicalam iento autom atizado es, en
realidad, una operación de alto volum en y bajo margen de utilidad. Alta producción es lo que
im porta en este departam ento. Es nuestro m ayor centro de utilidades” .
“ En la lavadora de perros cobram os de acuerdo al peso dcl perro. La jau la es pesada au
tom áticam ente antes de que entre a la prim era cámara, listo ajusta el nivel de agua, profundi
dad de inm ersión y cantidad de detergente necesario. Es muy confiable y casi no requiere
m onitoreo. Sin embargo, hubo un incidente cuando se metió agua en la báscula y le causó un
cortocircuilo. Por consecuencia, la m áquina no se reajustó a sí mism a. El últim o perro en la
m áquina antes dcl corle había sido un San Bernardo, el poodlc toy de Gladys Fenwick fue el
siguiente. Afortunadam ente el perro dem ostró ser un buen nadador, pero la señorita Pcnwiek
siem pre insistió que Rinky desarrolló un tic nervioso después del incidente. Ahora el departa
mento legal de la em presa ha añadido una cláusula de lim itación de responsabilidad para ev i
tar reclam aciones en la parte inferior del recibo del pedido.
“ Para servicios m ás personalizados, tales com o el lavado a mano, pedicura, corte de p e

lo y teñido, las jaulas se ponen ra estas m esas de trabajo especiales. Los lados com pletam ente
ajustables perm iten que el acicalador tenga fácil acceso al animal. El acicalado se realiza en
form a de línea de ensamble. D espués de que se term ina cada servicio se m arca cn la hoja de
pedido y el perro pasa a la siguiente estación. Hn los días con m ucho trabajo podem os tener
hasta siete o diez personas trabajando. Como puede ver, hoy tenem os un poco de exceso de
personal. Esta política de ‘no hace falta cita’ causa estragos con mi calendanzación de perso
nal. Pareciera com o que siempre tengo dem asiados o muy pocos em pleados.
“A lgunos servicios de acicalam iento se cobran por hora y otros por una cuota fija. Hay
un ligero cargo extra para razas excepcionalm entc agresivas. El cargo extra ha sido más alto
últim am ente para cubrir el increm ento de nuestro seguro de com pensaciones para los trabaja
dores.
“ Ultim am ente hem os añadido m ás tipos de servicios de acicalam iento a mano, Hstos
conceptos no fueron program ados en el sistem a de com putadora del m ostrador, por lo que te
nem os que leer cuidadosam ente las notas que están al pie de la página. A veces se nos olvida
algún concepto que está escondido entre las notas. Sí nos dam os cuenta a tiem po tenem os que
enviar al perro al cielo nuevam ente. Si el perro llega ai área de recolección sin que se le h a
ya realizado algún servicio solicitado, la visita com pleta es gratis, A veces el form ulario de
papel se m oja m ucho para poderlo leer y alguien tiene que ir al m ostrador para im prim ir uno
nuevo. Cada vez que tengo que detenerm e para m anejar el papeleo se retrasa la línea de pro
ducción.”
M aty hace una pausa para perm itir que Pen cam ine tras las m esas de trabajo, donde a un
viejo pastor alemán le están tiñendo a m ano el pelo gris alrededor del hocico de m anera exper
ta, restaurándole su apariencia juvenil. En la siguiente estación un gran doberm an está echado
de lado m ientras el técnico aplica una sustancia blanca a sus dientes acabados de limpiar.
“¿Qué es eso?” , preguntó Pcn.
"Lse es nuestro barniz protector patentado", explicó Maty. “Se pinta con él los dientes
del perro para eubrir decoloraciones desagradables. D ura alrededor de seis meses y luego se
tiene que repetir. Lo m ejor es que mientras se disuelve lentam ente libera un refrescante de
aliento no tóxico, ]E1 perro tiene dientes más blancos y un aliento a menta al m ismo tiem po!”
“¿Al perro no le im porta el sabor a m enta?” , preguntó Pen,
“ De hecho, huele com o m enta, pero sabe a tlacuache”, com entó Maty.
“Fascinante.” Pen m ovió su cabeza. “Esto ha sido muy instructivo, creo que deberíam os
pasar a los servicios veterinarios."
“Pasa por esa puerta” , le dijo Maty. “La Dra. Chur está a cargo hoy,”
Pendergast le agradeció la visita y abrió la puerta m areada com o Servicias veterinarios.
A diferencia del ruido caótico del departam ento de acicalam iento, esta área estaba pintada de
blanco antiséptico. La banda transportadora que entraba ai cuarto se dividía conduciendo a los
perros hacia uno de tres cuartos de exanim ación o dos cuartos de operación. Pudo ver a través
de las puertas de vidrio que los cuartos estaban vacíos en ese momento. Detrás de la última
puerta vio a una m ujer en la ya fam iliar bata de laboratorio subida en una alta escalera reem
plazando una carpeta de arehivo en un largo banco de archivos médicos. Ella bajó y salió por
la puerta, un rem olino en acción. Hila pareció estarlo esperando, “Hola, Sr. Sylnick, soy la Dra.
Su san Chur” , dijo extendiendo su mano. “Puede llamarme Sue.”
EL UPTOWN MALL 409
Una entrevista con ta Dra. Chur, veterinaria de McVet
“Llám am e Pen. ¿A llí es donde guardan todos los registros m édicos?” Pendergast se encam inó
hacia el cuarto de donde había salido la 13ra, Chtir.
“Sí, Los registros m édicos se están saliendo de control. ¡McVet ha sido dem asiado exi
toso! Prim ero pensam os que íbamos a servir al vecindario, pero estam os dando tratam iento a
pacientes de toda la ciudad. I -as personas que viven en las afueras de ia ciudad llevan a sus pe
rros al establecim iento del centro cam ino al trabajo, pero en cl fin de semana vienen al McVet
que está en cl centro com ercial. Si un perro es llevado a otro establecim iento de McVet ahí se
le abre un nuevo archivo y no tenem os conocim iento de ello.
“Frecuentem ente es difícil tratar adecuadam ente a un animal sin su historia] m édico
com pleto. La Sra. Parsons tiene un perro de exhibición que estaba recibiendo nuestro trata
miento de hormonas patentado cuyo nom bre comercial es atractivo para increm entar la libido
de perros viejos con pedigrí. N osotros no sabíam os que ei establecim iento del centro ya le ha
bía puesto inyecciones, por lo que el perro recibió una dosis doble que produjo resultados de
safortunados tanto para el perro com o para la Sra. Parsons.”
“F-stoy seguro”, asintió nervioso Pendergast.
La Dra. Chur continuó a un ritm o rápido. “Debido a que los perros no pueden decirle a
sus propietarios lo que les pasa, la m ayoría son adm itidos para una visita estándar. Cuando un
perro regresa podem os decidir adm inistrarle medicam entos o realizar procedim ientos adicio
nales al pedido original. A m enos que sea una em ergencia, tratam os de ponem os en contacto
con el propietario antes de incurrir en cargos adicionales. Cuando doy tratam iento ai perro fir
mo la hoja de pedido para asegurarm e que haya hecho todo y añado cualquier concepto adicio
nal al área de notas de ¡a forma. También escribo notas en el archivo del paciente.”
■‘Algunas personas traen a sus perros frecuentem ente, y el areliivo se hace difícil de leer.
Todo está sujetado con clips en orden cronológico, por lo que hay que revisar cada página pa
ra saber lo que se le ha hecho al animal. En realidad m e sería muy útil un sistem a de referen
cias cruzadas.
“Las vacunas y los procedim ientos m édicos tienen un costo fijo, sin im portar el tamaño
de la dosis, aunque la dosis puede variar de acuerdo al peso del animal. Algunas razas son más
sensibles que otras, por lo que tengo que ser cuidadosa acerca de las inyecciones y los m edi
camentos.
“ Las cirugías son los únicos servicios que requieren una cita. Se ca le n d a ría n con casi
dos días de anticipación, a m enos de que sea una em ergencia. Las cirugías se cobran de acuer
do a una tarifa establecida por escrito. Los precios se revisan y actualizan cada trimestre.
“Las recetas se llenan y entregan aquí en el cuarto trasero. H ay un soporte al lado de la
jau la para los m edicam entos, por lo que cuando hem os term inado con cl perro la receta acom
paña al animal hacia el área de recolección. Las recetas están em pacadas previam ente y valo
radas por medio de una lista de precios estándar. El uso tiende a ser muy errático. Al principio
teníam os problem as porque se nos acababan determ inados m edicam entos. A hora tendem os a
tener un excedente para evitar inconveniencias a los clientes. N uestro proveedor tiene un gran
paquete de software de PC que lleva cuenta de su inventario, y se hace un pedido por teléfono
al vendedor cuando nos quedan pocas. M e encanta tener eso. ¿Tiene alguna otra pregunta?”
Pendergast estaba com enzando a sobrecargarse de inform ación. “Por ahora no se me
ocurre nada más. Tal vez le llam e después.”
“En cualquier m om ento espero estar muy involucrada con la especificación de este nue
vo sistema de com putadora. Hay m ucho que quiera que haga para nosotros. Biily lo está espe
rando. Es nuestro contador. Su oficina está bajando al corredor y a la izquierda.”
Pendergast le dio las gracias a la Dra. Chur. Regresó al piso de producción, dio la vuel
ta y se encam inó hacia un pasillo estrecho que conducía más allá del cuarto de descanso y ves-
tidores de los em pleados. A l final del corredor había varias oficinas estrechas. Había luz en una
de las oficinas del lado izquierdo. El cuarto era pequeño y todavía estaba más pequeño con las
pilas de reportes de hojas verdes cuadriculadas, cajas de pizzas vacías, un m inirreírigerador, li
breros y algo que parecía ropa para la lavandería. E! ocupante obviam ente pasaba gran parte
de su tiem po en este cuarto. Billy estaba agachado ante una hoja de cálculo tecleando datos de
una pila de formas de pedido arrugadas. Una placa en la pared anunciaba, “W illiam l.ing - E m
pleado del año” .
Una entrevista con William Ling, contador de McVet
“ Usted debe ser el experto en com putación.” Billy volteó y vio a Pen. Sus ojos cansados m os
traban las largas horas pasadas enfrente al monitor. “Encuentre un asiento si es que puede. P ó n
gase aquí, lim piaré esto." '
Pen se sentó cuidadosam ente en una silla tam baleante, enchuecada por los desperdicios
de la existencia de Billy que estaban en el piso. “¿.Qué está tecleando en esa hoja de cálculo?” ,
preguntó.
"Prom étam e que no se va a reír. Esto, de hecho, funcionaba cuando com enzam os el ne
gocio. Puede llam arla La pequeña hoja de cálculo que creció. Hace como dos años M ark Kea-
ting anunció la introducción de la cuenta de crédito revolvente de McVet. Sólo que hay un
problem a,,, él y sus com pañeros de ventas nunca se im aginaron cóm o íbam os a llevar las cuen
tas y facturar a los d ien tes. Y por eso hice esta hoja de cálculo en donde puedo teclear los car
gos de un cliente y llevar cuenta de quién ha pagado.”
“¿Lleva la facturación y las cuentas por cobrar en una hoja de cálculo?” , preguntó Pen
sin poderlo creer,
"A sí es. Mi solución tem poral se convirtió en mi propio infierno perm anente”, dijo Bill
con rem ordim iento. “Com enzam os a abrir nuevos establecim ientos, por lo que tuve que con
tratar y capacitar a los dem ás contadores de los establecim ientos. N unca he tenido tiem po p a
ra investigar y encontrar un paquete de cuentas por cobrar decente que reem place a éste. De
hecho, trabaja muy bien ahora. Tengo macros escritas para que casi cualquiera las pueda eje
cutar.”
“ Lnséñcm e cóm o funciona” , le dijo Pen.
“Cada mes copio los saldos finales de las cuentas hacia una nueva hoja de cálculo. C a
da día traen de la registradora a m i oficina las formas de pedido que fueron cargadas a la cuen
ta v aquí tecleo el nom bre del d ie n te, el núm ero de cuenta y el cargo total, siem pre y cuando
la form a no esté dem asiado mojada para leerla. Los clientes envían sus pagos directam ente al
establecí miento. A bro la correspondencia y tecleo los pagos antes de hacer el depósito al ban
co. Al final del mes ejecuto una macro que recorre toda la hoja de cálculo y saca el total de los
cargos del mes. suma cualquier saldo pendiente, cuotas por m orosidad y deduce los pagos que
se han realizado. El resum en resultante se escribe en esta parte de la hoja de cálculo que está
com binada con un formato de carta para enviar nuestros estados de cuenta de cobro.” Señaló
con su brazo cansado hacia una im presora láser grande que estaba sobre un archivero.
EJERCICIOS 411
Pendergast pestañeó. ‘‘¿N o lleva cada establecim iento su propia facturación'.'’'

“Sí lo haee. El enfoque corporativo está sobre la ingeniería y la expansión. Están ganan
do dem asiado dinero para preocuparse sobre la m anera de llevar las cuentas eficientem ente. Si
un cliente visita dos establecim ientos en un mes obtiene dos facturas. Si las com bina y envía
solam ente un cheque, los contadores de los establecim ientos afectados se llam arán entre ellos
por teléfono y lo dividirán.
■‘Además de la facturación, tam bién envío el reporte de ventas del establecim iento a la
oficina central. Ésta es otra hoja de cálculo. Im prim o los resultados y los envío todos los vier
nes. Ellos los teclean en su paquete financiero, el cual produce los reportes estándar. Ya sabe,
el estado de flujo de efectivo, el de pérdidas y ganancias, el de ingresos netos, etcétera. El nue
vo gerente de m ercadotecnia está pidiendo más y m ás detalles sobre las ventas de servicios es
pecíficos en los establecim ientos. ¡Como si no tuviera suficiente quehacer!” Había algo de
resentim iento en la voz de Billy. Pendergast pudo ver cóm o aparecía su angustia por un m o
mento. “ ¡Hasta han com enzado a preguntar si podría com enzar a enviar tarjetas de cum plea
ños! Yo creo que los que están en el m ostrador ya están muy ocupados. ¿Cree usted que piensan
que tengo una vida descansada? Puedo apreciar la necesidad de generar más clientes recurren
tes, pero a veces pienso que los que están en la oficina central desvarían muchas veces. Los re
cordatorios de vacunación son una gran idea, ¡pera las tarjetas de cum pleaños! Tal vez esto sea
bueno en nuestro establecim iento de Hampton Ililis, pero en esta parle de la ciudad obtengo
más rendim iento deseándole a nuestros pacientes 'feliz cacería' cuando com ienza la estación.
¡Nunca supe cuando tom e este trabajo que una com pañía con tan alta tecnología estuviera tan
atrasada! A McVet no le falta autom atización, ¡le falta inform ación!” . La cara de Billy estaba
roja, tenía una m irada salvaje.
“Creo que usted le ha dado al clavo” . Pendergast se levantó y se retiró hacia la puerta.
"Gracias, Billy. Ciertam ente tiene mucho conocim iento que será básico para este proyecto. De
finitivam ente valoro lo que m e dijo.”
“G racias Sr. Sylnick” , dijo Billy mucho más calmado. “No tengo m uchos visitantes.”
M ientras cam inaba de regreso hacia el frente del edificio, Pendergast estaba anonadado
por la dicotom ía entre el com portam iento agradable de las personas de servicio y el desconten
to que parecía estarse viviendo en la oficina trasera. La com pañía necesitaba algo m ás que un
sim ple sistem a de captura de pedidos. Estaba claro para él que su proyecto requeriría un plan
genera] muy fuerte y un contri)! de alcance para que pudiera tener éxito.
EJERCICIOS
Ejercicio 1 —Problemas y oportunidades
Pendergast regresó a su oficina después de su prim era visita a McVet. Se sentó en su escrito
rio y tomó un bloc am arillo grande, desprendió tres hojas y las rotuló PR O BLEM A S, O PO R
TU N ID A D E S y PREGUNTAS, respectivam ente.
412 Apéndice / ESTUDfO DEL CASO McVET
1.1 De acuerdo a las entrevistas de Pendergast y usando los conceptos que se presentaron en
el capítulo 2, E l plan general del proyecto, ¿qué problem as ve que existen cn McVet?
1.2 ¿Cuáles oportunidades no explotadas puede encontrar que ayudarían a McVet?
1.3 ¿Qué preguntas adicionales le gustaría hacer en su siguiente ronda de investigación?
Ejercicio 2 —Objetivos, criterios de evaluación,

opciones de solución
2.1 Usando los conceptos de IR AC IS, convierta los enunciados de problem as y oportuni
dades en objetivos. Establezca si la satisfacción del objetivo increm entará las ganancias,
evitará costos o m ejorará el servicio a los clientes de McVet. A lgunos objetivos pueden
caer en más de una categoría. Para cada objetivo, ¿cóm o podría m edirlo? ¿Qué m edidas
básicas se necesitarían tom ar para establecer el nivel de mejora deseado?
2.2 ¿Hay alguna pista cn las entrevistas de Pendergast que puedan indicar cuáles objetivos
pueden ser más importantes que otros para McVet? De serlo así, ¿cuáles son'.’
2.3 El criterio de evaluación para este proyecto i ncluirá criterios que midan qué tanto una so
lución propuesta satisface cada objetivo y m idan los costos de la solución. Además, el
plan general debe establecer vectores de calidad para guiar el diseño de! nuevo sistema.
Según la lista priorizada de objetivos creada por ei equipo de Pendergast (respuesta 2.2),
¿cuáles son algunos vectores de calidad que usted cree que deben especificarse cn el cri
terio de evaluación para este proyecto?
2.4 Piense en una lista de opciones de solución que ayuden a satisfacer los objetivos que han
sido establecidos para McVet. D iscuta brevem ente los méritos o problem as de cada so
lución.
Ejercicio 3 —Modelo de contexto
Trate de hacer ios ejercicios 3, 4 y 5 en forma sim ultánea. Kn un proyecto real, el m odelo de
contexto, el modelo de eventos y el modelo de inform ación se realizarán juntos.
3.1 Trace un diagram a de contexto que m uestre el alcance que está im plicado por los obje
tivos definidos por el equipo de establecim iento del plan general del proyecto de Pender
gast. (Consejo: Tai vez quiera com enzar trazando un diagram a de flujo de datos aplanado
del proceso que existe en el negocio y luego decidir cuáles deben estar dentro y fuera del
alcance.)
3.2 Vea !o.s agentes externos en el diagrama. ¿H a m ostrado un contexto de alcance expandi
do o de alcance reducido?
EJERCICIOS 413
Ejercicio 4 —Modelo de eventos
4.1 Cree una lista de eventos para el proyecto. Para cada evento indique si es esperado o
inesperado. Tam bién anote cualquier pseudoevento o evento tem poral en la lista.
4.2 ¿Hay algunos eventos sobre los que no se está seguro si deben estar dentro o fuera del
alcance? De ser así, ¿qué se deberá hacer acerca de ellos?
4.3 Tome el evento que representa el registro de un perro en un establecim iento M cVet y cree
una entrada del diccionario de eventos, Hl diccionario debe incluir el nom bre del even
to, la descripción del evento, el iniciador, el transportador actual, el transportador futu
ro, el estím ulo, la actividad, la respuesta y el efecto.
Ejercicio 5 —Modelo de información
Com o éste es un proyecto bastante grande, los servicios restantes se enfocarán solam ente en
un área o aspecto del tem a dcl sistem a pretendido.
5.1 Usando cualquier inform ación de la que actualm ente tiene a su disposición, cree un mo
delo de inform ación para los eventos:
El cliente coloca pedido para perro

El em pleado pregunta qué servicios de acicalam iento se solicitaron para un perro
El em pleado inform a que se ha concluido con el servicio
Ei veterinario pregunta qué servicios m édicos se solicitaron para el perro
El veterinario informa que ha concluido el tratam iento médico.
Trace un diagram a en ti dad-reí ación que incluya las entidades, relaciones, nombres de
relación y los cuatro puntos de cardinalidad relevantes. (Consejo: ¡Cuenta con gran can
tidad de inform ación en las notas de la entrevista, en las pantallas antiguas y en el dic
cionario de eventos!)
5.2 ¿Qué asuntos se presentaron cuando trató de colocar los cuatro puntos de cardinalidad en
las relaciones? ¿Cuáles políticas o reglas del negocio están implicadas por la cardinalidad?
5.3 ¿Puede identificar.cualquier relación de supertipo/subtipo en el m odelo de inform ación
de McVet? ¿Vio algún subtipo correspondiente en cualquiera de los otros m odelos de
análisis que se tienen hasta ahora?
5.4 ¿Tiene algún tipo de entidad asociativa? D e ser así, ¿dónde?
5.5 ¿Tiene algún tipo de entidad atributiva? De ser así, ¿dónde?
5.6 Com o m ejor pueda, liste los atributos de cada entidad y escriba un a breve definición de
cada entidad y atributo. Indique si un atributo es requerido u opcional y asigne un tipo
de dato para cada atributo y un candidato de identificador para cada entidad.
Ejercicio 6 —Prototipo de interfaz
6.1 ¿Cuáles son algunas de las formas diferentes en que se podría organizar la lista de even
tos para prepararla a fin de hacer un prototipo de interfaz?
6.2 Cree un primer prototipo para la disposición de ias ventanas requeridas para registrar a
un perro en McVet. (Consejo: Use com o guía el diccionario de eventos, el modelo de
inform ación, sus observaciones del nivel de habilidad de los usuarios y los vectores
de calidad del plan general.)
Ejercicio 7 —Modelo arquitectónico
H e visto que algunos estudiantes presentan arquitecturas para este caso de estudio que van des
de una centralización com pleta con una sola com putadora m ainfram e hasta la descentraliza
ción com pleta con una arquitectura igual-a-igoal sin ningún servidor, pasando por todos los
esquem as cliente/servidor interm edios posibles. No hay arquitectura técnica perfecta para Mc-
Vct. Cada solución tendrá sus problem as particulares.
McVet tiene actualm ente cinco establecim ientos dentro de la m ism a área metropolitana
que su oficina central. Este año se añadirán tres más. Es probable que el siguiente año se ex
panda hacia otra ciudad.
7.1 Haga una m atriz de evento/ubicación de negocios para la lista de eventos. Puede m ante
nerla sim ple determ inando cuáles eventos suceden, o deben ocurrir, en la oficina central
o en los establecim ientos, y tal vez también modele eventos al nivel conceptual, en vez
de hacerlo a nivel del negocio.
7.2 ¿Cuáles estadísticas necesitaría recopilar para hacer un buen trabajo de modelado arqui
tectónico pitra McVet?
7.3 Está siendo obvio a partir de los modelos que determ inadas entidades, tales com o clien
te y perro, necesitan estar disponibles en cualquier ubicación de McVet, incluyendo to
dos los establecim ientos y oficinas centrales. Además, también necesita estar disponible
la historia de los tratam ientos a los perros (conceptos de pedido) a través de toda la
em presa. Dado su conocim iento de McVet, ¿cuáles son los pros y contras de las arqui
tecturas de datos centralizadas contra las distribuidas para la com pañía? ¿Q ué recom en
daciones haría y por qué?
Ejercicio 8 —Diseño de base de datos
8.1 Transform e el m odelo de inform ación del ejercicio 5 en un primer diseño de base de
datos relaciona!. Liste los cam pos, su tipo de dato y si son opcionales u obligatorios. Pa
ra cada tabla, seleccione una clavc prim aria. Para cada relación del m odelo de inform a
ción implemento la clave extem a adecuada en el diseño de base de datos.
8.2 ¿Hay algún área del diseño de la base de datos que deba cam biar con respecto al m ode
lo de inform ación? D e ser así, ¿por qué sí o por qué no?
RESPUESTAS A LOS EJERCICIOS 415
Ejercicio 9 —Diseño de interfaz externa
9.1 U sando la lista de eventos com o guía, proponga una organización general para cl nuevo
sistem a de McVet y diseñe un memí principal. Luego, usando las disposiciones de ven
tana del ejercicio 6, cree un diagram a de navegación de ventanas para el evento registro
de perro. Com ience la navegación con el m enú principal y m uestre las rutas de navega
ción propuestas de ventana a ventana. Usando la notación del capítulo 11, declare el ti
po de ventana para cada ventana y proponga la unidad de trabajo adecuada para cl
usuario, marcando en dónde piensa que debe guardar cl trabajo.
9.2 M ejore las disposiciones de ventana colocando botones de com ando o conceptos de m e
nú en las ventanas. Para cada ventana escriba una cspeci fie ación de diseño externo que
incluya:
U na descripción de ventana que le diga al usuario la m anera de operar la ventana

U na mi ni cspeci fie ación de ventana que defina cuándo está activado cada botón o con
cepto de menú y qué sucede cuando se hace clic en él.
U na especificación de campo que liste cada campo de la interfaz y especifique cuáles
cam pos son visibles o no visibles, aelualizables o no actu alizab as, entradas requeridas u
opcionales, y una m iniespecificación que establezca la m anera de recuperar los datos p a
ra cada ventana desde la base de datos.
Ejercicio 10 —Diseño de componentes internos
10 .1 Dependiendo del lenguaje de desarrollo seleccionado, el código para este sistem a puede
variar en su grado de orientación a objetos. Supongamos que decidim os em plear 0 0 p a
ra representar las clases de negocios y de aplicación dentro del sistema. Usando nuestro
modelo de inform ación y el diccionario de eventos para registrar un perro en McVet, lis
te las clases candidato del dom inio del negocio y/o de la aplicación que pueda necesitar
para una im plem entación orientada a objetos.
10.2 ¿H ay alguna entidad de supertipo/subtipo en la inform ación que parezca ser un buen can
didato para la herencia en el m odelo de clases?
RESPUESTAS A LOS EJERCICIOS
Respuesta al ejercicio 1 —Problemas y oportunidades
1.1 Enunciados dei problema de McVet

D espués de que Pendergast estableció una lista de enunciados de problem as en McVet, se reu
nió con una muestra de usuarios de McVet para validar y extender la lista. Luego com enzó a
agrupar los problem as en aquellos que increm entan los costos de McVet, aquellos que dism i-
iiuyen las ganancias potenciales de McVet y aquellos que impiden proporcionar cl nivel más
alto posible de servicio a los clientes de McVet. Luego siguió clasificando los problem as rela
cionados con costos en los que están exponiendo a McVet al riesgo de un error, los que están
increm entando ios costos de operación y los problem as técnicos directam ente relacionados con
cl sistem a de captura de pedidos actual. Numeró cada enunciado de problem a para poder se
guirle el rastro a lo largo del establecim iento dcl plan general. Lo que viene a continuación es
su lista de enunciados de problem as resultante.
Problemas de McVet
Los siguientes problem as exponen a McVet al riesgo d e e rro r. Algunos de los problem as lo
exponen al riesgo de com eter un error o una omisión en el tratam iento del perro, y otros p ro
blem as están relacionados con la valoración precisa dcl pedido, cl cobro de la factura o la in
tegridad de las funciones financieras de McVet.
1. U n solo establecim iento de McVet no puede decir si un paciente m édico ha visitado

cualquiera otra instalación de McVet. Sí un perro ha sido llevado a más de un McVet
para tratam iento m édico, existe un archivo m édico en cada establecim iento. No hay
referencias cruzadas de ellos, lo que increm enta el riesgo de un m al tratamiento.
2. La salida de la báscula requiere el registro m anual del peso del perro, lo que incre
m enta el riesgo de error. Además, la presencia de agua en la báscula del módulo sa
nitario Perro Feliz ha dado com o resultado un error que casi ahoga a un perro.
3. La sensibilidad de algunas razas a determ inados medicam entos plantea un riesgo de
dar un mal tratam iento a un perro. A ctualm ente es responsabilidad del veterinario el
recordar cualquier sensibilidad de la raza hacia los m edicam entos.
4. La facturación y cuentas por cobrar se realizan en un medio muy volátil, una hoja de
cálculo, exponiendo los datos al error.
5. Las cuentas por cobrar son m anejadas por cada establecim iento, por lo que M cVet no
tiene una historia de pagos o de crédito consolidado para un cliente que es cliente de
m ás de un establecim iento.
6. Hl nom bre y núm ero de cliente debe ser tecleado manualm ente en la hoja de cálculo
de facturación, increm entando el riesgo de error de identificar incorrectam ente al
cliente y a l a cuenta.
7. A veces el form ulario de pedido está dem asiado mojado para leerlo, haciendo diffcil
el registro preciso de cargos en la hoja de cálculo de facturación.
8. Hay una separación inadecuada de responsabilidades en la función de contabilidad,
LI contador abre la correspondencia, captura los cargos y prepara el depósito banca-
rio, haciendo muy fácil que se sustraiga dinero.
Los siguientes problem as dan com o resultado un increm ento directo en los costos de
o p e ra c ió n de McVet. M uchos de los problem as están relacionados con la naturaleza m anual
de las tareas.
9. Todos los registros del archivo m édico del perro están en orden cronológico, por lo
que un veterinario debe revisar cada una de las páginas para consultar el historial clí
nico dcl perro, increm entando cl tiempo dedicado a cada uno.
10. La entrada a la contabilidad general y al paquete de contabilidad central se lleva

tiem po y es intensiva en mano de obra, debido a que toda la entrada actualm ente es
manual.
1.1. El proceso para registrar que un sen-icio se ha term inado es manual, lo que requiere
el m anejo de papelería que hace más lento el volumen de producción de la línea,
12. T-os servicios que no están codificados directam ente cn el sistem a se escriben en la
parte inferior del pedido, causando que cl personal de acicalam iento requiera tiem po
adicional para leer cuidadosam ente las notas, A veces se olvidan conceptos y al clien
te no se le cobra la visita com pleta (vea pérdida de ganancias).
13. La política de “no se requiere cita" hace que sea difícil la calendarización adecuada
de em pleados cn cl equipo de acicalam iento, causando días eon exceso de personal
y días con falta de personal.
14. Si se pierde o daña una hoja de pedido, un em pleado de acicalam iento debe salir al
m ostrador para im prim ir otra copia.
15. Los archivos médicos de McVet consum en una gran cantidad de espacio en un esta
blecim iento que ya está lim itado por falta de espacio.
16. El papel de forma continua de varios tantos que se usa en la im presora es caro.
17. i..os servicios médicos que se proporcionan son escritos a mano en el form ulario de
pedido, y deben ser valorados manualmente.
1S. Los servicios médicos que se proporcionan deben registrarse en form a redundante en
el form ulario de pedido y en el archivo m édico del paciente.
19. Hl uso de medicam entos es errático, causando que el establecim iento tenga exceso
de inventarios para evitar que le falten.
20. Hl departam ento de ventas realiza nuevos programas sin darse cuenta del impacto
que tienen en los sistemas de inform ación.
21. La hoja de cálculo de facturación y cuentas por cobrar es problem ática e intensiva en
m ano de obra para mantenerla.
22. Cada establecim iento tiene su propio contador para facturación.
23. Si un cliente envía un cheque para facturas de más de un establecim iento los conta
dores de los establecim ientos deben llam arse para dividir los cargos.
24. Los reportes financieros del establecimiento son enviados por medio de una hoja de
cálculo a la oficina corporativa, causando más manejo manual y transferencia de datos.
25. McVet no puede elaborar un texto de noticias por correo a la m edida hacia la región
socioeconóm ica de su base de clientes, por lo que puede ser que las tarjetas no sean
tan efectivas en cualquier área de com ercialización particular com o debieran ser. E s
to desperdicia el material, mano de obra y gastos de envío de las tarjetas y puede fa
llar para producir la concurrencia del negocio.
26. Cada contador tiene un gran exceso de trabajo debido a la naturaleza manual del sis
tema de íacturación, corriendo el riesgo de una rotación de em pleados prematura.
Hl siguiente conjunto de problem as está directam ente relacionado a un pobre diseño de siste
ma de la aplicación de captura de pedidos existente. Lstos problem as están más directam ente
relacionados con la im plem entación técnica del sistem a actual, sin em bargo podrían ser fací!-
m ente clasificados en la categoría anterior de problem as que increm entan los costos de opera
ción. (Los usuarios tienden a juntar este tipo de problem as bajo el concepto “pecados vistos en
el sistem a de com putadora actual” .)
27. El sistem a actual para el registro de pedidos no tiene docum entación y nadie sabe có
mo m odificarlo Esto plantea riesgos al negocio de una falla de sistem a, y ha dado
com o resultado la falta de habilidad del sistem a para adaptarse a los cam bios del
negocio.
28. Los recordatorios generados por el sistema actual tienen una m ala redacción, son an
tiestéticos y es imposible cambiarlos,
29. D ebido a que los clientes están identificados por su núm ero telefónico en la base de
datos, cl núm ero telefónico no puede ser actualizado en un registro de cliente cuan
do cambia.
30. Cuando se inserta un registro de cliente, si el número telefónico para cl cliente ya exis
te en el sistema se añade un dígito adicional (ficticio) para que el número sea único.
31. K1 sistema actual está codificado para perm itir solam ente tres perros por cliente. Los
clientes que tienen más de tres perros tienen un registro de cliente duplicado.
32. La navegación entre la pantalla de clientes y la pantalla de captura de pedidos es pro
blem ática, ya que requiere que los usuarios regresen al menú principal.
33. La pantalla de captura de pedidos requiere que cl usuario teclee el núm ero telefóni
co del cliente y el nom bre dcS perro con exactitud antes de que el pedido sea acepta
do por el sistema.
34. La pantalla de captura de pedidos contiene cam pos de captura codificados para los
servicios disponibles, haciéndolo inflexible para la adición o elim inación de servi
cios conform e cam bia el negocio.
35. Los servicios que no están codificados en la pantalla de captura de pedidos son ano
tados en el campo "otros", haciendo im posible que McVet lleve cuenta con precisión
de las ventas de servicios que no están listados oficialm ente en la pantalla.
36. Los servicios que no están codificados en el sistem a actual no pueden ser valorados
automáticamente.
37. La im presora para la impresión de pedidos no es confiable. El papel se atasca íre-
cue lilemente.
38. No hay enlace entre lo que se solicitó y lo que se cobró en realidad. Esto dism inuye la
habilidad de McVet para llevar cuenta con precisión de las ventas por tipo de servi
cio, falla para proporcionar la rastre a bilí dad de pedidos dentro del establecim iento y
expone a McVet al riesgo de que el cajero com eta un fraude,
39. El program a actual para la im presión de recordatorios no perm ite que el usuario re
dii7t a la lista m ediante ningún criterio de selección, y los envíos por correo no pue
den ser hechos a la m edida por tipo de servicio.
40. El sistem a actúa! es incapaz de generar ningún otro tipo de tarjetas, tales com o las de
cum pleaños o de saludo en convalecencia.
41. Los registros de clientes son borrados cuando el perro muere, perdiendo un cliente
repetitivo potencial de la base de datos de M cVet en caso de que el cliente adquiera
otro perro.
42. La rutencion es de solam ente un año en línea, forzando a los clientes con regresos
p o to frecuentes a que tengan que volver a dar sus datos de cliente.
Los sigu ien tes p ro b lem as co n trib u y en a una pérdida de ganancias potencial p a
ra M cV et.
43. Los errores o servicios fallantes debido a un mal seguimiento de pedidos o a formas
de papel ilegibles dan com o resultado que al cliente no se le cobre la visita com pleta.
44. La facturación realizada solam ente en un ciclo mensual da com o resultado en un po
tencial costo de oportunidad perdido de las cuentas por cobrar.
E sto s ú ltim o s p ro b lem as fallan en proporcionar el m ejor servicio posible a los

clien tes de M cV et.
45. Los clientes deben llenar un nuevo perfil de cliente en cada nuevo establecim iento
que visiten, aunque ya hayan sido d ie n tes de otro establecim iento de McVet.
46. Los clientes que acuden a más de un establecim iento reciben un recordatorio de
cada establecim iento.
47. Los clientes envían pagos directamente a cada establecimiento. Si visitan más de un es
tablecimiento deben enviar varios pagos, duplicando el esfuerzo por parte del cliente.
1.2 Enunciados de oportunidades de McVet

Pendergast y su grupo de usuarios también registraron una lista de oportunidades. Varias de
ellas fueron inspiradas por las tecnologías disponibles, pero trataron de redactar el enunciado
en forma objetiva.
A. A los clientes que notifican a McVet que su perro ha muerto se les podría dar un cu
pón de descuento para un nuevo perro. Esta prom oción de mercadotecnia requeriría
la cooperación de las tiendas de m ascotas del área local.
B. Con un sistema de inform ación accesible McVet podría expandir la cam paña por co
rreo directa hacia otro tipo de envíos por correo, tales com o los saludos de cum plea
ños, tarjetas de saludo en convalecencia, tarjetas de buena caza, tarjetas por
graduaciones de escuelas de obediencia, etcétera.
C. McVet puede ser capaz de increm entar el tráfico entre sem ana proporcionando des
cuentos en esos días. Para que el plan sea benéfico, la pérdida de ganancias por los
descuentos de los días entre semana tendría que ser superada por un aum ento en la
clientela, clientes más satisfechos o ahorros de costos a causa de niveles de personal
más consistentes.
D. McVcí podría ser capaz de beneficiarse por costos de inventarío m enores llevando
cuenta eon m ás precisión del consum o y la adquisición de los medicam entos. (Esta
oportunidad fue inspirada por el com entario de la doctora Chur sobre que se tiene
disponible un sistem a de seguim iento de inventario basado en PC.)
E. Existen tecnologías (tales com o el código de barras) que perm itirían que McVet lle
vara cuenta y dirigiera con más precisión a los perros por el piso de las instalaciones
reduciendo til riesgo de error y dism inuyendo cl costo de mano de obra por el m ane
jo de papelería.
F. Los clientes recurrentes y sus perros podrían ser revisados más rápidam ente dando al
cliente alguna form a de identificación que pudiera ser leída por cl sistem a para recu
perar el registro adecuado. Ejem plos de este tipo de tecnología incluyen tarjetas de
plástico con bandas m agnéticas, códigos de barra en una tarjeta o en la placa de iden
tificación del perro o hasta chips electrónicos incrustados en cl hom bro del perro.
(Lsto últim o ya se realiza en muchos refugios de animales locales perm itiendo que
se adopte a un perro con un “chip en su hom bro”.)
G. Para los clientes que traen a sus perros para servicio periódico y rutinario, tal como
el viaje mensual por la lavadora de perros, un registro exprés podría dism inuir signi
ficativam ente el tiempo de manejo requerido para adm itir al perro. Ll registro exprés
podría usar la identificación autom ática del perro y la recuperación de un perfil de
pedido estándar para sim plem ente aceptar al perro rápidam ente para su visita están
dar sin m olestar al cliente con el proceso de registro normal. (Tal vez McVet pudie
ra instalar un servicio de atención en automóvil.)
1.3 Preguntas adicionales para McVet

En este momento Pendergast estaba un poco preocupado acerca del alcance de su proyecto. En
su entrevista original con el Sr. Shedmore se le dijo que su em presa estaba contratada para “... d i
señar nuestro nuevo sistema de captura de pedidos y facturación automatizados para McVet”.
A hora le quedaba claro a Pen que el alcance de este proyecto podría fácilmente extenderse más
allá de los aspectos de la simple captura de pedidos y facturación. McVet tenía problem as sig
nificativos con su seguim iento de pedidos en et piso de las instalaciones, adm inistración de in
ventarios y oportunidades para expandirse hacia nuevas tecnologías corno las tarjetas con
código de barras o m agnéticas para la cuenta del cliente.
Tina pregunta crucial que giraba en la mente de Pen era si a Shedm ore le gustaría la idea
de central izar las funciones de facturación y cuentas por cobrar. Estaba seguro que podría ju s
tificar cl porque cada establecim iento no necesitaba un contador de tiempo com pleto entre su
personal. Con un sistem a de inform ación integrado entre los establecim ientos y las oficinas
centrales, la facturación y aplicación de los pagos de los clientes podría m anejarse en un solo
lugar, reduciendo am pliam ente las operaciones redundantes y el costo de mano de obra.
Pen decidió hacerle a Shedm ore las siguientes preguntas:
1. ¿Está dentro del alcance del proceso de planeaeión general de este proyecto la reco
mendación de cambios organizacionales al negocio?
2. Si se van a realizar cam bios organizacionales, ¿apoyará e nnpleoietitará com pleta
m ente estos cam bios? (Pen estaba convencido que la orden para el cambio debía pro
venir del negocio y no debía ser vista com o un resultado del nuevo diseño del
sistema. Este concepto es crucial para que los usuarios hagan suyas las razones para
el cam bio y no las vean com o impuestas por el grupo de tecnología de información.
Otra preocupación de Pen fue si McVet estaba creciendo tan rápidam ente y ganando
tanto dinero que no estaba seguro si los ejecutivos de McVet harían prioritario el h a
cer cam bios significativos para controlar sus costos. Frecuentem ente las com pañías
no perturbarán lo establecido ni harán grandes cambios sino hasta que se vean forza
das por un descenso en los negocios.)
3. ¿Q ue tantas de las oportunidades potenciales identificadas debería considerar el pro

yecto para que estuvieran dentro de su alcance? (Por ejemplo, cam pañas por correo
directo o de cupones, registro exprés, identificación autom ática de perros.)
Respuestas al ejercicio 2 —Objetivos, criterios

de evaluación, opciones de solución
2.1 Enunciados de objetivo de McVet
Por ahora, Pendergast tiene una m uestra de em pleados de McVet de diversas áreas que están
com isionados para ayudarle a elaborar el pian general del proyecto. Su equipo para el plan g e
neral incluye a Riíl Ltng, Wanda W elcome, Maty Cote y a la Dra. Sue Chur dcl establecim ien
to en el centro com ercial Uptown Malí y representantes de otros establecim ientos y de las
oficinas centrales. Los reunió en cl salón de conlereucias para convertir los enunciados de pro
blemas y oportunidades en objetivos. Recordando que las personas tienen mejor disposición
para asistir a las reuniones si se les alimenta, trajo una charola eon rosquillas y tres jarras de
un fuerte café gourm et y una selección de jugos de frutas para la Dra. Chur, ya que no puede
tom ar cafeína en los días que tiene fechadas las operaciones.
Entre todo cl grupo convirtieron cada enunciado de problem a y oportunidad en un enun
ciado de objetivo, clasilicaron a cada uno de acuerdo a si servía para increm entar ganancias,
evitar costos, o m ejorar servicios, y com entaron sobre la m anera en que podrían m edir la m e
jo ra deseada. Cuando term inaron habían insertado/actores x com o indicadores de lugar en ca
da uno de los enunciados y asignado objetivos específicos a cada m iem bro del equipo para que
investigaran la cifras reales con qué reem plazar a los fa ctores x. Pendergast condujo la reunión
y escribió varios com entarios y conversaciones que se realizaron bajo alguno de los objetivos.
Al térm ino de la sesión su lista de objetivos fue como la siguiente:
Objetivos derivados de los enunciados de problem as
!. Evitar el costo de un tratam iento equivocado a un perro m ediante la creación de un

historial médico com pleto para cada perro a la cual tengan acceso inm ediato todos
los establecim ientos de McVet. Nuestro objetivo es reducir la incidencia de malos
tratam ientos debido al conocim iento incom pleto del historial del tratam iento del p e
rro por parte de los veterinarios d e x ocurrencias por año a y ocurrencias por año.
Sota: El grupo hizo la observación de que McVet nunca ha m edido la razón de inci
dencia de m al tratam iento en el pasudo, p o r lo que no se dispone inm ediatam ente de
dalos de comparación. A unque todos en el salón pudieron com entar el fam oso caso
del perro de exhibición de la Sra. Parsons, y otro incidente que involucró un esta
blecim iento de McVet que operó la articulación de cadera errónea, todos estuvieron
de acuerdo en que el riesgo de un m al tratamiento im portante en el futuro era de
principal importancia y que McVet debería tener una m eta de cera errores para el
fa c to r y en el enunciado.
422 Apéndice i ESTUDIO DEL CASO McVET
2. Evitar el costo de errores debido a una medición de peso im precisa m ediante ei trans
porte del peso del perro directo de la báscula hacia el pedido, elim inando la transfe
rencia m anual del valor del peso.
Nota: A unque el errar todavía no se ha cometido, existe la posibilidad de adm inis
trar un nivel de dosis de medicam entos inadecuado cuando ésta depende del peso
del. perro, ¡ a báscula redundante en el módulo sanitario Perro Feliz fu e descartada
para el alcance de este proyecto. E l problem a del agua ha sido solucionado p o r el
departam ento de ingeniería.
3. Kvitar el costo de prescribir m edicam entos inadecuados y reducir el costo de bús

queda de contraindicaciones sobre los m edicam entos dándole a los veterinarios ac
ceso rápido a inform ación sobre la sensibilidad a los medicam entos por raza y
m edicam ento.
Mora: Aunque el error todavía no se ha cometido, la Dra. Chur fue capaz de citar
tres incidentes de este año en donde un veterinario tuvo que consultar a un colega
de otro establecim iento para asegurarse de que el m edicam ento era adecuado para
la raza antes de adm inistrar una dosis.
4. Evitar el eosto de incurrir en un error de facturación realizando las funciones de fac

turación y de cuentas por cobrar en un m edio menos volátil que una hoja de cálculo.
Nota: Se asignó) a B ill Ling para determ inar qué tantos errores tipográficos estaban
ocurriendo dentro de los program as de hoja de cálculo, en caso de haber alguno.
5. Evitar costos de mano de obra por la notificación a otros establecim ientos cuando un
cliente adeuda facturas creando una vista consolidada del crédito del cliente a través
de todas las ubicaciones de McVcl. a la cual todos los establecim ientos tendrán a c
ceso. En prom edio mi contador debe perder veinte m inutos sem anales actualizando
una lista de clientes morosos y faxeándola a todos los demás establecim ientos.
6. invitar el riesgo de una m ala identificación del nom bre y núm ero de cuenta del clien
te en las facturas haciendo que la aplicación de facturación lea autom áticam ente el
nom bre y el núm ero del cliente a partir de una sola fuente. A ctualm ente un prom e
dio de tres clientes por mes no Linean a M cVet que sus nom bres están mal escritos en
sus facturas.
7. E vitar la pérdida de ganancias y el costo de m anejo de formas dañadas, eliminando
las formas de pedido en papel com o entrada para la aplicación de facturación. En ca
da establecim iento los contadores reportan que hay. al m enos, dos formas de pedido
diarias que requieren atención especial, debido a que la form a esíá dem asiado m oja
da para leerla o la escritura a mano les da problem as. Al menos una vez por mes y
por establecim iento no se le cobra una visita a un cliente debido a que los cargos es
critos a mano en la form a de pedido no pueden ser com prendidos con precisión por
el contador cuando captura ios cargos en la hoja de cálculo de facturación, lil precio
prom edio de una visita de cliente es de $56.
8. HviLar el costo de sustracción de fondos potencial estableciendo una adecuada sepa
ración de responsabilidades entre las personas que registran las cuentas por cobrar,
las que reciben y registran los pagos y las que hacen los depósitos bancarios.
Nota: Pendergast observó que en cada establecim iento una sola persona tiene con
trol completo sobre ei. registro del cobro a l cliente y el reporte de. la venta, y la m is
ma persona también abre la correspondencia, registra los pag o s y hace el depósito.

Sería m uy fá c il para un contador deshonesto dejar de registrar una factura, y luego
cobrarle al d ien te interceptando el pago y depositándolo en su propia cuenta. Billy
dijo en fo rm a defensiva que esto no había representado un problema, y si alguien no
le creía, entonces, ¿por qué todavía, todavía estaba manejando un Pinto ¡978?
9. livitar cl costo de una visita m édica prom edio de un perro perm itiendo que el veteri
nario realice búsquedas personalizadas en el historial m édico del perro para consul
tar conceptos particulares en vez de tener que leer un historia] cronológico. La Dra.
Chur estim ó que esto podría reducir un prom edio de dos minutos por visita para cer
ca de 15% de sus clientes que tienen archivos médicos grandes.
10. Tvitar el costo de mano de obra mediante la elim inación de entrada manua! en los es
tablecim ientos de McVet en el sistema de contabilidad general para reporte de ven
tas. Actualm ente, un em pleado de tiempo com pleto gasta aproxim adam ente seis
horas diarias tecleando ias ventas de McVet de cada establecim iento en el software
de contabilidad del establecim iento. Existe el potencial para elim inar un puesto de
trabajo del departam ento de contabilidad central.
11. Bvitar el costo de mano de obra en la línea de acicalam iento reduciendo a 50% el
tiem po com binado que se necesita para determ inar cuáles servicios se requieren y
cl tiempo requerido para reportar un concepto de servicio com o terminado.
12. Evitar pérdida de ganancias por no cobrar a los clientes, debido a conceptos de servi
cio laltantes por incidentes de conceptos fallantes de .t por m es a y por mes.
Nota: Wanda estim a que en los fin e s de semana atareados en su establecimiento, al
m enos no se le cobra a un d ie n te por la visita a causa de que. se olvidó un concep
to en la línea de acicalamiento. Se le (¡signó la tarea de recopilar estadísticas de los
dem ás establecim ientos para llenar el factor x y determ inar la causa principal de los
errores para ver si el ja c to r y puede ser puesto a cero errores p o r m es como meta a
alcanzar.
13. Evitar el costo de exeeso de personal cn los días ligeros en cantidad mensual y m e
jo rar el servicio a clientes cn los días atareados, prediciendo con más precisión el ni
vel de personal requerido.
Nota: El equipo tuvo una gran discusión sobre si este objetivo caía dentro del alcan
ce. Billy sugirió que para que un sistem a de cóm puto pudiera predecir con precisión
los niveles diarios de personal, el program a tendría que tom ar en cuenta las tenden
cias de ventas semanales, las tendencias estacionales, el pronóstico del tiempo, la ra-
lendarización de juegos del equipo de j'utbol local y muchos otm s factores que
afectan el qué tantos d ie n tes asisten a un establecim iento McVet en un día determ i
nado. Wanda hizo un chiste de. que si M aty no contratara a tantas de las amigas de
escuela de su hija, ta l vez fu era m ás apta para enviarlas a casa en los días con m e
nor trabajo, y fu e recibido p or una cara larga de Maty-■Pendergast sugirió que deja
ran el objetivo en la lista por ahora y volvieran al lema cuando hubieran priorizado
los objetivos, luego rápidam ente hizo una pausa para com er durante la cual se le oyó
decir a M aty que su recepcionista con cabeza de poodle no sabía de lo que estaba
hablando.
14. Evitar el costo de mano de obra en x cantidad semanal elim inando la necesidad de
que el em pleado de acicalam iento cam ine hacia el m ostrador para volver a imprim ir
un pedido.
M aty hizo notar que al m enos dos veces diariamente alguien de su equipo tiene que
ir al m ostrador para volver a im prim ir el pedido, lo cual lo quita de la. línea de aci
calamiento p o r cerca de cinco minutos. Wanda añadió que esto también interrumpe
a la persona que está en el m ostrador y frecuentem ente causa que un cliente tenga
que esperar m ientras la computadora está ocupada.
15. Evitar el costo del espacio innecesario en x cantidad anual por nuevo establecim ien
to, alm acenando los registros médicos en un m edio que ocupe menos espacio que los
archivos de papel actuales.
Nota: B illy realmente defendió este objetivo debido a que McVet p a g a m ucho dine
ro p o r espacio de centro com ercial en áreas m uy bien ubicadas, p o r lo que. cualquier
reducción en. la cantidad de metros cuadrados requeridos para un establecimiento
áe McVet podría ahorrar m ucho dinero conform e se abren nuevos establecimientos.
La Dra. Chur no aceptó de buena gana el que los veterinarios puedan pasársela sin
los archivos m édicos y p a sar a un sistem a com pletam ente sin papel. Se asignó a la
Dra. Chur que consultara a tos dem ás veterinarios para ver si aceptarían una cul
tura sin papel. Ella dijo que también llamaría a su herm ano en P hoenix que es un
doctor en una clínica médica que recientemente realizó un proyecto piloto en el que
no se usa pape!.
16. Reducir 50% cl costo del papel que se usa para im prim ir pedidos y recibos de pedi
dos. (Los pedidos actuales se imprim en en formas caras de vanos tantos.)
17. Lvitar el costo de mano de obra en x cantidad por pedido médico reduciendo el tiem
po que se lleva el valorar los conceptos de pedido médicos de m edio m inuto por p e
dido a dos segundos por pedido.
Nota: Wanda estimó que a ella le lleva cerca de m edio m inuto valorar el pedida m é
dico prom edio debido a todas las adiciones escritas en. las notas. También m encio
nó que los clientes tienden a cuestionar m ás los cargos adicionales cuando los
escribe el cajero enfrente de ellos en vez. de venir directamente del veterinario. Su re
querim iento de la valoración de pedidos m édicos en dos segundos asegura en gran
m.edida que el. proceso será automatizada.
18. Evitar el costo de mano de obra en x cantidad por visita m édica reduciendo 50% el
tiempo que se necesita para registrar los servicios médicos del paciente. (Los servi
cios médicos son registrados actualm ente por el veterinario en forma redundante,
tanto en la forma de pedido como en el archivo m édico del paciente.)
19. Evitar los costos de inventario e iu t cantidad anual reduciendo el nivel de existencias
disponibles de 60 a 30 días.
\o iij: I m Dra. Chur reportó que actualm ente tienen existencia de m edicam entos a
~*r. ’-.r.e.! ác 60 días para evitar quedarse sin mercancía. Cada 90 días se realiza el
;tv.rTÁ¿in>! ffcieo v se descartan los medicam entos expirados que se encuentren. Billy
a -mruru que el costo real no está en los medicam entos expirados, sino en el costo de
oportunidad, va que McVet tiene recursos inmóviles en el inventario. El resto del
grupo no quedó com pletam ente convencido, pero acordó m antener este objetivo en
la lista.
20. Evitar el costo del desorden forzando a que el departam ento de ventas haga que los
departam entos de tecnología de inform ación y de contabilidad valoren la factibilidad
de los nuevos programas.
Nota: Después de m ucha discusión, indignación del grupo y m ucha gesticulación por
parte de Billy, el grupo estuvo de acuerdo en que este objetivo debería eliminarse de
la lista y transferirse a una lista de temas p ara el Sr. Shedmore.
21. Evitar el costo de m ano de obra del contador reduciendo 35% el tiem po que se lle
va para m antener la iniurinación de facturación y cuentas por cobrar de cada esta
blecim iento.
22. E vitar el eosto de mano de obra en cantidad anual elim inando dos puestos de tiem
po com pleto de los contadores de establecim ientos de M cVet actuales.
Nota: B illy realmente tuvo problem as con este objetivo, pero ya se había hecho la p e
tición de una facturación centralizada, eliminando mucho de lo que actualmente ha
cen los contadores de tiempo completo en cada establecimiento. Con la adición de
varios nuevos establecimientos en el horizonte, la expansión del personal de contabi
lidad con una correlación de uno a uno con los establecimientos ya no tiene sentido
y, de hecho, plantea una barrera para una rápida expansión. Dada su experiencia y
am-plio conocim iento de la compañía, Billy era un candidato obvio para dirigir un
nuevo departam ento de facturación centralizada, p o r lo que eventualmente capituló
y perm itió que este objetivo quedara abiertamente establecido.
23. Evitar el costo de mano de obra de contabilidad d e.t cantidad mensual permitiendo que
los clientes escriban un solo cheque para facturaciones de varios establecimientos.
24. E vitar el costo de transferencia de datos de x cantidad mensual elim inando la trans
ferencia manual de datos de cargos mensuales de los establecim ientos hacia la ofici
na central.
25. Evitar los m ateriales desperdiciados y el costo de correspondencia de x cantidad
anual debido a piezas postales directas poco efectivas, e increm entar la ganancia en
\ cantidad anual m ediante la generación de más clientes recurrentes perm itiendo que
M cVet elabore cam pañas por correo directas hechas a la m edida de las característi
cas socioeconóm icas de la región de m ercado a la que sirve.
Nata: M arge Inn, la nueva cabeza de m ercadotecnia de McVet, añadió algunas co
sas a este objetivo. Asegura que McVet podría generar m uchos m ás d ie n tes recu
rrentes si pudiera generar piezas postales directas m ás efectivas para la base de
d ie n te s existente. A dm itió que no tiene evidencia em pírica para valorar su afirm a
ción, pero cree firm em ente que McVet todavía no ha aprovechado d potencial de su
base de d ie n tes existente.
26. Evitar el costo de la rotación de personal prem atura potencial de los contadores de
los establecim ientos debida a sobrecarga de trabajo m ediante la reducción de su car
ga de trabajo 35% . La rotación de personal podría costar a la com pañía hasta $y,000
por reclutar, contratar y capacitar a un nuevo contador.
27. Evitar cl riesgo de falla del sistema de captura de pedidos actual estableciendo una
solución que este bien docum entada y sea fácilm ente m odiñcable.
28. El objetiva para el problem a 28 fu e establecido adecuadam ente en el objetivo 25.
29. Hvitar cl costo de la captara redundante de registras de cliente (se lleva tres minutos
por cam bio de núm ero telefónico de cliente, aproxim adam ente cuatro veces a la se
m ana por establecimiento) perm itiendo que el núm ero telefónico del cliente sea ac
tualizado en el registro de cliente actual.
30. El objetivo p a ra el problem a 30 está establecido adecuadam ente en el objetivo 29.
31. M ejorar el servicio a clientes y evitar el costo de capturar y m anejar registros de
cliente redundantes perm itiendo que los clientes tengan una cantidad ilim itada de p e
rros en el sistema.
Nota: Wanda indicó que la incidencia de clientes que poseen más de tres perros en el
área metropolitana es lo suficientemente rara para que este objetivo mereciera el es
tablecimiento de un fa c to r x. Pendergast no estuvo tan convencido y decidió escarbar
un poco más. Preguntó qué hace el encargado del m ostrador cuando los clientes vie
nen con una camada de cachorros que requieren despam sitación o vacunación. Con
seguridad esta situación es común e involucra a un cliente con más perros que el li
mite de tres del sistema actual. Wanda replicó que capturan a to á o slo s cachorros en
el sistema como un solo perro y registran vanas dosis. Pen resumió, ¿Por lo tanto,
el sistema actual tiene perros que se llaman 'achorros ’ que aparecen como un perro
que recibiera 10 dosis revitalizadoras el mismo día?" El grupo estaba realmente ape
nado y estuvo de acuerdo en que ésta era una práctica de negocios indeseable y no
debería continuarse con ella en el nuevo sistema.
32. Reducir el tiempo que se necesita para capturar un pedido m ejorando la navegación
entre pantallas.
Nota: El grupo decidió que algunos de los problem as que se relacionan directamen
te con el sistem a actual son bajos en la escala de evitar costos, pero registraron a l
to en el m edidor de frustración del usuario. En vez de tratar de determ inar la m eta
de mejora m inúscula del fa c to r x, estuvieron de acuerdo en pasar éste y otros obje
tivos m ás a la categoría de mejoras generales en eficiencia, o dicho más directam en
te, erradicación de algunas de las fa lla s de diseño del sistema antiguo.
33. Reducir el tiempo y habilidades requeridas para capturar un pedido haciendo que el
sistem a recuerde al identificador del cliente y del perro cuando se cam bia de la pan
talla de m antenim iento del cliente a la pantalla de captura de pedidos.
Vt Evitar el costo de captura de datos y m ejorar el servicio a clientes haciendo que el
nuevo sistem a sea lo suficientem ente flexible para permitir que McVet añada o eli
m ine servicios disponibles en la función de captura de pedidos. W anda estim a que
1 5 ^ de todos los pedidos requiere que se listen conceptos especiales en la sección
" cOar " del pedidü.
E vitar el costo de valorar m anualm ente conceptos de pedido (sucede en aproxim ada
m ente 15 ^ de todos los conceptos de pedido actuales) haciendo que el sistem a va
lore a ni omáñ carneóte lodos los servicios.
Nota: U'ajida todavía no estuvo satisfecha con este objetivo, debido a que implica
que el cajero nn tendrá libertad para hacer ajustes de precios en el m omento para
un cliente inconfortne o a m concepto no previsto. M arge sugirió que los nuevos es
tablecimientos M cVet que están planeados p a ra el año próxim o tal vez no quieran
contratar cajeros con tanta experiencia y autoridad com o Wanda, y que la capaci
dad de m odificar los precios puede ser que no sea una característica deseable. P en
dergast transfirió la pregunta sobre la autoridad del cajero para m odificar los
precios a una lista de asuntos a ser consultados con los gerentes de McVet.
36. E l objetivo del problem a 36 fu e establecido adecuadam ente en el objetivo 35.

37. M ejorar el servicio a clientes reduciendo la incidencia de los atasques de papel (falla
de tecnología) de un prom edio de tres veces diarias a una por semana.
Nota: H ay que tom ar en cuenta que el grupo se contuvo al no p ed ir “ningún atasque
de papel". Bajo la indicación de Pendergast, estuvieron de acuerda que era irrazo
nable pedir un rendimiento de cero defectos de la gran cantidad de impresoras que
hay en el mercado. D espués de algunos jaloneos, estuvieron de acuerdo en que m ien
tras la impresora no se atascara cada día, una vez a la semana era tolerable.
38. Evitar el riesgo de fraude por parte del cajero y reducir errores en x errores m ensua
les llevando cuenta con precisión entre los servicios solicitados y los servicios pro
porcionados.
39. Evitar el costo de enviar por correo noticias innecesarias en x cantidad mensual per
m itiendo que el usuario estreche ia lista m ediante la especificación de criterios de se
lección para que los envíos por correo puedan ser ajustados por tipo de servicio.
40. El objetivo para el problem a 40 fu e establecido adecuadam ente en el objetivo 25.
41. Increm entar las ganancias en x por ciento conservando y com erciando con clientes
que han notificado a McVet que sus perros han muerto.
Nota; l a conversación se hizo un poco surrealista sobre este objetivo. Billy pregun
tó cómo pretendía com erciar servicios con perros muertos. M aty sugirió que podrían
hacer una expansión hacia taxidermia. M arge insistió que “una vez que a alguien le
gustan los perros, siempre le gustarán los p erro s”, y que todo lo que requería McVet
era encontrar una form a para proporcionar al afligido cliente un nuevo perro y es
taría de vuelta en el negocio. Pendergast asignó a M arge que investigara qué tantas
ganancias podría representar esto.
42. Evitar cl costo de volver a capturar clientes repetidos en la base de datos que no han
ido a McVet el año anterior. E sta situación sucede casi tres veces a la sem ana por
tienda y se lleva cerca de tres minutos el volver a capturar el registro del cliente,
43. E l objetivo para el problem a 43 j'ue establecido adecuadam ente en el objetivo 12.
44. Increm entar ganancias (por medio del valor en el tiempo del dinero) perm itiendo a
McVet que facture a los clientes en un ciclo menor a la facturación mensual.
Nota: Este fu e un objetivo deseado por Billy que involucra m ás un cambio de po líti
ca que un cam bio de sistema. Sim plemente quiso asegurarse de que el nuevo sistema
sea lo suficientem ente flexible p ara que sea capaz de m anejar ciclos de facturación
no únicamente mensuales.
45. M ejorar el servicio a clientes solicitando a los clientes que llenen solam ente un per
fil de cliente y poniéndolo a disposición en todas las ubicaciones de McVet. Se esti-
ma que cerca de 25% de los clientes de McVet son clientes de más de un establecí'
miento, aunque nadie lo sabe con seguridad.
46, M ejorar el servicio a clientes enviándoles record átonos de acuerdo con su asiduidad
a los establecim ientos de McVet,
47. M ejorar el servicio de cobro de cuentas de clientes enviándoles por correo un estado
de cuenta consolidado. Se estim a que 25% de los clientes son clientes de más de un
establecim iento de M cVet y más de 50% de ellos cargan ios servicios a su cuenta con
McVet,
Objetivos derivados de tos enunciados de oportunidad
A. E l objetivo para la oportunidad A fu e establecido adecuadam ente en el objetivo 41.

B. E l objetivo para la oportunidad H fu e establecido adecuadam ente en el objetivo 25.
C. E vitar el costo de exceso de personal en los fines de sem ana y posiblem ente incre
mentar ganancias desplazando a algunos clientes a visitas entre sem ana olreciendo
servicios especiales y descuentos. Marge, de m ercadotecnia, tendrá que investigar la
factibilidad de este program a para asegurarse de que las ofertas de los días de entre
sem ana den como resultado un increm ento neto en ganancias y no se com an las ga
nancias existentes.
D. Evitar el costo de inventarios excesivos y elim inar la mano de obra requerida para re
gistrar y colocar pedidos de inventarío explotando el software de pedidos de m edi
cam entos existentes y los servicios disponibles de los proveedores,
Nota: La Dra. Chur fu e asignada para investigar el costo y características de los
servicios de los proveedores.
E. Evitar el riesgo de error y dism inuir el costo de m anejo de papelería en x minutos por
pedido prom edio a través de un seguim iento y direccionam iento de perros más pre
ciso en cl área de producción.
Nota: liste objetivo fue inspirado por tecnologías tales rom o el código de barras, sin
embargo no le quedó claro al equipo si las m ejoras al sistem a de direccionam iento
del piso de las instalaciones actual caen dentro del alcance de este proyecto. Pen
añadió esta pregunta a la lista de asuntos para la alta gerencia.
F. M ejorar el servicio a clientes y evitar cl costo de m ano de obra en recepción redu

ciendo el tiempo que se lleva identificar a los clientes repetidos y a sus perros de 30
segundos a 2 segundos. (Ejem plos de este tipo de tecnología incluyen tarjetas de
plástico con bandas m agnéticas, código de barras en tarjetas o en la placa de identi
ficación dcl perro o hasta chips electrónicos incrustados en el hom bro del perro.)
G. M ejorar el servicio a clientes y evitar el costo de mano de obra en recepción
reduciendo el tiempo que se lleva colocar un pedido recurrente para un cliente que
regresa con su perro, de 2 minutos a 30 segundos. (La idea es recuperar cl últim o pe
dido o identificar al pedido com o un pedido predeterm inado para el perfil del perro.)
2.2 Enunciados de objetivo priorizados de McVet

Cuando cl grupo de Pendergast term inó de especificar los objetivos del proyecto, pospusieron
la investigación de los factores x para que pudieran tener una base sólida sobre la cual priori-
zar la lista de objetivos. D urante su siguiente reunión elim inaron ios duplicados y separaron los
objetivos restantes en tres categorías, los que consideraron de muy alta prioridad, los que con
sideraron de muy baja prioridad y los restantes de prioridad m edia que caen en medio.
Objetivos de alta p rio rid a d

El grupo estuvo de acuerdo en que los objetivos más importantes para el nuevo sistem a caen
en varias clasificaciones muy generales. Todos estuvieron de acuerdo en que los problem as que
causan inconvenientes, disgustos o afectan a los d ie n tes de McVet en cualquier forma, son de
la mayor im portancia para el proyecto. Com o una organización de servicio, la reputación de
McVct es sólo tan buena com o su desem peño en la visita más reciente de un cliente. A los ob
jetivos que pretenden m ejoras m ás significativas para los servicios al cliente se les dio alta
prioridad.
La siguiente clasificación de alta prioridad fue para la reducción significativa de costo
de mano de obra dentro de McVct. Los objetivos m ás prom etedores fueron aquellos que bus
can un cam bio en la form a en que McVet adm inistra la facturación, las cuentas por cobrar y la
transm isión de datos al sistem a de contabilidad general, debido a que se pueden elim inar pues
tos de trabajo m ediante la centralización de esta función, y McVet puede evitar el tener que
contratar y capacitar a un nuevo contador de tiem po com pleto para cada nuevo establecim ien
to. D ebido a que el departam ento de acicalam iento es el m ayor centro de ganancias de McVet,
con transacciones de alto volum en y bajo margen, a cualquier reducción cn el costo de esta área
tam bién se le da una prioridad alta. Por últim o, las mejoras en la eficiencia del personal con
mejores salarios de McVet, los veterinarios, fueran listadas com o asuntos de alta prioridad.
Objetivos de alta prioridad que buscan m ejorar

directamente ei servicio a dientes
45. M ejorar el servicio a clientes solicitando a los éstos que llenen solam ente un perfil
de cliente y poniéndolo a disposición de todas las ubicaciones de McVet. Se estima
que cerca de 25% de los clientes de McVet acuden a más de un establecim iento, aun
que nadie lo sabe con seguridad,
47. M ejorar el servicio de cobro de cuentas de clientes enviándoles por correo un esta
do de cuenta consolidado. Se estim a que 25% de los clientes acuden a más de un es
tablecim iento de McVet y m ás de 50% de ellos carga los servicios a su cuenta con
McVet.
31. M ejorar cl servicio a clientes y evitar el costo de introducir y m anejar registros
redundantes de los clientes perm itiendo que éstos tengan un núm ero ilim itado de pe
rros en el sistema.
32, Reducir el tiempo que se necesita para capturar un pedido m ejorando la navegación
entre pantallas.
430 Apéndice i ESTUDIO DEL CASO McVET
33. Reducir cl tiempo y habilidades requeridas para capturar un pedido haciendo que el
.sistema recuerde al identificador del cliente y del perro cuando se cam bia de la pan
talla de m antenim iento del cliente a la pantalla de captura de pedidos.
34. Evitar cl costo de captura de datos y m ejorar el servicio a clientes haciendo que el
nueve sistema sea lo suficientem ente flexible para perm itir que McVet añada o eli
m ine servicios disponibles en la función de captura de pedidos, W anda estim a que
15% de todos los pedidos requiere que se listen conceptos especiales en la sección
“otros” del pedido.
37, M ejorar el servicio a d ie n tes reduciendo la incidencia de los atasques de papel (fa
lla de tecnología) de un prom edio de tres veces diarias a una por semana.
42, Evitar el costo de volver a capturar clientes repetidos en la base de datos que no han
ido a McVet el año anterior. Ksta situación sucede casi tres veces a la sem ana por
tienda y se lleva cerca de tres minutos el volver a capturar el registro del cliente.
E. M ejorar el servicio a clientes y evitar el costo de mano de obra en recepción redu
ciendo el tiempo que se lleva identificar a ios clientes repetidos y a sus perros de 30
segundos a 2 segundos, (Ejemplos de este tipo de tecnología incluyen tarjetas de
plástico con bandas m agnéticas, código de barras en tarjetas o en la placa de identi
ficación del perro o hasta chips electrónicos incrustados en el hom bro del perro.)
G. M ejorar el servicio a clientes y evitar el costo de mano de obra en recepción redu
ciendo el tiem po que se lleva colocar un pedido recurrente para un cliente que regre
sa con su perro, de 2 minutos a 30 segundos. (La idea es recuperar el últim o pedido
o identificar al pedido com o un pedido predeterm inado para el perfil del perro.)
Objetivos de alta prioridad que buscan reducir los

costos de facturación y contabilidad
10. Evitar el costo de mano de obra m ediante ia eliminación de entrada manual en los es
tablecim ientos de McVet en el sistem a de contabilidad general para reporte de ven
tas. Actualm ente, uri em pleado de tiempo com pleto gasta aproxim adam ente seis
horas diarias tecleando las ventas de McVet de cada establecim iento en cl respectivo
softw are de contabilidad, Existe el potencial para elim inar un puesto de trabajo del
departam ento de contabilidad central.
21. E vitar el costo de mano de obra del contador reduciendo en 35% el tiem po que se lle
va para m antener la inform ación de facturación y cuentas por cobrar de cada estable
cimiento.
22. Evitar el costo de mano de obra en x cantidad anual elim inando dos puestos de
tiempo com pleto de los contadores de establecim ientos de McVet actuales.
23. F.vitar el costo de mano de obra de contabilidad de a cantidad mensual perm itiendo que
los clientes escriban un solo cheque para facturaciones de varios establecimientos.
24. E vitar el costo de transferencia de datos de x cantidad m ensual elim inando la trans
ferencia m anual de datos de cargos m ensuales de los establecim ientos hacia la ofici
na central.
26. Evitar ei costo de la rotación de personal prem atura potencial de los contadores de
los establecim ientos debida a sobrecarga de trabajo m ediante la reducción de su car-
ga de trabajo en 35%. La rotación de personal podría costar a la com pañía hasta

$9,000 por reclutar, contratar y capacitar a un nuevo contador.
7. Evitar la pérdida de ganancias y el costo de manejo de formas dañadas, elim inando
las formas de pedido en papel com o entrada para la aplicación de facturación. Hn ca
da establecim iento los contadores reportan que hay, al m enos, dos formas de pedido
diarias que requieren atención especial, debido a que la form a está dem asiado m oja
da para leerla o la escritura a mano les da problem as, Al m enos una vez por mes y
por establecim iento no se le cobra una visita a un d ie n te debido a que los cargos es
critos a mano en la form a de pedido no pueden ser com prendidos con precisión por
el contador cuando captura los cargos en la hoja de cálculo de facturación. El precio
prom edio de una visita de cliente es de S56.
Objetivos de alta prioridad que buscan reducir

ei costo de acicalamiento y médicos
11. Evitar el costo de mano de obra en la línea de acicalam iento reduciendo 50% el tiem
po com binado que se necesita para determ inar cuáles servicios se requieren y el
tiempo requerido para reportar un concepto de servicio com o term inado.
14. E vitar cl costo de mano de obra en x cantidad semanal elim inando la necesidad de
que el em pleado de acicalam iento cam ine hacia el m ostrador para volver a im prim ir
un pedido.
17. Evitar el costo de mano de obra en x cantidad por pedido m édico reduciendo el tiem
po que se lleva cl valorar los conceptos de pedido médicos de m edio minuto por p e
dido a dos segundos por pedido.
15. Evitar el costo de mano de obra en x cantidad por visita médica reduciendo en 50% el
tiempo que se necesita para registrar los servicios médicos dcl paciente. (Los servi
cios médicos son registrados actualm ente por el veterinario en forma redundante,
tanto en la form a de pedido com o en el archivo médico del paciente.)
35. Lvitar cl costo de valorar m anualm ente conceptos de pedido (sucede en aproxim ada
mente 15% de todos los conceptos de pedido actuales) haciendo que el sistem a va
lore autom áticam ente todos los servidos.
Objetivos de p rioridad media

Los objetivos de prioridad media fueron aquellos que no consiguieron provocar gran entusias
mo, pero tam poco m erecieron desprecios irónicos del equipo. Estos objetivos caen en la clasi
ficación de “cosas buenas que deberán hacerse en este proyecto".
Objetivos de prioridad media que buscan dism inuir costos o evitar riesgos
1. Lvitar el costo de un tratamiento equivocado a un perro mediante la creación de un

historial médico com pleto pitra cada perro al cual tengan acceso inmediato todos los
establecimientos de McVet. Nuestro objetivo es reducir la cantidad de incidentes de
malos tratamientos debido al conocimiento incom pleto dcl historial del tratamiento
dcl perro por parte de los veterinarios de x ocurrencias por año a y ocurrencias por año.
2. Hvitar el costo de errores debido a una medición de peso imprecisa m ediante la trans
m isión del peso d d perro directo de la báscula hacia el pedido, eliminando la transfe
rencia manual del valor del peso.
3. Evitar el costo de prescribir m edicam entos inadecuados y reducir el costo de búsque
da de restricciones sobre los medicam entos dándole a los veterinarios aceeso rápido
a inform ación sobre la sensibilidad a los medicam entos por ra /a y m edicamento.
4. Hvitar el costo de incurrir en un error de facturación realizando las funciones de fac
turación y de cuentas por cobrar en un medio m enos volátil que una hoja de cálculo.
5. Evitar costos de mano de obra por la notificación a otros establecim ientos cuando un
cliente adeuda facturas creando una vista consolidada del crédito del cliente a través
de todas Ja ubicaciones de McVet, a la cual todos los establecim ientos tendrán acce
so. En prom edio un contador debe perder 20 m inutos a la semana actualizando una
lista de clientes m orosos y enviándola por fax a todos los dem ás establecim ientos.
6. Evitar el riesgo de una mala identificación del nombre y número de cuenta del cliente
en las facturas haciendo que la aplicación de facturación lea automáticamente el nom
bre y el número del cliente a partir de una sola fuente. A ctualm ente un promedio de tres
clientes por mes notifican a McVct que sus nombres están mal escritos en sus facturas.
R. Evitar el costo de sustracción de fondos potencial estableciendo una adecuada sepa
ración de responsabilidades entre las personas que registran las cuentas por cobrar,
las que reciben y registran los pagos y las que hacen los depósitos bancarios,
12. Evitar pérdida de ganancias por no cobrar a los dientes, debido a conceptos de servi
cio fallantes por incidentes de conceptos tallantes de x por m es a y por mes.
13. Evitar el costo de exceso de personal en los di'as ligeros en x cantidad mensual y me
jorar cl servicio a clientes cn los días atareados, prediciendo con m ás precisión el ni
vel de personal requerido.
25. Evitar los m ateriales desperdiciados y el costo de correspondencia de x cantidad
anual debido a p ie/as postales directas poco efectivas e increm entar la ganancia en x
cantidad anual m ediante la generación de m ás clientes recurrentes perm itiendo que
McVet elabore cam pañas por correo directas hechas a la medida de las característi
cas socioeconóm icas de la región de m ercado a la que sirve.
27. Hvitar el riesgo de falla del sistem a de captura de pedidos actual estableciendo una
solución que esté bien docum entada y sea fácilm ente modificable.
29. Hvitar el costo de la captura redundante de registros de d ie n te (se lleva tres minutos
por cam bio de numero telefónico de cliente, aproxim adam ente cuatro veces a la
sem ana por establecim iento) perm itiendo que el núm ero telefónico del cliente sea
actualizado en el registro de cliente actual.
38. E vitar el riesgo de fraude por parte d d cajero y reducir errores en x errores m ensua
les llevando cuenta con precisión entre los servicios solicitados y los servicios
proporcionados.
39. E vitar d costo de enviar p o r corrco noticias innecesarias en x cantidad m ensual per
m itiendo que el usuario estreche la lista mediante la especificación de criterios de
selección para que ios envíos por correo puedan ser ajustados por tipo de servicio.
C. Hvitar el cosLo de exceso de personal en los fines de sem ana y posiblem ente incre
m entar ganancias desplazando a algunos dien tes a visitas entre sem ana ofreciendo
servicios especiales y descuentos. Marge, de m ercadotecnia, tendrá que investigar la

tactibilidad de este programa para asegurarse de que las ofertas de los días de entre
sem ana den com o resultado un increm ento neto en ganancias y no se com an las g a
nancias existentes.
E. Evitar el riesgo de error y dism inuir el costo de m anejo de papelería en ,t minutos por
pedido prom edio a través de un seguimiento y dircceionam iento de perros más pre
ciso en el área de producción.
Objetivos de p rio rid a d baja

Los objetivos a ios que el equipo les dio la prioridad más baja fueron aquellos que tienen un
bajo potencial para producir beneficios tangibles o caen fuera del alcance m edular del proyec
to. Se decidió que aunque sería muy bueno tener algunas características, tales com o el surtido
de invenían o automático. McVet no lienc un problem a significativo con la adm inistración del
inventario de m edicinas, por lo que se asignó una prioridad baja.
Objetivos de baja prioridad que buscan reducir

costos de inventario y de administración
19. Evitar los costos de inventario en x cantidad anual reduciendo el nivel de existencias
disponibles de 60 a 30 días.
D. Hvitar el costo de inventarios excesivos y elim inar la mano de obra requerida para re
gistrar y colocar pedidos de inventario explotando el software de pedidos de medi
camentos existentes y los servicios disponibles de los proveedores.
15. Evitar el costo del espacio innecesario en x cantidad anual por nuevo establecim ien
to, alm acenando los registros m édicos en un medio que ocupe m enos espacio que ios
archivos de papel actuales.
16. Reducir el costo del papel que se usa para im prim ir pedidos y recibos de éstos en
50%. (Los pedidos actuales se imprim en en formas caras de varios tantos.)
Objetivos de baja prioridad que buscan reducir costos de mano de obra
9. Evitar el costo de una visita médica promedio de un perro perm itiendo que el veteri
nario realice búsquedas personalizadas en el historial m édico del perro para consul
tar conceptos particulares cti ve/, de tener que leer un historial cronológico. La Dra.
Chur estim ó que esto podría reducir un prom edio de dos minutos por visita para cer
ca de 15% de sus clientes que tienen archivos médicos grandes.
Objetivos de baja prioridad que buscan incrementar

ganancias o m ejorar e! servicio a dientes
41. Increm entar las ganancias en .r por ciento conservando y com erciando eon clientes
que han notificado a McVet que sus perros han muerto.
44. Increm entar ganancias (por medio del valor en el tiempo dei dinero) perm itiendo a
McVet que facture a ios clientes en un ciclo menor a la facturación mensual.
4fi. M ejorar el sen'icio a clientes enviándoles recordatorios de acuerdo a su asiduidad a

los establecim ientos de McVet.
2.3 Vectores de calidad

Hl equipo de elaboración del plan general del proyecto, conducido por Pendergast, com enzó a
crear una lista de criterios de evaluación contra los que podrían ser evaluadas las diversas op
ciones de solución. Convirtieron cada objetivo en una medición tangible o intangible del bene
ficio y listaron los elem entos familiares que miden el costo de la solución, tales com o el costo
de im plem entación y m antenim iento, el tiem po para im plem entarlo y el grado de riesgo. L ue
go com enzaron a hablar acerca de lo que constituye la calidad del sistem a term inado.
Facilidad de usu: L! sistem a debe ser fácil de usar en todas las áreas de captura de
pedidos, procesam iento de pedidos y funciones de caja. Facilidad de uso se define es
pecíficam ente de la siguiente manera;
Facilidad de capacitación: l.’n nuevo recepcionista de McVet debe poder ser ca
pacitado para operar las funciones de registro y entrega en una hora, si es que ya
está familiarizado con los productos estándar de interfaz gráfica de usuario. L'n
nuevo recepcionista que no haya usado una interfaz gráfica de usuario requerirá
un día adicional de capacitación para aprender a usar el ratón, los mentís y los
controles de ventana. Los em pleados de acicalamiento deberán aprender a recu
perar e indicar la realización del pedido con una o dos horas de entrenamiento.
Ahorro de tecleo: Cualquier com unicación hom bre-m áquina que sucede m ien
tras el cliente está esperando (por ejemplo, registro, entrega) deberá tratar de
usar cl m enor tecleo posible, liste ahorro tam bién es im portante para la recupe
ración e indicación de realización de los pedidos de acicalam iento y médicos.
Todos los com andos desplegados: El operador del sistema no tendrá que me-
m orizar ningún com ando para poder usar el sistema. Todas las opciones dispo
nibles deberán estar desplegadas con claridad en la barra de menú, conceptos
de menú, barra de herram ientas o botones de com ando. Se sobreentiende que
este vector de calidad puede estar a veces en conflicto con el ahorro de tecleo,
sin embargo en estos casos la indicación de que el usuario no necesite menu ¡ri
zar com andos tom ará precedencia sobre el ahorro de tecleo.
C onfiabilidad: Kl sistem a deberá estar listo y funcionando durante todas las horas
que M cVet está abierto al público. Si la red de com unicación hacia las oficinas cen
trales se cae, los establecim ientos M cVet deberán continuar siendo o perad oriales p a
ra aceptar y procesar pedidos de clientes.
M a n terribilidad: El sistem a com pleto deberá ser codificado en forma tal que pueda
>er m antenido fácilm ente por personal de la IT que posea aproxim adam ente dos años
de instrucción universitaria en ciencias de la com putación o dos años de experiencia
con el lenguaje dado.
Flexibilidad: El sistema deberá estar diseñado para perm itir que McVet añada y eli
mine establecim ientos, nuevos servicios, nuevos productos y nuevos tipos de progra
mas de publicidad directa sin incurrir en cambios significativos al sistema.
Inmediatez de respuesta: El sistema deberá lograr un tiempo de respuesta de dos se

gundos o menos para la recuperación de pedidos y registro de terminación de los servi
cios realizados a un pedido en los establecimientos de McVet. Éste es ei tiempo de
respuesta más rápido requerido para el sistema. Los reportes de ventas, facturación, ad
ministración de inventario y demás funciones que no suceden enfrente del cliente o en
el piso del establecimiento mientras se dan servicio a los perros, no requiere tal res
puesta inm ediata del sistema. Hl sistem a deberá estar optim izado para que los eventos
com unes repetitivos, tales como la creación de un pedido o el registro de terminación
de un servicio de acicalamiento, sean los más rápidos. Procesos más com plejos, tales
com o la referencia cruzada de la historia médica de un perro o la búsqueda de sínto
mas, pueden tener requerim ientos de tiempo de respuesta más relajados.
Capacidad para com unicarse con otros sistem as: La transferencia de información
desde ei nuevo sistema hacia el sistem a de contabilidad general existente deberá ser
casi invisible y requerir de muy poca o ninguna intervención humana. Hl grupo de
m ercadotecnia de las oficinas centrales de McVet deberá ser capaz de accesar la base
de datos de clientes y de inform ación de pedidos por medio de herramientas de repor
te para usuario final, a fin de que pueda realizar análisis estadísticos que están fuera
del alcance de este sistema. Las lecturas com plejas de la base de datos 110 deberán te
ner un cfccto negativo sobre el desem peño del sistem a de producción durante las ho
ras de operación normales.
2.4 Opciones de solución para la satisfacción de tos objetivos de McVet

El grupo de elaboración del plan general del proyecto estaba realm ente com enzando a sentirse
com o un equipo cohesivo. Habían llegado a un consenso sobre la lista de problemas y oportu
nidades potenciales de McVet. Habían convertido esos problemas y oportunidades en objetivos
del proyecto, investigando maneras de medir los objetivos en términos de incrementar ganan
cias, evitar costos y mejorar el servicio a clientes. Los objetivos habían sido priorizados y se h a
bía creado una lista de criterios de evaluación para medir si cualquier solución propuesta logra
el beneficio deseado de cada objetivo y cae dentro de las restricciones de eosto indicadas por el
negocio. Además, habían redactado vectores de calidad para determinadas partes del sistema.
Ahora ya por fin era tiempo de com enzar a hablar acerca de las posibles soluciones, Pen-
dergast proporcionó la prim era opción de solución de “no hacer nada”. Lo que sigue es una
lista de sus opciones y parte de la discusión subsecuente.
5 0 1 . Statu Quo. N o hacer nada.

E l grupo completo estuvo de acuerdo que la opción de solución número uno era in
deseable. M e Vet estaba ganando m ucho dinero en este mámenlo, pero su habilidad
para expandirse rápidamente a otras ciudades podría estar am enazada p o r sus
grandes ineficiencias. iil no hacer nada podría ser aceptable si M cVet quisiera p e r
m anecer como una operación pequeña de cinco establecimientos, pero su fo rm a a c
tual de operación funciona como una barrera para la expansión a gran escala.
5 0 2 . C o n stru cció n p erso n alizad a. Hl diseño y construcción personalizados de un sistema
de información integrado que automatice las funciones de la colocación de pedidos,
el servicio de acicalamiento, el servicio médico, el control de caja y la adnunistración
del inventario de medicamentos y otros artículos en cada tienda, y que además se en-
lace di redám ente con la función centralizada de facturación, cuentas por cobrar y re
portes de venías en las oficinas centrales y tenga una interfaz autom ática con los sis
temas existentes de contabilidad y nómina.
La visión áe una solución integrada a nivel empresarial, diseñada a la m edida espe
cíficam ente para McVet, fu e ciertamente la m ás atractiva de todas las opciones de
solución. También es potencialm ente la opción de solución m ás cara de. la lista. Las
buenas noticias son que McVet tiene m ucho dinero. Las m alas noticias son que vir
tualm ente no tiene personal de IT capaz de tal empresa, y el esfuerzo completo de
bería ser realizado p o r fu e ra o se tendría que fo rm a r el personal de desarrollo a
partir de cero.
SOS. P aquetes co m p rad o s. Buscar la com pra de una solución de paquete que proporcione
un sistem a de inform ación integrado que automatice las funciones de la colocación de
pedidos, el servicio de acicalamiento, el servicio medico, el control de caja y la adm i
nistración del inventan o de medicamentos y otros artículos en cada tienda, y que ade
más se enlace con la función centralizada de facturación, cuentas por cobrar y reportes
de ventas en las oficinas centrales y tenga una interfaz automática con los sistemas
existentes de contabilidad y nómina.
A todos los em pleados áe M cVet les gusta p ensar que su com pañía es com pletam en
te única. La verdad es que conforme McVet se expanda, muchas de sus necesidades
de información y procesos de negocios com enzarán a parecerse cada vez m ás a cual
quier otro proveedor de servicios grande. L l grupo decidió que deberían exam inar
si ya existe una solución en el mercado que pudiera satisfacer las necesidades de
McVet. ¡.a com pra de un sistem a existente, en vez de la construcción de uno, les pa
reció muy atractiva a algunos de ellos. Esta solución fu e defendida en particular por
B illy y los dem ás contadores. Wanda, M aty y los veterinarios fu ero n m.ucho m ás es
cépticos en cuanto a que sus necesidades pudieran ser satisfechas p o r una solución
de paquete integrado. M arge advirtió que una solución en paquete no hace nada p a
ra distinguir a McVet de sus competidores.
S 0 4 . Solución m ezclada de construcción personalizada y en paquete. Buscar la com

pra de las partes del sistem a que sean buenas candidatas para encontrar software
existente que pueda ser integrado fácilmente con las parles más personalizadas del
negocio. Por ejemplo, un paquete de adm inistración de inventario ha sido identifica
do com o un módulo com prado potencial. Otros candidatos incluyen la com pra de
partes del sistem a para realizar las funciones de cuentas por cobrar. Las partes del sis
tema que corresponden muy de cerca con la colocación de pedidos y el cum plim ien
to de procesos en los establecim ientos McVet serían fabricadas a la m edida de las
especiílcaciones de McVet.
.Ve propuso un com prom iso entre los partidarios de la solución en paquete y las áe
la solución construida a la meáiáa. J.a opción áe solución 4 busca com prar e inte
grar paquetes que autom aticen fu nciones que están estanáariz.adas a través áe m u
chas industrias, siempre y cuando sea suficiente una solución genérica, pero se
reserva el derecho de construir soluciones a la m eáida en donde McVet tenga re
querim ientos específicos de que el sistem a m apee procesos de negocios propios o
proporcione funcionalidad que d é a McVet una ventaja com petitiva en el m ercado.
La desventaja de esta solución es que el grupo de I T debe hacer que las porciones
com pradas de la aplicación se integren en form a casi im perceptible eon las que
construyan.
SOS. S olución p arc ial. Construir una solución personalizada que satisfaga las necesida
des más aprem iantes de McVet en las áreas de colocación y cum plim iento de pedi
dos y la facturación y adm inistración de cuentas por cobrar centralizada, pero deje
fuera de alcance objetivos de m enor prioridad, tales corno la adm inistración de in
ventario.
La opción de solución 5 fu e un intento para proporcionar una solución de m enor ta
maño que autom atice solam ente los objetivos de alta y m edia prioridad, v que deje
fuera de alcance a los dem ás conceptos. Los conceptos de m enor prioridad podrían
ser Integrados com o la fa se dos del proyecto.
Después de calificar las opciones de solución contra los criterios de evaluación, cl equi
po de elaboración del plan general del proyecto para McVet recom endó la opción de solución
4 a la gerencia, la cual prom ueve la construcción personalizada de una aplicación de colocación
y satisfacción de pedidos, acoplada con un paquete de seguimiento de inventario com prado pa
ra los establecim ientos de McVet, La recom endación sugiere el movim iento de la facturación
de las cuentas de crédito, las cuentas por cobrar, el reporte de ventas y la integración con el sis
tem a de contabilidad lucra de los establecimientos hacia una ubicación centralizada en las ofi
cinas centrales, y recom endó que el equipo analice si estas funciones centralizadas podrían estar
disponibles por m edio de una expansión del sistem a de contabilidad central que ha sido
com prado a un vendedor de software financiero internacional im portante, reduciendo así la can
tidad de software que tendría que ser construido a la medida.
Shedm ore quedó muy com placido con la propuesta y la buena investigación y participa
ción de los em pleados. Le dio a la propuesta su com pleta aprobación y conservó a la em presa
de Pendergast para que realizara el análisis, desarrollo c integración del proyecto, así com o el
reclutam iento y form ación de un equipo de tecnología de inform ación interna capaz de m ante
ner el softw are en el futuro.
Respuestas al ejercicio 3 —Modelo de contexto
3.1 Diagrama de contexto para el proyecto de McVet

Pendergast encontró que era más fácil trabajar al m ism o tiempo sobre el diagram a de contex
to y la lista de eventos en vez de hacerlo por separado. Batalló para encontrar el nom bre de la
burbuja de contexto. D ar servicio a perros quedaba corto en alcance y hacía pensar en im á
genes desagradables de cirugía autom atizada. O perar a McVet parecía dem asiado am plio, ya
que m uchas funciones de la oficina central no estaban incluidas en su alcance. Pen se decidió
sobre operar establecim iento McVet, que im plicaba que las actividades asociadas con el m a
nejo del establecim iento quedaban en alcance, aunque algunas de las actividades que están
dentro de su burbuja, tales com o la facturación y las funciones de correo directo, sin duda
serían m ovidas a la oficina central. La figura A -7 m uestra este prim er paso del diagram a de
contexto.
3.2. Contexto de alcance expandido contra reducido

E l diagram a de contexto que ha trazado Pendergast parece ser un modelo de alcance expandi
do. H a elegido mostrar al cliente com o originador de la inform ación de pedido de servicio en
vez de ai recepcionista. A unque esto podría inquietar al rccepcionista cuando viera que no es
tá incluido en cl diagrama, él es en realidad el transportador de los datos y 110 su fuente origi
nal. La escala es también una selección interesante de agente externo. Pendergast decidió que
el recepcionista no era el agente externo adecuado para el peso del perro, debido a que, nueva
m ente, es sim plem ente cl transportador actual de los datos. El perro no es un buen candidato,
debido a que es incapaz de decir su peso al sistema. M ediante la colocación de una pieza de
hardw are, tal com o una báscula, en el modelo de contexto, Pendergast está declarando su de
seo de hacer que el sistem a se com unique con este hardw are particular.
S e r v ic io s de
a c ic a l a m ie n t o
s o l ic i t a d o s
Ventas, detalles
Reportes de cuentas por cobrar
e inventarios
de ventas
Figura A-7. Diagrama de contexto para operar establecimiento McVet.

Respuestas al ejercicio 4 —Modelo de eventos
4 .7 Lista de eventos
Pendergast hizo un prim er borrador de una lista de eventos. A notó cuáles eventos eran inespe
rados y cuáles esperados. Para los eventos esperados anotó si algunos eran tem porales o pseu
doeventos. Luego organizó su lista de eventos en form a muy general por tema.
I = E v ento in e sp erad o
E = E v en to esp erad o
T = E v en to te m p o ral (se e sp era que sea activ ad o p o r cl tiem p o )
P = P se u d o e v e n to (no o c u rre n c ia de u n evento esperad o )
Eventos de recepción:
l El clien te c o lo c a p ed id o p ara el perro
E l n u e v o clien te c o lo c a p ed id o para n u e v o p erro
El n u ev o clien te co lo ca p ed id o p a ra p erro ex isten te (cam b io de p ro p ied ad )
El clien te ex isten te co lo ca p ed id o p ara n u ev o p erro
El clien te ex isten te co lo ca p ed id o p ara p erro ex iste n te (rep ite v isita de clien te y
p erro)
I El clien te so licita c ita p ara ciru g ía (para el perro)
E E l clien te re g istra al p erro p ara c ita de ciru g ía
P El clien te falla en cl reg istro del p erro p a ra c ita de ciru g ía
E El re c c p c io n ista p esa al perro
Eventos de realización de pedido:

E Se ad m in istra tratam ie n to Perro Feliz
E E l em p lead o d e acic ala m ie n to p reg u n ta so b re los se rv icio s de ac icalam ien to so li
citados p ara el p erro
E El em p lead o de acicalam iento reporta el servicio de acicalam ien to com o term in ad o
E E l v eterin ario p re g u n ta so b re servicios m éd ico s so licitad o s p ara el p erro
1 El v eterin ario p reg u n ta so b re cl h isto rial m édico del p erro
I El v eterin ario h ac e d ia g n ó stic o de la co n d ició n del p erro
I E l v eterin ario p resc rib e m ed icam en to s
E E l v eterin ario rep o rta el tratam ie n to m é d ico co m o term in ad o
Eventos en la entrega de perros:

E E í clien te rec o g e al perro
P E i clien te n o rec o g e al perro
E El cajero so licita el total d e cargos del pedido

E El clien te p a g a el p edido
E l clien te p ag a el p ed id o c o n efe ctiv o /ch e q u e
El clien te carg a el p ed id o a su c u e n ta en M cV et
Eventos de facturación:
T T iem p o p ara fa c tu ra r el créd ito a clientes
E E l clien te p a g a factura
P E l clien te n o p a g a factura
Eventos de inform es de contabilidad/ventas:

E E l co n ta d o r salda d ia riam e n te lo rec ib id o en c ic c tiv o
T T iem p o p a ra reg istra r la activ id ad en la c o n tab ilid ad g eneral
Eventos de mercadotecnia:
I M e rc ad o te cn ia solicita rep o rte d e ventas
I El d ep a rtam e n to de m e rc ad o te cn ia c re a un a n u ev a lista d e p recio s
I El d ep a rtam e n to de m e rc ad o te cn ia c re a u n n u ev o serv icio
I El d ep a rtam e n to de m e rc a d o te c n ia re tira u n serv icio
I El d ep a rtam e n to de m e rc a d o te c n ia c re a n u ev a literatu ra de co rreo d irecto
I E l departam en to de m ercadotecnia solicita la lista de co rresp o n d en cia de los clientes
Eventos de adm inistración de inventario:

I El in v e n tario cae p o r abajo del p u n to de reo rd en
E M cV et recib e artículos para el in v en tario
P M cV et no recib e artículos p a ra el in v en tario
I El d ep a rtam e n to d e c o n tab ilid ad so licita los saldos del in v en tario
Eventos de m antenim iento de clientes:

I El clien te n o tific a a M cV et q u e el p erro h a m u erto
I El cliente n o tific a a M cV et d e ca m b io de d irecció n , n ú m e ro te lefó n ico
4^2 Preguntas relativas a la lista de eventos

Pendergast revisó su lista de eventos y anotó unas cuantas preguntas relación a los eventos que
ík form a intuitiva estaban fuera del alcance.
El evento nuevo cliente coloca pedido para perro existente im plica que quien hubiera si
do responsable de pagar las cuentas de McVet por determ inado perro, ya no lo es, y las cuen
tas deí perro ahora serán pagadas por alguien diferente, liste evento 110 representa ningún
problem a si ia transferencia se da dentro de la misma familia, por decir, un hijo o hija se m u
da y se lleva al perro, o un divorcio da com o resultado que la custodia se le otorgue a un cón-
yuga diferente que cl que está registrado en McVet. Cuando los perros se com pran, venden o
se regalan puede ser que los nuevos propietarios 110 sean capaces de identificar el nom bre del
propietario anterior en McVet, y si no se les pregunta puede ser que ni siquiera se les ocurra
preguntar si el perro ya tiene un registro en McVet. En estos casos puede ser que no haya fo r
m a para que la reccpcionista discierna con precisión que el perro ha visitado anteriorm ente un
establecim iento de McVet y, por lo tanto, creará un nuevo registro de perro. Pendergast se pre
guntó si esto sería un asunto de im portancia.
E l d ie n te no lleva a l perro a una cita para cirugía es la no ocurrencia del evento el clien
te lleva a l perro para cita de cirugía. Pendergast lo añadió a la lista debido a que quiere recor
dar que hay que preguntar si McVet tiene una política con relación a no presentarse. Si el
cliente es un ausente crónico de las citas de cirugía ealendarízadas, ¿hará algo McVet para tra
tar de im pedirlo? ^
La form a en que está redactado el evento se adm inistra tratamiento de Perro Feliz lleva
al lector a creer que el sistema puede ser capaz de determ inar autom áticam ente que un perro
particular ha salido del m ódulo sanitario Perro Feliz. Pendergast quiere asegurarse de que este
nivel de integración con los sistemas del piso de las instalaciones esté dentro del alcance del
proyecto, ya que en caso contrario el em pleado de acicalam iento será responsable de registrar
cuando un servicio de Perro Feliz halla term inado.
E l evento muy lamentable el cliente no recoge al perro deja a Pendergast preguntándo
se si alguien ha abandonado alguna vez un perro en MeVct y cuál es la política de McVet. pa
ra los perros a los que dejan a pasar la noche o definitivam ente abandonados. Si esto ¡legara a
suceder, ¿que papel desem peñaría el sistem a en el seguim iento de la situación del perro?
El cliente notifica a M cVet que el perro ha m uerto es un evento que M arge insistió en
mantenei en la lista para detener el ílujo de tarjetas de cum pleaños y otro material p o r correo
dirccto dirigido al perro. Pen hizo una nota para preguntar, ¿tjué sucede si el perro m uere mien
tras está bajo el cuidado de McVet? Sí Binky tiene un ataque al corazón en la máquina lavado
ra de perros, ¿será gratis la visita com pleta?
4,3 Entrada dei diccionario de eventos

Nom bre El cliente coloca pedido para perro.
del evento:
Descripción: Cuando un cliente trac a un perro a McVet, la prim era tarea es determ inar si
el cliente o el perro han visitado anteriorm ente un establecim iento McVet.
Si el cliente nunca ha estado en M cVet se debe crear un nuevo registro del
cliente. Si el perro nunca ha estado en M cVet se debe crear un nuevo regis
tro del perro. Después de que ha sido registrada la inform ación básica acer
ca del cliente y cl perro, la reccpcionista coloca un pedido de servicio para
todos los conceptos que ha especificado el cliente que quiere que se realicen
al perro. El perro es puesto en la jau la y al cliente se le da un recibo del p e
dido impreso.
Iniciador: Hl cliente inicia los datos para este evento.
Transportador: Actual: en la situación actual cl reeepcionista registra toda la inform ación
para colocar un pedido.
Futuro: para d ie n tes que repiten hay ei potencial de emitir etiquetas o ta p e

tas de identificación que le proporcionen al sistem a una identificación rápi
da y precisa sobre el d ie n te y d perro.
Estím ulo; Pedido de servicio.
A ctividad: If el cliente ya tiene un registro en McVet
R ecuperar registro de cliente
Verificar nombre, dirección y núm ero telefónico
Else (nuevo d ie n te)
Crear nuevo registro de cliente
End if
if el perro ya tiene un registro en M cVet para este cliente
Verificar inform ación del perro
Else if el pen o tiene un registro bajo un cliente diferente
M over el registro del perro a este cliente
Else if el perro no tiene registro anterior en McVet
Crear nuevo registro de perro
Knd if
Créate nueva instancia de pedido
For each tipo de servicio solicitado
Crear nueva instancia de concepto de pedido
End for each
Elaborar recibo de pedido
Respuesta: Rccibo de pedido
Efecto: El perro es entregado al recepciom sta y puede ser pesado y regresado a la
cola de espera. El cliente tiene su recibo de pedido en la m ano y puede aban
donar el establecimiento.
Respuestas al ejercicio 5 —Modelo de información
5.1 Diagrama entidad-relación para captura de pedido

y cumplimiento de funciones
Sin im portar qué tan grande o pequeño sea cl proyecto, Pendergast siem pre se siente mucho
más seguro después de que tiene iniciado el modelo de inform ación para la parte m edular del
sistema. En este caso, la creación de un pedido y la entrega de un servicio forma la parte m e
dular del negocio de M cVet. l'n a vez que esta parte del modelo de inform ación com ience a to
m ar form a, Pendergast sabe que podrá ser fácilm ente extendida en muchas direcciones para
acom odar 3as funciones del cajero, la facturación, los pagos, el inventario, etcétera. La figura
A-8 (un ERD , diagram a entidad relación) m uestra el m odelo de inform ación de Pendergast p a
ra los daios que se necesitan para colocar un pedido y m arcarlo com o terminado.
F ig u ra A - 8 . E R D p a ra las fu n c io n e s de c a p tu ra de p e d id o y s u c u m p lim ie n to .
5.2 Asuntos relacionados con la cardinalidad de la relación

Se presentaron varios asuntos cuando e! equipo de análisis de Pendergast com enzó a crear el
m odelo de inform ación para la función de captura de pedidos. Hubo preguntas sobre la prim e
ra relación trazada entre cliente y perro. El analista necesita saber si McVet obliga a que todos
Jos clientes tengan al m enos un perro. La re solución vino por parte de Marge, de m ercadotec
nia, quien dijo que aunque los perros pudieran eveníaalm ente ser elim inados de la base de d a
tos por causas de muerte, M cVet todavía querría conservar la inform ación de! cliente para sus
esfuerzos de m ercadotecnia continuos. Se desató un fuerte debate sobre si los perros pudieran
ser poseídos por m uchos clientes, tai com o la custodia conjunta o los perros de carreras poseí
dos por grupos de socios. Este debate fui: resuelto cuando Billy hizo la observación de que a
McVet no le im porta quién posee el perro, ya que lo único que requieren es que alguien sea in
dicado como responsable financiero del pago de los servicios proporcionados por MeVeL.
[in una revisión rápida del diagrama, avanzando a partir de arriba a la izquierda vemos
que los establecim ientos de McVet no requieren tener ningún pedido en e1 sistema, perm itien
do que nuevas tiendas se instalen antes de su primer pedido. Sin embargo, los pedidos deben
ser tom ados en un y sólo un establecim iento de McVet. 1:1 empleado que loma el pedido, que
es por lo general el recepcionista, es registrado en cada pedido. Un pedido se coloca a nombre
de sólo un perro. Se estuvo de acuerdo en que McVet no tom a pedidos para varios perros. Si
un cliente llega con varios perros, cada perro tendrá un pedido separado en el sistema.
Todo pedido deberá tener a un perro (McVet no vende ningún artículo en el mostrador) y cada
pedido debe tener un nom bre de cliente com o parte responsable del pago. Aunque el cliente es
dcrivable a partir del perro al m om ento del pedido, la parte financieram ente responsable pue
de cam biar para el perro en el futuro, por lo que el cliente es también asociado directam ente a
cada pedido.
Cada pedido debe especificar a! menos un tipo de servicio. Los tipos de servicios repre
sentan la lista de servicios proporcionados por McVet. D ebido a que m uchos tipos de servicios
pueden colocarse en un pedido y el m ism o servicio puede aparecer en m uchos pedidos, se crea
un concepto de pedido para registrar la solicitud de aplicar un lipa de servicio específico a un
pedid.o específico. Los conceptos de pedido son creados para el pedido por el recepción ista
cuando el cliente solicita los servicios. También pueden ser creados por el veterinario confor
m e se realizan procedim ientos adicionales en el perro. Los tipos de servicios pueden tener pre
cios de servicio pasados, presentes y futuros listados para el tipo de servicio. A lgunos tipos de
servicios requieren un m anejo más cuidadoso del perro y, por lo tanto, se hace un cargo extra
p o r raza para determ inadas razas agresivas.
Los perros son clasificados por raza. Se dio una gran discusión sobre si las razas m ez
cladas, tales com o las de cocker y poodle, serían razas separadas por lo que se refiere a McVet.
La adm inistración de McVet decidió que cada perro sería clasificado en únicam ente raza y que
todas las razas mezcladas serían representadas en la tabla de razas. E sta solución funcionó m uy
bien, debido a que muchas razas mezcladas tienen sensibilidades únicas hacia determ inadas
drogas o procedim ientos.
5.3 Relaciones de supertipo/subtipo en el modelo de información de McVet

H ay varios lugares donde el m odelador de inform ación puede descubrir relaciones de superti
po/subtipo. El lugar más obvio es la entidad tipo de servicio. McVet proporciona dos clasifica
ciones de servicios com pletam ente diferentes, las que son tipos de servicios m édicos y las que
son tipos de servicios de acicalam iento. A unque pueden com partir muchas de las mismas ca
racterísticas, hay algunas diferencias importantes. Solam ente los veterinarios con licencia es
tán autorizados para realizar procedim ientos médicos o prescribir m edicam entos. For lo tanto,
el subtipo que se ve en la entidad tipo de servicio puede tam bién ser reflejado en la entidad em
pinado. Los em pleados pueden clasificarse fácilm ente en tres subtipos: veterinarios, em plea
dos de acicalam iento y personal auxiliar (figura A -9)
Figura A-9. P o sib le s re la c io n e s de su p e rtip o /s u b tip o cn el m o d e lo

de in fo rm a c ió n d e M cV et.
Siguiendo este patrón, los conceptos de pedido también pueden clasificarse en subtipos
de conceptos de pedido de acicalam iento y conceptos de pedido médico. Tal vez ya haya des
cubierto este mismo patrón de suhtipo en cl modelo de eventos si hizo subtipos del evento el
cliente coloca pedido para perro en el cliente coloca pedido m édico para perro y el cliente co
loca pedido de acicalam iento para perro. Los datos requeridos para cada uno de estos eventos
son ligeram ente diferentes y m erecen un exam en adicional por parte del analista. Ya sea que se
elija conservar a todos o a ninguno de estos subtipos cn el esquem a de base de datos final, es
m ás una decisión de diseño que un asunto de análisis.
5.4 Tipos de entidad asociativa

Varios tipos de entidad asociativa em ergen en el modelo de inform ación de McVet. Hl patrón
clásico de pedido y concepto de pedido es el resultado de clientes que son capaces de solicitar
m uchos tipos de servicios a la vez. Cargos extra por raza, es otro ejemplo de tipo de entidad
asociativa. Hs el resultado de una raza siendo sujeta a cargos adicionales en varios tipos de ser
vicios y un tipo de servicio con cargos extra para varias razas.
5.5 Tipos de entidades atributivas

H ay al m enos un buen tipo de entidad atributiva en el modelo de Pendergast. La entidad p re
cio del servicio es el resultado de un solo tipo de servicio que tiene muchos precios. Hl atribu
to precio de servicio podría formar un grupo repetido en la entidad tipo de servicio si no fuera
prom ovido para que se convirtiera en una entidad por su propio derecho.
5.6 Definiciones de entidad y atributos

Los siguientes atributos y definiciones están basados en el diagram a entidad-relación que se
presentó en la figura A-8. Los candidatos idcntiñcadores están subrayados. Todos los grupos
repetidos han sido norm alizados, po r lo que la cardinalidad de atributos puede ser expresada
eom o requerida u opcional.
Entidad: Ubicación McVet

D efinición: U na ubicación de McVet es un establecim iento individual o una oficina ad
m inistrativa operados por McVet. Al m om ento en que se escribe esto, Mc-
Vct opera cinco establecim ientos encargados de proporcionar servicios
veterinarios y de acicalam iento a perros y tiene una oficina central para la
adm inistración corporativa.
Atributos:
Tipo
Nom bre Requerido de Dato Definición
C ódiao de ubicación S Char(2) Un c ó d ig o de dos ca ra cte re s que id e n tifica rápida

m e n te una u b ica ció n de M cVet.
N o m bre de ubicación S Char(3Q) El n o m b re oficial d e ia com pañía q ue se usa para

d e sig n ar una u b ica ció n M cV et, ta! c o m o "H a m p to n
H ills " o "U p to w n Malí".
T ipo de u b ica ció n S Char(6} Indica si una ubicación M cV e t pro p o rcio n a servicio s
a pe rro s o si so la m e n te es una o ficina a d m in is tra ti
va. L ista = ESTABL, OFNA.
Ú ltim o n ú m e ro S 'n te g e r Cada u b ica ció n M cV e t asigna n ú m e ro s de pedido

de secuencia en secu e ncia a lo largo del año. Al final de año las
se cu e ncias se vu e lve n a p o n e r en cero. C uando se
co loca un p e d id o, el s iste m a busca el ú ltim o
n ú m e ro ae secu e ncia del e s ta b le c im ie n to , le sum a
1 y actualiza el ú ltim o n ú m e ro de secuencia.
K ntidad: Cliente
D efinición: U n cliente es la parte desiganada para ser financieram ente responsable de
todos los servicios que se le proporcionan a los perros listados para ella. El
sistem a asigna un núm ero de cliente a cada nuevo cliente. E l núm ero es
usado por el sistem a de facturación si el cliente carga los servicios a su cuen-
tacon McVet,
A tributos:
Tipo
Nombre Requerido de dato Definición
Nú m a ro Char(S) Un id e n tific a d o ' ú n ico asignado p o r ei siste m a

de c lie n te que sirve c o m o n ú m e ro de cu e n ta para el c lie n te
d u ra n te su vida c o m o c lie n te en M cVet.
Apellido Ctiar{20) El a p e llid o dado por el clie n te para q ue aparezca en

to d o s los p e didos, fa ctu ra s y d o c u m e n to s d e co
rreo directo.
N o m bre Char{20) El n o m b re dado por el d ie n te para que aparezca en

to d o s los p e didos, facturas y d o c u m e n to s de co
rreo directo.
Inicial m edia CharU) Una inicial m ed ia o p cional dada por el c lie n te para
que aparezca e ^ to d o s ios p edidos, facturas y do
c u m e n to s de co rre o d ire cto .
Prefijo Char(3) Ei c lie n te p u ede e sp e cifica r o p cio n a lm e n te un pre

fijo para los saludos por correo d ire cto . Lista = Sr.
Sra. S rita. Dr.
Sufijo N Char(3} El n o m b re del c lie n te p u ede c o n te n e r un sufijo, tal

co m o Jr. Sr. III.
D ire cció n N Varchar La d ire cció n de la calle o a p artado p ostal del clie n te
(180) se req u ie re si al c lie n te se le van □ cargar servicio s
para cobrarle p o s te rio rm e n te . En caso co n tra rio , los
clie n te s p u e de n o p ta r por no dar su d ire cció n , pero
tie n e n q ue pagar c o m p le ta m e n te al retirar a! perro.
Las d ireccion e s son c a m p o s d e te x to grandes que
aceptarán re to rn o s de carro para d ireccion e s de v a
rias líneas.
Ciudad N Char(30) El n o m b re de la ciu d a d asociado con la dirección

del cliente.
E stado N Char(2} La abreviatura para el e sta d o o provincia en donde

se e n cu e n tra la ciudad. M cV e t no va a m a n te n e r re
laciones de ciu d a d /e sta d o /có d ig o p ostal en la base
de datos.
C ódigo p o s ta l N Char[10! El c ó d ig o p ostal a sociado con la d irección.
T eléfono en ei día N Char(15) Un n ú m e ro te le fó n ic o en d o n d e se p u ede e n co n

tra r al clie n te hasta a n te s de las 5 p .m . Se req u ie re
para las v is ita s d e tip o m éd ico , p e ro no para las vi
sita s d e acica la m ien to . .
Teléfono en la ta rd e N Char(15) U n n ú m e ro te le fó n ic o e n d o n d e se p u e d e e n co n
tra r al clie n te d e sp u é s de ias 5 p .m Se req u ie re
para las v is ita s ve te rin a ria s q ue re q u ie re n u na p e r
m an e n cia para pasar la noche.
Entidad: Perro
D efinición: Un perro es el cliente canino al que se le aplican los servicios de cuidados y
veterinarios en McVet. McVet tiene la misión establecida de tratar solamente
perros y no hay planes actuales o futuros para expandirse hacia otras mascotas.
A tributos:
Tipo
Nom bre Requerido de dato Definición
ID de c e rro S Token Un valor asig n a do por el siste m a para id e n tific a r en

fo rm a unívoca una instancia de perro.
N o m b re de p e rro S Char(20) El n o m b re dado al p e T o por el c iente.
U ltim o N Integer El ú ltim o peso co n o cid o del perro p u e d e ser deriva

p e so en kilos do del peso d e 1perro registrado en el ú ltim o pedido
Es po sib le que el poso m ás re cie n te sea guarda
do en form a 'e u u n d a n te con oí reg istro del perro
para una recuperación rápida.
Focha do n a c im ie n to N Date Los c iie n ie s que p roporcionan la ’recha de naci

m ie n to de sus pe rro s recibirán una ta rje ta oe c u m
pleaños per co rre o a n u alm e n te .
Sexo S C n a r(l) Indica si eí perro es m acho o hem bra. 1 ista = IVr, H.
Castrado s Yes/No Un ca m p o S/N que indica s: el perro ha sid o castra

o esterilizada do/esterilizada.
Alergias N Note Un ca m p o de te x to en d o nde se p u ede a n o ta r cual
q u ie r alerg a del nerro.
M u e rto S Yes/No Un ca m p o S/N que indica si e! perro ha m u e rto . Va-

lor p re d e te rm in a d o = K.
Entidad: R a /a
Definición: U na raza es una clasificación com ún para perros que indica el tipo de perro.
En McVet se reconocerán todas las razas tradicionales, tales com o Dálmata,
Col lie, Poddle Toy, así como razas mezcladas tales com o Cocker Poodle y
otros híbridos.
Atributos:
Tipo
N om bre Requerido de Dato Definición
ID de raâ Token Es un valer asig n a do por el s iste m a para id e n tifica r

en fo rm a unívoca una instancia ce ra¿a.
N o m bre de la ra/a Cnar(30) El n o m b re co m ú n por el que se m en cio n a a la ra/a,

tai c o m o "P a sto r ¡n a le s" "Poodle',' ''D á lm a ta "
c o n tin ú a
c o n t in u a c ió n
Tipo
N om bre Requerido de dato Definición
C andidato para S Yes/No Indica si la raza p u ede pasar por ei m ód u lo sanitario

Perro Feliz del perro feliz. Varias razas raras, pequeñas o con pe
lo e x ce siva m e n te largo, están e xclu id a s de la m á q u i
na y d e ben se r trabajadas a m ano.
S e nsibilidades N N ote Un ca m p o de te x to gra n d e en d o n d e se anotan ias
se n sib ilid a d es p a rticu la re s y las reacciones a los m e
d ica m e n to s o re striccio n e s. Las se n sib ilid a d es de !a
raza d e ben se r despiegadas en to d o s los d o c u m e n
to s a'e p e d id os y e sta cio n e s de trabajo, y d e ben e sta r
d isp o n ib les para se r revisadas p o r io d o s , p e rsonal de
a cica la m ie n to o ve te rin a rio s, a n te s de p ro p orcionar
los se rvicio s.
Entidad: Kmplcado
Definición: L'n em pleado es un trabajador al que la corporación McVet le paga salario o
por hora.
Atributos:
Tipo
N ú m ero de S CharOO) El n ú m e ro de em p le a d o asig n a do p o r el siste m a

e m pleado de nóm ina. (O bserve que aquí se usa un tip o de dato
co n co rd a n te con el siste m a de nóm ina.)
A p e llid o S Char(20í El a p e llid o dado por cl e m p le a d o para que aparezca
en to d o s los d o c u m e n to s in te rn o s y de nóm ina.
N o m b re S Chan¡20) El n o m b re dado por el e m p le a d o para q ue aparezca
en to d o s los d o c u m e n to s in te rn o s y de nom ina.
Inicial m edia N C h a rd í Una inicial m edia o pcional dada p o r el em p le a d o .
Prefijo N Char(3) El e m p le a d o p u ede e sp e cifica r o p c io n a lm e n te un p re
fijo para los saludos de co rre o d irecto . Lista = Sr„
Sra., Srita. y Dr.
Sufijo N Char(3) El n o m b re del e m p le a d o p u ede c o n te n e r un s u fijo tal
co m o Jr.r Sr., Ni.
Iniciales S Char(4) Una co n ca te n a ció n (hecha a m ano) de las iniciales del
e m p le a d o para q ue aparezca en d a to s de co lu m n a s
do nde el espacio está d e m a sia d o lim ita d o para d e s
plegar el n o m b re co m p le to .
Tipo de e m p le a d o S Char(7) indica el tip o de habilidades del em pleado. Los e m p le a
dos pueden estar listados co m o veterinarios, acicalado
res o personal de soporte. S o lam ente los veterinarios
pueden proporcionar servicios m édicos. Ei personal de
soporte no p u ede proporcionar ningún servicio al perro.
Lista = VETERINARIO, ACICALADOR, SOPORTE.
Entidad: JJedido
Definición: Un pedido representa una instancia de un cliente que solicita uno o más ser
vicios para un solo perro en un establecim iento McVet específico. El pedido
registra la techa, número de pedido y estado de la transacción y sirve como
encabezado para todos los conceptos de pedido.
A tributos:
Tipo
ID de c e d id o S lo k e n Un va lo r asignado por el siste m a para id e n tific a r en

fo rm a unívoca una instancia de pedido.
N ú m e ro de ped id o S Char(12) El núm ero de pedido se im prim e en los d ocum entos

y se despliega en la pantalla para ayudar a los e m
pleados y clie n te s a identificar rápidam ente el pedi
do. Es asignado por el sistem a cuando se crea el
pedido. Aunque es único, no es la PRIM ARY KEY pa
ra la tabla de pedidos. Es una concatenación del c ó
digo de e sta b le cim ie n to M cVet, una s e c je n c ia de
n úm eros y ios dos últim os dígitos del año de la fecha
del pedido. Ejem plo: 02-00123-98 representaría el pe
dido 123 colocado en el esta blecim ie n to #2 en 1998.
Fecha del p e d id o S ü a te La fecha en ¡a que se co locó el ped id o (DD,

M M ,A A A A ).
Estado del pedido S Char(10) Indica la co n d ició n do! ped id o c o n fo rm e pasa por el
procc-so d e e je cu ció n del pedido. Los e sta do s váli
d os son:
NUEVO: El e sta d o inicial dol ped id o indica que to
davía no se ha p ro p o rcio n a d o nin g ú n servicio.
EN PROCFSO: Se están realizando se rvicio s, pero

no se han te rm in a d o todos.
T E R M IN A D O : Todos los se rvicio s han sido m arca
d os c o m o te rm in a d o s y el perro está listo para que
lo recojan.
C AN C E LA D O : Se canceló el pe d id o co m p le to .
CER RADO : El perro ha sido re co g id o y el c lie n te ha

pagado en e fe ctivo o firm a d o para que se le cargue
a su cu e n ta en M cV et.
Peso del pe rro Integer Ei peso del perro en kilos es registrado en la báscula
en kilos y actualizado en el p e d id o in m e d ia ta m e n te d e s
pués de que se crea el pedido. SI la báscula falla
para reg istra r el o e so del perro, el usuario puede
te c le a r m a n u a lm e n te en el p e d id o el peso e s tim a
do del perro.
Naturaleza N o te Para v is ita s m éd ica s se le pide al c lie n te que

del problem a explique b re v e m e n te la naturaleza de las lesiones
o co n d ició n del perro.
c o n tin ú a
R ESPUESTAS A LOS EJERCICIOS 451
co n tin u a ció n
Tipo
IMombre Requerido de Dato Definición
M e d ic a c ió n N N ote Para visita s m ódicas se le pide al cliente que liste

actual cu a lq u ie r m e d ic a m e n to que e s té to m a n d o actual
m e n te el perro. M cV e t ha evaluado re c ie n te m e n te
esta política y de cid ió que ta m b ié n se le debe ha
c e r e sta p re g u n ta para las visita s de acica la m ien to .
in s tru c c io n e s N Note Indica cu a lq u ie r in stru cció n de m anejo especial pa
especíales ra e ste pedido.
Entidad: Concepto de pedido

Definición: U n concepto de pedido representa una petición para un tipo de servicio en ci
pedido. Cuando el pedido se crea por prim era vez, los clientes solicitan que
se realice nno o m ás servicios para el perro. Como los perros frecuentem en
te son adm itidos para una visita de oficina estándar para servicios veterina
rios, el veterinario puede insertar conceptos de pedido adicionales conform e
prescribe o adm inistra medicam entos o realiza procedim ientos adicionales.
Los cargos extras por raza también se añaden al pedido com o conceptos de
pedido cuando el cliente solícita tipos de servicio que requieren un cargo
adicional para la raza dcl perro (tales com o aplicar sham poo a mano a un
bull terrier.)
A tributos:
Tipo de
Nom bre Requerido Dato Definición
ID de co n c e p to S Token Un valor asignado p o r el siste m a para Id e n tifica r en

de ped id o fo rm a univoca una instancia de co n ce p to de pedido.
N ú m e ro de S In te g e r Indica el n ú m e ro de línea de co n ce p to del co n ce pto
c o n c e p to cíe pedido de pedido, para que los co n ce p to s se d e splieguen
en el m is m o orden en to d a s las ventanas y reportes.
E stado del S Char(1C) Indica la condición del co n ce p to de pedido co n form e
c o n c e o to de pedido pasa el ped id o por el p ro ce so de ejecución. Los es
ta d o s válid o s son:
NUEVO: El esta do inicial de un c o n c e p to de pedido

so licita d o p o r el clie n te indica que el se rvicio to d a
vía no ha sid o p ro porcionado.
EN PROCESO; Indica q ue el perro está a ctu a lm e n

te recibien d o el servicio.
T E R M IN A D O : Indica que el s e rvicio está te rm in a

do. Este p u ede ser el e sta d o inicial de co n ce p to s
añadidos por el ve te rin a rio al ped id o del perro d e s
pués de que han sid o pro p o rcio n ad o s.
c o n t in ú a
452 Apéndice / CASO DE ESTUDIO McVET
Tipo de
Nom bre Requerido Dato Definición
C AN C E LA D O : Indica q ue el tipo de se rvicio no se

aplicó in te n c io n a lm e n te por M cVet.
O rigen Char(S) Indica si el c o n c e p to de p e d id o fue so licita d o por el

clie n te , p re scrito por el v e te rin a rio o in se rta d o por
el siste m a , c o m o es el caso para los cargos extras
por raza. Lista - CLIENTE, VET SIS TE M A .
Precio u n itario M oney El p recio u n ita rio os cl p rccio u n ita rio del fip o de
s e rvicio al m o m e n to en que fu e crea d o e! co n ce p to
de pedido. Un p recio u n ita rio d e b e e sta r aco m p a
ñado p o r un valor de base de precio.
Base de precio Char(4) Índica la unidad de m ed id a para el p re cio unitario.

Los cargos en M c V c t son una tasa única, por hora
o por peso. La base de pre cio se req u ie re cu ando
el p rccio u n ita rio es añadido al c o n c e p to de pedido.
Lista = UNI, /H R , /KG.
Cantidad D ecim al El ca m p o de cantidad se usa para reg istra r la

(5,2) cantidad de un id a de s cargadas por el c o n c e p to de
pedido. Para ca rg o s de tasa única ía cantidad es,
por lo general, 1. Para cargos por hora la cantidad
es la cantidad de horas ajustada al cuarto de hora
m ás cercano d u ra n te el cual el s e rvicio fu e realiza
do. Para les ca rg o s por kilos el ca m p o de cantidad
refleja el p e so del perro a ju sta d o al kilo m ás cerca
no. A lgunas ca n tid ad e s no p u e de n se r d e te rm in a
das sin o hasta q ue se realiza el se rvicio .
Entidad: Tipo de servicio

Definición: La lista de tipos de servicios representa a todos los servicios, tanto médicos
com o de ac ical amiento, que son proporcionados por McVet. Los servicios
pueden ser retirados desactivándolos o volviéndolos a activar.
Atributos:
Tipo
ID de tip o Id e ntifica d o r Un va lo r asignado p o r el s iste m a para id e n tific a r cn

de s e rvicio fo rm a unívoca una in stancia de tip o de se rvicio .
N o m bre de Char(2ü) La descripción oficial corta por la cual se hace

tip o de servicio referencia al se rvicio en ventanas y reportes d e n tro
de McVet.
D e scrip ció n N o te La narración proporcionada por el d e p a rta m e n to

de m e rc a d o te c n ia d e m erca d o tecn ia para d e scrib ir a m p lia m e n te al
se rvicio . Puede ser usada en fo lle to s y catálogos
p ro m o cio n a les.
c o n t in ú a
Tipo
Clase de tipo S Char(IO) Indica si el tip o de s e rvicio está clasificado c o m o

de s e rv e io v e te rin a rio o de cuidados. Lista = VETERINARIO ,
AC IC A LAD O . "
M esa de in te rva lo N In te ge r La cantidad de m ese s d e sp u é s de la ú ltim a vez
de se rv ic io so licita d a en la q ue d e b e se-' re p e tid o el tip o de
servicio. Este n ú m e ro se usa para gene-ar recor
datorios.
In stru ccio n e s N Note Un ca m p o de te x to en d o nde pueden darse notas
especiales de p ro c e d im ie n to s , p re ca u cio n e s o avisos.
A ctivo S Yes/No Indica si el s e rvicio e stá a ctu a lm e n te d isp onible
para ve ^ ta en to d o s los e s ta b le c im ie n to s M cVet.
Entidad: Precio del servicio

D efinición: El precio del servido establece el precio unitario y la base de precio para
un tipo de servicio específico. Cada tipo de s e r a d o puede tener solamente un
preeio activo a la vez. I ,os rangos de fechas de vigencia de precios no pueden
traslaparse para un tipo de servicio. La fecha de expiración es opcional, lo que
.significa que, si no se ha dado, el precio es vigente hasta nuevo aviso.
A tributos:
Tipo
ID de p re cio S token Un v a lo ' asignado por el siste m a para id e n tifica r

del s e rvicio u n ívoca m e n te una in stancia de p recio de se rvicio .
Fecha de vigencia S D ate L.a fecha en ¡a cuaí eí p re cio del s e rvicio es vig e n te .
Focha de expiración N D ate La fecha en que expira el p re cio del se rv'cio . Los
p re cio s sin fecha de expiración pe rm a n e cerá n vi
g e n te s hasta q ue se dé y alcance una fecha de te r
m inación.
Precio u n ita rio M oney TI pre cio u n ita rio es eí p re cio u n ita rio al m e n u d e o
de tip o de se rvicio , co m e n za n d o en la fecha de ¡ni-
c o y te rm in a n d o en la fecha de expiración e s ta b le
cida en cl re g istro de p recio del se rvicio .
Base de orecio Char(4) Indica la unidad de m ed id a paâ el p recio un ita rio .
Los cargos en M cV e t son una tasa única, p o r hora
o por peso. La base de pre cio se req u ie re cuando
el pre cio u n ita rio es añadido al c o n c e p to de p edido.
454 Apéndice / CASO DE ESTUDIO McVET
Entidad: Cargo extra por raza

D efinición: Un cargo extra por raza es un costo adicional que se suma al precio de un ti
po de servido cuando el tipo de servicio se aplica a una raza específica. Los
cargos extras son independientes del precio del servicio. Tienen su propio ran
go de fecha de inicio y unidad de medida. Los cargos extras se suman para
razas particularm ente grandes, difíciles o bravas.
Atributos;
Tipo
ID de carao S Token Un valer asig n a do por el s iste m a para id e n tifica r

extra oor raza cr, fo rm a unívoca una instancia de cargos e x tras
por raza.
Fecha de vigencia s Date La fecha a p a rtir de la cual es vig e n te ei cargo exira

por raza.
Techa de expiración N Date La fecha en q ue expira el cargo extra por raza. Los
precios sin fecha de expiración p e rm a n e cerá n vi
g e n te s hasta q ue se dé y alcance una fecha de te r
m inación.
Precio u n itario S M oney El p recio u n ita rio es el p recio al m e n u d e o del cargo

extra por raza, co m e n za n d o en la fecha v 'g e n te y
te rm in a n d o en la fecha de expiración establecida
en el re g istro de p recio de se rvicio .
Base de precio S Char(4) indica la unidad de m ed id a para el pre cio unitario.

Los cargos en M cVet son una ta sa única, por hora
o por pese. La base de pre cio se req u ie ro cuando
el pre cio u n ita rio es añadido ai c o n c e p to de pedido.
Respuestas al ejercicio 6 —Prototipo de interfaz
(5.1 Los usuarios del sistema en las ubicaciones de McVet tienen tareas específicas, tales co
mo recepción, acicalamiento, veterinaria y contabilidad. Un primer paso lógico para la or
ganización de la lista de eventos podría ser el agrupar los eventos por tem a (o más
precisam ente, por el transportador futuro). Los eventos del recepcionista podrían incluir
todas las permutaciones posibles de cliente coloca pedido p ara perro, los evenios que ro
dean la realización de citas para cirugía, el peso del perro, la entrega del perro y la acep
tación de pagos en el punto de venta para el pedido. La idea es considerar el dar al
recepcionista todo lo que podría requerir en un solo lugar en el sistema agregando todos
los eventos dei recepcionista cerca unos de otros dentro de la interfaz. Luego los eventos
podrían agruparse por objeto para ver cuáles eventos afectan a los clientes, perros, pedi
dos de reservación y tipos de servicios. Kste mismo proceso podría ser repetido para los
veterinarios y acicaladores, dándoles a cada uno de ellos un área de trabajo personalizada
dentro de la aplicación (¿tal vez su propio mareo MDI?) en donde puedan ejecutar todas
las tareas de las que son responsables sin tener que navegar por toda la aplicación.
Otro ejercicio útil pudría ser el ordenar la lista de eventos com pleta por objeto para ver
cuáles funciones comunes, tal com o la búsqueda de pedidos, podrían requerirse a través
de todo el sistema. La organización cronológica de eventos de procesam iento de pedido
también podría ser útil, exam inando si una colocación de izquierda a derecha o de arri
ba hacia abajo de estas funciones en el menú principal o en una barra de herram ientas
podría hacer que la interfaz fuera más intuitiva para los usuarios.
6.2 Para crcar ct prim er prototipo, Pendergast abrió su modelo de inform ación, lisiado de
atributos y diccionario de eventos para el evento de recepción de clientes. Luego hizo al
gunas suposiciones acerca del nivel de habilidad del usuario. Recordó que aunque Wan
da tenía mucho entrenam iento, M arge dijo que los nuevos establecim ientos estarían
buscando cl reclutar em pleados con menos experiencia. Hsto llevó a Pen a suponer que
todos los com andos, datos e instrucciones de la interfaz tendrían que estar claram ente es
pecificados y que h fa c ilid a d de entrenam iento es un vector de calidad principal. Tam
bién recordó que uno de los objetivos fue reducir significativam ente el tiem po de
registro, por lo que el ahorro de tecleo tam bién es un vector de calidad principal, uno que
a veces puede estar contrapuesto a la fa cilid a d de entrenamiento.
Luego continuó para identificar las diversas ventanas necesarias para recibir un perro. Ll
sistem a necesitaría una forma para seleccionar entre una lista de clientes y perros exis
tentes, capturar o actualizar inform ación acerca de un cliente y sus perros, capturar el
nuevo pedido y sus conceptos de pedido, seleccionar entre una lista de tipos de servicio
y posiblem ente buscar un pedido anterior de un cliente y copiarlo. Dejando para más lar
de todos los asuntos navegación al es, hizo un bosquejo de algunas presentaciones de las
ventanas que había identificado.
La prim era ventana que trazó Pendergast fue la de perfil de cliente, en la que se m antie
ne inform ación básica acerca de un cliente y sus perros. La ventana es capaz de crear o
actualizar a un cliente y varios perros para ese cliente. La inform ación de cliente se
m uestra en la parte superior de la ventana y la de los perros en la parte inferior. La lista
despíazable de los perros en la parte inferior está sincronizada con los detalles sobre los
perros de la parte inferior derecha, en tal forma que cualquier perro que tenga el enfoque
se despliegue en el área de detalle (figura A -10).
La siguiente ventana que trazó Pendergast fue la ventana de captura de pedido, en la cual
el reccpcionista capturará los detalles de un pedido después de que hayan sido identifi
cados y verificados el cliente y cl perro.
Después de haber term inado con las dos ventanas de m antenim iento, Pen pasó a las ven
tanas de selección. Creó la ventana selección de tipo de servicia para dar al recepcionis-
ta una lista de tipos de servicio activos a partir de la cual pudieran seleccionarse uno o
más tipos de servicios para crear nuevos conceptos de pedido (figura A-12), Los usua
rios dijeron que les gustaría que tam bién estuvieran desplegados los precios actuales en
la ventana de selección. Pendergast identificó inm ediatam ente esto com o un asunto de
desem peño potencial que tendría que ser atacado en cl diseño. En el modelo lógico el
prccio más actual es derivable a partir tic la entidad precio de servicio, com parando la
fecha actual con las fechas de vigencia y de expiración para cada tipo de servicio. Ln el
diseño final necesitarla im aginar una form a para desplegar rápidam ente todos los tipos
de servicio, junto con sus precios más actuales. M entalm ente consideró sus opciones, po
dría guardar cl prccio más actual cn la base de datos con el tipo de servicio y actualizar-
lo por m edio di; procedim ientos almacenados cada vez que cam biaran los precios del ser
vicio. Podría alm acenar en la caché el contenido de la ventana selección de precio de ser
vicio Idealmente en cl cliente para que la ventana no tuviera que accesar la base de datos
cada vez que fuera abierta. H izo una nota para com entarlo con las personas de m ercado
tecnia y saber qué tan frecuentem ente cam bian los precios y si alguna vez han iniciado
un cam bio de precio que entre en vigor durante cl mismo día laborable.
£ é rfil de! ciierrte
Prefijo: Nombre IM : A p e llid o : Sufijo: Número de cliente:
n i
D irección:
Teléfono en el día:
C iu d a d : E stad o : CP: Teléfon o en la tard e:

n:
Perros: - Detalles del perro:------
Seleccionar nombre: Nombre: Sexo: Peso:
"[Ti H /Castrado?; Kfls
Raza: Nacimiento
Alergias: □ ¿ M u e rto ?
Figura A-10. La disposición de ventana perfil de cliente.
McVet ya ha acordado que podría em itir tarjetas de ID (identificación) a clientes para que
pudieran recuperar sus registros para una recepción rápida. Pendergast imaginó el paso de
una tarjeta a través de un lector m agnético para recuperar el perfil de cliente o tal v e/ un
escáner de código de barras. Pen también necesitó una form a para localizar a un cliente o
a su perro en la base de datos cuando el cliente no proporcionara su tarjeta o cuando el
cliente no estuviera seguro bajo qué nom bre se registró al perro. La ventana también po
dría usarse para m over un registro de perro de un cliente a otro. Concibió una ventana se
lección de cliente que perm itiera que los usuarios teclearan una cadena de caracteres de
nom bre parcial para el apellido del cliente, una cadena parcial si recordaban parte del nú
m ero de cliente o posiblem ente una cadena parcial para recuperar por medio del nom bre
del perro (figura A -13). También añadió la raza al criterio de selección para ayudar a h a
cer más estrecha la búsqueda. E l conjunto de resultados en el cuerpo de la ventana podría
m ostrar en ía parte superior todos los registros que satisficieran el criterio de selección.
Debido a que los clientes pueden tener más de un perro, los renglones subsecuentes del
m ismo cliente podrían suprim ir los valores repetidos. Pendergast estaba contento con la
flexibilidad que proporciona esta ventana, pero hizo otra anotación sobre un problem a de
desempeño potencial, ya que tendría que poner a su m ejor experto en SQL a trabajar so
bre esta ventana para asegurar que fuera recuperada en un tiempo aceptable.
C aptura d o podido - [Núnii-ra dt> p edido E stad o d e pedido]
Nom bre del cliente: Número de diente Fecha de pedido:
Nombre del perro Sexo: Peso: Re¿a: a ¿Qk para Perro feliz?
I .■ " ■ ' I Q [3 ¿Castrado? | ¡ Kgs [ ■ -
Naturaleza del problem a Medicamentos actuales:
Instrucciones especiales
—Elementos de pedido:------------------------------ ------------------ .________

Orí- Precio Precio Cantidad
Tipo de servicio en linea: gen unitario: de base: Cantidad: a pagar:
*
i?
■ :■ : IS
Iva:
Total:
F ig u ra A - l l . La. disposición de la ventana de captura de pedido.
S elecc ió n d e tip o d e se rv icio
• Todos o Sólo cuidados o Sólo veterinario

Precio .
Mombre del tipo de servicio unitario . ®cl°
actual de baSH
A
w
ir
Figura A-12. L a d isposición de la ventana de selección de tipo de servicio.

F ig u ra A -13, La disposición de la ventana de selección de cliente.
Selección del pedido

Número
Estado del pedido Fecha del pedido > = de pedido: Establecimiento:
r ~ 'w \ i i n i ía
Figura A-14. La disposición de ía ventana de selección de pedido

La últim a ventana que dibujó Pendergast fue la ventana selección de pedido. El recep-
cionista necesita una form a para desplegar los pedidos que están siendo atendidos actual
m ente en cl establecim iento de McVet. E l sistema tam bién tiene especificado que debe
recuperar el historial de pedidos del cliente y perm itir que el recepcionista copie un p e
dido, ya sea que el pedido haya sucedido en ese establecim iento McVet o en cualquier
otro. Pen pensó que podía im aginar una ventana que fuera capaz de recuperar todos los
pedidos pendientes en el establecim iento o investigar el historial de pedidos para un
cliente dado si la ventana fuera abierta para un registro de cliente. Pen acabó con la dis
posición de la ventana de la figura A -14 y program ó una reunión con los usuarios para
que revisaran su trabajo.
Respuestas al ejercicio 7 —Modelo arquitectónico
7.1 La figura A -15 m uestra una matriz de evento/ubicación del negocio para cl proyecto M c
Vet. A lgunos de los eventos a nivel negocio de la lista de eventos han sido consolidados
en eventos a nivel conceptual para m antener el diagram a simple.
7.2 Para hacer un buen trabajo de modelado arquitectónico para McVet se necesitaría saber
la cantidad actual y futura proyectada de pedidos colocados por día en cada estableci
m iento, incluyendo volúm enes de tráfico promedio y pico. También se necesitaría deter
minar la cantidad estim ada de clientes que pagan en efectivo o lo cargan a su cuenta y
los perros que pueden ser clientes de McVet conform e se satura el mercado. La com pa
ñía necesitaría determ inar algún ciclo razonable para el archivado de pedidos viejos,
clientes inactivos y perros que estadísticam ente caen m ás allá de su esperanza de vida.
M cVct también debe proporcionar una estim ación razonable de su crecim iento futuro
potencial. Cada nuevo establecim iento añadirá problem as adicionales a la infraestructu
ra de la inform ación. Estas estadísticas, junto con las estimaciones de tam año en bytes
que se puedan recolectar del m odelo de inform ación pueden dar una buena idea de los
requerim ientos de capacidad de disco para cada establecim iento y para la oficina central.
Luego puede ser m odelada la cantidad de tráfico de red entre los establecim ientos y las
oficinas centrales para varios esquem as de distribución.
7.3 McVet tiene un problem a clásico de necesitar que una gran cantidad de sus datos estén
cn todos lados a la vez. Revisem os las diferentes opciones sobre dónde ubicar los datos
de McVet:
C e n traliza ció n : McVet podría m antener una copia m aestra de la base de datos en una
ubicación central. Para eso, la aplicación podría ser m uy centralizada en un servidor cen
tral muy poderoso. 1,a ventaja es que todos los datos están ubicados cn un lugar y siem
pre son actuales. La desventaja es que cl sistem a com pleto está a merced de una red de
área am plía. Si es muy, muy rápida, no hay gran problem a, a menos que, por supuesto,
la red de área am plia se caiga. Si esto sucede, los establecim ientos de M cVet quedan sin
sistem a de com putadora hasta que se restaure la com unicación eon el host central.
8
1
1
Oficinas centrales
establecimientos
Ubicaciones de
¡jí*
1
Evento/ubicación de negocio
Ei cliente coloca pedido X

í
El cliente solicita cita para cirugía
El acicalador reporta term inación deE servicio
X
X
1
&
El veterinario reporta term inación del servicio X

El diente recoge al perro X
Es tiem po para facturar a clientes con cuenta de crédito X
Cliente paga factura X
El empleado hace ei corte de caja X

Es tiem po de registrar la actividad en la contabilidad general X
i
El usuario solicita reportes de ventas
Mercadotecnia actualiza precios,'servicios
X X
X
S
Mercadotecnia crea envíos por correo directo X X
!
El inventario cae por abajo del punto de reorden X
I
McVet recibe abastecimientos de inventario
El usuario solicita saldo de inventar'o
X
X X
8
El cliente cambia datos del perro/cliente X X
¡
Figura A-15. U n a m atriz: d e e v e n to /u b ic a c ió n d e n e g o c io s pava M cV et.
Datos descentralizados replicados: Cada establecimiento de M cVet podría tener una co
pia com pleta del esquem a de base de datos en su propio servidor de datos. El esquema de
replicación va desde que cada establecimiento tenga cada uno de los registros a estable
cimientos que sólo tengan los registros que se haii creado en ese establecimiento (frag
m entación horizontal). La ventaja de la replicación de todos los registros es que cada
establecimiento puede investigar el historial de un perro en McVet, sin tener que consul
tar a ningún servidor de otras ubicaciones. I .a desventaja es un tráfico incrementado en la
red de área am plia para m antener a todos los sitios en sincronía. U n esquem a de fragm en
tación horizontal en donde cada establecimiento conserva una copia de solamente sus
clientes, perros y pedidos que han visitado ese establecimiento reduce el tráfico de red en
tre establecimientos, pero incrementa la com plejidad de la aplicación debido a que, si un
cliente, perro o pedido no se encuentra en un establecimiento, ia aplicación debe buscar
por el sistema, ya sea en la base de dalos de la em presa o en los demás establecimientos,
para encontrarlo. Hay ventajas significativas en que los establecimientos tengan su propia
copia com pleta de la base de datos. Están com pletam ente protegidos ante fallas de siste-
raa si la base de datos central, la red de área am plia o el sistem a de otro establecimiento
se cae. También tienen mejor desempeño debido a que el acceso a los datos es local al si
tio. La desventaja se tiene en cl manejo del esquem a de replieación. Los datos pueden ser
sincronizados en tiempo real o periódicam ente. En un ambiente replicado siempre se
corre el riesgo de que un registro sea actualizado en dos lugares antes de que sean sincro
nizados y se debe decidir cuál actualización “gana".
Para McVet, Pendergast se inclinó por un esquem a de base de datos com pletam ente re
plicado en donde cada sitio tenga una copia com pleta. La base de datos será sincroniza
da periódicam ente, posiblem ente en la noche. La ventaja abrum adora sería la autonom ía
para cada establecim iento si falla cualquier pane de la red de área am plia. La desventa
ja sería el riesgo de que un cliente visitara otro establecim iento antes de que los datos lo
hicieran.
Respuestas al ejercicio 8 —Diseño de la base de datos
8 .1 El siguiente esquem a dcl diseño de la base de datos fue derivado dcl modelo de inform a
ción dcl ejercicio 5. Está escrito en tina forma que no depende de los dialectos. La herra
m ienta de base de datos particular que use puede diferir ligeram ente en sintaxis, tipos de
dato y lim itación del tamaño del nom bre de las tablas v columnas.
”r o 5.l c:L a \ >ie U b i c ac i ó n M c V e t {

Cód ub i c.oí: ' ón r (2 ) >JO" PiUMARY 'ZrW,
Kos-.hr^. _c.e_ubi c:.. cj.-: C har : .!■S ) NO':
T ip c _ d c. u;;.; í:^;; i c r C::ür:£>;
~ J n y_n lLii'.í?r o . ..d<?. z,e c u vr.c i a id : NC. tCUT,",; ;
Crcj-i'ê Lah_0 C l i e n t e
Ou s t. c-r.er _Kumb rj r C h a r(B ) NULL P7^ I MAKY KEY ,
Ape M i d e Cha r" í 2 0 ) :vú~ Kl; I,!,,
f'.'cT.h re Cr.ar : 2 j ) n c : K'JLI.-,
! r:--.cia__r:^c] : c'j
Fr í.: f i j o
Su::: j o
i; : re¡:: c i c r va.rc:f':¡j i ^
"iUL'Iad C har ( 3 0) ,
C.’1: a r. i2) f
Cediere co s !. C!:ar ; ID) ,
T-e ;éiü:io_í?r__o:_;v: :i "h a r [1 } ,
To'-ó: cr: '.a -¿i^de
í!ros:.Ci Lab", e R a z a (
'.^_ác_rs.z a Tcksri NT7T.T. I-KIMAKY KEY,
XotiI'j r 9._á e _ 1i-_ríj. z a CJriar f 3 0 ) KL'LL r
C 'ündidazo_pa.ra_.?orr _'- e : 1 7. NO- MUI ,L,
S o r. y . v i ' : da.de n No Le ) ;
Crc "r'ible P e r r o (
1 D_ d e _p e-r r o o k cn KOT :J? !Y A R Y K.Jl Y ,
Nrjni: r e d em perró C.' :\a r f 2 C i NOT NT7V.I,,
'J : “Í .T l O _ p O O C: t) k i O S i II L Cl ü <ir ,
” ftí'::i:'i ds-r : : ¿¿c i x i L - n t o TJc í L h ,
.->ex o Chur ; ! NCT KULL,

Cí¡3 :'.r(5f;n_o_enter: l i z a d a Yes/Ncj NCT KL'LL,
A', e rg i ;=s K o le ,
M:,c:r;.0 ' Yey/Nc NOT NULL,
'-Júnior o de c ^ ie iiL e c ^ í- í b ; KOT MüLL t'OHLiGM KKY
Ha c e r e f e r e r c iu s u o". i enl.-H ¡jú.T :C ro_¿c_ciie:iT .e}
Tn eo r= Z a Token KOT .N'JLL fOHLiGM KEY
H.ic-o í c l G r o r c i ' a r a z a O'"). de -axal j ;
C r e ía te “ a d i é Empleado i
K¿-'fiero ,.¿e_c-T.p^ ea do C hu'■ í 10 ) KOT Küj_._ i'RLKAKY KKY,
Apc I I "I e.e C’r.cr í /. 0 j NO'i1 KLLL,
Ko^ndr e Ch .:ir (2 j ) KOT KL'LL ,
L nic ia_ _ '"i.ed ; ;¡ C har ; 1) ,
P re fije C har ¡3) ,
;ru =i ; e Ch,ir-;]! ,
L n ic iaie u C har ¡ 4 ) MCI' KL'LL ,
T: p o _ d e _ e r p I e;;dn Char i7 ¡ MOL MULL):
Create '¿ubis Tipo de.servicio '

LE _ d e _ t ip o _ d e_s-s rv - c i o T oken MCL NULL I^JK : r-Âsiv :<?,y ,
Müi:iiji'=_áe '.I p o do s e r v i c i e Chur ¡30 ¡ KOT MUT.T.,
Di!K;:ripi'.,i 6 n _ ¿ ü _ n o r c a d o r e c r n a No Lo KOT NULL,
C I j se_cie_..ti p e de. s e r v i c i e C h a r i l ü ! NOT NU7.L,
Meces de .! n l . e r v a l o _ d e _ 5 c r v i e i o T rd.eye r,
Tri s L r' u e c i e r_e íi _ e eí pe c i a i e s K a i e ,
A ctiv e Y es/K o KOT N'JLL) ;
C re ía te tai;L e P e d id o !
TT;_de_ped' do Token kot k l l l 1■K: MARY KÍ'IY ,
Kúnit? ro _ d e _ p e d : de C har (12) NOT NU.:.,
Pecha.. df>'. p e d í de D a te MOT KUT.T,,
Kb :.ado_ d e '.. p e d i d o C h ar¡lü i n c t tct;tT:,
Pe fio do". .._ p e rre _ o ::_ k ilo í; in le n e r ,
N¿i :. u r a i o z a _ d c l _ p r o b I erra K"-;; Le ,
M e a i c a c i ó : : _ a c nua 1 Kol.o ,
Ir_í= “ ru.ee i c z\eB_etJpec : íil e t; Ko'..o,
Múr.cro de c l :en:.e Char ¡E ? l'ORTTGK KEY
Mace r e f e r e n c i a a c l i e n t e ¡KÚTiCro_de_c '. I en ',.e ) ,
Cód I yo...de_nbieacicr:. C'r.nr-i?.) NOT M"JLL FOIiiiGN KhlY
lio c e r e f li r e n e i a a u.picació::. XcVe ¡Cedí ge . de..j:i ■ieaCLÓii i ,
TD cíe...perro 'Token KOT NJLL KORY.l G'J KKY
Hace r e t e r e n t i ü a ¡;-arr;j í TD de . p e r r o ) ,
'i'o:iiaaO_pOr- C har !. 1C; KOT ÑUTI. FORLi;]N KEY
H;ioe r e f e r e r . o i a a crf.pleadc ¡Njmer'C de.eif.plea.de;
C.r;:;j :..c i.a P ie C o n c e p t o _ d e _ p e d i d o (

I D _ d o _ c e n c e p ;.c _ d e _ p e d I do Ti¡l<es KOI' K'JL.'. PRIMARY XZY,
Nú~ e r c _ c e _ c o n cayl. o_d e p ed i d o Tni.ec e r MCI KL'LL,
E s ta d c_": e _ c o" c e p t.o de iie d id o C:: a i" v I 0 NGT KULL,
O rujs-' C har ; H) MT¡T KULL,
i'-ve;: I _¡.n_ La r i o ypriey ,
B a n e_ ¿ e_ p recio C har ¡4) ,
C'a:H. i c3;ir: ¡)ecir.al ¡5 ,2 ) ,

TD. do p o d id o Tyke:: NOT XUT.T TOKUTGK 5CFY
Paco ' o r e reno : ¿¡ a p e d i d o T e_ p s d i do ¡- ,
IE de l. i p c _ d e ._ s e r v ie : o Toke’i NOT KX'TJ. PO.RZIGK XFY
ha.ee r o í e i ;j y Tipo do so r'v i :.: i o : .LJ_de_:.ipo de s e r v i c i o ; ,
[’ra p c rc io r.d ín _ r ;:) r Char ( 'i C,j PÜKPTGN K7,Y
Ha;:o r e r e r e r c i ¿¿ ü. en;:_tí 3 no (K'.!ÍT.ero_do_.cn,. p.;oaoa! ,
;JKZC:;; ÍTT: t3«_j5edMo,h';i:Ticro do_ooncepto_de...pod:d;.); ¡ ;
Creado r.ai;'. ií P r e e i o _ d e _ s e r v í c i ó (
*D_P ro cié ; d e s e r v i c i o T;i k o: ¡ 'JO'" M77,1, ;;H_MAtí Y XI7Y,
Peería. do e f e c t i v i d a d lla’..e NOT KLT,t,,
Pec.~_a_e!c:_c:xr;± r .:1 ■:: i ó:: Da:.e ,
P r e c \ o _ u : i i ’:a rie ; Kcnoy KO'I.' NL;_L,
Tí c s e _ d e _ p r c o i o Cr_ar ¡ 4 ) KC'l' .NLiLl-,
!T'_de_Tipo de:._M!:.rv i c i ó Toi-ioi: NOT NNI,T PCKPiGN KZY
Paco r c t o r o ' i i a ;■ Ti p c _ dc _ :íorv ; o ■.;; i".D_do_t ip o _ d e serv-¡ c i c j : ;
C -eale ' Cargo e x t r a p o r r a z a ¡

1 i: de. .c3rgo_oxT.ra_r;;-;-r r;¡ 7.u Tckcn KOT Ni:;.L ?IÍTMARY KklY ,
Pcc:ia_de_efoo:, i v i dad UaTe [\Cr NUIL,
Voo'r'ia ...de_exp i r a c i ó n üare,
P roc ic._.i.n :. I.í; r i o Kejne y KOT Nj T.7,,
Base d(í_precxO C'r.ar i 4; MGT Njt.T,,
13_ele:_v i cjti de e r v i c i ó Tc)ke?r: NOT NN7,T r'OKHTGN KTY'
P ace r o í o r iú a. Tipc_.do.. Se rv ; Cic ¡iD_cic. t i p o de_f:,ervi c i c ) ,
TD_GO_raza Toser: MOT XULL “ OKrTGK JÍEY
Küce r e ío r c n c .L a u r a z a ¡ ID_áo . r az a ! ; ;
8,2 Hay varias modificaciones adicionales que quedan pendientes en nuestro diseño de base
de datos antes de que quede terminado. Los requerim ientos del sistema debido al esque
ma de replicación de datos seleccionado o a las necesidades de auditoría pueden añadir
fech a y hora de la última actualización a cada tabla. Si se escoge un esquem a de fragm en
tación horizontal puede ser que cada renglón tenga que incluir una clave externa hacia su
ubicación. McVet “o rig in a r. También Pendergast todavía está preocupado con el desem
peño de tener que calcular el precio actual para cada tipo de servicio, listá considerando
seriamente la adición de los precios unitarios más actuales y la base de precio a la tabla
tipo de servicio, una ligera des normalización que tendrá que ser m antenida por medio de
procedimientos almacenados cada vez que cambie un precio de servicio. liste cambio
de la deícrininación de precios actuales de la acción de lectura a las acciones de inserción,
actualización y borrado es un com prom iso seguro en McVet, debido a que los precios so
lamente cambian unas cuantas veces por año, pero son leídos muchas veces al día.
Respuestas al ejercicio 9 —Diseño de la interfaz externa
9,1 Pendergast reunió a su equipo de diseño para discutir la disposición general de la aplica
ción. D ecidieron que McVet tenía una división de tareas muy particular, por la que una
división organizacional podría funcionar muy bien para el sistema. D ecidieron agrupar
eventos para cada papel de usuario y crear marcos MD1 separados para cada sección de
k aplicación. D e esa forma los recepcionistas tendrían todo al alcance de sus m anos den
tro de un solo m arco M DI, los ve (.crin itrios tendrían todas sus ventanas en su propio m ar
co M D I y los em pleados de acicalam iento tendrían su propio mareo para sus ventanas.
La. navegación en cada m arco estará optim izada para ayudar a los usuarios a lograr sus
tareas únicas. La m ism a ventana podría aparecer en m uchos marcos, tal com o selección
de pedido, y los usuarios podrían abrir m arcos diferentes del propio, siempre y cuando
tuvieran la autorización para hacerlo. P or ejemplo, el veterinario quizá quiera abrir la
aplicación de inventario o la aplicación de recepción. E l tener m areos separados para
áreas organizaeionales distintas del sistem a ayudaría a controlar la confusión que pueda
darse cuando cl usuario tiene muchas ventanas abiertas. L a aplicación de inventario po
dría estar abierta al mismo tiem po que la aplicación de recepción, pero las ventanas de
inventario no podrían estar entrelazadas con las ventanas de recepción, debido a que es
tán en marcos M D I separados. Eí equipo también estuvo de acuerdo en que el usuario
sólo debe ser capaz de abrir una instancia de cada tipo de m arco M D I a la vez.
El equipo de diseño dibujó un menú principal con grandes botones oprim ibles con im á
genes (figura A-16). Cada botón abre una de seis aplicaciones separadas dentro del sis
tema de McVet.
rI V Í ¿ : V Í B l ; ; ■ - " "
Figura A-16. H1 m e n ú principal de McVet.
Luego com enzaron a trabajar sobre la navegación dentro del m arco MDI recepción (fi
gura A -17). Su prim era suposición fue que el recepcionista probablem ente m antendría
abierto el m areo MDI recepción durante el tum o com pleto. Para el evento el cliente co
loca pedido para perro decidieron que el objetivo principal era hacer que el recepcio
nista tuviera la ventana de perfil de cliente lo m ás rápidam ente posible para verificar la
dirección actual, núm eros telefónicos y detalles del perro del cliente antes de colocar el
pedidü. Tuvieron dos formas de hacer esto. Si un cliente se presenta con una tarjeta de
.110 de McVet que perm ite que el sistem a identifique electrónicam ente al registro del
cliente y el perro, el sistem a podría abrir la ventana p erfil de cliente tan pronto com o se
leyera la tarjeta. Si el cliente no tiene una tarjeta de identiíleación rápida, cl recepcio-

nista deberá preguntarle si ya ha visitado algún establecim iento de McVet alguna vez.
Si no lo ha hecho, cl recepción isla deberá tener la posibilidad de abrir la ventana p erfil
de cliente directam ente desde selección de cliente y establecer un nuevo cliente. Sí el
cliente ya ha estado en un M cVet anteriorm ente, o no está seguro, el recepcionista h a
ce una búsqueda para cl cliente y/o el perro en la ventana de selección de cliente, en
cuentra los registros de clientes, hace clic en ellos y continúa hacia la ventana p erfil de
cliente.
F ig u ra A -17. D iagram a de navegación de ventanas para la ventana de registro dentro

(leí marco MDI recepción.
W anda le dijo al equipo que, com o reccpcionista, tam bién quisiera que la ventana selec
ción de pedido estuviera abierta todo el tiempo para que pudiera llevar cuenta de cuáles
pedidos se están procesando en el establecim iento en ese día, Bs en esta ventana desde
donde el recepcionista abriría un pedido term inado para realizar las (unciones de entre
ga, abrir un historial de cliente para copiarlo o revisar el estado de un pedido si un clien
te pregunta por él o llega antes de tiem po a recoger a su perro.
D esde ia ventana captura de pedido el usuario sería capaz de abrir la ventana perfil de
cliente del cliente, y desde cualquier perfil de cítente el usuario deberá ser capaz de abrir
la ventana captura de pedido para ver el pedido más reciente del cliente, colocar un nue
vo pedido o abrir una lista de la historia de pedidos del cliente en McVet en la ventana
selección de pedido. E l perfil de d ie n te tiene su propio com ando Guardar que graba los
cambios hechos al registro de cliente y los registros de perro asociados. La ventana cap
tura de pedido tiene un com ando Guardar separado que graba los cam bios al pedido y
sus conceptos de pedido asociados.
Cuando el recepcionista coloque un nuevo pedido en la ventana captura de pedido se po
drá abrir la ventana selección de tipo de servicio y el usuario podrá seleccionar uno o más
tipos de servicio y hacer clic en OK. Cuando se cierre la ventana selección de tipo de ser
vicio se crea un concepto de pedido para cada tipo de servicio seleccionado, Pendergast
también consideró hacer que la ventana selección de tipo de servicio fuera una hoja MDI,
m anteniéndola siem pre abierta y perm itiendo que el recepcionista arrastrara y soltara ti
pos de servicio en la sección de concepto de pedido de la ventana. Por ahora decidió d e
ja rla com o una ventana de respuesta, debido a que la interfaz ya se está haciendo lo
suficientem ente com pleja tal com o está.
9.2 Pendergast y su equipo de diseño tienen ahora la navegación, tipo de ventana y unidad
de trabajo elaborado para las ventanas de recepción. Después de que revisaron su traba
jo, term inaron la especificación de diseño extem o. Una vez que la especificación fue re
visada por los usuarios y el equipo de diseño, quedó lista para pasársela al equipo de
desarrollo y al grupo de aseguram iento de calidad para la codificación y preparación de
los planes de prueba.
Nota: He tratado de m antener independiente el lenguaje de las respuestas, sin embargo
la especificación de diseño de interfaz exlem a favorece una im plementación Windows.
También he incluido el térm ino ventana de datos (dw_) de PowerBuilder para describir
las áreas de desplegado de las ventanas. Los usuarios de otras herram ientas G U I p u e
den sustituirlo p o r su propia nomenclatura.
Disposición de ventana —Recepción
F i g u r a A -1 8 . E l m a rc o M D I re c e p c ió n .
Descripción de ventana —Recepción
Barra de título: Recepción ■(no m b re y a p e llid o de re g istro dol em p le a d o ]

M en ú : Sí
. . .
Tipo de ventana: M a rc o M DI
La venían a de recepción es un m arco MDI que contiene todas las ventanas necesarias
para realizar las funciones de recepción en McVet. Se abre desde el menú principal de M cVet
haciendo clic en el icono “recepción". La barra de título muestra el nom bre y apellido del em
pleado que está actualm ente registrado en el sistema. El m arco contiene un m enu que permite
que el usuario im prim a ventanas, salga de la aplicación, corte, copie y pegue texto, seleccione
a partir de una lista de reportes disponibles, organice las ventanas dentro del mareo y obtenga
ayuda en línea. Solam ente puede estar abierta una instancia d d m arco a la vez. Si el usuario
hace clic en el ¡cono "recepción” del menú principal mientras el m areo está abierto, el enfoque
regresará al m areo abierto en vez de abrir otro m arco de recepción.
Nota: l a especificación de diseño para el com portamiento de un marco M D I sólo debe
rá ser definidas una sola vez p a ra el proyecto, y luego todos los dem ás m arcos M D I de la apli
cación deberán apegarse al estándar o hacer notar en dónde y p o r qu é son diferentes.
468 A péndice / ESTUDIO DEL CASO McVET
Míniespecificacíón de ventana —R e c e p c ió n
Parám etros de entrada: A u to riza ció n de usuario, n o m b re de usuario.
Abrir: A b rir s e le c c ió n de clie n te , s e le c c ió n de p e d id o .
Cerrar: Cerrar todas las ve n tan a s abiertas d e n tro del m arco (activa co n
firm a c io n e s para cu a lq u ie r guardar íaltante}.
Cierra la ventana y 'e g re s a el e n foq u e al m e n ú principal.
Conceptos de menú
Rótulo del Activado Cuando se hace clic

Rótulo
concepto
Archivo Im p rim ir C uando una o m ás hojas esté n Im p rim e un rep o rte en papel
abiertas d e n tro de! m arco de la hoja que tie n e el eníoq u e
en el m arco
A rchivo Salir Siem pre Ejecuta Cerrar
Edición Dcshacer C uando han ca m b ia d o valores Regresa el valor de los datos

de d a tos ai valor a n te rio r
Edición C ortar C uando hay Sexto se le ccio n a do Corta te x to hacia el portapapeles
Edición Copiar C uando hay te x to se le ccio n a do Corta te xto hacia el portapapeles
Edición Pegar Cuando el p o rta p a p e le s Copla del p o rta p a p e le s hacia ei

tie n e datos ca m p o se le ccio n a do
R eportes Lista de re p o rte s S iem pre D espliega una lista de los

disp o n ib les re p o rte s d isp o n ib le s d e n tro del
m arco recepción
Ventana y osa Ico C uando al m e n o s una hoja ~üne en mosaico las hojas abiertas
está abierta
Ventana Cascada C uando al m e n o s una hoja Pone en cascada las hojas abierta;;
está abierta
Ventana Capas ■ C uando al m e n o s una hoja Pone en capas las hojas abiertas
está abierta
Ventana ¡hojas abiertas] C uando al m e n o s una hoja b n lista las hojas a b ie rta s por
e stá abierta títu lo de ventana
Ayuda [título de la ventana] C uando el e n fo q u e es-á Abre ia ayuda a nivel ventana

en una hoja para la hoja cue tie n e el eníoque
Ayuda C o n te nido S ie m p re A b re el c o n te n id o de la ayuda
Ayuda índice Siem pre A b re el índice de la ayuda
Ayuda A cerca de S ie m p re A b re la ventana acerca de

Disposición de ventana —Selección de cliente
Selección <le cítente
Apellido: Nombre del cliente: Nombre deJ perro: Raza:

i m r ~ . p; i ip ! r ~
Número Nombre
Nombre del cliente de cliente del perro Raza
A
‘ífgss
&■
¥M¡
ü !
<r
Buscar Nuevo A brir i Cambiar dueño Historial de pedidos
Figura A-'19. La disposición de ventana de selección de clieme.
Descripción de ventana —Selección de clien te
Barra de título: S elección de d ie n to
i ipo cié ventana: Hoja
1 -a ventana selección de cliente es una hoja que siem pre perm anece abierta dentro del
marco MDI de recepción. Puede estar m inim izada en el marco, pero no cerrada. Se usa para
localizar un perfil de cliente dentro del sistem a de establecim ientos McVet. El usuario puede
teclear criterios de selección en la parte superior de la ventana y luego hacer clic en el botón
Buscar, El sistema regresará todos los renglones de cliente y sus perros asociados que con-
cuerden con el criterio de selección dado por cl usuario. IÍI apellido del cliente es el valor de
búsqueda más com únm ente usado. Al perm itir que cl usuario especifique búsquedas de cade
na parcial sobre cl apellido es muy probable que se detecten jos nombres mal escritos y se co
rrijan en el sistema. Hl número de cliente también es una búsqueda por cadena parcial, aunque
se pretenda que el recepcionista sólo use este cam po cuando la tarjeta de identificación rápida
del cliente falle al leerse en el lector de tarjetas. Los cam pos nombre de perro y raza son usa
dos por el recepcionista cuando trata de localizar un perro particular en eí sistema, cuando el
cliente no sabe bajo cuál m iem bro de 1.a fam ilia fue creado el registro del perro o cuando un
perro está cam biando de propietarios.
C uando los registros se presentan en el conjunto de resultados cl usuario puede seleccio

nar a un cliente y abrir ya sea la ventana perfil de cliente para ese cliente o el historial de p e
didos del d ie n te en McVet. Si no encuentra ningún cliente en el sistema, el recepcionista puede
hacer clic cu Nuevo para crear un nuevo perfil de cliente.
La ventana también perm ite que eí recepcionista cam bie al propietario de un perro exis
tente localizando el registro actual del perro, seleccionándolo y haciendo clie en C a m b ia r
d u e ñ o . Se abre un cuadro de diálogo que pregunta si cl usuario quiere crear un nuevo cliente
o encontrar a un cliente existente en la base de dalos. Si se selecciona nuevo, el sistema r.bre
la ventana perfil de cliente en modo de nuevo, pero recupera el 10 del perro en la sección
de perro de k ventana. Si el usuario desea encontrar al cliente existente se m uestra la ventana
selección de cliente estándar, perm itiendo que el usuario tom e al nuevo cliente desde la base
de datos. Cuando el usuario encuentra al cliente y hace clic en O K se abre la ventana perfil de
cliente y el registro deí perro se añade al nuevo registro del cliente.
Miniespecificación de ventana —Selección de cliente
Parámetros de entrada: N one

Abrir: Coloca cu rso r en el ca m p o de a p e llido
Cerrar: D esactivado
Botones
Rótulo Activado Cuando se hace clic
Buscar S ie m p re R ecupera d w _ se le cció n _ d e _ clie n te usando el criterio

de selección
Nuevo S ie m p re A b re p e rfil de d ie n te , m o d o - n e w
A brir C uando el e n fo q u e está en un A b re p e rfil de c lie n te usando n ú m e ro ..

rengión en d w _ s e le c d ó n _ d e _ clicn te , m o d o = n c w
de c lie n te
Cam biar C uando el e n fo q u e está en un A b re cuadro de diálogo, d o nde p regunta si ei usuario

tiu e ñ o renglón en d w _ se le cció n _ q u iere c re a r un nuevo c lie n te o e n co n tra r
d e s d ie n te un, clie n te e xiste n te .
If n e w
A b re p e rfil de d ie n te , usar,do !D_do_porro,
m ode = new
Else
E jecuta la fu n ció n se le cció n de clie n te
C uando el c lie n te e s :é se le ccio n a do
A b re p e rfil do cliente, usando n ú m e ro _ de _ clie n te ,
lü _ d e_pe.no, m o d e = añadir perro
End if
H istorial C uando el e n foq u e está en un Abre s o lccció n de ped id o js a ",d o núm oro_da_ciiente,
cié ren g ló n en d w _ se le cció n _ n o m b re d e cliente, ID__de_perro,
p e d id os d e _ d ie n le rio m b re _d e _ p e rro
Especificación de campo —Selección de cliente
N o m b re de o b je to: d w _ c riie rio .d e se le cció n de clie n te

E stilo de pre se n ta ció n : Forma libre
Campos
Nombre i Nombre Reque V isua Actúa- Reglas

de columna de tabla rido lizado lizado
A o e llid o C liente ■N A ce p ta caaena parcia;

N ú rne rc_ d e c lie n te Chente N A ce p ta cadena parcial
N o m bre _ d e _p e rro Perro : A ce p ta cadena parcial
Nombre._de ra/a Raza Ejecuta búsqueda de ra/a
ID de raza Raza Puesto por la búsqueda de raza
N o m bre de objeto: d w _ se le cció n de c lie n te

Estilo de presentación: Cuadrícula
O rd e n a m ie n to : A p ellido, n o m b re , n o m b re de perro, n ú m e ro de clie n te
H ltros: N inguno
S upresión: S u p rim e valores re p e tid o s en apelnco, nombre., n ú m e ro de clie n te
M é to d o de se lección: U nico
Agrupa m ie n to : N inguno
A ctualizabie: No
Campos
Nombre Nombre Reque- Visua- A ctua Reglas

de columna de tabla ndo lizado lizado
Concatenar nombre + inicial

m edia + a p e 'iid o + su fijo
i
I D_de_.perm N '
N o m bre rie raza Raza s N
I s
Miniespecificación de recuperación —Selección de cliente
dw_selección_de_cliente
Parám etros de entrada: apellido, número _de_cliente, nóm brenle_perro, ID_de_raza

Select
Cliente. A pellido
Cliente. Inicial_raed ia
Cliente .Nombre
Cliente. Sufijo
Cliente. Nú mero_de_cIiente
Perra. Nombrü_de_p erro
Perro.ID „de_p erro
Raz a .N o m bre_de_ra/a
From
Cliente
Perro
Raza
W herc
Cliente.A pellido LIKE Apellido
AND C líente.N úraero_de_clíente LIKE NúmeroJ.e__cliente
AND Perro.N úniero_de_cliente = C íiente.N úm ero_de. cliente
AND Perro.N om bre_de_perro LIKE N om bre ^de_ perro
AND Pcrro.ID _de_raza = !D_de_raza
Disposición de ventana —Selección de pedido
Selección de pedido {Nombre dei cítente - Nombre de! perro (opcional}}

NCmerc
Estaos del pecico -ec"a oel pstílcc >= de psd cío Estab ed-nlento
1“ " " " !T| i I | II 1*1
KÚTie'o Neutro Pecha

de pedico cel ci eñe Norrare del perre del ped do ¿stado
¡A
' fH
■ : '
.. . . .
mm
ÉB
' ' ' SfP
Ira
-' PPt
' B ¡
PP
Wm
:. ..
- H
■ ' ^1
3osear Nuevo . Abrir Borrar. Cancelar oedidü . j ' Entregar .
Figura A-20. La disposición de ventana selección de pedido.
Descripción de ventana —Selección de pedido
Barra de títu lo : Selección de pedido- [N o m b re deí c lie n te - n o m b re del perro {si se abre
d e s d e el re g istro de cliente)]
Tipo de ventana: Hoja
La ventana de selección de pedido es una hoja que siempre perm anece abierta dentro del
m arco M D I recepción. Puede ser m inim izada en el mareo, pero no cerrada. Se usa para dos
propósitos principales, prim ero para m onitorear el estado de los pedidos que se están atendien
do en el establecim iento M cVet y, segundo, para buscar el historial de pedidos de un cliente y
su perro en McVet,
Para recuperar pedidos que están en proceso en el establecimiento, el recepcionista sim
plem ente selecciona a partir de la lista desplegable de estado de pedidos (Todos, N uevos, En
proceso, Terminados, Cancelados, Cerrados y N o cerrados) y se asegura que el establecimiento
de la lista desplegable esté en form a predeterminada en el establecim iento actual de McVet. Al
hacer clic en Buscar al usuario se le presenta una lista de todos los pedidos con ese estado que
hay en el establecimiento. El criterio de selección más com ún para e] recepcionista será la se
lección de pedidos que están dentro del establecimiento y que están Terminados o No cerrados.
Para recuperar el historial de pedidos de un d ie n te y su perro, el recepcionista selecciona

ría el renglón de cliente/perro desde la ventana selección de cliente y haría clic en H istorial de
pedidos o en Historial de psdidos desde la ventana perfil de cliente. El sistema colocará el
nom bre del cliente y del perro en la barra de título de la ventana selección de pedido y pondrá
el enfoque en la ventana con el cursor en el campo estado d el pedido. El usuario puede estrechar
la búsqueda dando una fecha inicial, un estado o un establecimiento específico o dejar estos cam
pos en blanco. Cuando eí usuario hace clic en B uscar, cl sistema recupera todos los registros de
pedido concordantes para esa combinación de d ien te y perro. El recepcionista puede abrir un
pedido antiguo eon la intención de copiarlo. En cualquier m omento en que un cliente y perro es
tén desplegados en la barra de título, el recepcionista puede hacer clic en NU0VO para colocar un
nuevo pedido para el perro. Para reajustar la ventana a un estado de consulta de pedido general
el usuario hace clic en Borrar, y el cliente y el perro son eliminados de la barra de título.
Miniespecificación de ventana —Selección de pedido
Parámetros nú¡riero_de_ciisn[e. nom bre_d3_ciiente, id__do_porro. nom bre do perro

de entrada: (si sr: abre- desoe un registre de diente!
Abrir: :f númsro_de_dien{s. nu'ribre_de_ciiente, id_de_perro, nombre, de p o ro not nuil.

Pone- núm ero_ds_c!iente, id_de_perro en d*v_criterio_de_se!ecc:6r_
despedido
Colocar nombre_de_clienie, ncmbre_de_perro en bar-a de título
End if
Cerrar: Desactivado
Botones
-1 us car Siempre Recupera dw_selección_de_.ped;do

usanuo criterio ds selección
Nuevo If d'.'7_er!ieT1o_de_se:ecc¡cn_ce_ped¡do, nc-'r,bre_de_ Abre captura da pedido usando

d ie n to y uw__i:ri!e'io_de_selet;c ún_de_pedldo, número_de_c!iente, id_
id_de_perro son NOT NL'I l (sólo puede de_perro, m ode = new
coeoar un nuevo pedido si el d ie n to y oí perro
están nombrados en la barra de t'tu o i
Abrir Cuando el enfoque está en un renglón en Abre captura de podido usardo
dw_selecoión_de_pedido id_de_pedido, m ode = m odiíy
Borrar S ie m p re Reasigna la ventana a su estado
oree eterrry nado
cw _seleccóo_de_ped'do ■ vac’o
estaco del .peaido = lodos los
e stablecim iento = establecim iento
actual
id_de_cliente - nuil ■
ia de perro = nuil
datos oo barra do títu :o = Dorados
Cancelar Cuando el enfoque está or¡ un ren g ó n de dw_ Ejecuta procedim iento cancela podido
' eeoido seieoción_de_pedido y estaoo_dííl_pcdido =
nuevo o en proceso
Entregar Cuando el foco está en podido donde estado_ Abre :a ventana de entrega de p e ro
del_oed¡do te'm inado íloaavía no está diseradai
Especificación de campo —Selección de pedido
N o m b re de o b je to; dw _cr¡te r¡o _ d e _se le cc¡ó n _d e _ ,3 ed¡do

E stilo de p re se n ta ció n : Form a libre
Campos
Nombre Nombre Reque- V isua A ctua Reglas

de colum na de tabla rido lizado lizado
Klúm ero_de_c líente C liente N N N

iD _de_pe rro Perro H N
E stado_del_pedido Pedido S S S Lista = todos, nuevo, en
p roceso, te rm in a d o ,
cancelado, cerrado,
no cerrado
Fecha_dol_pedido Pedido N s s
N ú m ero _de_ped¡do Pedido N s s
E stablecim iento U bicación M cVet S s s Lista = to d o s +
ubicaciones M cV et
do nde tipo _ de _ u b ica ció n
- e s ta b le c im ie n to
Código_de_ubicación Ubicación M cV ct N N N Puesto por lista d e sp le
gable de e stsb íecim e n to
N o m bre de o b je to : d w _ s e le cció n _ d e _ p e d id o
E stilo de p re se n ta ció n : Cuadrícula
O rd e n a m ie n to : N ú m e ro _ d e _ p cd id o , d e sce n d e n te
Filtros: N inguno
Supresión: N inguno
M é to d o de selección: Selección m ú ltip le
A grupación: Ninguna
A ctúa lizable: No
Campos
Nombre Nombre Reque Visua A ctua Reglas

!D _de .pedido Pedido S \J N
N Gm e rc_d e_pe d ¡d o Pedido S S N
N om bre del cliente Sóio se desp.iega s s N Concatenar n om bre

+■ inicia; m edia i- apellido
+ s in ¡o
A p e llid o C liente 2 NI N
.nicial_m edia C liente N NI N
M om bre C liente S NI N
Sufijo C liente N M N
\lo m b rc _ d e _ p e rro Perro S S N
-echa ,de _p e d id o Pedido s S N
Estado .d e L p e d id o Pedido s S N
Miniespecificacíón de recuperación —Selección de pedido
dw__selecciórt_de_pedido
Parámetros de entrada: número_de_c líente, id de perro, eslado_del_pcdido, fecha_del_pedido,

número_d(‘_ pedido, c:ódigo_de_uhicación
Select
Pedido. Tü_d e_ped ido
Pedido.N úm ero_de_pedtdo
C li en Lti.Apellido
Cliente. In i ei al_ media
Cliente.N om bre
Cliente.Sufijü
Perro. N o m b re_de_perro
Pedid o .Fech a_del_pedido
Pedido. Ks Lado_de I_p edi do
F ro m
Pedido
Cliente
Perro
W here
C lien te. Número_de... cliente = Pedido.N úm ero_de_cliünte
A ND Perro-IL5_de_perro = Pedido.ID_de._perro
AND Pedid o .N úmero_de_e 1ie n te = Núm ero_de_cliente
AND Pedido.ID _de_perro = ID _de _ p erw
AND Pedido. HsLcido_dül_pedidu = Estado_del_j>edido
AND Pedido.Fecha_del_pedido >= Fecha del_pedido
A ND Pedido. Código_de_ubieaeión = ('ódigo_de ubicación
AND Pedid o. Nú m ero de pedido = Núm ero_de _pedido
Disposición de ventana —Perfil del cliente
Perfil rfet cítente
P re fijo : N o m b r e IM: Apellido: Sufijo: Numero de cliente:

□ i r ...................... ¡
Dirección:
Teléfono en el día
Ciudad: Estado: CP: Teléfono en la tarde:

zm m
P e rro s:----------------- Detalles del perro:------
Seleccionar nombre: Nombre: Sexo: Peso:
|T | a ¿Castrado? |____ | Kgs
Ra?a: Nacimiento:
I
Alergias: □ ¿ M u e rto ?
Agregar perro: Eliminar perro s [Pedido nuevo j Abrir líttima pedido Historial de pedidos Guardar
Figura A-21. La disposición de ventana perfil de cliente.
Descripción de ventana —Perfil de cliente
Barra de título: Perfil del clie n te
1ipo de ventana: Hoja
La ventana p e rfil de cliente es una ho ja cn donde cl rccepcionista captura, actualiza o ve

rifica la precisión de un registro de d ie n te y sus registros de perra asociados en el sistema. La
ventana recupera un solo registro de cliente y todos los registras de perro asociados con el
cliente. Hl cliente se m uestra en la parle superior de la ventana y los perros en la parte inferior.
En el lado inferior izquierdo de la ventana se tiene una lista despla/able de ios perros del clien
te. A la derecha están visibles los detalles del perro cuyo renglón tiene el enfoque en el control
de lista. El botón Guardar de la ventana se aplica al cliente com pleto y todos sus perros. To
dos los cambios a la ventana que no hayan sido guardados deben realizarse antes de que pue
da crearse un pedido para el cliente.
La ventana puede abrirse desde tres lugares diferentes. Prim ero, si el cliente tiene una
tarjeta de identificación rápida para cl perro, el sistem a abrirá la ventana perfil de d ie n te tan
pronto com o la tarjeta pase por el lector. La ventana tam bién puede ser abierta desde la venta
na selección de cliente para cualquier renglón de cliente único seleccionado. Además, la ven
tana puede ser abierta desde la ventana captura de pedidos.
Miniespecificación de ventana —Perfil de cliente
! Parámetros número_c¡e_cl¡ents, id_de_.peiro, m oci

; de entrada:
i Abrir: !f m ode = nuevo

If id_de, perro no: = nuil ¡el perro existente esté siendo añ3didc a un nuevo oliente)
Recuperar d w _ m a n te n m e n to _ d e _ p e ro usando .d_de_pcrro
Doner d w m a n te n m e n to _ d c _ o c ro nümero_de_clíente - nuil
Else
Desplega' ventana en blanco lisia para insertar nuevo clienie
End ií
□ se If m ode = m odificar
Recuperar o w _ m a n le ri m iento, desdiente usando r;únr;cro_dü_ciienie
Recuperar a v e n a n te ni mi ento_de_perro usando núm ero _dc_clicnto
Poner el enfoque ai renglón en dw_seiección_de_pen'o donde id_de_pero
= id_d&_pe!,ro
□ s e If m ede = añadir perro
Recuperar dw_m aníe ni miento, de .cliente usando riúm ero_je_c!isnt9
Recuperar dw_m aníenirriento_de_per.'ü usando número de_cüente
Ahadir dw..m a:iten!npier:o de ñ e ro usando id_de_perro, poner dw _m anten’m ienio
_.ae c e ro , núm ero_de_clente - nuil
Poner el foco al renglón en d w_s e leed ó n_de_ perro, donde ;d_de_pero = /d_de_perrn
Fnd i f _____________________________________________________________ __________
C o n firm a r los ca m b io s no grabados con el usuario (¿desea guardar su trabajo?) y

luego cerrar la ventana
Botones
Agregar p o ro Sicm oro Inserta nuevo renglón en dw _selecc¡ón_de_perro y colo

ca ei cursor en el cam po n o m b re del perro en d w _ m a n -
te n im ie n to _ d e _ p e rro
Eliminar perre Si el e n foq u e está en un S e le ct c o n ta d o r From ped id o W h e re Pedido.
renglón de perro en ld_de_perro = ld _ d e _ p e tro
ow _ se ie cció n_ d e _ p e rro If e n cu e n tra re n g lo n e s
In fo rm a ai usuario oue el perro no p u e d e ser e lim in a do
d e b id o a q ue e xiste n p e d id os para el perro
Flse
M arca al perro para ser borrado a! G u a rd a r y lo e lim ina
del desp lie g ue .
End if
Pedido nueve Si no hay ca m b io s A b re captura de p e d id o s usando n ú m e ro _
p e n d ie n te s y perro. de_cüente, id_de_perro, m o d o - nuevo
M u e rto NOT = S
Abrir últim o Si no hay ca m b io s A b re captura de p e d id o s usando r¡ú m ero_de_ctiente,

pedido p e n d ie n te s id_de_perro, m o d e - ú ltim o _ p e d id o
Historial Si no hay ca m b io s A b re se le cció n de p e d id o usando n ú m e ro_de_clier¡te,
de pedidos p e n d ie n te s n om b re _ de _ cü e n te, id_de_porro, n o m b re _ d e _ p e rro
Guaidar Si hay ca m b io s Guarda ca m b io s en la base de datos para clie n te , p e rro
p e n d ie n te s
Especificación de campo —Perfil de cliente
N o m bre de objeto: d w _ rn a n te n im ie n to de d ie n te
Estilo de p re se n ta ció n : Form a libre
Campos
Nombre Nombre Reque V isua A ctua Reglas

N úm ero_de_cl ¡ente C liente S S N Cuando es nuevo ejecuta

O b te n e r s ig u ie n te
n ú m e ro de clie n te
Prefije C liente N s S Lista ■= Sra , Srita., Sr. y Dr.
N o m bre C liente S s S
lnicial_m edia C liente N s s
A p e llid o C liente S s S
Sufijo C liente N s S
D irección C liente N s s Edición en varias líneas
Ciudad C liente N s S
Estado C liente NI s s Lista = abreviaturas
estándares
Cóciiyo p ostal (CP} C liente N s s
Teléfono en el día C liente N s s
Telefono en la tarde C lie rte N s S
N o m b re de objeto: dw _ se [e cció n _ d e oerro

E stiio de p re se n ta ció n : Tabular - Sólo es visib le el n o m b re del perro
Sincronización: Sincronizada c o r d w _ m a n te n im ie n to _ d e _ p e rro , m ism a s c o lu m
nas d e datos
O rd e n a m ie n to : N o m b re del pe rro
i Actualizable: Por m e d io de d w _ m a n te ri¡rn ¡e n to _ d e_ p e rro
N o m bre de objeto: d w _ m a n to n im ie n to _ d e _ p e rro

E stilo de p re se n ta ció n : Form a libre
Campos
Nombre Nombre Reque V isua Actúa- Reglas

de columna de tabla rido lizado tizado
Número. de_eliente Perro (FKi S N N Puesto = riw_manten¡-

mienío_de_cliente ;
cúme ro._de_e liente
¡D_de_perro Perro s N N Obtiene nuevo identifi-
cador en inserción
Nombre_de_perro Perro s S S ■
:
Sexo Perro s s S Lista = M, H
Castrado_ester¡;¡zada Perro s s S Cuadre de verificación.
Mareado - S
Rótulo dinámico. If sexo
= M, rótuio = castrado,
else rótulo = esterilizada
Ú!timo_peso_en_kilos Perro NI s S Fl peso es puesto por la
báscula o por el pedido
más reciente, pero puede
ser tecleado manualmente
por el usuario
Nombre_de_ra¿a Raza S s S Ejecuta óúsqueda de raza
lü_de._raza Perro (FK) S N N Puesto por búsqueda
de raza
Pecha_de_naci miento Perro N S S
Alergias Perro N S S
Muerto Perro S s s Cuadro de verificación.
Marcado = S
Míniespecíficación de recuperación —Perfil de cliente
dw_mantenim iento_de_ciiente
Parám etros de entrada: N úm ero_de_cliente

Select
Cliente .Núm ero_de_c líente
Clien te. Prefijo
Cliente. Nombre
Cliente.Inicial _mcdi a
Cliente. Apellido
Clien Le.Su fijo
Cliente. D irección
Cliente.Ciudad
Cliente.Estado
Cliente. Código_postal
C1ien te.Te 1éf o n o_en_el_día
CI i en Le.1T eléf ono_eo.,Ja_ í ard e
From Cliente
W here C liente.N úm ero_de_clientc = Nútmero_de_clienie
dw_mantenim iento_de_pe rro/d w_selección_de_perro
Parám etros de entrada: Número_de_clíente

Select
P erro.N úm ero_de_cl i e nt e
P erro.ÍD_d e_perro
P e rro.N orabre_de_perro
Perro. Sexo
Perro. Castrad o esterilizada
P erro.U lti rri o_pe s o_en_ kilo s
Perro .ID_de_raza
P erro.Feeh a_de_nacim ie nto
Perro. Al erg ias
Porro .Muerto
Ra/,a.Nom brc_de_raza
From
Perro
Raza
W here
Perro.Número__de_c lien te = Núm ero_de_chente
A ND Raza,ID _de_raza = Perro.ID _de_raza
482 Apéndice ! ESTUDIO DEL CASO McVET
Disposición de ventana —Captura de pedido
Captura de pedido [Número de pedido-Estado de pedido]
Número de cliente; Númfíro de cliente: Fecha de pedido:

. i r~ i l _ _ ... ..........
Nombre del perro: Sexo: Peso: Raza: E ¿Porro feliz ük?
1 ¡ | H ¿Castrado? ¡_ ] Kgs. j ~
Naturaleza dei problema: Medicamentos actuales:
... . __________________________i i__________________________ ____ i

Instrucciones repódales:
, - Elementos de pedido:----------------------------- ----------------------------

! Precio Precio Cantidad
! Línea Tipo de servicio Origen unitario de base Cantidad apagar
P1
—
Iva
Total
Agregar elemento j Eliminar elemento Abrir c¡ionio j Copiar pedido Cancelar pedido Guardar
F igu ra A -22. L a d isposición do ia ventana de captura de pedido.
Descripción de ventana —Captura de pedido
Barra de : ítulo: i C aptura de pedido
rip o da ventana: Hoja
La ventana de captura de pedidos es una hoja en la cual el recepcionista captura, actua

liza o crea una copia de un pedido. La ventana recupera un solo pedido para un d ie n te y perro
dados. M uestra e! encabezado del pedido y iodos los conceptos de pedido asociados. El recep
cionista puede añadir conceptos de pedido, elim inar conceptos de pedido, copiar el pedido ha
cia un nuevo pedido o cancelar los pedidos que no han sido terminados. El com ando Guardar
de la ventana graba Lodos los cam bios a los pedidos y conceptos de pedido.
La ventana puede ser abierta desde la ventana de selección de pedido o desde la ventana
de perfil de cítente.
Miniespecificación de ventana —C aptura de p edidos
=aráT-et'os núm ero d e p íle m e , id de_perro, id_de nedide, modr.

de entrada:
Abnr: :f m ode ■■■■ new
Recjpe.'a dw _nuevo .pedido usando núm e:o_de cücnte, id, de perro
nstanciar dw. mamen. m ie r‘ o. de_pecido usando valores de dvv_ nt,evo_peo oo
irs:an o ia r dw_nnanten¡m :Gnto_ae_conccato_ae..oed¡oó
rls e f m ode -- m o d ry
Recuperar dw._rranten'rnien:o_de_ped¡do usanco id_.de podido
Recuperar dvv_manten;niento_de. concepto_de_ood:do usando id_de_oedido '■
Else if m ode = ú,t¡mc o e d ;do
Recuperar dw m anterim ,er,to_üe_ped¡ao u sa rd o núm ero_de_ciiente,
id de_perro, últim o_psdido
Recuperar d w _ m a n te n m e n to de concepto de pedico jsa n o o <d de pedido
End :f
Ce'rar: t-on irm ar cam bios ro guardados con el usuar.o ¡¿quiere guaroar sLj trabaio?) y
■uege cerrar la ventana
Botones
Rótulo Activado ; Cuando se hace clic

Agrega' Siempre Abr,r selección de tipo de servicio
elem ento âra cada tico de servicio select: onaco insertar
nuevo renglón do concepto de aeoioo e r
d w _ m a rito n m ie n tü_.de_concc-pto_de_pedido
Eximirá' Si el enfooue es‘ á en un salo M arca' e. rerg.ón de concopto_oe_;:edida cara
e le m e rto 'englón en d w .nünten¡m icr;to_de cue sea oorrado al Guardar, elim inarlo
_ccnceeto_ce_Ded¡do y es‘ ,=do_de col desplegaos
_concep‘. c_de p e d :do no = c e ra d o
Abr,r cíe n te Si ro hay cam bios s ir gua-dar Abrir perfu uc ciiem e usa nao núm cro_ds_
die n te, sd_de_pnrro, m odo — m e d r cac¡ó.n
Cop.ar p e d d o Si no hay cambios s n guarcar C o n firm a r copia
R eajustar la ventana con m ode - n e w
Poner d w _ m a n te n im ¡e n to d e _ pe d id o id_de_pedido
= nuil ■ '
Poner dw_m antersim iento.. d e jo e c id o fecha_de_
ped id o - techa a ctú a !
Poner d'A'_manten¡mi!:ento_de._pediao có d ig o _d c_
ubicación = có d ig o de u b ica ció n actual
Poner dw ._m aníenim iento_de_per.iido to m a d o _
por = n ú m e ro de e m p le a d o d e l usuario
Poner dw . m an te n m íe n to_do-_concepto_de_ped ¡do
¡d_de_ped¡do - nuil
Poner d w rra n iG n ¡m ie n to _ d c_ co n ce p to _ d e _ p e d ¡d o
¡d_de. co n ce p to _ d e .pedido - nu;;
O b te n e r e l sig u ie n te n ú m ero de pedido
Cuando el enfoque está en un E e c u ta r el p ro c e d im ie n to cancelar c e d id o
ped.do renglón on d w se;ccción_de
p e d :do y estado_del pediuo =
nuevo o en proceso
Guardar Si hay cam bios sin guardar Grabar los cam bios a la base de dates para p e d id o
y c o n c e p to de pedido. Un ped id o debe tener al
m e n o s j n c o n c e n to de Decido
Especificación de campo —Captura de pedido
N o m bre del objeto: d w _ n u e vo_p e d :d o
E stilo de pre se n ta ció n : O cu lto - e ste a rre g lo so js a para recu p e ra r la in fo rm a ció n de c lie n
te , perro y raza para un nuevo pedido
Campos
----------- i-- ■

N úm ero_dc_cl¡e?ite C liente S N
N o m bre C liente s N N
Inicial m edia C liente N N N
A p e llid o C liente S N N
Sufijo C liente N N N
N o m hre _ d e _p e rro Perro S N IV
ld_de_perre Perro S N N
Sexo Perro S ■N N
Castrado, .esterilizada Perro S N N
ÍD_de_raza Perro (FK) S N N ;
N om bre_de_raza Raza S N N
i C andidato_para_
Perro_Fel ? Raza N
s i R ..
N o m bre de o b je to: d w _ m a r.te n im ie n to _ d e _ p e d id o
Estilo de p re se n ta ció n : Forma libre

Campos
Nombre Nombre Reque V isua A ctua Reglas

N ú r :c rc_de_c,iente C liente S 3 N
N om bre de cliente S.ó'g se s c N C oncatenar nom bre t niela
despl ega ' me-dia + apellido sufijo
\o rr.b re ! Cliente 5 N X
.m cia L m e d a Cl ente N K M
A p e lld o C-i ente S ¡\ N
Sufijo □ ¡ente N :M N
Nom ore..de perro Perro S s N

ID_de_oe-ro Perro S N N
Sexo Pgto j; S K
Castr3cc_esteril¡zaca Perro 3 \ H sexo = VI, rótulo -
css’lracc. eise r ó tjlo =
5 esterilizada
1n_do_r3za P e ro iF<¡ S ■\¡ N
No-nore._de_raza Haza S C; N
Elegiólo para_ Haza s S N
Perro_Feliz
ID_.de pedido Peo ¡do N N O o te n e 7 nuevo :dent-

fieador a la inserción
N úrncro_de_ped do Pedido S \ O btener siguiente núm ero
de pedido cuenco nuevo.
Desplegarlo en ¡a berra de
titu lo !
Es~adomdel_pedirin Ped:do
s s N Estado inicia. = nuevo
Desplegarlo en la b a ra de
título
r echa_.del. podino Pedido s 3 1 N Pañería a ;a fecha actual
cuando nuevo
■~eso_del_peire._ Pedido N S 5 Puesto por ia báscu a o
en kilos cspíu'ado per e; us-jano
Natu raleza Pediao N s S
dcl_ problem a
M e d lc a c ó n .a c iu n l Pedid o M s S
lnstrucciones_ ‘ Pedido \ s s
e sp e cia os
Código_d r;__uh ¡■nan: n r- Pod:do S ' N N Puesto a código de ubica
ción a c tja l cuanco nuevo
Iom 3do_oor Pacido s N N P re sto a núm ero de ern-

p lesdo del usuario cuando
nuevo
M om bre de o b je to : d w _ m a n t e n im ¡e n t o _ d e _ c o n c e p t o _ G e _ p e d ¡d o
r s tiio de pre se n ta ció n : Tabular
O rd e n a m ie n to : N ú m ero de c o n c e p to de pedido
Filtros: N inguno
Supresión: N inguno
M é to d o de se lección: S elección única
Ag rap a m ie n to: N inguno
Actualizable: Sí
......................
Campos
Nombre Nombro Reque V isua A ctua Reglas

IU_de pedido ConcopT.c_de_ S N iSi =oner - aw_mar'?e'iirniento_de_.

pe d :do ÍFK; ped:da ic_dc...pedido para
conceptos nuevos
Núm erc_de_ Ccncepto_ce_ 5 S N
■::o 'i c a Dto_.(i r n d iu o podido
Estaao_dei_ Conceptü_de_ Q S N üsrsdo inicia! = NEW

^cnêpt'j_de_pec¡¡dü oedioo
ü 'ig e n C o rcep to _ ce _ S N Despliega el p rim e" caráctar

pedida :í aoncep’ c_de_ped:do tue
insertado oor el recepción s:a,
origen - CLIENTE Else :f inser
:ado por el ve te in a n o , erigen -
V h l Else :t insertado po:' e! sis
tem a ¡cargos extras),
origen = SISTEÍVA
End i:
Precio_unr,ono Cancepto_ s S N
d e_oedidc
Precio de base Canea oto_ s S N
de_Dedido
Cantidad Ccncaoto N S S
de_pedido
ID_de tipo Concep‘ o_ S 5 \

de servicio ae_pedido
Nom bre_de_ti po Tipü_ S S
d e rse rvicio ae_se^vic.o
C a m id a d _ p a g a r11 S s \ Cantidad_a pagar = cantidad x

p recio u n ita rio , redondeado
a 2 d e cim a le s
Su o Total ' s N En el pie p e ro no se despliega

on esta ventana. Sub_total -
S U M A p re c io _ e xte n d id o
c o n t in ú a
c o n tin u a c ió n

Tasa_de_¡m pyesto_ * Parám etro S N N O b te n e r tasa de im p u e s ta de

de sve nta s del siste m a ve n ta s de los p a rá m e tro s del
siste m a
IVA * s S N Se despliega en el p ;e. IVA =
Suútot-al x la sa _ d e _ im p u e sto _
de_.ven'as, redo n d e a d o a
2 d e cim ales
Total * - s N Total = S ubtotal + im p u e s io
* /•;/precio y las rutinas de im puesto de venta son tipos de actividades que deberán estar alojados
en una fu n ció n u objeto común.
Miniespecificación de recuperación —C a p tu ra d e p e d id o
dw_nuevo pedido
Parámetros de entrada: número_de_cliente, id de perro

Selcct
Cliente.N úm ero de_cliente
Cliente.N om bre
C liente,Inicial m edia
Cliente. Apellido
Cliente. Su fije
Pe rro. N ombre_d e_perro
Perro.ID_de .perro
Perro. Sexo
Perro. Castrad o esterilizada
Perro. ID_de raza
R aza. N o m hre_d e_raza
Raza.Elegible para_Perro_í■eJiz
•rom
Cliente
Perro
Raza
(Vhere
C 1ie n te, N ú tn ero_de e lien le = jVíím e ro_de_clien te
AND Perro.ID _de_perro = ÍD de perro
AND R a /a J I) de raza = Perro.ID de raza
dw_mantenim iento_de_pedido
Parám etros de entrada: Núm era_de_clienie, ID_de__perro, último_pedido, ID de_pedido

Cliente. Núm ero_de_c líente
Cliente. N om bre
Clien te. Inicial_m edia
Cliente. A pellido
Cliente.Sufijo
Ferro. N om b re_de_perro
Pe rro.I D d e p erro
Perro. Sexo
Perro,C a st rado_e steril izada
Perro.ID _de_raza
Raz a.N om bre_d e_raza
Raza.Elegible_ para Perro_Feliz
Pedido. I D . de_pedido
Pedido. N ú mcro_d e_pe d id o
Pedido. Es tado_d el _ped i d o
Pcdido.Fechü del pedido
Pedido. Pes o_d e 1. perro._en_kilo s
Pe(i ido. N atural eza_d el_problcm a
Pedido. Medieaei ó n_actual
Pedido. In s tru c d o n e s_es p e d al e s
Pedí do. Có di e o_de_u bi c ac i ó n
Pcdido.Tom ado_por
From
Cliente
Perro
Pedido
Raza
W here
C liente.N jm ero_de_diente = P edido.N úm ero_de_diente
A ND P c r r o .I D d c p c r r o = Pedido.ID _de_perro
A ND R aza.ID _de_raza = P erro.lD _de_raza
AND If' última j e d i d o = cierto
Pe d id o .N ú m ero_de_d i e nte = N úm ero_de_diente
Pedido.ID _de_perro = ID de_perro
Pe dido .Fech a_del pedido = M A X
Else // ú)timo_pedido = faisc
Pedido. H )_de_pedido = ID _de_pedido
End if
dw_ m antenim iento _de_concepto_de_pedido
Parám etros de entrada: lD _de_pedido

C oncepto_de_pedi do. TD_de_pedido
Conc e p t o d e p e d id o .Nú rn ero_de_conc epto_de_p edido
Conc ept o_de_pedi do.Ex t ado_del_co nc ep Lo_de_p edido
Conc ep to_de_p edido.Origen
C oneep to_de_pe did o .Prec io_unitari o
C onccpto_de_pedido. B ase_de_prcci o
Con eepto_de_pcdi do. Cantidad
Con c cpto_de_ped ido.I D d e _ tip o .d e s crvi ció
Tipo_de_s ervi ció .No m bre_de_tipo_de_s ervicio
Frorn
Conc epto_de_pedido
Tipo_de servicio
Whcrc
C o nce pto_dc_ped ido.ID _dc_ped ido = ID ^de jie d ld o
AND Tipo_de_servicio.TD_de_íipo de_servicio = Coneepto_de_pedido.ID _de.
ti po_dc_ser vicio
Disposición de ventana —Selección de tip o de servicio
Selección de tipo de servicio
• Todo O Sólo acicalamientoO Sólo veterinario

Precio
Nombre dei tipo de sen/icio unitario Pretio
actual de base
A.
Qk C a n c e la r
Figura A -23. L a disposición de ventana selección de lipa de servicio.
Descripción de ventana —Selección de tip o de servicio
Barra de título: S elección de tip o de se rvicio
T ipo de ventana: Respuesta
La ventana de selección de tipo de servicio es una ventana que se abre cuando el recep
cionista solicita la adición de conceptos a un pedido. El usuario puede seleccionar uno o más
lipos de servicio de ia lista. Cuando se hace clie en O K el sistem a inserta un nuevo renglón de
concepto de pedido en dw _m antenim iento_de_concepto_de_pedido para cada concepto selec
cionado. Hay tres botones de opción en la ventana que perm iten que el usuario filtre la lista pa
ra m ostrar todos los servicios, sólo los servicios de acicalam iento o sólo los servicios de
veterinario. La ventana sólo recupera los tipos de servicio activos.
Los tipos de servicio son recuperados de la base de datos ju n to con sus precios actuales.
La ventana también recupera cualquier cargo extra que esté en efecto para la raza de perro y
m uestra ei cargo extra debajo del tipo de servicio. La selección del tipo de servicio selecciona
a ii loma lie ám ente al cargo extra.
Miniespecifícación de ventana —Selección de tip o de servicio
P arám etros de entrada: ID_de_raza

Abrir: R ecupera d w _ s e le cc¡ó n „d e _ tip o _ d e _ se rvicio
B o tin e s
Rótulo Activado i Cuando se hace clic
OK S ie m p re In se rta ios tip o s de s e rvicio s e le c d o ra d o s en d w _ m a n te n im ie n -

to _ d e _ co n ce p to _ d e _ p e d id o y cierra la ventana
Cancelar S ie m p re Abandona las a cciones y cierra la ventana
Especificación de campo —Selección de tip o de servicio
N o m b re de objeto: dw _ se le cció n _ d e _ tip o _ d e _ se rvic.o

Estilo ae p re se n ta ció n : Tabular
O rd e n a m ie n to : N om bre de tipo de servicio, íD_de_cargo_extra_de_raza, prim ero los lu lo s

Filtros: If All, d e sp lie g a to d o s los ren g lo n e s,
Else if G roo m in g Only, despliega ios re n g lo n e s en d o n d e clase_de_t¡-
p o „d e _ s e rv ic io = C U IDADO S
Else if V e te rin ary Only, de sp lie g a los re n g lo n e s en d o nde clase_de_t¡-
po.,de_ser vicio = VETERINARIO
End ¡f
Supresión: M inguno
M é to d o de selección: Selección m ú ltip le

A grupación: Si un ren g ló n de cargo extra acom paña a un ren g ló n de tip o de s e rvi
cio se les trata co m o una unidad para la se lección.
Actualizable: No
Campos
Nom bre Nom bre Reque Visua- Actúa- Reglas

de columna de tab la rido lizable [izado i
F:itrO - s s s Botones de opción en e. en

cabezado. Lista - Todo, Sóio
cuidados, Sóio veterinario
:D_..de,/iipo._de_serv¡do 7¡po_de_ssrv¡cio s \ N
Nompre_ae_l¡uo Tipo_de_servicio s S N ID_de_cargc_extra de_/aza
de_servicio \ :0T MULL., desplegar
n o m b 'e en ROJO
Fnd ;f
P'ecio_uni‘ ario T¡po_de Precio s s N i D_de_sargo_ext'a_de_raza
NOT NUI 1, precio_Lnitario =
p re o io_u n ¡ta ri o_d e_ce rg o. ex* ra
fn d if
Base_de_preciü ~¡po_de Prccio s VJ If TJ_as_cargc_ex:ra_de_raza
NOT NULL, base_de_precro =
base de_.c-recio_de_cargo_
extra
bnd if
1D_o e_c a rg o_e x t'a_ Cargo__extra._ N N N
de_raza de_raza
P re c io .u n ita ro _ Ca^go_extra_ N N N
de_cargo_e>:tra de_raza
Base_de_précio Cargo_excra_ N N :\ i
óe_cargo_ extra d e jo z s
í
Miniespecificación de recuperación —Selección de tip o de servicio
dw_selección_ de_ tip o d e s e r v i d o
Nota: El equipo de diseño está preocupado acerca del desem peño de esta selección. Si prueba ser
un problem a habrá que lanzar al escuadrón áe optimización.
Parámetros de entrada: lD _de_raza

Select
Tipo_de_servicio.ID_de_.tipo, d e s e rv ic io
Tipo_de servicio.N om bre_de_lipo_de_scrvicio
Ti p o_d e_s ur v icio.Prcc i o_im it ari o
Tip o_d e_s ervicio.B a se_d e_prec i o
C arg »_extra_de_raza.ID_de_c argo_extra_d e_raza
C arg o_cx tra_de_ raza. Pre c io_u ni tario_d e_c arg o_exlra
Cargt)_cxtra_dc_raza,Ba.se_de_precio_de_cargo_extra
From
Ti p o_de_servicio
Preci o_dc_s ervicio
C argo_extra_de_raza LEFT JÜIN on Tipo_de_servicio
W hcrc
Ti po_de_ser vi cío. Activo = “S ”
A ND Precio_de servicio.ID _de_tipo_de_servicio = Tipo_de_servicio.ID _de_ti-
po_de_ servicio
A ND (Precio_de_sem cio.F echa_de_expiración = N U LL
(OR Precio_de_servicio.Fecha_de_vigencia <= Fecha actual
AND Pre c io_de_ serv ic i o .Fech a_de_ex p irac ión >= Fecha_actual))
AND Cargo,. extra_dc_razaJD _de_lipo_de_servicio = Tipo_de_servicio.ID _de_
tipo_dc_servicio
AND Cargo_extra_de_raza.ID _de_raza = ID _de_raza
A ND (Cargo_extra_de_raza.Fccha_de_expiración = N U LL
(OR Cargo cxtra_de_raza.Fecha_de_cfectividad <= Fecha..actual
A ND Cargo extra_de_raza.Fecha_de_expiración >= Fecha_actual))
Respuestas al ejercicio 10 —Diseño de componentes internos
10. i Las prim eras ciases obvias podrían ser las clases de papeles en el dom inio del nego
cio que pueden derivarse del m odelo de inform ación: d ien te, perro, ubicación McVet,
empleado, concepto de pedida, tipo de servicio, precio de servicio, cargo extra de ra
za y raza. Tal vez quiera crear una clase de relación, guardián de perro, para m ane
ja r la relación entre un perro y quién es responsable de la mascota. D e esta form a se
tiene un lugar lógico dónde guardar la política para el cam bio de propietarios. Tam
bién se podría pensar en otras clases de atributos. Los objetos que se especializan en
calcular el impuesto de ventas correcto podrían ser muy útiles en este sistema. D en
tro de la función de recepción, una clase m anejadora de eventos, digam os, m anejador
de pedido nuevo, se recom ienda para m anejar la colaboración que se requiere entre
las clases del dom inio del negocio para crear un pedido.
10.2 Los candidatos obvios para la herencia son em pleado y tipo de servicio. La política
que se relaciona con quién puede proporcionar cuáles tipos de servicio es muy parti
cular en McVet. A unque la base de datos puede haber pasado ios subtipos de entidad
hacia sus tablas de supertipo respectivas, es probable que el modelo de clases deba
m antener esas ideas separadas. El tipo de servicio podría encontrar con las subclases
tipo de servicio médico y tipo de servicio de acicalamiento. Los em pleados podrían
separarse en subclases de veterinarios, acicaladores y personal de apoyo. Otros can
didatos para la herencia son las ubicaciones M cVet, que pueden ser separadas en es
tablecim ientos y oficinas adm inistrativas. Solamente los establecim ientos pueden
colocar pedidos. También, la clase concepto de pedido podría seguir la m isma subcla-
sificación lógica que el tipo de servicio que proporciona.

Ruble David-Analisis y Diseno de Sistema PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Ruble David-Analisis y Diseno de Sistema PDF

Caricato da

Copyright:

Formati disponibili

CONTENIDO

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

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

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

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

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

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

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

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

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

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

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

CAPÍTULO 7 DAR LOS TOQUES FINALES

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

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

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

Determ inación de los requerim ientos

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

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

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

CAPÍTULO 10 CONCEPTOS DE INTERFAZ GRÁFICA

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

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

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

¿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

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

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

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

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

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

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

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

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

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

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

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

CAPÍTULO 13 DIEZ MITOS DEL DESARROLLO

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

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

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

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

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

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

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

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

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

LAS HABILIDADES DE UN ANALISTA

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

LAS HABILIDADES DE UN DISEÑADOR

¿QUÉ SE NECESITA PARA UN PROYECTO

La era dei técnico con conocimientos generales

La tendencia hacia la especiaiización

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

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

Program ación de herram ientas G U I de destino 3 3 0 0 1 0 2 0 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

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

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

Administración sólida de un provecto

Sobre espirales y cascadas

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

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

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

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

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

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

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

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

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

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