CONTENIDO
PRÓLOGO..........................................................................................
xix
PREFACIO........... ..............................................................................
xxi
AGRADECIMIENTOS CAPÍTULO 1
................... .................................................. xxvii
¿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 ? ..................................................... La gente a d e c u a d a ...................................................... A d m in is tra c ió n sólida de un p ro y e c to ................... M etodolog ía sólida ................................................... ¿Qué es lo que hace que una m etodología sea "buena"? ............................................................... Características de las buenas m etodologías de d is e ñ o ........................................................................ Características de lás buenas m etodologías de análisis ......................................................................
6 6
9 9 15 15 17
CONTENIDO
CAPÍTULO 2
P anorám ica de las técnicas de este lib r o .......................
21
R esum en................................... ..............................................
29
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 . ......................................................................... La declaración de la m eta ........................................
35 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 ...................................................................... M ed ició n de o b je tiv o s - E l fa c to r x ....................... R egresando a la declaración de lam eta..................
38 40 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 ........................................................................ Agentes e x te r n o s ........................................................
JO 60
Flujos de d a t o s ............................................................. Flujo de m a te ria le s ..................................................... Alm acenes de datos ....................................................
62
N om enclatura y d e fin ic io n e s ............................................
66 66 68
¡x
CONTENIDO
C A P ÍT U L O 4
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
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 ? ........... .............................................. No hay eventos internos ............................. .. Algunos ejemplos de e v e n to s ...............................
81 82 83
Los productos del m odelo de eventos........................... La lista de e v e n to s .................................................... El diccionario de e v e n to s ........................................ Matrices de e v e n to s .................................................
85 85 86 91
Descubrimiento de e ve n to s............................................. Entrevistas con usuarios ........................................ El plan g e n e ra l.......................................................... Documentación del sistema e x is te n te .................. El m odelo de c o n te x to ............................................. El m odelo de inform ación .................... .................
93 93 94 94 94 95
Tipos de e v e n to s ............................................................... Eventos inesperados ............................................... Eventos e s p e ra d o s.................................................... Revisión de los tipos de e v e n to s ...........................
95 96 96 99
Organización del modelo de e v e n to s ........................... Ordenar los eventos en el t ie m p o ......................... Ordenamiento por s u je to ........................................ Ordenamiento por objeto ...................................... Eventos nivelados .................... ..............................
99 102 103 105 107
Resumen............................................... ...............................
112
CONTENIDO
X
CAPÍTULO 5
E je r c ic io s ...............................................................................
113
R espuesta s............................................................................
114
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 .............. Una breve lección de h istoria .................................
118 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 ................................... Entidades .......................................................... ..
121
Relaciones .................................................................... A tr ib u t o s ......... ...............................................................
123 128
T ipos de entidad a trib u tiva
CAPÍTULO 6
121
......................................
137
D efinición de a tr ib u to s ...............................................
139
E ntidades a s o c ia tiv a s .......................................................... 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
EL PROTOTIPO DE INTERFAZ ..........................
161
In tro d u c c ió n ...........................................................................
161
¿Qué es un p r o to tip o ? ........................................................ El p ro p ó sito del p ro to tip o ................................... .. . B eneficios de ía creación tem prana de p ro to tip o s ............................................................... Las desventajas de la creación de p ro to tip o s . . .
162 162
¿Qué tan detallado debe ser el p rototipo?
141
163 164
.....
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 ......... A g ru p a ció n de eventos por tem a .......................... A g ru p a ció n de eventos por o b jeto .......................
CAPÍTULO 8
170 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 .......................................................... ............. ..
CAPÍTULO 7
166
186
R e sp u e sta s.............................................................................
186
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
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 ....................................................... R evisión de los co m p ro m iso s a rq u ite c tó n ic o s ............
CAPÍTULO 9
227 235
Rápida respuesta en el c lie n t e ................................. H eterogeneidad del hardw are c lie n t e ................... Heterogeneidad del softw are c lie n te .....................
235 235 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
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! . . . . ............................. Relaciones uno a m uchos ........................................ Relaciones uno a u n o ................................................. Relaciones m uchos a m u c h o s ................................. A t r ib u t o s ........................................................................
243 244 246 246 247
Selección de una clave p r im a r ia ..................................... Claves prim a ria s de varias colum nas ...................
247 252
Im plem entación de entidades de s u p e rtip o /s u b tip o . . S olución de tablas de s u b tip o /s u p e rtip o .............. S olució n de sólo su p e rtip o ..................................... S olució n de só lo s u b t ip o ..........................................
255 255 256 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 ...................................................... S ensibilidad .................................................................. P ersonalización ..................................... .................... Dirección .....................................................................
271 273 274 275
C o n s is te n c ia .................................................................
277
C laridad ........................................................................ E s té tic a ...........................................................................
278 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 Cohesión Cohesión C ohesión
c o m unicativa ............................................ procedural ................................................. te m p o r a l..................................................... lógica ..........................................................
293 293 295 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
306 307 308 E specificación de ventanas ................................... . 324
Productos del diseño de la interfaz e x te r n a ................ Panoram as del sistem a y a p lic a c ió n ............. ■ ■ . D iagram ación de la navegación por ventanas . , . 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 346
.......................................................... .
E ncapsulación O cultam iento de la in fo rm a ció n / im p le m e n ta c ió n ........................................................ . Estado persistente ................................................... .
H e re n c ia ...................................................................... . P o lim o rfism o ............................................................ .
346 347 348 348 349 351 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 ? ......... . "N u e s tra aplicación tendrá una GUI. ¿Esto hace que esté orientada a objetos? " ....
354
Identidad de los o b je to s .......................................... . Clases contra o b je to s ..................................... ■ ■ ■ ■ . M ensajes
................................................................... .
"¿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
... ..
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 ........................................ El d o m in io fu n d a m e n ta l ..........................................
356 356
El d o m in io a rq u ite ctó n ico ........................................ Eí d o m in io de negocios .............................................
357 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 ..................................... D erivación de clases de aplicación a partir del m o d e lo de eventos ............................................
358 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
381
2 . 1 ; "E l clie n te /se rvid o r es b a ra to "......................... 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
APÉNDICE
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
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...................................................................... Una entrevista con W anda W eicom e, la agente de servicio a clientes de M cV et ...............................
^00
Tras la pared en M cVet ............................................ Una entrevista con M a ty Cote, supervisora de a cica lam ien to de M cV et .....................................
406
401
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 ............
E jercicio 2 - O b je tiv o s , criterios de evaluación,
411 .
opciones de s o l u c i ó n .................................................... Ejercicio 3 - M o d e l o de contexto ...........................
412 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
—P ro totipo de in t e r f a z ..........................
414
Ejercicio 7 —M od elo a rq u ite ctó n ico ..................... E jercicio 8 —Diseño de base de d a to s ................... E jercicio 9 —Diseño de interfaz externa .............. Ejercicio 10 - D is e ñ o de com ponentes internos .
414 414 415 415
Ejercicio
6
CONTENIDO
xvii Respuestas a tos e je r c ic io s ............................................... Respuesta al ejercicio 1 — Problem as y o p o r tu n id a d e s ................................. Respuestas al ejercicio 2 —O bjetivos, criterios de evaluación, opciones de solución ................................................
415 415
421
Respuestas al ejercicio 3 — M odelo de contexto ...............................................
437
Respuestas al ejercicio 4 — M odelo de e v e n to s .................................................
439
Respuesta al ejercicio 5 — M odelo de inform ación ........................................ Respuesta al ejercicio 6 —Prototipo de in te r fa z ............................................... Respuesta al ejercicio 7 —M odelo arquitectón ico .......................................... Respuesta al ejercicio 8 — Diseño de la base de datos ................................. Respuesta al ejercicio 9 — Diseño de la interfaz externa .............................. Respuestas al ejercicio 10 — Diseño de com ponen tes internos .....................
442 454 459 461 463 493
G L O S A R IO .......................................................................................495 BIB LIO G R AFÍA ...............................................................................507 ÍNDICE
510
C a p ítu lo
1
¿QUÉ ES EL ANÁLISIS Y DISEÑO?
INTRODUCCIÓN B ienvenido al capítulo 1. En este capítulo introductorio veremos el propósito del análisis y diseño, así com o las características de un buen analista y un buen diseñador. Para poner las b a ses de los capítulos que vienen a continuación, se revisará la tendencia hacia la especialigación en nuestra industria, se tratará el debate de la m etodología de cascada contra la espiral y se su gerirán algunos criterios sobre lo que hace que una m etodología sea “buena” . Finalm ente, d a rem os una panorám ica de las técnicas que com prenden al resto deí libro, en particular las actividades y productos para el análisis y diseño de sistemas cliente/servidor con interfaces grá ficas de usuario.
1
2
Capítulo 1 / ¿QUÉ ES EL ANÁLISIS Y EL DISEÑO?
EL PROPÓSITO DEL ANÁLISIS Y DISEÑO El análisis es el proceso de determ inar qué se necesita hacer, antes de decidir cóm o debe hacer se. El diseño es el proceso de determ inar cuál de m uchas posibles soluciones es la mejor para lograr lo que se necesita hacer, respetando las restricciones tecnológicas y de presupuesto del proyecto. El diseño escoge un cóm o específico para aplicarlo al qué. El análisis es el acto de descubrim iento. El diseño es el arte del com prom iso. Tradicionalm ente, los esfuerzos de análisis han tenido una dudosa reputación en el desa rrollo del software. Casi todos saben de algún proyecto al que se le dedicaron incontables m e ses (o a veces años) dibujando miles de burbujas, flechas, cuadros y líneas, sólo para ser abandonado en un librero y com enzar a codificar apresuradam ente. Tal vez tam bién haya sabi do de algún proyecto que se saltó cualquier pretensión de análisis y com enzó la codificación desde el prim er día. La construcción del softw are es sim ilar a la construcción de una casa. M uy poca gente en sus cabales com praría un terreno, contrataría a quince carpinteros y les diría: “construyan m e una casa”, dejándolos en el cam po con un montón de m adera y una caja de clavos para que lo hagan a su real saber y entender. (J^os carpinteros no estarían muy preocupados, debido a que ya han construido casas, por lo tanto, si se presentan dudas sobre los detalles, tales como la cantidad de cuartos o pisos que se requieren, con seguridad serían capaces de resolverlos en tre ellos.) El costo de tal tontería podría estar entre los cien o doscientos mil dólares y produciría una estructura bastante extraña. Es muy probable que el propietario no estará com pletam ente satisfecho con el resultado, y es posible que la casa sea com pletam ente inhabitable. A unque parezca tan loca la historia de este propietario de casa con sus retos arquitectó nicos, no es nada en com paración a los m illones de dólares perdidos cada año en proyectos de softw are, los cuales fallan para entregar lo que los usuarios necesitan, o se derrum ban com ple tam ente sin entregar nada. A sí com o sería tonto culpar a los carpinteros p o r su falla para pro ducir una casa decente bajo esas circunstancias, es raro el caso en que un proyecto de desarrollo de softw are falle debido a la falta de habilidades técnicas por parte del personal de program a ción. La m ayoría de los proyectos que fracasan lo hacen por falta de una buena adm inistración del proyecto y por fallas en el análisis de las necesidades del negocio y para diseñar una solu ción antes de realizar la construcción del producto. Se podría decir que el propósito del análisis y diseño es, al m enos, evitar que se caiga el proyecto, y lo óptim o, que articule com pletam ente las necesidades del negocio con base en una com prensión de sus problem as actuales y que encuentre la solución que m ejor satisfaga las n e cesidades y se ajuste a las restricciones presupuéstales de recursos y tiempo im puestas por el propio negocio. Un arquitecto residencial determ ina los deseos, gustos, problem as particulares, necesidades y presupuesto del propietario de la casa y luego explora las soluciones de diseño para verificar y validar los requerim ientos antes de construir. El analista de softw are define la naturaleza del problem a del negocio y el diseñador de softw are explora las diversas solucio nes, tom ando decisiones bien inform adas para llegar a un producto que dejará a los usuarios satisfechos.1
Analista y diseñador son papeles. Pueden ser la misma persona, pegonas diferenl.es o equipos completos de personal, dependiendo del tamaño del proyecto y det conjunto de conocimientos del personal.
LAS HABILIDADES DE UN ANALISTA
3
lisio se reduce a un concepto muy simple: “Encuentre lo que el negocio requiere que se haga antes de com enzar a im aginarse cómo h a c e rlo ’’ KI factor que com plica todo es que los negocios 110 son simples y sus problem as intrín secos crecen por la presencia de personas con diferentes opiniones sobre la m anera de resol verlos (o incluso si siquiera deben resolverse), y todo el lío está coronado con un laberinto inexpugnable de sistemas heredados muy enferm os.3
LAS HABILIDADES DE UN ANALISTA El papel del analista es ir y encontrar qué problem as existen en el negocio y determ inar lo que desean que suceda quienes están a cargo del mismo. Éste es un papel y un conjunto de respon sabilidades radicalm ente diferentes a las de, por ejemplo, un programador, cuyo trabajo es es cribir código confiable. Es razonable entonces que las habilidades que se requieren en el analista sean diferentes de las que se requieren en el programador. N o m e term inan de gustar los térm inos ‘‘analista de negocios” y "analista de softw are”, debido a que los analistas exitosos son una m ezcla de arribos. Como analista necesita estar consciente en forma muy precisa de la manera en que un negocio hace dinero. Com o veremos en el capítulo 2, los sistemas de inf orm ación de negocios existen para contribuir a ello. Por otro lado, el objetivo del juego es construir el .software. Por esta razón, el analista 110 puede d e sentenderse com pletam ente de los principios básicos de la autom atización. N ecesita estar profundam ente consciente de lo que es posible, factible y práctico en lo que se refiere a la com putación en los negocios. En términos generales, el analista es un investigador, ya que el análisis es un proceso de descubrimiento, K1 analista debe estar a gusto en el papel de arqueólogo, desenterrando gemas de datos desconocidos de entre el naufragio de los archivos planos de un sistem a heredado, o descifrando los jeroglíficos de un antiguo algoritmo de algún program ador que ya ha muerto. M uchas veces el analista se convierte en un sociólogo que es forzado a aventurarse y vivir en tre la tribu para aprender sus costum bres y dialectos y para separar su m itología de la realidad. También son de gran im portancia las buenas habilidades para la com unicación. El análi sis no es una actividad “sosegada y sin sobresaltos” . En la fase de análisis de un proyecto se pasará gran parle del tiem po sacando inform ación de los posibles usuarios del sistema, reorga nizando lo que aprende y volviéndolo a presentar para su validación. Tal ve¿ sea llamado para hacer diplom acia, resolviendo conflictos y dando soluciones entre facciones del negocio que están en guerra, o pasará tiempo en el' papel de consejero de cam pam ento aliviando el miedo que los usuarios tienen al cambio. A lgunas em presas de IT (tecnología de inform ación) tienen la creencia de que si una per sona se pasa dos años encerrada en su cubículo dando m antenim iento a código COBOL, obtie ne mágicam ente el conjunto de habilidades mencionadas anteriorm ente y asciende a un orden de existencia superior: “analista-program ador”. D esgraciadam ente esto no es cierto. A] igual que muchas otras habilidades en la vida, un buen analista se crea por m edio de práctica dedi cada y aptitud para el trabajo. El analista necesita el entrenam iento adecuado y un am biente en donde pueda pulir su talento por medio de la repetición de las técnicas analíticas.
2
Los sistemas heredados son aquellos que ya existen en la compañía, incluyendo los sistemas que se vayan a reemplazar. Por lo general, han sido desarrollados hace algún Tiempo con (etnología vieja.
4
Capítulo 1 / ¿QUÉ ES EL ANÁLISIS Y EL DISEÑO?
" í j o t e P G -E o c 'jy e s. b i c c x i o u £ b S t í -\ e g u n j a t ? a e r e D o c u H e w r A D A
y e S u i ^ e o c c s o lío".
M uchos program adores talentosos se convierten en analistas excelentes, sin embargo, la program ación no es un requisito previo para el trabajo del analista. El conjunto de habilidades y aptitudes que se requieren para hacer am bas cosas es muy dispar y tal v e / no siem pre se dé en la m ism a persona. En m uchos establecim ientos de IT. el ascenso a “program ador/analista” involucra muy poco o ningún cambio en la cantidad de program ación requerida para el traba jo , y de hecho, se pasa muy poco tiempo realizando análisis. Hn estas situaciones, “analisla” es un título indicativo únicam ente del nivel de salario. 1.a realidad es que ningún esfuerzo de desarrollo de software de tam año apreciable pue de hacerse sin las habilidades de buenos adm inistradores, analistas y teenólogos. L’na em pre sa de IT con buen personal tratará de atraer y cultivar estos tres conjuntos de habilidades dentro de la organización y recom pensará a cada uno de estos de acuerdo con su experiencia. A lgunos establecim ientos han m ostrado éxito conviniendo a usuarios de sistemas en analistas, aunque esto, por lo general, requiere algún grado de entrenam iento sobre los d e talles de la autom atización. M uchos colegios de educación superior y universidades ahora están ofreciendo cursos sobre negocios con una concentración en la tecnología de la inform a ción, o aum entando su currículum en ciencias de la com putación con cursos sobre contabili dad, m ercadotecnia, producción y adm inistración en general. Kste es precisam ente el tipo de fundam entos educativos que form an una base sólida para una carrera com o analista.
LAS HABILIDADES DE UN DISEÑADOR
5
LAS HABILIDADES DE UN DISEÑADOR K1 diseñador es un bicho ligeramente diferente al analista. M ientras el enfoque del analista es tá orientado principalm ente hacia los negocios, con una fuerte base en la tecnología; el enfo que del diseñador es principalm ente sobre la tecnología con una fuerte base en los negocios. O diseño se refiere casi com pletam ente a los com prom isos, i 1 diseñador se enfrenta con la enorm e tarea de m apearlos requerim ientos del negocio, con la tecnología disponible. El ana lista se puede dar el lujo de suponer una tecnología perfecta. Él docum enta 1os requerim ientos del usuario cum o si todos los procesadores fueran infinitam ente rápidos y todos los datos es tuvieran disponibles instantáneam ente. Sin embargo, el diseñador debe hacer que los deseos y fantasías de los usuarios se ejecuten en el lastim ero conjunto de m áquinas que pone a su d is posición el departam ento de IT. El diseñador traza los planos a partir de ios cuales se construirá el sistema, lo que lo convifc.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,
Capítulo 1 / ¿QUÉ ES EL ANÁLISIS Y EL DISEÑO?
6
¿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 lallaron 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 especiolizaciú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.
Capítulo 1 i ¿QUÉ ES EL ANÁLISIS Y EL DISEÑO?
8
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 :
C ecíle
Jeanne
K athy
Yvonne
B rian
M a ry
A n n e tte
Elsie
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 á 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
3 = p ro fe s io n al ava n zad o
i = m a e s tro , p ro fe s o r
B ob
2 = con práctica en un pro y e c to
CU rc •C
o
s
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 cotivenierle para la enseñanza de las técnicas de ingeniería de software. D e hecho, observará que este libro está dispuesto en una forma similar, con el capítulo sobre ei plan general del proyec to precediendo a los capítulos sobre análisis y a continuación los capítulos sobre diseño. Sin embargo, la organización para el aprendizaje de una serie de técnicas no siempre es igual a la organización para el empleo de una sene de técnicas en nuestro caótico y ambiguo mundo real. A unque pocos pueden argum entar en contra de que la planeación debe preceder al análisis d e tallado, y que el análisis es un precursor lógico del diseño y la construcción, sería tonto insis tir que un proyecto de desarrollo a gran escala term ine toda su análisis antes de realizar nada del diseño, o que debiera diseñar lodo el sistema antes de construir cualquier parle de él. Los instructores de ingeniería de software han advertido desde hace mucho que, aunque sus cursos se presentan con un enfoque de cascada, los proyectos reales se ejecutan en lases, sucediendo muchas tareas en form a concurrente y con un grado moderado de iteración de ajus te mientras se aprenden cosas sobre la marcha, las cuales causan que se revisen tareas anterio res. Mi teoría es que muchos gerentes de proyectos estaban fuera del salón o hablando por teléfono durante esta plática en particular. Por lo tanto, la historia de la ingeniería de software está salpicada con fallas m onum entales que fueron el resultado de una mala adm inistración de las técnicas, más que de la falla de adecuación de las técnicas mismas.
¿QUÉ SE NECESITA PARA UN PROYECTO CLIENTE/SERVIDOR EXITOSO?
11
El desarrollo en fases increm entales y algún grado de iteración de ajuste, siem pre ha si do una práctica clave en la impl em entad ón exitosa de cualquiera de los llamados métodos de cascada (figura 1-3). Los buenos gerentes de provecto lo han estado haciendo durante años. Las m etodologías de cascada en realidad sufren de una m ala analogía. El agua, s.i.endo víctim a de la gravedad, no tiende a regresar hacia arriba de la colina para dar otro paso por su propia caí da. D e m anera similar, la gente tiende a tratar los regresos hacia el análisis o el diseño como una falla en vez de ser un paso hacia adelante.
Figura 1-3. Una cascada con iteraciones de ¡ruste integradas.
¡mplementacíón en fases Es una práctica sensata hacer los proyectos grandes en fases (figura 1-4). Una de las principa les razones es que el aprendizaje que se obtiene mientras se tom a una parte del proyecto a tra vés de su ciclo de vida com pleto proporciona experiencia valiosa que agiliza el desarrollo de fases subsecuentes. Otro beneficio es la entrega temprana de algunas partes del sistem a que puede usar el negocio.-5 Muchas fallas de proyectos que han sido achacadas a la cascada, en realidad fueron re sultado de nna falla del empleo de buenas técnicas de modelado en un plan de implemcntaeión correctam ente dividido en fases. El térm ino “parálisis de análisis” fue acuñado para describir proyectos que se encuentran entram pados en un gran dominio del problem a, para su desgracia, sin una conclusión previsible para el inmenso esfuerzo de modelado. Tales proyectos fueron cancelados, por lo general, por patrocinadores frustrados convencidos de que el departamento de IT se había convertido en estudiantes profesionales analizando el problem a en vez de hacer algo por él, o lo que es peor, las necesidades del negocio habían cam biado tan drásticamente en los siglos transcurridos desde que el proyecto se inició, que el sistema resultante sería ob soleto antes de que fuera instalado.
¿
Es tu se conoce tradicionalmeiite como “rugía de los 18 meses". Cualquier provéelo que billa en entregar n¡go en 18 rnese.s es probable que se cancele. Desafortunada ícente, la ventana de expectativas de 18 meses se está acíucaudo en los ambientes de negocios apresurados de estos días.
12
Capítulo 1 / ¿QUÉ ES EL ANÁLISIS Y EL DISEÑO?
F ig u ra 1-4. Un enfoque de cascada en fases.
El enfoque espiral Por el contrario, el modelo de desarrollo espiral (figura 1-5) integra las fases y la iteración de ajuste en la metáfora. El modelo espiral fue desarrollado originalm ente en el Pentágono étimo un método para controlar los costos desbocados de armas masivas y provectos de desarrollo de sistemas de defensa. La idea fue dividir el proyecto en fases más cortas de análisis, diseño, de sarrollo y evaluación. Después de cada fase se evalúa la viabilidad del trabajo term inado ju n to con una estim ación refinada para las siguientes fases. E sta técnica de p re su pu estación proporcionó revisiones de factibilidad cruciales para proyectos en donde frecuentem ente esta ban haciendo investigaciones sobre tecnologías com pletam ente nuevas. Se toma una decisión en la fase de evaluación sobre sí se debe continuar con otra iteración de ajuste. L a idea de la espiral ha cam biado ligeramente para adaptarse a las sensibilidades pecu liares de la industria de) software. En vez de enfocarse en el control del presupuesto, la espiral se ha em pleado com o un método para la entrega tem prana de código en una m etodología que ha llegado a ser popular bajo el'term ino RAI) (Desarrollo Rápido de Aplicaciones). El RAD com bina el enfoque espiral con una estrategia de división de un proyecto gran de en "cuadros de tiem po7' (figura 1-6). Un cuadro de tiempo es un conjunto de características definido que se prom ete entregar a los usuarios dentro de un marco de tiempo fijo, digamos ÍJÜ días. Dentro del cuadro de tiempo se realiza algo de análisis, un diseño breve y luego, usando herram ientas de desarrollo de alto poder, se construye un prototipo funcional. ILI prototipo es revisado por los usuarios y se solicitan modificaciones. El ciclo de codificación y de refinación del prototipo se repite tres veces, yendo en espiral volviendo a analizar, diseñar, y evaluar. Al final del cuadro de tiem po se instala la aplicación resultante. En la práctica, el RAD sufre de malas aplicaciones igual que la cascada. M uchos geren tes y program adores ven el modelo espiral como tres iteraciones de ajuste de “codificación’'. La ventaja principal del RAD es la codificación temprana, y en muchos establecim ientos la
¿QUÉ SE NECESITA PARA UN PROYECTO CLIENTE/SERVÍDOR EXITOSO?
13
producción de código es vista com o la única m edida tangible de que se ha realizado una acti vidad significativa, listo lleva a la m entalidad de "tres strikcs y out", en donde cualquier cosa que parezca análisis y diseño es rápidam ente abandonada, dando com o resultado sistemas d é biles que se desem peñan en form a dudosa en la fase de m antenim iento de su eiclo de vida.
Figura 1-5. U na m etodología espiral.
C u a d ro de tie m p o I
C u a d ra de tie m p o t!
E n tre g a de fase I
C u a d ro rfe tie m p o II!
En treg a de fase II...
Enlro g a de ... fa se n
Figura 1-6. Tres iteraciones espirales dentro de cuadros de tiem po.
Tos puntos tuertes del RAD son que los usuarios se involucran intensam ente, la creación temprana de prototipos y la im plem entación en fases. Sus puntos débiles incluyen una tenden cia hacia la codificación temprana, lo que hace que pasen muchas tarcas de análisis y diseño a m anos del program ador y, por lo tanto, depende de los técnicos con conocim ientos generales. Se apoya en program adores que son maestros de sus respectivas herramientas de desarrollo y
14
Capítulo 1 / ¿QUÉ ES EL ANÁLISIS Y EL DISEÑO?
am bientes de program ación y a) mismo tiempo son adeptos al diseño de interfaces y ai análi sis de negocios, además son com únicadores talentosos. E l enfoque abrum ador sobre el cuadro de tiempo hace difícil la construcción de com ponentes reutili/ables a largo plazo, y cuando se acerca la fecha de entrega lo prim ero que se hace es la docum entación. En vez de adm inistrar contra una especificación tangible, el adm inistrador se encuentra armado sólo con un látigo y un cronómetro. La m edida de avance principal se convierte en la cantidad de revisiones que se han hecho al código. Recientem ente m e encontré con un cliente al que lo habían enviado a un sem inario para investigar el desarrollo espiral. Mientras estaba ahí aprendió acerca de las técnicas RA D y la manera en que el software es m ejorado in ere mental m ente por la espiral, con cada iteración de ajuste. Regresó a trabajar el lunes “ilum inado" y anunciando al equipo del proyecto: “ la cali dad de un sistem a de software es proporcional a la cantidad de versiones que se han desecha do” . Esto m e pareció como el estribillo de una industria que tiene todo pero ha abandonado la idea de construirlo bien desde la prim era vez. Su conclusión, dem oledora para el presupuesto, me recordó la historia de Odius y Tedius, dos constructores de templos de la antigua Roma. Odius fue un gerente de proyecto rom ano establecido ccrca de Salisbury. Inglate rra, en el siglo ni d.C., de quien se dice que declaró, “L a calidad de un tem plo es proporcional a la cantidad de templos que se han desechado” . Después de ordenar la construcción y subsecuente dem olición de al m enos tres versiones del templo deí pueblo, fue asesinado brutalmente en un ataque de sus conscriptos bretones. Resultó que los habitantes del pueblo le habían ahorrado al em perador el costo de una ejecución pública, debido a que Odius había sobrepasado su presupuesto de capital y 110 tenía nada que mostrar a cam bio de ello, a excepción de tres m on tones de escombros.
'
Odius fue sucedido por su primo, Tedius, quien em pleó un enfoque de cascada es tricto para la construcción dei templo. D espués de tres años de analizar y balan cear las necesidades de los sacerdotes, dioses y fieles, Tedius ha producido rollos v más rollos de m odelos y diagramas, pero le falta aún la m ateriali/ación de un templo en la llanura de Salisbury, Tedius fue despedido sim ultáneam ente del pro yecto y del planeta por su falla en la entrega.
Tanto el enfoque de cascada com o el espiral tienen sus puntos buenos. D esafortunada mente am bos sufren de abusos brutales en el mundo real. Yo creo que la clave para el éxito del proyecto se encuentra en algún lugar entre esos dos extremos. H1 hecho es que un gerente mag nífico será capa?: de hacer que funcione un enfoque de cascada o espiral. Si tiene que trabaja)' con el de cascada dividirá al proyecto en varias fases e introducirá algún tipo de iteraciones de ajuste controladas. Si le toca un espiral, continuará em pleando buenas técnicas de “cascada” a íravés de cada fase e iteración de ajuste, para crear unidades más discretas con las cuales pue da ser adm inistrado el proyecto en forma efectiva.3 Con las personas adecuadas con habilidades adecuadas, em pleando una adm inistración sensata en productos en fases y usando una buena m etodología de desarrollo, un proyecto pue-
-
Fs> probable que un rntil ¿frente de proyecto haga uti enredo de cualquier en toque.
¿QUÉ ES LO QUE HACE QUE UNA METODOLOGÍA SEA "BUENA"?
15
de g o /a r los beneficios de una buena base de modelos sin hundirse en d pantano de la paráli sis del análisis ni obteniendo soluciones inadecuadas en un frenesí de clics del ratón y co d ifi cación.
¿QUÉ ES LO QUE HACE QUE UNA METODOLOGÍA SEA "BUENA"? Una buena m etodología arma a sus practicantes con un juego de herramientas de técnicas confiabies 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 ant.üS de construirlos.
Capítulo 1 i ¿QUÉ ES EL ANÁLISIS Y EL DISEÑO? 2, B! diseño necesita ser com pleto, de tal form a que cubra cada uno de los aspectos prin cipales del software que necesita construirse. Esto causará que se tengan varios üpos di ferentes de m odelos en la docum entación del diseño. En form a sim ilar a les planos arquitectónicos para la cim entación, enm arcado, sistemas eléctricos y de plom ería de una casa, d plano de diseño de software incluye un modelo para la disposición de la ba se de datos, la disposición de ventanas y reportes, la navegación en las ventanas, las es pecificaciones para cualquier otra interfaz electrónica y modelos estáticos y dinámicos de los com ponentes internos. Cada modelo está especializado para m ostrar un aspecto particular del sistema. Encontrará que los m odeladores son particularm ente adeptos de la articulación de esos aspectos para los que está orientada la técnica de modelado, p e ro fallan m iserablem ente cuando se trata de estirar el modelo más allá de su propósito original. Ningún modelo puede mostrar todas las facetas del sistem a funcional com ple to. Ese sería el sistem a mismo. 3, Bl diseño debe ser verificable antes de su construcción. Uno de los propósitos principa les del diseño es revisar y discutir la solución antes de lanzarse a la carga y codificarla. Parte del proceso de verificación es su rastreabilidad. Con una buena especificación de diseño se debe ser capaz de dem ostrar que se satisfarán los requerim ientos del proyec to y asim ism o se distinguirá entre varias versiones del diseño en cualquier momento. La docum entación del diseño va dirigida a dos públicos diferentes. Las partes externa m ente visibles del diseño (disposiciones de ventanas, reportes, diagram as de navega ción, m enús y especificaciones de botones) necesitan ser revisadas por los usuarios. Esto significa que una gran parte del diseño externo debe ser escrita en una form a no muy técnica. Las especificaciones internas de lo que sucede tras bam balinas es otro asunto, su público se lim ita a la com unidad de la IT que debe construir, probar y m an tener el sistem a. La especificación interna debe ser escrita directam ente para esta au diencia. 4, Una buena metodología de diseño crea productos diferenciados que son mensurables. Una de las tareas más difíciles de cualquier proyecto es estim ar cuándo se term inará. Para hacer una estim ación el gerente del proyecto debe tom ar m edidas, la cual involu cra el conteo de cosas que necesitan hacerse y la aplicación de algún tipo de m edida sobre de ellas para estim ar qué tanto tiem po se llevará el hacerlas. La medición viene, por supuesto, de haber contado estas cosas en el pasado y haber m edido qué tanto tar dó el hacerlas anteriorm ente (o plagiando el sistem a de medidas de otra persona). Por lo tanto, una m etodología de diseño debe producir com ponentes discretos lo m ás pron to posible. “¿Q ué tantas tablas tenem os? ¿Q ué tantas ventanas se requerirán para la in terfaz? ¿Q ué tantos reportes se requieren? ¿Cuál es la cantidad de objetos que necesitam os diseñar y construir?’' Tan pronto com o el gerente pueda tener productos firmes que contar, puede com enzar a refinar ía.s estim aciones de los esfuerzos requeridos y los conjuntos de habilidades n e cesarias para lograr la tarea. Conform e el proyecto avanza tendrá productos interm edios con los que se pueda m edir el avance. "¿Cuántas ventanas se lian diseñado? ¿Cuántas faltan de diseñar? ¿Cuál es la tasa de productividad del equipo? ¿Cuál es el tiempo pro medio que se lleva codificar y probar una ventana y sus funciones de tondo? ¿Cóm o in fluye esto en nuestra estim ación original?"
¿QUÉ ES LO QUE HACE QUE UNA METODOLOGÍA SEA "BUENA"?
17
5. Por último, pero no menos importante, el di seno debe ser fácilm ente aprovechado en el producto iinal. D ebe expresar el uso y la estructura del sistem a en una form a muy cor eana al resultado pretendido. Este punto puede parecer obvio, pero he visto proyectos que trataron de usar técnicas de diseño que fueron com pletam ente inadecuadas para el lenguaje de destino en el que se codificó el sistema. U sted no querría que su arquitecto casero le presentara un plano que fuera tan esotérico que no le diera idea de la forma que tendría la casa en su terreno. El lema del diseñador es: hacer un mapa de la técni ca hacia si destino. Si el sistem a va a operar con una base de datos relacional se deben escoger técnicas que sean particularm ente adecuadas para el diseño de bases de datos relaciónales. Si el sistem a em pleará un lenguaje orientado a objetos, entonces se debe rán usar técnicas de diseño orientado a objetos para las partes del sistem a que requieren objetos para lograr sus tareas. Si el sistem a incluirá com ponentes más tradicionales, ta les com o junciones estructuradas en las rutinas cliente o por lote en el servidor, enton ces son adecuadas técnicas de diseño estructurado mas tradicionales para esas partes del sistema. M uchos de los sistemas de negocios cliente/servidor actuales incluyen todos los para digmas del lenguaje anteriorm ente mencionados, tratando valientem ente de vivir en ar monía. Si esto es cierto para su sistema, entonces su docum ento de diseño incluirá una diversidad de técnicas de diseño que van desde la relacional y la orientada a objetos, hasta la tradicional, cada una establecida de acuerdo con sus respectivas partes de des tino en el sistema.
Características de las buenas metodologías de análisis El analisis consiste en com prender y docum entar las necesidades del usuario. La com prensión viene de hacer preguntas y escribir las respuestas, exam inar las respuestas y hacer más pre guntas. L n analista que no hace preguntas está realizando un análisis dudoso. Un analista que no escribe nada no ha hecho ningún análisis, sino que sim plem ente está en un curso de autoayuda expandiendo su conocim iento personal del negocio. L a falta de docum entación de ios descubrim ientos analíticos sabotea los cinco beneficios de un análisis exitoso. El resultado no es ni analítico, ni com pleto, ni verificable, ni m ensurable, ni aprovechable. Suponiendo en tonces que un buen análisis está escrito, una m etodología de análisis exitosa presentará las si guíenles características: L Una técnica de análisis debe m otivar el acto del descubrim iento proporcionando un marco de trabajo en el que el analista puede escribir lo que ellos saben y evaluar lo que tienen que aprender. Esto incluye ci tener inventiva para guiar el análisis. Por ejemplo, la técnica de análisis del modelado de inform ación indica que el analista descubre la po lítica del negocio para los cuatro puntos cardinales de cada relación/’ El m odelo propor ciona un lugar para registrar esta inform ación y el resultado está a la vista para su revisión en el diagram a entidad-relación.
(l
l,os conceptos sobre el modelado de información se cubren en el capítulo 5.
18
Capítulo 1 / ¿QUÉ ES EL ANÁLISIS Y EL DISEÑO? 2. La m etodología de análisis debe ser com pleta respecto a que cubra adecuadam ente cada uno de los aspectos del problem a de negocios. Com o verem os posteriorm ente en este libro, los sistem as de negocios tienen datos que deben recordarse, reglas de pro cesam iento y com portam iento definible. La m etodología de análisis necesita ser lo suficientem ente rica para m odelar los tres puntos de vista. D ebido a que ningún m o delo puede servir adecuadam ente en todas las situaciones, necesitam os em plear un conjunto de m odelos entrelazados, especializados que nos perm íta cam biar nuestra perspectiva para cada faceta del dom inio del problem a. 3. Los resultados del análisis necesitan ser vcrificables. La fase de análisis también tiene un público dual. Los usuarios son el público principa! para aprobar los docum entos co mo una representación precisa de sus necesidades. La mayoría de los modelos de in geniería de softw are Talla para satisfacer este requerim iento. El usuario prom edio no va a descubrir una relación de cardm alidad que no sea exacta en un m odelo de iniorm 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-relación o invitando a los usuarios a llenar datos reales con plum ones de colores en los ace tatos en los que aparecen las ventanas. El otro público del docum ento de análisis es, por supuesto, el propio equipo del proyec to. La calidad del análisis im pactará a la calidad del diseño. Las técnicas de análisis ne cesitan ser precisas y no am biguas de forma tal que el diseñador pueda concebir una solución sin tener que volver a hacer todo el proceso de análisis. 4. La m etodología de análisis tam bién debe crear unidades m edibles p ara el gerente del proyecto. A l inicio de la etapa de análisis, el tam año y alcance del proyecto pueden ser un poco difusos. El negocio quiere saber cuándo se le entregará el softw are y el gerente del proyecto todavía no conoce la dim ensión del problem a. Los modelos de análisis tem pranos pueden ayudar mucho para indicar cosas que el gerente pueda co n tar. Estos contcos inicíales se utilizan para extrapolar el esfuerzo que se requiere para el resto dei proyecto. El gerente deberá preguntarse, ‘‘¿qué tantas entidades están in volucradas? ¿N uestro sistem a crea, lee, actualiza o borra todas esas entidades? ¿Qué tan'.os eventos de negocios significativos deben reconocerse de acuerdo con el plan general del sistem a? ¿Estos eventos necesitan actualizaciones de tablas sim ples o re quieren un procesam iento significativo? ¿Q ué tanto nos lleva analizar problem as de
¿QUÉ ES LO QUE HACE QUE UNA METODOLOGÍA SEA "BUENA"?
19
este tam año? D ada la cantidad de entidades que esperam os m antener, ¿qué tantas ven tanas se necesitarán diseñar? 5. Esto nos lleva al punto final de la posibilidad de su aprovecham iento. Nadie en esta in dustria puede negar que una m etodología de análisis debe m otivar al propio análisis, ser com pleta, verificable y m ensurable. Ll qué tanto deba ser fácilm ente convertible en un diseño y, por lo tanto, pueda tener tendencia hacia un tipo de diseño particular, ha probado ser el catalizador para muchos debates de conferencias acaloradas y conflic tivas. La sabiduría convencional ha dicho desde hace mucho que el análisis debe ser una ar ticulación de la esencia del problem a, com pletam ente Ubre de cualquier solución par ticular, de ahí viene el térm ino análisis esencial. Ln la práctica, la gente ha encontrado que algunas técnicas de análisis están predispuestas para convertirse en un diseño par ticular, más fácilm ente que otras. Si se enfrenta con un conjunto de m etodologías de análisis com petitivas, cada una de ellas repleta con técnicas que m otiven el buen aná lisis, tengan una cobertura balanceada de los datos, el procesam iento y el com porta miento, sean igualm ente verificables y produzcan resultados m ensurables, entonces lo que lo im pulsará a tom ar una decisión, probablem ente será su capacidad de aprovecha miento. l.in mi propia carrera todavía no he en contradi) una técnica de modelado de análisis que carezca com pletam ente de alguna tendencia técnica. Hl análisis estructurado,7 y su én fasis sobre la diagram ación del flujo de datos está muy orientado a procesos. Hs muy fácil convertir un conjunto de diagram as de flujo de datos en una gráfica de estructura para un sistema 3GI,. Listo está bien para ¡a construcción de sistemas orientados a pro cesos. No es tan fácil convertir un conjunto de diagram as de flujos de datos a un dise ño orientado a objetos. I.a técnica es también bastante problem ática para el diseño de interfaces gráficas de usuario. Ln una form a muy similar, el ÜOA (análisis orientado a objetos);' goza de un factor de convertibilidad mucho mayor si el destino es un com pleto sistem a orientado a objetos. Si el destino 110 es un sistem a orientado a objetos o tal vez es un sistema de paradigm a mezclado (por ejemplo, relaciona!, 4GI - y algunos objetos), entonces el análisis orien tado a objetos tendrá un factor de convertibilidad m enor y puede, de hccho, haccr más difícil la labor del diseñador. Hl OOA es sim plem ente otra form a para organizar la m is ma información esencial que debe ser articulada en cualquier esfuerzo de análisis exi toso, La organización OOA puede estar bien adecuada para proyectos orientados a objetos sólo por ser más directam ente aprovechable en e! diseño orientado a objetos, y no porque goce de ninguna superioridad com o técnica analítica, o sea en alguna forma más com pleta, verificable o mensurable.
7
De Marco, 1979.
8
B ooch, 1994, Jacob sen e( ;il , 1992, R timban gb et al., 1991.
20
Capítulo 1 / ¿QUÉ ES EL ANÁLISIS Y EL DISEÑO? La habilidad para convertir fácilm ente un m odelo de análisis a un diseño atraviesa una línea Fina entre la articulación del problem a y el ordenar una solución. La form a de los m odelos de análisis puede influir profundam ente la form a del diseño. U na m etodología de análisis particular puede dictar un tipo de diseño particular, ya que escoger cualquier otro estilo de diseño podría representar la reescritura del docum ento de análisis. En este caso, el análisis prohíbe, de hecho, la imaginación de un paradigm a de diseño alter no. El peligro de esta situación es que el analista puede tom ar prem aturam ente decisio nes de diseño en nom bre del análisis, cancelando opciones que pueden ser pospuestas con seguridad hasta un m om ento en que exista m ejor inform ación sobre la cual basar una decisión. Un ejem plo com ún se da en los modelos de análisis orientados a objetos, en donde el analista trata de asignar un método particularm ente preocupante a su único mejor am biente, sólo para encontrar que el proceso puede vivir en una diversidad de clases, y teniendo cada una de las soluciones sus respectivos pros y contras.v Este tipo de com prom iso es indicativo de una decisión de diseño y no de un descubrim iento de análisis. Por otro Jado, una m etodología de análisis particular puede m otivar o perm itir una va riedad de diseños proporcionando suficiente material de análisis que se ensam bla fácil m ente en form as distintas. Es probable que si una m etodología de análisis m otiva determ inados tipos de diseño, puede desm otivar otros. {Por ejemplo, un modelo de in form ación puede m otivar un diseño relacional y desm otivar el uso de, digam os, tecno logía de arreglos tridim ensionales.) Por últim o, una técnica de análisis puede ser com pletam ente neutral respecto a las di versas opciones de diseño que puedan em plearse. La conversión hacia un paradigm a u otro podría realizarse con igual facilidad o dificultad.
Para este libro he escogido específicam ente un conjunto de técnicas de análisis, m odela do de contexto, modelado de eventos, modelado de inform ación y creación de prototipos de in terfaz, las cuales creo que son adecuadas para la gran m ayoría de sistem as de negocios cliente/servidor actuales, y se apegan bien a los cinco criterios de una buena m etodología. C a da m odelo tiene un firm e fundam ento histórico en i a ingeniería de softw are y un largo registro de éxitos en ia industria. Se ha probado que m otivan el buen análisis y tratan una am plia gam a de procesos, datos y com portam iento del sistema. L a inclusión del prototipo de interfaz tiene un largo cam ino para hacer que los resultados del análisis sean verificables por la com unidad de usuarios. Los m odelos tam bién producen unidades discretas que pueden ser contadas y m e didas, tales com o entidades, eventos, ventanas y reportes. Estas unidades ya llevan el tiempo suficiente para lograr una base m odesta de m ediciones dentro de la industria. Entonces, ¿dónde destacan las técnicas de este libro en el tem a del aprovecham iento? Las actividades de análisis, que se detallan en los siguientes capítulos fueron seleccionadas con el aprovecham iento en mente. Siendo alguien que ha pasado casi el m ism o tiempo diseñando sistemas que analizando, la habilidad para la transición fácil del análisis al diseño es muy im portante para mí.
9
Las técnicas orientadas a objetos se tratan en el capítulo 12.
PANORÁMICA DE LAS TÉCNICAS DE ESTE LÍBRO
21
I ,a premisa tecnológica de este libro es que el sistema de negocios de destino es muy pro bable que incluya una base de datos relaciona!, una interfaz gráfica de usuario y una diversi dad de lenguajes de program ación, que pueden ir desde los orientados a objetos, los basados en objetos, en SQL y los 3GL tradicionales, tendiendo la industria cada vez más hacia las cons trucciones orientadas a objetos. Los m odelos de análisis necesitarán convertirse fácilmente en diseños para este ambiente. He incluido técnicas que caen en la categoría de m otivadoras y fa cilitadoras para el diseño del destino, sin m andar absolutam ente un paradigm a de diseño par ticular o prohibir otros. H e escogido el modelo de inform ación com o el modelo de datos principal, debido a su excelente registro de éxitos para la creación de diseños de bases de datos relaciónales bien nor malizadas. Esta es una técnica que ha sido muy popular y exitosa y, por consecuencia, la dis ciplina goza de un am plio campo de profesionales expertos. Hl modelo de inform ación muestra m uy claram ente lo que el sistema necesita recordar, sin sobrecargarse con elem entos procesa les que los sistemas de adm inistración de bases de datos relaciónales existentes no son capaces de manejar. Se incluye el modelo de eventos debido a que es particularm ente adecuado para organi zar la especificación del análisis en una manera tal que se presta muy bien para el diseño de la interfaz gráfica de usuario m anejada por eventos, una tarea que consum irá mucho tiempo del proyecto. Hl diccionario de eventos proporciona el marco de trabajo para la especificación de procesos internos del sistem a. Junto con el m odelo de inform ación, contiene las m aterias prim as necesarias para declarar una estructura de clase para un sistem a orientado a objetos, diseñar gráficas tradicionales de estructura para com ponentes del sistem a o para diseñar pro cedimientos almacenados para el sen ad o r de base de ciatos. Hl modelo de contexto se incluye como una técnica aceptada desde hace m ucho para la determ inación y representación del alcance del proyecto. Ls principalm ente una herramienta de planeación que ayuda a clarificar el área de estudio y determ ina qué es lo que se encuentra dentro y fuera de su propio control.
PANORÁMICA DE LAS TÉCNICAS DE ESTE LIBRO Entremos a la tarea importante de ver en forma previa lo que se encuentra entre esta parte y el índice. Usaré la pirám ide com o m etáfora geom étrica principal para organizar las actividades de desarrollo de sistemas (figura 1-7). Hay un gran significado asociado a la pirám ide. También podría usar un cuadrado, un círculo o un conjunto de nubes sin forma, pero encuentro ad ecu a da la representación piramidal por varias razones. La pirám ide nunca perm ite que se olvide que el código que se construye es sim plem en te la base de una estructura que está especificada para que alcance un conjunto de objetivos del negocio. En la parte superior de la pirám ide está el plan general del proyecto. Esto in clu ye la m eta del proyecto y los objetivos que la soportan. Estas son las razones por las que el proyecto existe en prim er lugar. Bajo el plan, en una form a descendente, se encuentran todas las actividades que necesitan suceder entre la identificación de los objetivos del proyecto y la colocación de los unos y ceros en la parte inferior de la pirám ide que son el softw are r e sultante.
22
Capítulo 1 / ¿QUÉ ES EL ANÁLISIS Y EL DISEÑO?
M odelo M odelo M odelo de co n te xto de in fo rm a ció n de e ve n to s Pro to tip o de in terfaz M odelo arq u itectó n ico D iseño de b a se de d atos D ise ñ o de in te rfa c e s externe D ise ñ o de co m p o n e n te s interr C o n stru cció n y prueba
F ig u ra 1-7. La pirám ide de desarrollo de] software.
Si piensa sobre el tiem po que se lleva viajar de norte a sur, la pirám ide describe gráfica m ente un conocim iento cada vez más expandido acerca de un tema específico, conform e se desciende de las alturas del análisis hacia el diseño en la parte inferior y luego com enzar a pro fundizar en el código. Los gerentes de proyecto, los patrocinadores del negocio y los más cí nicos de nosotros preferim os im aginar la pirám ide com o el cada v e / más am plio gasto de dinero que se hacc conform e avanza el tiempo, T,a estructura de la pirám ide no pretende de ninguna form a dictar un enfoque de cascada o espiral para ¡legar de arriba a abajo. Kn vez de ello m uestra cóm o el código final y el análi sis interm edio y los producios del diseño soportan el plan general del negocio. El que llaga su proyecto en fases o que lo desarrolle de un solo golpe dependerá del tamaño del proyecto y las exigencias del negocio. Com encem os en la parte de arriba y vayam os hacia abajo: lodo proyecto necesita un plan general (figura 1-8) que contiene las órdenes de m archa del negocio que articulan ia m eta final y los objetivos del proyecto. El plan general del proyec to es una herramienta de organización que es desarrollada en conjunto por el grupo de IT y el negocio. E s vital para definir y controlar el alcance. Sin un plan general del proyecto el analis ta no tiene dirección o prioridades claras de lo que debe analizar, además no tiene idea de dónde debe detenerse. En el capítulo 2 se cubrirá específicam ente el plan general del proyecto. Tal vez tenga curiosidad de saber por qué están los siguientes tres m odelos alineados en ei m ismo nivel de la pirámide. El modelo de contento, el modelo de eventos y el modelo de in formación son tan ínterdependientes que es im posible term inar uno sin tener buena parte de los otros. Les llamo los “tres grandes", debido a que juntos forman el conjunto de los requerim ien tos del sistema. El m odelo de contexto (figura 1-9) define las fronteras del sistem a y m uestra la m ane ra en que está situado dentro del am biente del negocio. Esta es una técnica de modelado muy antigua que viene desde los días del análisis estructurado. Es particularm ente útil en el mundo c lie rite/servidor para explorar cí impacto del movim iento de la frontera de la autom atización en el negocio. Este tema se trata en el capítulo 3.
PANORÁMICA DE LAS TÉCNICAS DE ESTE LIBRO
23
Fifíura 1-H, R1 plan genera] del proyecto.
Figura 1-9. K1 modelo de contexto. I'l modelo de eventos (figura 1-IÜ) define el com portam iento del sistem a mostrando la m anera en que se espera que responda éste para cada evento del negocio establecido en el plan general del proyecto. El modelo de eventos no solam ente m.apea las entradas y las salidas, si no que también incluye la especificación de procesam iento para cada evento, la cual propor ciona detalles cruciales para el diseño interno de las funciones, métodos y procedim ientos del sistema. El modelado de eventos es una técnica analítica vital para el descubrim iento y la do cum entación de las reglas del negocio. Debido a que las interfaces gráficas de usuario son, por definición, “m anejadas por eventos” , el modelo de eventos proporciona el marco de trabajo y la racionalidad para el diseño de la interfaz gráfica de usuario. El capítulo 4 de este libro está dedicado al modelado de eventos.
24
Capítulo 1 / ¿QUÉ ES EL ANÁLISIS Y EL DISEÑO?
K1 modelo final de los “tres grandes” es tal v e / el crucial. El m odelo de inform ación (fi gura 1-11) contiene el m apa estático de los datos que requiere recordar el sistema. Intluvc pro fundamente el diseño de base de datos e impacta virtual mente en todos los aspectos del sistema. 1-as técnicas de m odelado incluyen la diagram ación entidad-relación, la definición de atributos y la diagram ación de transición de estados. Los modelos de inform ación tam poco res petan las fronteras del proyecto. M uchos de los datos que se m odelarán para el sistem a tam bién aparecerán en otros sistemas dentro de la organización (y tal vez tam bién fuera de ella). Por esra razón es im perativo que los esfuerzos del m odelado de inform ación tengan alguna coordinación a nivel de toda la em presa. El modelado de inform ación siempre debe realizarse con un fuerte sentido de contexto, lim itado por el alcance de los eventos del negocio. En caso contrario, podrá m odelar datos por siem pre o hasta que se le acabe el tiempo o el dinero. El modelado de inform ación es el tem a de 1 capítulo 5.
PANORÁMICA DE LAS TÉCNICAS DE ESTE LIBRO
25
El prototipo de interfaz (figura 1-12) se encuentra inm ediatam ente abajo de los “ tres grandes” modelos. Soy un gran partidario de la creación tem prana de prototipos, en especial de los que son rápidos y fáciles. E l prototipo pone una cara para los m odelos abstractos mostran do cóm o se podrían ver las ventanas y reportes en el nuevo sistema. A unque la creación de pro totipos com ienza tem prano en la fase de análisis, es el prim er avance hacia el diseño de sistemas. En la práctica he encontrado que es virtualm ente im posible term inar a los “tres gran des” sin verificar los requerim ientos con algún nivel de prototipo de interfaz. En algunos pro yectos he usado la creación de prototipos aún antes, p ara obtener los requerim ientos de eventos del negocio y el m odelo de inform ación. Tal vez se encuentre usted yendo y viniendo entre los “tres grandes” y ei prototipo varias veces hasta que usted y sus usuarios estén convencidos de que com prenden sus necesidades. Un sistem a robusto puede tener m uchos tipos diferentes de prototipos. La clave para la creación de prototipos exitosa es identificar primero el objetivo de aprendizaje y luego escoger el método más efectivo en costo de creación de prototipos para al canzar ese objetivo particular. La creación de prototipos es el tem a del capítulo 6.
Figura 1-12. El prototipo de interfaz.
E l capítulo 7 hace una breve pausa en el m odelado p ara discutir el im portante tem a de la resolución de asuntos del negocio. U no de ios m ás insidiosos depredadores de proyectos en el am biente cliente/servidor es ei costo oculto de la reingeniería de! negocio. El enfoque cliente/servidor proporciona frecuentem ente estandarización y autom atización a fronteras del negocio que antes eran dom inios de la hoja de cálculo, del procesador de palabras, de la n o ta am arilla adherible y de las servilletas de coctel garabateadas. Com o analista tal vez se e n cuentre en ía posición desafortunada de descubrir huecos que afectan los objetivos del negocio, en las prácticas o políticas, sin tener ninguna autoridad para resolverlos. E l cap ítu lo 7 plantea un proceso de resolución de asuntos que puede usarse para elim inar estos obstáculos del proyecto. . E n el capítulo 8 regresam os a nuestra pirám ide con el m odelo arquitectónico, liste m o delo es el proceso de m apear ¡os requerim ientos del negocio articulados en los m odelos de aná
26
Capítulo 1 / ¿QUÉ ES EL ANÁLISIS Y EL DISEÑO?
lisis h a d a una diversidad de configuraciones de hardw are y la selección de la más adecuada o la m enos restrictiva. Para esta tarea, los modelos de análisis necesitan com plem entarse con al gunas estadísticas, tales com o los volúm enes de transacciones, las tasas de eventos, tamaños de registros y las expectativas de los usuarios en cuanto a los tiempos de respuesta y actuali dad de los datos. No hay respuesta “correcta” en este modelo arquitectónico. Cada negocio y cada am biente de program ación de destino tiene sus imperfecciones. La clave para un m ode lado arquitectónico exitoso es ser capaz de usar los m odelos para evaluar los com prom isos de diseño y el desem peño relativo de diferentes esquem as de distribución geográfica, así com o la distribución entre niveles de hardware dentro del mismo sitio de negocios. A unque muchas de las actividades de análisis y diseño pueden ser fácilm ente divididas y realizadas en fases, es probable que gran parte de la arquitectura cliente/servidor general del proyecto com pleto se decida antes de la prim era fase del diseño. En la práctica también es po co probable que se escoja el hardw are después de que se haya realizado lodo el análisis. La vía arquitectónica por lo general corre paralela con los esfuerzos de análisis. En algunos proyec tos tal vez no se pueda escoger el hardware más adecuado, y en vez de ello se esté forzado a exprim ir el softw are en la desvencijada colección de máquinas que ya se encuentran en el cuar to de com putadoras. El modelo arquitectónico (figura 1-13) ocupa esta posición tardía en la pi rámide debido a que es el últim o punto hasta el que se pueden diferir en forma segura las selecciones arquitectónicas, y es también el punto en el eual ya se está arm ado con la m ejor in form ación sobre la cual basar estas decisiones.
El diseño de base de datos (figura 1-14) transform a e! modelo de inform ación a un es quem a físico de base de datos. El que diseñe toda la base de datos de un golpe o en fases, pue de depender de si el proyecto se com pone de fases o no. Al igual que m uchos de los tenias de este libro, una discusión com pleta sobre el arte del diseño de base de datos podría llenar un li bro com pleto. El objetivo del capítulo 9 es mostrar la m anera en que el modelo de inform ación se transform a en un diseño de base de datos relacional inicial y discutir las diversas opciones de que se dispone para optim izar el desempeño.
PANORÁMICA DE LAS TÉCNICAS DE ESTE LIBRO
27
Figura 1-14. El diseño de base de datos.
Los capítulos 10 y 11 tratan el diseño de la. interfaz gráfica de usuario. El capítulo 10 co m ienza con una discusión sobre lo que hacc que una GUI sea “buena”. M uchos de los concep tos represenian un cam bio significativo del mundo de pantalla verde de la mainframe. La últim a parte del capítulo 10 presenta el concepto de cohesión de ventanas. H e aplicado la m e dida de cohesión de módulos del diseño estructural de Larry C onstantino,10 y la he adaptado com o una calificación del impacto sobre las capacidades de uso y m antenim iento para com bi nar varios eventos de negocios en la m isma ventana. E l diseño de interfaz externa (figura 1-15) se trata en el capítulo 11. Esto incluye la diagram 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;ipean directam ente hacia el paradigm a del lenguaje de codificación de destino. Sí el sistema in cluye código orientado a objetos, entonces el diseño interno incluirá modelos de clase y modelos de com unicación de objetos dinám icos para esa parte del sistema. Si el sistem a inclu ye funciones m ás tradicionales y procedim ientos de bases de datos, entonces se encontrará trazando gráficas de estructura y escribiendo especificaciones para procedim ientos alm acena dos. El capítulo 12 m uestra la m anera en que se aprovecha el modelo de análisis en las activi dades de diseño interno.
10 Y ourcktn, C onstanl.int:, 1979.
28
Capítulo 1 / ¿QUÉ ES EL ANÁLISIS Y EL DISEÑO?
M o d e lo ,.r . de c o n te x to
. M o d e lo
d é in f ir m a c ió n
/lo d e lo
Rentos
d
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
d e c o n te x to d e in fo rm a c ió n
¿lodelo 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 proeedural, 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 esla fase. Muchos se han encontrado atrapados en una reunión en donde los patrocinadores dcJ n e gocio demandan una estim ación de costos precisa en un cien por ciento desde el prim er día en que plantean sus icquerim icntos. (Aunque se reserven el derecho de cam biar los requerim ieti los en cualquier momento, sin alee lar la fecha de entrega o el presupuesto.) A unque es común, esta situación se debe principalm ente a la ignorancia, inexperiencia u optim ismo del usuario, ílle encontrado a ejecutivos que creen que produce ganancias ju g ar estos juegos y, por lo ge neral, ese tipo de individuos con su imprudencia, llevan a la em presa por un curso ríes soso y traicionero.) ' ^ No es conveniente dejarnos llevar y decir cualquier cifra bajo coacción. Una estim a ción sólo es precisa al cien por ciento el último día del proyecto. En el p rim er día, una esti m ación no vale el oxígeno que se necesita para expresarla. Lo que se necesita es una form a para ponerse rápidam ente en la escala de precisión de cero por ciento a un nivel que puedan sobrellevar tanto usted com o el negocio. El proceso de establecer el plan general está dise ñado para aum entar rápidam ente la com prensión del problem a y, p o r lo tanto, le perm ite in crem entar la precisión de las estim aciones para encontrar una solución tan pronto com o sea p o sib le. He encontrado que si se involucra íntim am ente a los m iem bros del negocio en la crea ción del plan general, aum enta su sentido de propiedad del proyecto y su valoración, así como su apreciación sobre el reto de producir proyecciones signilieativas de costos, tiempo y recur sos, con inform ación limitada. Una buena estim ación nunca está grabada com pletam ente en piedra, por el contrario, se vuelve a revisar periódicam ente conform e el proyecto avanza, para verificar y revisar las esti maciones. I .a adm inistración de un proyecto contra un plan general bien elaborado también la considero la mejor forma para valorar el impacto de los cambios que suceden a lo largo del de
34
Capítulo 2 / EL PLAN GENERAL DEL PROYECTO
sarrollo. Cuando los miembros del negocio ayudan a crear el plan general, es m uy probable que com prendan la form a en que los cam bios de requerim ientos a mitad dei proyecto pueden afec tar el tiempo y el presupuesto requeridos para term inar el sistema.
CUÍDESE DE LOS PLANES GENERALES IMPRECISOS M uchos desastres de proyectos pueden achacarse a un plan general im preciso o inexistente. L.’n ejemplo espectacular sucedió una vez en l 'rieda’s P ren d í Frv Factory.1 Los sistemas del área de fabricación de la em presa se ejecutaban por medio de un conjunto diverso de aplicaciones por lotes muy antiguas. El sistema fue escrito hace quince o veinte años en una m ezcla de C O BO L y lenguaje ensamblador. Los usuarios com enzaron a preguntarse en voz alta el porqué sus hijos utilizaban una PC en la escuela para identificar constelaciones y, en cambio, eilos tenían que seguir tecleando com andos m nemónicos en una pantalla en blanco,2 Fenw ick P rescott el director de inform ática, se m ovió rápidam ente para form ar un equi po de proyecto, escoger unas siglas y com enzar con la im portante tarea del análisis de los re querim ientos, D esgraciadam ente no se preocupó de producir un plan general en donde se indicaran los objetivos y el alcance del proyecto. Un equipo de analistas profundizó en el ne gocio haciendo gran cantidad de diagramas, burbujas, ílechas, cuadros y líneas. Hn unos cuan tos m eses el alcance del análisis se había am pliado desde los sistemas de producción hacia ventas, registro de pedidos, facturación, contabilidad, recursos hum anos y nómina. Cada usua rio y gerente del negocio añadió su propia lista de requerim ientos al proyecto, creando una dis persión de alcance monumental. El gerente del proyecto no tenía nada contra qué evaluar los resultados, debido a que la expectativa original nunca se había escrito y acordado. Después de dieciocho meses estaba claro que el equipo del proyecto estaba perdido en el desierto. La euforia inicial se había desgastado desde hace mucho y se había abierto una bre cha de inconform idad cnt.rc el negocio y el departam ento de IT. Convencido de que el depar tamento de IT era incapaz de producir cualquier cosa, el director ejecutivo negoció un trato secreto para conseguir la adm inistración de inform ación de la com pañía en l’orma externa y su m ariam ente despidió a todo el personal de la IT, incluyendo al asediado y desconcertado Sr. Prescott. La lección que debe aprenderse es que el plan general establece una obligación contrac tual entre la IT y el negocio, lis importante ser explícito en cuanto a las expectativas y respon sabilidades de cada parte. Si no se hace por escrito, las expectativas no establecidas pueden volverse contra usted. Lin el m ercado de inform ación global actual, una falla de proyecto, téc nica o política, puede dar como resultado la elim inación com pleta del departam ento de IT,
1
Se han cambiado ios nombres para protegía- a los culpables.
2
h ito Ci an ejemplo ordinario, pero poderoso, sobre la manera en que la PC ha cambiado las expectativas de los usuarios sobre lo que constituye una interfaz- aceptable. Muchos empleados se rehúsan simplemente a usar la tecnología antigua, y las compañías esián encontrando que es cada v e / más diííeil atraer a ios nuevos universitarios sraduados a trabajos que involucran el uso de sistemas basados en caracteres.
EL MARCO DETRABAJO PARA LA TOMA DE DECfSIONES DEL PROYECTO
35
EL MARCO DE TRABAJO PARA LA TOMA DE DECISIONES DEL PROYECTO Cualquier ciclo de vida de desarrollo sensato incluye una etapa, de planeación o viabilidad. Me gusta el térm ino “plan general de proyecto” debido a que denota “razón de ser” , El m arco de trabajo para la tom a de decisiones es una técnica para reunir a la gente a fin de lograr consen so sobre las metas, objetivos y criterios de evaluación de un proyecto. Esta visión com ún se utiliza com o base para seleccionar opciones a lo largo del proyecto. La figura 2-1 m uestra un diagram a del m arco de trabajo para la tom a de decisiones. En la cim a de la pirám ide está la m eta deS proyecto: un resum en que perm ite que todos sepan lo que se trata de lograr con el proyecto. En !a siguiente capa se tienen una variedad de objeti vos que soportan la m eta. Estos son una especie de pequeñas m etas. Cada objetivo, en algu na forma, contribuye a lograr la meta, la cual se alcanza cuando se satisfacen todos los objetivos.
Figura 2-1. El marco de trabajo para la toma de decisiones de un proyecto.
La capa que sigue a los objetivos, es la de los criterios de evaluación. E sta capa contie ne las m ediciones que se necesitarán para determ inar si se ha logrado un objetivo. H1 estrato inferior de) m areo de trabajo para la tom a de decisiones representa las diversas opciones de so lución. Dichas opciones de solución son ías diversas rutas que pueden tom arse para alcanzar la meta. Éstas se valoran contra los objetivos, usando los criterios de evaluación y así determ inar cuál es la que satisface m ejor los objetivos del proyecto. El resto de este capítulo se enfocará en la m anera de usar el m areo de trabajo para la tom a de decisiones a fin de crear un plan general para el proyecto. Éste no es un ejercicio p a ra que un gerente lo realice a escondidas en una esquina oscura. El m arco de trabajo para la
36
Capítulo 2 / EL PLAN GENERAL DEL PROYECTO
tom a de decisiones del proyecto es una técnica que requiere participación abierta de los usua rios, del personal técnico y de los gerentes, quienes representan a todas las partes interesadas en e! nuevo sistem a. Los planes generales de proyecto m ás exitosos resultan de un a p lan ea ción cuidadosa y de la ejecución de una serie de sesiones para alcanzar el consenso, en d o n de alguien que facilita las cosas, conduce al grupo a lo largo de la construcción del marco de trabajo. Para m uchos proyectos tam bién se requerirá algún grado de m odelado adicional, tal co m o los m odelados de contexto, de eventos y de inform ación, antes de que se puedan realizar estimaciones razonables del alcance y tam año del proyecto. Estos temas se tratarán en capítu los posteriores.
La declaración de la meta Recuerdo un paseo que hice una vez con mi vecino. Él era un ingeniero retirado que trabajó en el cohete de propulsión para el program a Apolo. Recuerdo que le pregunté, “¿Cómo es que un equipo de m iles de individuos de todo el país pudo poner a un hom bre en la Luna en los años sesenta y actualm ente sea una batalla el proporcionar un sistem a de captura de pedidos decen te?” Su respuesta fue bastante simple. “Todos conocíam os la meta. Las personas involucra das en el proyecto A polo no tenían dudas acerca de su misión. Teníamos que poner un hombre en la Luna antes de que term inara la década, y regresarlo con seguridad a la Tierra.” (Estoy convencido de que el sindicato de astronautas insertó la cláusula de “regresarlo” en la versión 1.2 de la declaración de la meta.) L a meta del program a A polo era clara. Era corta e iba al punto. No era am bigua, debido a que se usó lenguaje simple que todos podían entender. Lo mejor acerca de ella es que era m ensurable. Se sabía lo que constituía el éxito, específicam ente, llevar a alguien a la Luna y regresarlo con seguridad antes del 31 de diciem bre de 1969. Otro factor importan te era que m u cha gente creía que esto se podía lograr. Aparte de la m eta explícita, también había una m eta im plícita en el proyecto A polo que no estaba establecida oficialmente. ¿Puede recordar cuál era?3 Todo proyecto de sistem a de inform ación tiene una meta. El factor que com plica las co sas es que los sistemas de negocios no son sim ples. Las personas tienen diferentes puntos de vista en lo que se refiere al proyecto. Se necesita un plan general para concentrarse en la meta del proyecto. La m eta necesita ser clara, no ambigua, concisa y m ensurable. Todos necesitan estar de acuerdo sobre ¡o que es y saber cuando se ha logrado. ¿Pero cóm o definir la meta? He encontrado que es muy difícil com enzar a escribir una oración que resum a todo el proyecto. U na form a m ejor para definir la m eta es a través de la lista com pleta de objetivos individuales que deben lograrse para que el proyecto sea un éxito. Los objetivos se determ inan descubriendo todos los problem as que hay en la form a actual de hacer negocios y proporcionando ideas sobre oportunidades no aprovechadas. D espués de que la lista de objetivos ha sido ratificada por el grupo, puede ser destilada en una declaración de m eta resum ida que represente al conjunto de los objetivos del proyecto.
■' La mei a implícita era "ganarle a tos rusos la carrera a la Luna" Esta meta no estable ¡ida probablemente sirvió mucho más ^ara motivar al proyecto, que la meta oficialmente establecida.
EL MARCO DETRABAJO PARA LA TOMA DE DECISIONES DEL PROYECTO
37
Regresaré a la declaración de la m eta después de que haya discutido los problem as, opor tunidades y objetivos.
Los problemas y las oportunidades son la base para los objetivos Cuando se reúne por prim era vez a un grupo de usuarios del sistema, gerentes del negocio y personal técnico para discutir un nuevo sistem a de inform ación, es inevitable que la gente co m enzará diciendo todo lo que está mal con el sistem a antiguo. D e hecho, es muy probable que se dé poca o ninguna discusión acerca de una nueva visión del futuro sino hasta que todos h a yan tenido oportunidad de ventilar la frustración que sienten con ia forma actual de hacer negocios. Esta es una dinámica hum ana im portante que hay que reconocer, y com o analista se p u e de tom ar ventaja de ella. El proceso de ventilación es critico. Se necesita dar a los usuarios la oportunidad de desahogarse, al principio de la fase de planeación, en un am biente controlado. Si no ventilan sus asuntos es probable que se queden gruñendo y causen problem as durante todo el tiempo que dure el proyecto. Para obtener mejores resultados, una com binación de usuarios y gerentes deberá reunir se con los m iem bros del equipo del proyecto en una sesión que puede durar varios días o una semana. Quien facilita las cosas desem peña el papel de dirigir la discusión y de hacer las pre guntas, teniendo cuidado de no interferir con su propia opinión. A veces vale la pena pagar a un consultor profesional para que proporcione la neutrali dad de un tercero que requiere este papel. Todas las reuniones se registran ya sea electrónica o m anualm ente. Es de gran im portancia que cuando un usuario diga su problem a, vea que uno lo escribe.
Problemas Kl inicio del proceso analítico com ienza preguntándole a la gente qué hay de m alo en el am biente actual. Por lo general, las personas com ienzan poco a poco, sin querer ofender o lla mar la atención hacia ellos mismos, pero rápidam ente se encienden las pasiones y el grupo expióla en una letanía de pecados que ellos ven en el sistema actual. Cada una de estas decla raciones se registra en una lista de problem as. El objetivo del ejercicio es descubrir la mayor cantidad de problem as posibles, pero no tratar de resolverlos en ese momento. Un sistema de inform ación nuevo es una solución. Para diseñar la solución adecuada se debe com prender el problem a que se está traíando de resolver. Los problem as pueden ir desde la variedad de los obstáculos im portantes (como, “el sistema antiguo produce resultados falsos que 110 se pueden tom ar com o datos precisos"), hasta los m undanos (como, “los reportes de im presora son difíciles de leer” ). Existe un problem a en cualquier m om ento en que alguien no esté satisfecho con el com portam iento o capacidades de su sistema de inform ación existente y puede expresar lo que piensa que debiera ser el com portam iento o capacidad adecuado. Por ejemplo, si un em pleado de captura de pedidos se queja de que el sistem a es dem asiado lento, ¿entonces cuál es un tiem po de respuesta adecuado? En el libro best seller de 1982 The One M inute M anager, los doc tores Kenneth Blanchard y Spencer Johnson dan una definición m agnífica de un problem a en térm inos de com portam iento.
Capítulo 2 / EL PLAN GENERAL DEL PROYECTO
38
“Un problem a existe si hay una diferencia entre lo que está sucediendo actualm ente y ¡o que se desea que s u c e d a .D e s p u é s añaden: “Si no puede decir m e lo que le gustaría que estuviera sucediendo, todavía no tiene un problema. Sim plemente se está quejando. ”‘í
Al asentar cada queja com o un problem a se deja la puerta abierta a m uchas diferentes opciones de solución.
La diferencia entre problemas y oportunidades Además de los problem as con los sistemas, organización y procedim ientos actuales, puede ha ber oportunidades no explotadas disponibles para el negocio que no han sido utilizadas. La di ferencia entre problem as y oportunidades es sutil. Un problem a existe cuando algo no eslá trabajando y se le quiere componer. En cuanto a una oportunidad, no hay nada necesariam en te malo. La oportunidad se presenta cuando se puede aprovechar una nueva tecnología, pro ductos o servicios que no existían antes o que no habían sido considerados. Las oportunidades están inspiradas frecuentem ente por la nueva tecnología. Por ejemplo, un participante puede llegar con la idea de dar com putadoras laptop o de mano al per sonal de ventas para que puedan escribir los pedidos en torm a electrónica m ientras están en el camino. Debemos tener cuidado de no indicar una solución tecnológica en nuestra declaración de oportunidades. Puede haber muchas formas para explorar las oportunidades, tanto tecnoló gicas com o 110 tecnológicas. Una buena declaración de oportunidad para nuestro ejemplo es: “elim inar la captura de datos redundante moviendo la captura de datos para que esté más cer ca de la fuente” .
Objetivos A unque m uchos planes de proyecto se inician y terminan tradicionalm entc con una am plia lis ta de requerim ientos, el propósito de determ inar los objetivos es obtener las razones que se en cuentran Iras los requerim ientos. Por ejemplo, un requerim iento com ún que he visto es “el sistem a debe tener interfaz con una im presora lá s e r’. Después de buscar el objetivo subyacen te, puede encontrar que el problem a real es que los clientes no pueden leer sus facturas debido a que se im prim en en papel rosado con un tipo de im presora de impacto con tinta morado pá lido. El “requerim iento” fue la solución propuesta por alguien para el problem a. El objetivo verdadero del requerim iento podría ser “reducir errores en los pagos e increm entar la satisfac ción del cliente com unicando con claridad los cargos que se hacen en cada factura” . Cuando se especifica el asunto de esta manera, se abre la puerta para una diversidad de soluciones, que van desde cam biar el color del papel en la im presora de impacto hasta m andar las facturas a los clientes por medios electrónicos. Un objetivo es una frase que cuando se lleva a eabo elim ina el problem a o aprovecha una oportunidad. Los objetivos son com o “pequeñas m etas” . También deben ser claros, concisos y m ensurables. Cada objetivo soporta a una parte de la m eta (figura 2-2). Si se llegan a alcanzar todos los objetivos se ha alcanzado la meta total,
'■ Blcimihaid y John>un. 1982.
EL MARCO DETRABAJO PARA LA TOMA DE DECISIONES DEL PROYECTO
39
Figura 2-2. M uchos objetivos pueden soportar ¡a. meta.
Cada problem a y oportunidad se convierten en un objetivo aplicando un concepto sim ple llamado ÍR A C IS (lacrease Reverme, Avaid Cost, fm pruve Service), liste es un viejo térm i no de !BM'a . que se refiere a increm entar las ganancias, evitar los costos y m ejorar el servicio a nuestros clientes. N ecesitam os recordar que los negocios existen para ganar dinero y tener clientes satisfechos.’ I .a razón por la que existe el sistema de inform ación del negocio es para ayudar a la com pañía en esta misión. Utilizando el IR A C IS es bastante fácil convertir un problem a u oportunidad en un ob jetivo que establece si el negocio va a obtener un aumento en las ganancias, una dism inución en los costos o un servicio a clientes mejorado cuando se cum pla con él. M uchos de los obje tivos pueden caer en más de una categoría. Determ inando si tratam os de aum entar ganancias, evitar costos y m ejorar el servicio, este ejercicio nos enfoca para encontrar una form a para m e dir a fin de cuentas el objetivo. También, el objetivo tiende a evitar que los participantes en el establecim iento del plan general planteen soluciones técnicas y los im pulsa a considerar las ra zones del negocio para sus propuestas. Tometnos un problem a identificado por un grupo de m ercadotecnia en una em presa de impresión de cheques de seguridad que proporciona cheques a bancos y otras instituciones fi nancieras, Cuando los clientes abren nuevas cuentas en el banco se les muestra un conjunto im presionante de cheques personales que pueden ser suyos por una pequeña cuota. M uchos de estos cheques solí productos creados especialm ente para este banco p o r la empresa. Se supone que la fuer/a de ventas de la im presora de cheques es el principa] contacto con los clientes para todos los aspectos de la relación, !■! grupo de desarrollo de productos del d e partam ento de m ercadotecnia tenía un problema. Éste era que el personal de ventas que estaba en el campo tenía métodos incom pletos e inconsistentes para la recolección de inform ación vi tal acerca de los nuevos clientes y los nuevos productos que requerían esos bancos. Esto forzó
^
Los eseéptiens pu^clen argumentar que algunas agencias gubcrnamenlalcs existen para perder dinero l: irri tar a los clientes, jx'iu su misión de negocios subyacente debería ser la nihirm.
40
Capítulo 2 / EL PLAN GENERAL DEL PROYECTO
al grupo de desarrollo de productos a establecer contactos separados con los clientes para acla rar sus necesidades, cansando retrasos en la planeación de nuevos productos. Problem a: El personal de ventas proporciona inform ación incom pleta al grupo de desarrollo de productos acerca de los nuevos clientes y los requerim ientos de nuevos productos. ¿Cómo podem os convertir esto en un objetivo'? Com encem os haciendo que el problem a negativo sea una oración positiva. E l personal de ventas necesita proporcionar inform ación com pleta al grupo de d e sarrollo de productos acerca de los nuevos olientes y de los requerim ientos de productos nuevos. Luego necesitam os aplicar el IR A C IS. Como analista, usted se pregunta, "¿resolvien do este problem a es probable que increm entem os ganancias, evitem os costos o m ejorem os el servicio a los clientes?'’. Planteemos algunas posibilidades: Increm ento efe ganancias: N o hay correlación aparente entre la obtención de in form ación com pleta de clientes y productos y la obtención de m ás clientes o más ventas de los clientes existentes. E v ita r costos: La obtención de inform ación com pleta acerca de los clientes defi nitivam ente bajará los costos para los nuevos productos, en el proceso de la infor mación que realiza el grupo de desarrollo, debido a que no tendrán que volver a llam ar a los clientes m uchas veces para solicitar aclaraciones.
Mejora de servido: También m ejorará el servicio al cliente. Cuando a los clientes se les molesta menos disminuye su costo actual de hacer negocios con la compañía.
A hora podem os volver a establecer el objetivo usando los térm inos IR AC IS ade cuados. O bjetivo: Evitar el costo de llam ar a los clientes para pedir aclaraciones, hacien do que el personal de venias proporcione inform ación com pleta sobre los .nuevos productos. Kso tam bién m ejorará el servicio a los clientes reduciendo la cantidad de veces que se tiene que hacer contacto con ellos.
Medición de objetivos —El factor x Todav ía no hem os term inado con nuestro objetivo. Este objetivo es claro y conciso, ¿pero cóm o lo mediremos'.’ Aquí es donde fallan m uchos planes generales de proyecto. Llegan a esta etapa y cantan victoria, pero el trabajo real apenas com ienza. N ecesitam os encontrar al go a lo que yo llamo el escurrid izo fa c lo r x. El fa c to r x pone un núm ero al increm ento en ga-
EL MARCO DETRABAJO PARA LA TOMA DE DECISIONES DEL PROYECTO
41
milicias, a la dism inución de costos y a la m ejora de servicios para cada objetivo que es po sible medir. Si nunca establecem os el fa c to r x, ¿cóm o llegarem os a saber si el proyecto es exitoso? Regresando a la em presa de im presión de cheques, esta com pañía particular no tenía idea de cuánto tiempo gastaba realm ente el grupo de desarrollo de productos haciendo contacto con los clientes para pedir aclaraciones. Por lo tanto, ¡ni siquiera sabían que tenían un problem a! Hay un viejo adagio de negocios que dice, ‘‘N o se puede m ejorar lo que no se mide". Si sólo se percibe que se tiene un problem a, en realidad 110 se puede continuar para tom ar ninguna de cisión racional para resolverlo, sino hasta que se sabe su im portancia relativa y se tiene algu na idea del grado en que se le puede atacar. L1 proceso de creación de un plan general de proyecto frecuentem ente descubre la nece sidad de hacer algunas m ediciones básicas en la organización. Es im portante que se hagan es tas m ediciones. Cuando se descubre un objetivo al que le falta cualquier medida sobre el grado del problem a, los siguientes pasos le perm itirán registrar la deficiencia y continuar con la reu nión del grupo. 1. Establecer con el grupo la m anera en que podría m edirse el objetivo. Se pueden to m ar m ediciones tangibles en térm inos de tiempo o dinero. A lgunos objetivos pueden requerir m ediciones intangibles, tales com o “satisfacción del cliente” . Los objetivos diseñados para m ejorar el servicio a clientes pueden ser difíciles de medir. U na téc nica es tratar de m edir el costo del cliente para hacer negocios con uno, ya sea en tiempo, en dinero o en esfuerzo. Trate de obtener tantas mediciones tangibles como pueda para el plan general. Le ayudarán a establecer el lado de los beneficios para cualquier análisis costo-beneficio que se pueda realizar sobre las diversas opciones de solución. 2. inserte un factor x en la declaración del objetivo, mostrando dónde se necesita una medición. La existencia de la variable hace que sea claro, para cualquier lector, que la declaración del objetivo está incompleto hasta que se proporcione un valor. O bjetivo, (con factores x insertados): [ivitar el costo de llamar a clien tes para aclaraciones [por x $) haciendo que el personal de ventas propor cione inform ación com pleta sobre nuevos productos. Esto tam bién m ejorará el servicio al cliente reduciendo la cantidad de veces que se ha ce contacto con él (y número de llamadas). 3. A signe personal específico para establecer las m ediciones básicas para evaluar el al cance del problem a. En el ejemplo podrían medir la cantidad de llam adas y la dura ción de cada una. También podrían clasificar las llamadas por el tipo de inform ación que se está solicitando. Tam bién se tendrá que establecer un costo de mano de obra prom edio para el departamento, 4. E stablezca un tiem po para volver a reunir al grupo, después de que se hayan realiza do las m ediciones, a fin de revisarlas y evaluar el grado en que se quiere atacar el problem a.
42
Capítulo 2 / EL PLAN GENERAL DEL PROYECTO
Se debe ser muy cuidadoso si el plan general incluye un objetivo que prom ete una reduc ción en cosios de m ano de obra. La im plicación es que el provecto pretende reducir personal. No ponga esto en el plan general a menos que pretenda conseguir ese resultado. Muy frecuen tem ente los ahorros en mano de obra no reducen el personal, sino que, en vez de ello, despla zan a los trabajadores de actividades de oficina hacia tareas de más provecho. Esto no elim ina el costo del trabajador a la com pañía; sino que hace que, sean más productivos (eso espera mos). A segúrese que el plan general ponga en claro cuáles resultados pretende entregar el. pioyecto. El plan general deberá indicar con claridad el criterio por el cual usted será juzgado cuando lo termine. Otra tram pa com ún que hay que evitar es lo que le llamo los objetivos de m aternidad y buena alim entación” . Estos son objetivos muy vagos, tales com o, el nuevo sistema evitará costos elim inando todos los errores del ciclo de producción” . Todo mundo puede estar de acuerdo en que esto es algo bueno, pero es com pletam ente inalcanzable. E ste tipo de declara ciones deja al proyecto muy vulnerable a las fallas. El proyecto puede ser severamente critica do com o un desastre cuando suceda el prim er error en la producción después de la instalación del nuevo sistema. No se necesita ninguna investigación para escribir un objetivo de “maternidad y buena alim entación” . En vez de ello deberá preguntarse, ' ‘¿cuál es la tasa de errores en el ciclo de pro ducción actual y cuál es la causa fundam ental de esos errores? “¿Q ué tanto puede esperarse razonablem ente que un sistem a de inform ación nuevo o m ejorado dism inuya la tasa de estos errores?” “¿Que otras soluciones creativas pueden em plearse para reducir los errores en pro ducción?” ^ . . . Los factores x que se pongan en el plan general deí proyecto se usarán para justificar la existencia del proyecto y, a final de cuentas, se usarán para valorar su éxito cuando se entre gue. Piense en elíos com o sus casos de prueba y tom e el tiempo para m edirlos y negociar expectativas razonables con el negocio.
Regresando a la declaración de la meta... Después de que haya com pilado una lista exhaustiva de los objetivos con el grupo y haya determ inado el método de m edición de cada uno, es tiempo de regresar a la declaración de la meta. Si ya tiene un borrador con una declaración de la m eta del proyrecto, revíselo y cornjalo a la luz de los objetivos y vea si todavía resume el proyecto. Si se pospone la declaración de la m eta hasta después de que se hayan term inado los objetivos, ahora es tiempo de destilarlos en un resumen corto que pueda servir com o meta final del proyecto. U na buena técnica para analizar y resum ir los objetivos es agruparlos en categorías. Lis te todos los objetivos que increm enten las ganancias, seguidos por aquellos que eviten costos y, po r último, aquellos que m ejoren el servicio a clientes. Algunos objetivos pueden caer en dos o hasta en las tres categorías.
Establecimiento de ¡a prioridad de los objetivos No todos los objetivos se crean de la m ism a forma. El equipo para el plan general necesita de term inar cuáles objetivos son más im portantes que otros. Para hacer este ejercicio se necesita tener resueltos los factores x. El equipo necesitará una fuerte indicación sobre cuáles proble mas son los más severos v cuáles objetivos contribuirán más al bienestar de ia com pañía. Este
EL MARCO DETRABAJO PARA LA TOMA DE DECISIONES DEL PROYECTO
43
upo de análisis también requiere frecuentem ente alguna dirección de la alta gerencia. La direc ción estratégica del negocio también puede desviar la ponderación de la lista de objetivos. Las buenas declaraciones de metas son com o las de los objetivos. Necesitan ser: C la ra s y no am biguas (con palabras cortas, com unes y com prensibles)
Concisas (deben bastar de una a tres oraciones)
M ensurables (deben incluir m ediciones para los objetivos m ás críticos) Regresem os por un m om ento a nuestro ejemplo de la em presa de im presión de cheques. Antes de pasar por el marco de trabajo de tom a de decisiones hicieron un borrador inicial de la declaración de meta. En la m añana del prim er día de sesiones, los usuarios y sus gerentes es tuvieron muy contentos con la siguiente meta: "La m eta del proyecto es proporcionar a l departam ento de mercadotecnia un sis tema de com putación para la recolección y disem inación de información sobre nuevos productos. ’’ Ellos habían establecido una solución en vez de una meta. Después de seguir los pasos que se indican en este capítulo rccscribieron su declaración de m eta de la siguiente manera: "Nuestra meta es reducir de cinco a dos días, el tiempo que le lleva al departa m ento de m ercadotecnia validar y com pletar las especificaciones para un nuevo producto, desde el m omento en que se recibe lu inform ación completa de la ofici na de ventas, hasta la entrega de especificaciones precisas y aprobadas a las p la n tas de producción. " Es claro, no am biguo, conciso y m ensurable. De hecho, cuando este grupo particular ter minó con el m arco de trabajo para la tom a de decisiones estableció una solución, la cual ni si quiera involucra un nuevo sistem a de com putadora. Sucedió que m ediante la com binación de entrenam iento a los vendedores y un nuevo diseño de formularios, ¡fueron capaces de lograr su objetivo sin tener que volver a escribir ni un solo sistem a automatizado! Cuando los objetivos son ordenados y ponderados en térm inos de su im portancia relati va, se está listo para finalizar la declaración de meta del proyecto y pasar a la siguiente parte del marco de trabajo para la tom a de decisiones.
Criterios de evaluación La siguiente capa del marco de trabajo para la tom a de decisiones del proyecto es el criterio de evaluación que establece la m anera en que se m edirá cualquier solución dada en relación con los objetivos. Las m ediciones del factor x de los objetivos le proporcionan m uchos criterios de eva luación. Por ejem plo, si un objetivo es “evitar costos de $1,400 m ensuales elim inando la transferencia de docum entos en papel entre la bodega y la planta” , entonces el criterio de eva luación es m edir a qué grado cualquier tipo de solución propuesta satisface el objetivo de la reducción de $1,400 m ensuales.
Capítulo 2 / EL PLAN GENERAL DEL PROYECTO
44
Convierta sus objetivos en criterios de evaluación Para establecer una lista de criterios de evaluación com ience listando los objetivos m ensura bles o tangibles. E stablezca cóm o valorará cualquier solución contra la medición. ¿Debe el ob jetivo ser satisfecho com pletam ente o pueden aceptarse soluciones que satisfagan el objetivo de destino en algún grado m enor? Para los objetivos que no pueden m edirse fácilm ente tam bién se necesita determ inar el criterio de evaluación. Discuta dentro del grupo cóm o podría tra tar de valorar una solución contra cada objetivo intangible. ^ Cuando hava term inado este paso deberá tener un criterio de evaluación establecido p a ra cada objetivo. Los criterios de evaluación deberán tener una ponderación que corresponda a la im portancia relativa de los objetivos.
Extienda la lista con criterios estándar de evaluación de costos Cualquier evaluación de los cursos de acción propuestos, deberá involucrar alguna determ ina ción de costo/beneficio. H asta ahora nos hem os enfocado en lo s beneficios de m ejorar al ne gocio. La lista de objetivos nos da una m edición de esos beneficios. E l criterio de evaluación tam bién necesita sopesar el costo de cualquier solución dada. ^ Los costos se presentan de m uchas m aneras. L a siguiente lista incluye v a ria s categorías de costos que deben ser parte de cualquier evaluación de un sistem a de inform ación. Tal vez pueda tener una lista de costos m ás detallada en su organización.
El costo óptim o de adquisición (construirlo o com prarlo) El costo óptim o para im plem entarlo Hl costo óptim o para m antenerlo a lo largo del tiem po Evita riesgos técnicos excesivos Tiem po de entrega aceptable Factibilidad con la gente y experiencia disponible A ñada estos conceptos relacionados con costos a su lista de criterios de evaluación. El equipo necesita estar de acuerdo sobre qué tan im portantes son estos conceptos en relación con los dem ás de la lista: Por ejemplo, ¿el tiempo de entrega es más im portante que los d e m a s. (> e rechazará una solución si el costo para im plementarla sobrepasa a los beneficios m edidos por los objetivos? , ■ Algunas com pañías dem andan que cada proyecto, en form a independiente, este justm cado en costos. La experiencia ha mostrado que el prim er proyecto d iente/servidor es mucho más caro que si se desarrollara usando tecnología m ainítam e. Esto hace que sea muy difícil justificarlo con base en un solo proyecto. Por lo tanto, si la curva de aprendizaje y la com plejidad tecnológica de este am biente es tan cara al inicio, ¿para qué cam biar? No se puede responder a esta pregunta directam ente. M i em bargo, se pueden proporcionar estas observaciones. El paso a tecnología cliente/servidor es tá frecuentem ente m anejado por f u e r a s poderosas, aunque m undanas, en el espacio de traba jo del negocio. Tj i com putadora personal ha ganado claram ente la guerra por los corazones de los usuarios. E s abrum adora la inm ensa cantidad de software en paquete para la PC, que pue de ser explotado.
EL MARCO DETRABAJO PARA LA TOMA DE DECISIONES DEL PROYECTO
45
Por lo general, los sistem as cliente/servidor tienen que justificarse en un nivel más estra tégico, tal com o la reingeniería del negocio para pasar la captura y manejo de datos fuera del cuarto de vidrio hasta las fronteras de la organización, en donde el personal tiene contacto di recto con los clientes, proveedores y producios. D ebido a que el prim er proyecto requerirá de una cantidad descom unal de aprendizaje, modelado e infraestructura tecnológica, tiene sentido com enzar en lo pequeño y avanzar hacia los sistemas grandes en vez de em pezar con un enfoque de gran explosión. Los beneficios rea les se dan en los proyectos siguientes (segundo, tercero y cuarto), cuando m ediante la reutili zación del personal, modelos, m etodología y tecnología, los sistemas pueden desarrollarse en un marco de tiem po m ucho m ás productivo.
Criterios de evaluación adicionales para los sistemas de información Además de ios criterios de evaluación que están relacionados con los beneficios de los objeti vos del proyecto y de los costos asociados con una solución, en la lista se deben tener consi deraciones que son uní versal m en te aplicables a los sistemas de inform ación. A esto se le llama la lista “idad” , debido a que m uchos de los vectores de calidad de la lista term inan en “idad” . Facilidad de uso Confiabilídad Capacidad de m antenim iento Extcnsibilidad Flexibilidad Seguridad Eficiencia Actualidad de inform ación Inm ediatez de respuesta H abilidad para com unicarse con otros sistemas Los conceptos de la lista necesitan considerarse cuidadosam ente. Experim entos de Gerald 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.
Capítulo 2 / EL PLAN GENERAL DEL PROYECTO
46
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).
cu c o >
t/)
CQ V O Cl en
Pronósticos de ventas
Asignación de la producción
-co ‘lrjo 3 ocJ Lr i_
2
3
3
1
1
1
3
2
1
2
’ S y) y c CJ o
\
0 = r o se aplica 1 = bajo 2 = m edio 3 = afto
Captura de pedidos
Calificación de vectores de calidad:
Facilidad de e n tre n a m ien to
2
T iem p o de respuesta rápido
3
2 2
3 2
F lexibilidad
3
A h o rro de teclados
3
3
3
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
2
1
3
3
f i g u r a 2-3. Calificaciones de los vectores de calidad por área de interés.
Tal vez haya observado que hasta el m om ento no hemos hablado acerca del hardware. Todos los criterios de evaluación que se han visto hasta este punto pueden aplicarse tanto a sis temas no autom atizados com o a los autom atizados. Es im portante no dar un sesgo al criterio de evaluación hacia soluciones com pletam ente técnicas. I’or ejem plo, si su establecim iento ha seleccionado un sistem a de adm inistración de base de datos estándar, el vector de calidad sub yacente puede ser el lograr capacidad de m antenim iento y extensíbilidad; habilidad para co m unicarse con oíros sistem as y costo óptimo de adquisición y m antenim iento a lo largo del tiempo. El softw are de desarrollo estandarizado evita riesgos técnicos excesivos y es factible con el personal y experiencia disponibles dentro del departamento. Cuando baya recopilado su lista de criterios de evaluación deberá tener lo siguiente; U na lista de criterios ponderados que miden los beneficios de lograr los objetivos tangi bles e intangibles. U na lista de criterios de costo, tiempo y riesgo que m iden los recursos requeridos para im plem entar cualquier solución dada y un acuerdo sobre las restricciones del proyecto. El criterio de costo tam bién debe ser sopesado por su im portancia relativa. U na m atriz de vectores de calidad para cada subsistem a principal que esté dentro del al cance, la cual proporciona dirección técnica para las expectativas del usuario sobre el desem peño \ com portam iento del sistema.
EL MARCO DETRABAJO PARA LA TOMA DE DECISIONES DEL PROYECTO
47
Cuando se ha term inado, a cada concepto de la lisia de criterios de evaluación se le d e be asignar una ponderación que refleje su grado de importancia. A rm ado con esta inform ación, el grupo está listo para descubrir diversas opciones y será capaz de llegar a un consenso por medio de un curso de acción racional.
Opciones de solución Hay m uchos puntos durante un proyecto en donde se presentan alternativas. La etapa de pla ntación es solam ente uno de ellos. Cualquier decisión involucra com prom isos, y el m arco de trabajo para !a tom a de decisiones ayuda a regresar la concentración en los objetivos origina les del proyecto para que las personas puedan hacer selecciones en form a razonable. Posterior mente en el proyecto se tendrán que tomar muchas decisiones que involucran la arquitectura del hardw are y la distribución de procesos y datos a través de la red. El tener un plan general sólido y un modelo del negocio como se describe en los siguientes capítulos, ayudará a com prender los com prom isos de ingeniería y a tomar decisiones bien inform adas. Sin las bases del plan general, estos asuntos críticos son resueltos frecuentem ente en form a arbitraria por la ad ministración o por "el que grita más fuerte o durante más tiem po”. 1 .as opciones de solución deben ser consideradas con el grupo de establecim iento del plan general del proyecto. Las regias para la generación de ideas indican que cualquier suge rencia debe escribirse y toda la evaluación debe ser pospuesta hasta que el grupo haya term i nado de añadir opciones de solución a la lista. Un buen moderador guiará al grupo a través de la generación de ideas para una variedad de soluciones técnicas, abarcando toda la gam a des de las im plcm entaciones de alta tecnología hasta las que em plean tecnologías básicas. El gru po también debe ser m otivado para ver si el problem a puede abordarse con una solución que no sea técnica. A veces una buena solución es cam biar la forma en que opera el negocio y de jar a un lado la tecnología. Sin im portar cuáles opciones de solución queden en la lista, la prim era opción siempre debe ser el ‘'statu quo” . Siempre m ida el costo/beneficio de hacer algo contra la línea base de no hacer nada. A veces el "statu quo” resulta la m ejor solución. Regresemos a nuestro ejemplo del grupo de desarrollo de productos de la em presa im presora de cheques. La declaración de su meta fue la siguiente: "Nuestra meta es reducir de cinco a dos días, el tiempo que le lleva a l departa m ento de mercadotecnia, validar y term inar las especificaciones para un nuevo producto, a partir del m om ento en que se recibe la información completa de la ofi cina de ventas hasta la entrega de especificaciones precisas y aprobadas a las plantas de producción. ” Después de que desarrollaron sus objetivos y criterios de evaluación com enzaron a dar ideas sobre opciones de solución.
Opciones de solución del departamento de mercadotecnia 1. Statu quo. 2. C ontratar m ás gente. 3. R eem plazar los archivos en papel y los archiveros con una base de datos en línea basada en PC.
Capítulo 2 / EL PLAN GENERAL DEL PROYECTO
48
4. R ediseñar los form ularios en papel q ue u sa el personal de ventas. 5. R ediseñar el flujo de trabajo p ara que m ercadotecnia teclee inform ación directa m ente en los sistem as de la planta. 6. D ar u n m ejor entrenam iento al personal de ventas. 7. C apturar los datos electrónicam ente en su origen (por ejem plo, darle laptops al per sonal de ventas) y bajar datos directam ente a los sistem as de producción, 8. U na com binación de los núm eros 4 y 6 (nuevos formularios y mejor entrenamiento). Después de que se ha creado una lista de opciones exahustiva de solución es tiem po de m edir cuál o cuáles opciones son las m ejores p ara satisfacer los criterios de evaluación. Se pue de crear una m atriz (figura 2-4), la cual enlista todos los criterios de evaluación y sus ponde raciones asociadas a la izquierda. En la parte superior se acom odan las opciones de solución con el “statu quo” en la prim era colum na.
C riterio d e e va lu a c ió n
P on deración
O b ie tiv o 1
%
O b la tiv o 2
%
O b je tiv o 3
%
O b ie tiv o 4
%
O b ie tiv o 5
%
O b je tiv o 6
%
C osto d e a d o u is ic ió n
%
C osto d e distrib u c ió n
%
C osto d e m a n te n im ie n to
%
V a lo ra c ió n d e riesqo
%
T ie m p o d e e n tre q a
%
Factibilid ad
%
fig u ra 2-4. Ejemplo de formulario de evaluación.
EL MARCO DETRABAJO PARA LA TOMA DE DECISIONES DEL PROYECTO
49
A m í me gusta listar prim ero los criterios de evaluación basados en objetivas, seguidos por los criterios basados en costos y luego por los criterios de vector de calidad, El grupo pue de enfocarse prim ero en valorar los beneficios com o están determ inados por los criterios basa dos en objetivos. Cualquier sistem a de valoración funcionará siem pre y cuando se aplique en forma consistente. Por ejemplo, se puede usar una valoración de cero a cinco. Si una opción de solución satisface com pletam ente un criterio de evaluación, se pone un cinco en la celda don de se intersectan. Si falla com pletam ente p ara satisfacer el criterio de evaluación, se escribe un rero. Si se satisface el criterio en alguna m edida, el grupo tendrá que determ inar una valora ción adecuada, la cual refleje el grado en que la opción se ajuste al criterio. Cuando se ha ter minado se pueden ponderar los valores con base en la ponderación del criterio de evaluación y luego sumarlos.
Estimación de costos Para los criterios basados en costos, lo m ejor es usar el costo m onetario, el costo en tiem po y el costo en recursos estim ados. Debido a que el enfoque principal de esta obra es sobre inge niería de softw are y no sobre adm inistración de proyectos, no se propone cubrir detalladam en te la estim ación de costos. Para hacerlo bien se necesitaría un libro com pleto. Sin em bargo, íicntro del contexto del análisis de sistemas de negocios perm ítam e proporcionar estas obser vaciones. Para estim ar el costo de cualquier solución dada se necesitará tener una buena idea del ¿amaño del problem a. La m ejor forma que conozco para determ inar el tam año de un problem a de negocios es hacer un análisis preliminar. Entre más grande sea el proyecto, más importante es com enzar a m odelar a los “tres grandes”, los modelos de contexto, de eventos y de inform a ción, en las fases de planeación. L a estim ación de costos com ienza con encontrar aquello que se puede contar. 1:1 m ode lo de contexto declarará las fronteras del sistem a y m ostrará las interfaces requeridas. El m odelo de contexto puede exponer interfaces de datos electrónicas o una integración com ple ja con sistem as existentes, así com o com ponentes en línea y de reportes. El modelo de eventos le proporcionará una li sta de todos los eventos de negocios principales con los que está planea do que el sistem a debe responder. Esta lista es crucial para determ inar la funcionalidad desea da del sistema. El modelo de inform ación es, tal vez, el indicador más importante de la com plejidad del sistema. M ediante la determ inación de qué tantas entidades están involucra das en el problem a del negocio, ei tamaño de la solución puede m edirse contra el costo de sis temas de negocios sim ilares. Una vez que se tiene una idea del tam año del sistema, según lo expresan los modelos, hay una diversidad de formas para determ inar el costo de construcción o la com pra de uno de esos sistemas. A casi cualquier cosa que se pueda contar, se le puede asignar una m edida para determ inar el esfuerzo total que se requiere para crearla. Se pueden contar entidades, cantidad de reportes, puntos de función, cantidad de ventanas, etcétera. Para aplicaciones GUI, que se concentrarán altam ente en la creación de la interfaz y en la base de datos subyacente, he estim ado satisfactoriam ente el tam año del proyecto con base en la cantidad de ventanas. La cantidad de ventanas de la interfaz es particularm ente relevan te en una aplicación GUI de negocios, debido a que ahí es en donde se gasta la m ayor parte del esfuerzo de desarrollo. La estructura orientada a objetos de un program a G U I hace que la esti mación de “líneas de código" sea particularm ente irrelevante.
50
Capítulo 2 / EL PLAN GENERAL DEL PROYECTO
E! núm ero de ventanas estim ado puede extrapolarse a partir del conteo de entidades y de la lista de eventos. Si se acepta que una buena aplicación GUI, que es responsable de la crea ción, consulta, actualización y borrado de una entidad, necesitará al m enos una ventana para seleccionar entre varias instancias de la entidad y una ventana para actualizar cada instancia de la entidad, entonces una estim ación aproxim ada de la cantidad de ventanas de un sistem a es “cantidad de entidades por dos". Otros factores que pueden increm entar la cantidad de venta nas son eventos poco usuales que caen más allá de las simples funciones de crear, leer, actua lizar y borrar. El siguiente paso es pedir, tom ar prestado o robar algún tipo de m edida de un proyecto GUI ciiente/servidor similar, Se puede dividir el esfuerzo total para el análisis, diseño, codifi cación y prueba para la cantidad de ventanas producidas en la aplicación final para obtener una m edida “por ventana”. Si su establecim iento tiene algunas m ediciones para el desarrollo de software, ya tiene m ucho adelantado. Si no, puede llam ar a su grupo de usuarios local, consultores y asociacio nes profesionales para que le presten algunas m ediciones de otras com pañías. D espués de que haya valorado cada una de las opciones de solución, puede evaluarlas en respecto a su costo de entrega relativo, costo de m antenim iento, tiem po de entrega y riesgo re lativo. El últim o criterio a aplicar son las calificaciones del vector de calidad. Recuerde que cri terios tales com o tiempo de respuesta rápido pueden aplicarse en form a desigual a través de la aplicación, por lo que cuando se evalúan opciones de solución debe estar consciente de a qué partes del sistema se aplica el vector de calidad. Cuando se term ina la evaluación, el grupo debe ser capaz de estar de acuerdo con un cur so de acción. A veces un grupo escogerá una solución m enos óptim a, debido sim plem ente a que es expedita. O tras veces se escogerá la solución más cara por razones estratégicas de lar go plazo. Sin im portar cuál solución se escoja, )o im portante es que el negocio y la organiza ción de IT hayan llegado a un consenso juntos. Todos saben la razón por la que existe el proyecto y tienen una visión de !o que deberá ser cuando se term ine.
EL PLAN GENERAL ESCRITO COMO UN CONTRATO L a m ayor parte de este capítulo ilustra el proceso que sigue la gente para llegar al consenso sobre las m etas y objetivos de un proyecto. Siento que la com prensión del proceso es mucho m ás im portante que la estructura actual del docum ento escrito que produce el proceso. No cum pliría con mis deberes si no le dijera cóm o escribir iodo esto, por lo que este es un for m ato que se sugiere para un docum ento de plan general de proyecto. El form ato actual puede variar dependiendo de los estándares em presariales, sin em bargo, el contenido debe incluir lo siguiente: L a m e ta. Un plan general escrito debe indicar claram ente la m eta del proyecto en la pri m era página. Los objetivos. A continuación de la declaración de la m eta se deben enlistar los objeti vos individuales de) proyecto en térm inos claros, concisos y m ensurables. Los objetivos también deben categorizarse de acuerdo con su im portancia relativa, para que todo lec tor esté consciente de cuáles son los objetivos prim arios y cuáles los secundarios.
EL PLAN GENERAL ESCRITO COMO UN CONTRATO
51
E l cu rso de acción rec o m en d ad o . 1.a siguiente sección debe indicar la solución reco m endada o los siguientes pasos. (A lgunas com pañías insistirán en un plan com pleto del proyecto, otras pueden indicar solam ente que hay que continuar con el análisis del negocio y plantear olra sesión de establecim iento del plan general p ara determ inar la solución óptim a del diseño.) Junto con la panorám ica de la solución seleccionada, tam bién se debe incluir una revisión del proceso de evaluación para que el lector com prenda el porqué el grupo se definió por la dirección indicada y cuáles opciones se rechazaron. A lcance de la solución. La opción de solución debe incluir una declaración del alcan ce. E sta le dice al lector qué tanto del negocio está incluido dentro de las fronteras del proyecto. Para esta sección frecuentem ente necesitará aventurarse en los siguientes ca pítulos y producir un modelo de contexto a nivel conceptual, una lista de eventos y un diagram a entidad-relación. El modelo de contexto y la lisia de eventos son muy buenos para la definición del alcance. También considero que es aconsejable dejar establecido explícitam ente lo que queda lucra de alcance. E sto es m ucho m ás seguro que la im pli cación de que una parte del negocio está fuera del alcance sim plem ente por haberla omitido. P la n del proyecto. Antes de continuar con el análisis m uchas com pañías insistirán en te ner un plan del proyecto. Esto incluye una declaración detallada de la m etodología a em plear, puesta por lo general, en térm inos de una estructura de división del trabajo. El perso n al el presupuesto y la calendarización sólo pueden de term inarse después de que haya sido estim ado el tamaño del proyecto por medio de algún modelo. P apeles y resp o n sa b ilid ad es. Rn el plan general necesitan m encionarse los papeles de la IT y del negocio. Ambas partes necesitan cum plir sus responsabilidades para que el proyecto sea exitoso. Para asegurarse de que el negocio m antenga su com prom iso, yo soy muy explícito en las es pee iñ c aciones sobre el plan general, de qué tantas personas se necesitan y durante cuánto tiempo. Continúe y ponga nom bres. Tam bién incluya los nom bres del patrocinador del proyecto, del com ité de dirección del negocio y del equi po de resolución de asuntos. F acto re s críticos p a r a el éxito. Cualquier condición previa para el éxito que esté fuera del control del gerente del proyecto debe quedar establecida desde el inicio. Yo siempre reitero en esta sección los nom bres de las personas del negocio y el tiempo que se requie re que dediquen. Si se requiere la adquisición e instalación de cualquier tecnología nue va, lo m ejor es indicar que el éxito del desarrollo del software depende de la instalación y prueba satisfactoria dei hardware. F irm a s. Al igual que cualquier otro contrato, el plan general debe ser ratificado por am bas partes. La gerencia de la IT y el patrocinador del proyecto deben firm ar en la línea punteada. Los proyectos más exitosos so.n aquellos en donde se logra que el negocio se com prom eta en los niveles más altos de la organización. Para cuando se term ina el plan general, el proceso analítico ya debe estar en camino. Los siguientes capítulos se entecarán sobre los detalles de los modelos que se necesitan para un buen análisis de los sistemas de inform ación de negocios.
52
Capítulo 2 / EL PLAN GENERAL DEL PROYECTO
RESUMEN Para ponerlo en térm inos simples, el plan general es el porqué, el análisis es el q u é y el diseño es el cómo. El plan general plantea la justificación y objetivos del proyecto. Dice claram ente quiénes son los participantes y especifica los papeles y responsabilidades de todos. Le dice a los analistas dónde com enzar y les dicc cuándo han acabado. El analista puede consultar el plan general del proyecto y preguntar “¿Cuáles son los ob jetivos más im portantes?” A hí es donde debe enfocar sus esfuerzos. Si al proyecto se le acaba el tiem po y el dinero, usted querrá asegurarse que se hayan satisfecho los objetivos más im por tantes. El plan general del proyecto es el inicio del proceso analítico. El marco de trabajo para la tom a de decisiones del proyecto es una técnica para determ inar las metas y objetivos de un p ro yecto. Im agínese la meta com o una bandera puesta en la cim a de una pirámide. H ay muchas for mas para llegar a la meta. Toda la actividad subsecuente del proyecto debe estar enfocada para lograrla. Los objetivos individuales se derivan de la expresión de problem as y oportunidades. Una form a efectiva para descubrir problem as es reunir en un salón a las partes interesadas y dejar los que hablen acerca de su situación actual. Los problem as y nuevas oportunidades pueden ser convertidos luego en objetivos, los cuales deben ser claros, concisos y mensurables. D ebido a que no todos los objetivos son creados iguales, cada objetivo necesita ser ponderado en térm i nos de su im portancia relativa. Cuando trate de medir los objetivos determ ine si el logro del objetivo podría increm en tar las ganancias, reducir costos o m ejorar e l servicio a los clientes. Tal vez la tarea m ás im por tante en la definición de objetivos es la búsqueda del escurridizo fa c to r x que consiste en la variable que se coloca en el enunciado del objetivo para indicar qué tanto de increm ento en ganancias, de reducción de costos o de m ejoras de servicios se desean. Requiere alguna in vestigación adicional, pero cada fa c to r x debe ser reem plazado con cifras significativas y alcanzables. 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. Hubbie 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
3
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 cons 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
Capítulo 3 / EL MODELO DEL CONTEXTO
56
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.
Confirmación de recepción de pedido Cliente
Buró de crédito c/info. sobre el cliente
( Verificación V de crédito
Servicio a clientes
Departamento de mercadotecnia
Listas de productos y precios
Lista be embarque Reporte de ventas diarias
Factura Estadísticas de tendencia de ventas
Almacén Notificación
Factura
Gerente regional de ventas
Detalle de ventas mensuales
Sistema de cuentas por cobrar
Departamento de contabilidad
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 planeació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 automanzació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 indcpendicne 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 externo
Almacún do
F ig u ra 3-2* Notación de diagraniación de flujo de datos.
iJcMarco, 1979.
líelos
58
Capítulo 3 / EL MODELO DEL CONTEXTO
La fortaleza principal de la notación DFD es que trata a un proceso com o una caja n e gra. El térm ino caja negra viene del mundo de la ingenien a eléctrica. U na caja negra repre senta cualquier sistem a con entradas y salidas conocidas, pero su m ecanism o interno está oculto al usuario. (Lsta no es ia infame caja negra de los desastres aéreos, sin em bargo después de sobrevivir al naufragio de num erosos proyectos de software, m e hubiera gustado tener una.) Un aparato de televisión es un ejem plo m agnífico de una caja negra. El usuario de la te levisión no necesita saber cóm o hace su magia. De hecho, la m ayoría de nosotros somos com pletam ente ignorantes sobre el funcionam iento interno de nuestro amigo electrónico. Sabem os cóm o usarlo. Como espectadores de televisión estam os familiarizados con las entradas y las sa lidas. Lo que es más importante, el com portamiento de! aparato de televisión se tiene bien com prendido. Yo sé que si hago clic en el núm ero 4 del control remoto, el program a cam biará a lo que se esté transm itiendo actualm ente en dicho canal. (También sé que si lo hago repetidam en te mi esposa me tirará al suelo y me quitará el control.) Para los usuarios del softw are de negocios !a aplicación de com putadora también es una caja negra. A nuestros usuarios no les im porta la m anera en que obtienen sus datos en pantalla o si sus facturas se están creando en el cliente, en el servidor o en cualquier nivel intermedio. Para ellos el funcionam iento interno del sistem a sigue siendo un enigma. Es útil com enzar des de la perspectiva del usuario, debido a que es, a final de cuentas, una caja negra lo que se va a entregar. La notación para el diagram a de contexto es muy simple. Trataré las definiciones form a les en cuanto sea posible, y luego explicaré el porqué este diagram a aparentem ente inocuo es tan útil para los proyectos de desarrollo cliente/servidor. H ay cuatro notaciones principales para el diagram a de contexto. El círculo o elipse se usa para representar procesos, la flecha para los flujos de datos, un rectángulo para representar agentes extem os y un par de líneas paralelas para mostrar datos almacenados.
Procesos Las reglas convencionales de diagram ación de flujos de datos insisten en que un proceso debe ser nom brado con un fuerte verbo seguido por el objeto al que se aplica la acción. Los proce sos de nivel m ás operativo, aquellos que realizan una actividad funcionalm ente cohesiva, son bastante fáciles de nombrar. Crear factura de cliente Acum ular salarios por pagar Enviar productos term inados D eterm inar la velocidad del vehículo Para la m ayoría de los sistemas de negocios, la burbuja de proceso de un diagram a de contexto es un popurrí de diversas actividades, y encontrar un buen nom bre puede ser difícil. Antes de que se rinda y lance las siglas del proyecto a la burbuja, trate de obtener un buen nom bre con verbo y objeto que describa al sistem a com pleto. Encontrará que es una experiencia re tadora, pero clarificante, que le ayudará a com prender de lo que se trata el sistema.
NOTACIÓN DE DiAGRAMACIÓN DE FLUJO DE DATOS
59
Intente generar varios nombres para la burbuja de contexto, tenga cuidado de escoger •serbos adecuados y que destaquen, además de nom bres de objeto relevantes. Luego defina el iKoceso en un párrafo corto y sim ple con redacción clara. Incluya en la definición una breve ja o o rám ica de todos los procesos que están contenidos dentro del alcance de] contexto. Tal Tez quiera también excluir específicam ente a procesos vecinos que no se encuentran dentro del área de estudio. D espués de que esté satisfecho con la definición del proceso vuelva a exaa^ 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 íransformeción establece que un proceso modifica los datos en alguna form a.2 La salida debe ser dií'ede 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
Historia de crédito del diente
Existencias disponibles
Inventario 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 denvable 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écsic 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
Capítulo 3 / EL MODELO DEL CONTEXTO
60
Historia de crédito del cliente
Inventario 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 ciberespaeio, por lo que ambos térm inos fueron abandonados rápidam ente en favor de entidades externas, fisto duró solam ente unos cuantos años hasta los noventa, en donde las valencianas fueron m ás pequeñas, los hom bres usaron corbatas floreadas y estos cuadros se convirtieron en agentes externos. Fue por este tiempo en que renuncié a tratar de estar a la moda. M e adherí al nom bre agentes externos, pero sí en realidad realm ente quiere estar actualizado, puede llam ar les actores, aunque tal vez para cuando lea esto se les m encione com o objetos de inte/activi dad orientados a negocios. Los agentes externos están fuera del contexto del área de estudio. Por esta razón nunca se muestran flujos entre dos agentes externos. Sólo se despliegan los datos que fluyen hacia o desde el sistem a en el diagram a de contexto. Los agentes externos son m encionados con un nom bre. Ellos pueden representar departam entos específicos o grupos de usuarios dentro del negocio, clientes, vendedores, transportistas o hasta otros sistemas de inform ación. Cada agen te externo del modelo requiere un nom bre y una definición.
NOTACIÓN DE DIAGRAMACIÓN DE FLUJO DE DATOS
61
Lo que se debe y no debe en la denominación de los agentes externos Frecuentem ente m e preguntan, “¿las personas están dentro d el sistem a o fuera del sistem a?” Es «na pregunta perfectam ente legítim a. A unque la gente se va a su casa en la noche, las activi dades que realiza en el trabajo pueden existir com o procesos dentro de nuestra área de estudio. Algunos de sus papeles pueden estar fuera de nuestra área de estudio y aparecen com o agenles 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 Samson 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-
Capítulo 3 / EL MODELO DEL CONTEXTO
62
pititín, hasta pudiera ser preferible expandir el alca.nct; del modelo de contexto a sus extremos para poner en definitiva a los iniciadores de la inform ación (figura j-7 ).
Figura 3-7. Iniciadores ele ios dalos a in io agentes externos.
Tengo mucho qué decir acerca de los agentes externos en la sección “A lcances expan dido y reducido’". La selección de un agente externo puede ser muy com plicada y puede tener ram ificaciones im portantes en el mundo cliente/servidor.
Flujos de datos M e gusta representar a los flujos de datos como com puestos de atributos de datos individuales, agrupados en paquetes de inform ación sobre una banda transportadora. Cada v e / que un pa quete es entregado al sistem a se requiere que el sistem a reaccione en u na form a predecible. Esa reacción puede incluir la em isión de una respuesta, la cual tam bién es un paquete de inform a ción com puesto de atributos de datos individuales. En el diagram a de contexto los flujos de datos caen claram ente en dos categorías, es tím ulos y respuestas. Los flujos de estímulos son las “entradas” y los flujos de respuestas son Jas “ salidas". \ To hay convención que insista que los flujos viajen de izquierda a derecha en un diagram a de flujo de datos, sin em bargo, en el mundo occidental la gente tiende a percibirlos de esa manera. Debido al gran núm ero de flujos que están representados, en un diagrama de contexto, es poco probable que todos los datos viajen claram ente en la dirección oriental. La definición de un flujo de datos es crítica, lis irónico que el aspecto m ás fuerte de la diagram ación de flujos de datos sea exactam ente en donde la técnica frecuentem ente se aparta en la práctica. Se debe recordar siem pre que los flujos de datos están com puestos de datos. No estoy tratando de extender este tema. Si los flujos de datos están com puestos de daros, ¿enton ces en cuál modelo se definen los datos? (Si respondió en “el m odelo de datos” , ganó. Es un asunto tram poso, debido a que nuestra industria ha cam biado inteligentem ente el nom bre de modelo de datos por el de modelo de inform ación.) Al fin de cuentas, se puede derivar un modelo de inform ación (tratado a detalle en el ca pítulo 5) atribuyendo todos los elem entos de datos de los flujos de entrada y salida del m ode lo de contexto a entidades del modelo de inform ación. Lo que es más, veremos en el capítulo
NOTACIÓN DE DIAGRAMACIÓN DE FLUJO DE DATOS
63
4 que los II lijos de datos de estím ulo y respuesta del modelo de contexto existen solam ente p a ra transportar eventos del negocio específicos. Por lo lanío, es muy poco probable que usted sea capaz de sentarse y tra /a r el modelo de contexto perfecto sin haber tenido un buen inicio en ci modelo de eventos y en el modelo de inform ación al mismo tiempo. La razón por la que la denom inación y definición de! flujo de datos llegue a ser tan com plicada es que los atributos de los datos pueden ser agrupados en forma bastante arbitraria por el modelador o por conveniencia gráfica. Pitra ilustrar este punto he trazado la m ism a idea ló gica en varias formas diferentes. En la figura 3-8 un solo flujo, llamado Nuevo pedido del cliente, entra al sistem a desde ei cliente. En la figura 3-9 tenemos esencialm ente la m ism a inform ación entrando al sistema, pero se m uestra com o dos flujos, Expediente del cliente y N uevo pedido.
Figura 3-8. Nuevo pedido del cliente m ostrado com o un flujo de datos.
Figura 3-9. Nuevo pedido del cliente m ostrado com o dos flujos cic datos,
Si profundizam os en nuestra burbuja de contexto para ver a dónde van estos flujos, en contrarem os que la parte de Expediente del cliente de los datos ha sido dirigida al proceso A c tualizar expediente del cliente, y que la inform ación del pedido ha sido dirigida hacia Crear nuevo pedido. Para satisfacer la ley de la conservación, la figura 3-10 usa un divisor o em pal me de flu jo de datos para separar el flujo en dos flujos a fin de que sólo la inform ación que se requiere sea dirigida a cada proceso. La figura 3-11 ya tiene separados los flujos y, por lo tan to, pueden fluir directam ente a sus procesos respectivos.
64
Capítulo 3 / EL MODELO DEL CONTEXTO Muevo pedido del cliente
Muevo pedido
Nuevo número de cuenta de! cliente Siguiente número de cuenta del cliente
Cliente
Siguiente número de pedido
Pedido
Figura 3-10. Se puede usar un divisor para separar los flujos do dalos.
Siguiente número de cuenta del cliente
Cliente
Siguiente número de pedido
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 encuentra en
Cliente N om b re
Dirección de envío
Suevo pedido: Cliente Nom bre
Colocó Fue colocado por
-9<
Es destino geográfico pa ra
4+
Pedido Fecha del pedido Modo de entrega
o Toma
Empleado Nom bre
Fue tom ado por
Región de m ercado Código de región
Contiene
4+-
Fue pedido en
- |^
Concepto de pedido Cantidad Unidad de medida
Y c:>" Fue pedido en
Soücita fa entrega de
Producto 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
Capítulo 3 / EL MODELO DEL CONTEXTO
66
mentos de datos que está transportando. La mejor form a de hacerlo es m ediante el m odelo de inform ación.
Flujo de materiales Com o analista de inform ación se pasará la m ayor parte de su tiempo m odelando dalos. Puede haber ocasiones, especialm ente cuando maneja sistemas de fabricación, en ios que estará con frontado con la com prensión del flujo de materiales. Los flujos de m ateriales m uestran el m o vim iento real de m ateria física a través de un proceso, mientras que los flujos de datos m uestran el movim iento de datos a través de un proceso. C uando se m anejan sistem as de inform ación que llevan cuenta de datos acerca del m a terial. frecuentem ente es útil hacer un diagram a de flujo del material para ayudarse a desarro llar el diagram a de contexto para el sistem a de inform ación. La figura 3-14 m uestra un diagram a de flujo de materiales para un proceso de fabricación autom atizada que llena frascos con com ida para bebé, tapa los frascos y aplica las etiquetas adecuadas.
Figura 3-14. Un diagram a de flujo de m ateriales.
Hn ios sistemas de fabricación se pueden em plear varias m áquinas para m anejar el m a terial. U na m áquina dada puede proporcionar datos al sistem a de inform ación que lleva, cuen ta y controla el proceso autom atizado. M ediante la creación de un diagram a de flujo de m ateriales (figura 3-15) puede verificar su conocim iento del proceso y establecer una base p a ra la com unicación con los usuarios (que tal vez no sepan nada acerca de com putadoras, pero que han hecho com ida para bebé desde hace veinticinco años). M ediante la conversión de las burbujas de proceso de materiales a agentes externos, po dem os establecer una frontera de autom atización para un sistema de inform ación y com pren der su relación con el material del que controla y lleva cuenta (figura 3-16),
Almacenes de datos Los almacenes de dalos son lugares del sistem a en donde se recuerdan los datos cuando no se utilizan. Se les m uestra com o líneas paralelas. En el m undo real pueden representar bases de datos, archiveros, m em oria de com putadora o hasta m em oria humana. Desde el principio del tiem po se ha decretado “no deberás poner alm acenes de datos en un diagram a de contexto". La sabiduría convencional es que los alm acenes de datos muestran los datos inactivos dentro de las fronteras del contexto.
NOTACIÓN DE DIAGRAMACIÓN DE FLUJO DE DATOS
67
F ig u ra 3-15. lil flujo de datos puede m oni torear o controlar el flujo de m ateriales.
Figura 3-16, [ .os procesadores de m ateriales se convierten en agentes externos para el sistem a de inform ación.
Hay una situación en la que a m í no m e preocupa poner alm acenes de datos en un dia grama de contexto. Es en el caso de los alm acenes de datos pasivos. Si los datos que fluyen h a d a el sistema se están utilizando a partir de un almacén de datos sobre el que el sistem a no tsene control (el sistem a tiene acceso de sólo lectura), entonces pienso que está bien m ostrarlo como un almacén de datos. Tam bién se le podría m ostrar com o un agente externo. Si el siste ma ¡lega a actualizar el almacén de datos, entonces se convierte en un almacén de datos activo v se está obligado a mover esa parte del almacén de datos dentro de las fronteras del contexto (figura 3-17).
68
Capítulo 3 / EL MODELO DEL CONTEXTO
F igu ra 3-17. D os notaciones aceptables para los almacenes de datos pasivos.
NOMENCLATURA Y DEFINICIONES Se le ha dado una burbuja, un m anojo de flechas, algunos cuadros y el conjunto ocasional de lincas paralelas. Su tarea es describir en una página un sistem a de negocios extrem adam ente com plejo. Esta es la razón po r la que es tan im portante que escoja nom bres descriptivos y sig nificativos, ya que en caso contrario el diagram a no dirá m ucho. A unque su denom inación sea m agnífica, cada una de las personas que la lea se form ará una opinión ligeram ente diferente acerca de lo que está tratando de leer. N ecesitará precisar definiciones escritas para cada obje to del diagram a. Tenga cuidado de no caer en la tram pa de los nom bres descuidados. El p eor nom bre que puede poner en una burbuja de proceso (aparte del no ponerle nom bre) es Procesar datos. Ya sabem os que procesa datos, Hsto es lo que hace una burbuja. En form a sim ilar, es inadm isible poner las palabras D atos o Inform ación en un flujo de datos. H a desperdiciado espacio valio so y no le h a dicho nada al lector. I x>s diagram as gráficos por sí solos no constituyen u na especificación de análisis. Nada reem plaza al texto claro y conciso. Los diagram as proporcionan un a estructura y organización para el lexto, pero de ninguna form a elim inan la necesidad de una explicación y una definición. I jis m ejores analistas con los que he tenido e l placer de trabajar han tenido una cosa en común, son hábiles para escribir.
ALCANCES EXPANDIDOY REDUCIDO
69
TÉCNICAS PARA LA CREACIÓN DEL MODELO DE CONTEXTO La diagram ad ón del contexto es mucho más difícil de lo que parece. E s poco probable que v a ya a plasm ar el alcance del sistem a trazando una burbuja en una página en blanco, rodeándola con cuadros y com enzando a conectarla con flechas (figura 3-18). Un vez de tra /a r una burbu ja, a m í m e gusta trazar un diagram a de flujo de datos “aplanado’1 sobre el área de interés del negocio (figura 3-19). Ks como quitar la tapa de la burbuja de contexto y dejar ver los proce sos principales que están dentro. A dición al mente, tam bién incluyo procesos vecinos que pue de ser que estén o no dentro de m i alcance. Encuentro que es muy útil hacer una lista de eventos con base en mi plan general (vea el capítulo 4 para una discusión detallada del modelado de eventos) y dejar que mi lista de eventos m e guíe trazando cada grupo principal de eventos a lo largo del negocio.
Depa rtamento de mercadotecnia
Sistema de cuentas por cobrar
Departam ento de contabilidad
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.
Capitulo 3 / EL MODELO DEL CONTEXTO
70
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 de m ercadotecnia
Sistema de cuentas p or cobrar
Departamento de contabilidad
Figura 3-22. Un diagram a de contexto de alcance expandido.
ALCANCES EXPANDIDOY REDUCIDO
73
El diagram a de alcance expandido nos perm ite ignorar tem poralm ente quién hace qué y dónde sucede. Ahora podem os buscar dentro del contexto y ver qué procesos de transform a ción de datos suceden para el evento E l cliente coloca pedido. Lo que encontram os es que tradicional mente ha habido m ucha actividad en las oficinas de ventas regionales que caen fuera del dominio del sistema antiguo. Los clientes de CCI son, en su m ayor parte, tiendas locales de mascotas y tiendas especializadas. Son visitadas una vez al mes por un representante de ventas quien trata de levantar el pedido en ese momento, pero, por lo general, term ina dejando un catálogo con el propietario de la tienda. Luego los clientes hacen sus pedidos por teléfono a la oficina de ventas regional. En la oficina de ventas el pedido es registrado en un form ulario de pedido preliminar. Es una política estándar el tratar de vender accesorios adicionales que hacen juego con lo que el d ie n te este com prando. Si el cliente se traga la carnada se añaden artículos adicionales al pe dido. Luego el pedido es revisado para ver que esté com pleto, se revisa el crédito del d ie n te y se confirm a el pedido. En el sistem a actual, el formulario de pedido confirm ado se envía a las oficinas centrales donde se teclea en el sistema. Se im prim e un acuse de recibo d d pedido en una im presora de línea y se envía por fax de regreso al cliente. En este m om ento tal vez haya identificado algunas áreas que se pueden m ejorar en este negocio. M uchas lim itaciones tecnológicas d d pasado han conspirado para influir la form a ac tual de los negocios. Cuando se instaló d sistem a de captura de pedidos original en mainframe hace quince años, es probable que encontrara una resistencia trem enda si se hubiera tratado de poner term inales de captura de pedidos en las oficinas de ventas. Algunas de las razones se hu bieran debido a la tecnología que estaba disponible en esc momento. El softw are de telecom u nicaciones estaba inmaduro. El espacio en disco era caro y las pantallas tradicionales basadas en caracteres tenían un espacio muy limitado. Esto hubiera necesitado códigos crípticos y abre viaturas de datos, que habrían hecho que las interfaces fueran difíciles de aprender y usar. A ctualm ente nuestra capacidad de telecom unicaciones ha avanzado mucho. El espacio de disco es relativam ente barato. Las com putadoras personales poderosas están am pliam ente disponibles, equipadas con interfaces gráficas de usuario que perm iten que se m uestre una am plia cantidad de inform ación descriptiva y con ilustraciones. Nuestra com unidad de usua rios también está cam biando. A ctualm ente la PC es un equipo com ún en la m ayoría de las o fi cinas, escuelas y casas. Virtualm ente, cualquier persona recién ingresada ya deberá saber cóm o usar una. Al m over el proceso de captura de pedidos a las oficinas de ventas regionales m uchos procesos que actualm ente son m anuales podrían ser autom atizados fácilm ente. Con una in terfaz intuitiva bien diseñada, el personal de ventas podría capturar los pedidos prelim inares en línea en vez de en papel. El volum en de pedidos m anejado p o r cada oficina es un décim o del volum en del departam ento de captura de pedidos central. L a com putadora podría usarse para ayudar a sugerir conceptos adicionales que hacen ju eg o con el pedido d d cliente. Una sim ple edición podría validar el pedido para ver si está com pleto, así com o hacer la revisión de crédito en forma electrónica. Para cuando el pedido se confirm e, ya está en el sistema. H asta podríam os explorar la posibilidad de pasar la función de captura de pedidos a los clientes.
74
Capítulo 3 / EL MODELO DEL CONTEXTO
Nuestro diagrama de alcance expandido tam bién nos ayuda a explorar posibles mejoras para los flujos de respuesta. Kn nuestro diagram a de alcance reducido el acuse de recibo del pedido se envía a ía im presora. En el mundo real, cada em pleado de captura, de pedidos se le vanta, camina hasta la im presora, desprende el acuse de recibo (teniendo cuidado de no rom perlo), lo coloca cara abajo en la m áquina de fax, hace la llam ada al num ero de fax del cliente y lo envía. Nuestro diagram a de alcance expandido muestra al acuse de recibo del pedido fluyendo directam ente hacia el diente. A hora estamos libres para explorar nuevas soluciones tecnológi cas para este problema. Para esta situación hay paquetes de software am pliamente disponibles en el mercado que pueden enviar com o fax un docum ento directam ente desde ia PC, sin tener que pasar por la im presora. El nuevo sistem a de captura de pedidos podría buscar el núm ero telefónico del clien te y enviarle directam ente el documento,
UN PROYECTO -M U C H O S CONTEXTOS M ediante las técnicas anteriores es probable que el proyecto explorará muchos contextos dife rentes antes de definirse por el alcance final. Conform e el análisis avance, el alcance también puede cambiar. Los cambios de alcance grandes, tales com o el m over la captura de datos a las oficinas de cam po, también requiere análisis de costo/beneficio rigurosos. Este tipo de deci sión es realmente parte de la fase de establecim iento del plan general del proyecto. Tal vez com ience con un alcance reducido de! sistem a actual y luego cree un diagram a de alcance expandido donde se m uestre a los generadores y consum idores últimos de los d a tos. Posteriorm ente en el proyecto, conform e se asignan partes del modelo a la tecnología, tal ve/, quiera crear un nuevo diagram a de alcance reducido para m ostrar el contexto en la form a en que se refiere a una im plenicntación particular. También hay algunos factores hum anos a considerar cuando se hace este tipo de análi sis. (C óm o supone que van a reaccionar los em pleados de captura de pedidos ante un m ode lo de contexto que claram ente elim ina a su departam ento? I le visto varios proyectos que caen en situaciones políticas problem áticas debido a que nadie ha preparado a los usuarios para la m agnitud de los cambios que se dan a consecuencia de la introducción de un sistem a radical mente nuevo. Esta falta de consideración para los factores hum anos da com o resultado usuarios que com ienzan a obstruir el proyecto subversiva o públicam ente, ya sea rehusándose a p artici par o quejándose am argam ente acerca de la calidad del trabajo que se está haciendo. A v e ces la anim osidad rápidam ente degenera en hostilidad abierta y puede, de hecho, m atar al proyecto. La única forma para cam biar esta situación es atacar el problem a directam ente m os trando a las partes afectadas cóm o será su trabajo cuando llegue el nuevo sistema, (A unque ev én en k cola de desem pleados cuando llegue el nuevo sistem a.) El departam ento de in fo r m ática no i a a ser capaz de hacer su trabajo sin la cooperación de la alta gerencia para co m partir la visión del futuro con el negocio, m anejar las expectativas de los usuarios y resolver sus preocupaciones.
RESUMEN
75
CÓMO SE RELACIONA EL MODELO DE CONTEXTO CON LOS OTROS MODELOS Ya vimos qué tan íntim am ente enlazados pueden estar los procesos de modelado de contexto y el de establecí m iente del plan general del proyecto. Para cualquier proyecto que contempla un cam bio en las fronteras del sistema que está reemplazando, el modelo de contexto llega a ser un elem ento crucial para la exploración de opciones y el establecim iento de un plan gene ral (capítulo 2), Veremos en el siguiente capítulo que el modelo de contexto está directam ente relaciona do con el modelo de eventos (figura 3-23), el cual forma la base de gran p an e de las tareas de diseño de interfaz que se van a realizar. En cualquier m om ento en que se m ueva la frontera del contexto tam bién se alterará el paisaje del modelo de eventos (capítulo 4).
F igura 3-23. Los eventos estim ulan al sistem a para que responda en una m anera predecible.
Cuando el contexto del proyecto se expande para incluir ubicaciones del negocio geo gráficam ente distribuidas, M) como el ejemplo dado en este capítulo, entonces la arquitectura técnica del sistem a de des 'no llega a ser más com plicada (capítulo 8). Por último, es la definition de los datos que cruzan la frontera del sistem a lo que llega a ser el modelo de inform ación del sistema (figura 3-24). A final de cuentas, se tendrá que atri buir cada elem ento de datos a su tipo de entidad propio y com prender las relaciones com ple jas que hay entre los datos (capítulo 5).
RESUMEN El modelo de contexto consiste de una burbuja en el centro, la cual representa el área de estudio, 1,os agentes externos que caen fuera del control del sistema se muestran com o rectángulos. Es tos agentes externos envían flujos de estímulos al sistema o reciben flujos de respuesta de éste.
Capítulo 3 í EL MODELO DEL CONTEXTO
76
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 metnorizado y asegurándose de que se haya pagado la cu o ta corresp o n d ien te. El proceso A probar perm isos de construcción puede vivir dentro de la burbuja de con texto, haciendo que esté dentro de nuestra área de estudio y dentro del alcance de la autom atización potencial, pero O rville, com o persona, no pertenece al interior de la burbuja. El se va a su casa en la noche. No todos los procesos realizados por O rville están dentro del alcance. O rville tam bién contesta el teléfono y hace café.
78
Capítulo 3 / EL MODELO DEL CONTEXTO A m enos de que se pretenda incluir estos procesos en el nueve sistem a, es m ejor dejarlos fuera. 3. La parte capciosa de la pregunta es el m odelo de contexto “esencial” . L a palabra “esencial” se ha utilizado en nuestra industria durante décadas p ara denotar algo independiente de la im ple m entación. El m odelo de contexto es una vista muy g e neral del sistem a usando diagram ación de flujo de datos com o la técnica de rep re sentación. Las convenciones de la diagram ación del flujo de dat.os indican que una burbuja de proceso debe transform ar datos en alguna form a y no sim plem ente transportarlos. Por lo tanto, las aplicaciones que sólo m ueven datos de un sistem a al siguiente no tendrán modelo de contexto esencial, ya que no realizan un p ro ce so de transform ación.
EL MODELO DE EVENTOS
INTRODUCCIÓN El capítulo 4 está dedicado al tema del modelado de eventos. É ste es una forma para definir los requerim ientos del sistem a desde un punto de vista del usuario. Com enzarem os listando los eventos de negocios para los que nuestros usuarios em plearán el sistema. A cada evento de nuestra lista de eventos se le da una definición detallada en el diccionario de eventos. Éste lis ta los datos que estimulan al sistem a para entrar en acción y los datos que com prenden la res puesta del sistem a ante el evento. Los elem entos de datos después se registran en el modelo de inform ación, que es el tem a del capítulo 5. Entre los datos de estím ulo y los datos de respues ta escribim os una definición de m iniespecificación sobre cuáles actividades debe realizar in ternamente el sistem a para transform ar la entrada dada y producir la salida deseada. La suma de los registros de actividad del diccionario de eventos form a la especificación de procesa m iento para nuestro nuevo sistema. El diccionario de eventos docum enta las políticas dc¡ ne-
80
Capítulo 4 / EL MODELO DE EVENTOS
gocio y las reglas que se requieren para responder adecuadam ente a cada lino de los eventos del plan general del proyecto. En este capítulo trataré la definición formal de un evento y le m ostraré cóm o descubrir eventos m ientras realiza el análisis. Le proporcionaré un form ato pa ra el registro de cada evento en el diccionario de cvenios y le mostraré las diversas formas en que se puede organizar una lista de eventos y las m atrices de eventos para que sean una ayuda en el análisis y el diseño. FJ modelado de eventos tiene su propia term inología, com o debe ser, y trataré los diferentes tipos de eventos (inesperados, esperados, temporales y pseudoeventos) y los niveles de eventos (el nivel conceptual, el nivel de negocios, el nivel de diálogo y el nivel de diseño). El modelado de eventos es un concepto clave que, cuando se le dom ina, ayuda a or ganizar las especificaciones de análisis en una form a que es fácilmente aplicada durante el di seño de la interfaz gráfica de usuario.
EL PROPÓSITO DEL MODELO DE EVENTOS fr’l propósito del modelo de eventos es describir cuál es el com portam iento adecuado de un sis tema. Esto se logra listando lodos los eventos del negocio atite los cuales está planeado que el sistema debe responder. Para cada evento de la lista se crea una entrada en el diccionario de eventos, la cual detalla la definición, estím ulo, actividad, respuesta y efecto en el negocio. El diccionario de eventos nos dice la m anera en que se espera que el sistem a se com porte cuando sucede el evento. Llega a ser un lugar de depósito crucial para las políticas del negocio, las cua les deberán ejecutarse cada vez que sucede el evento. El modelo de eventos es aplicado com pletam ente a las tareas que suceden a su creación. Para el analista, el modelo de eventos establece la actividad del usuario en relación con el n e gocio en térm inos que ellos pueden com prender fácilmente. La lista de eventos describe al sis tem a desde la perspectiva del usuario. Para el arquitecto cliente/servidor, un modelo de eventos que ha sido com entado con estadísticas proporciona inform ación critica acerca de quiénes usan el sistema, qué datos se requieren en cualquier momento dado y qué tan rápido se espera que responda. Para el diseñador de la interfaz, el modelo de eventos proporciona las justificaciones de negocios para la navegación y el contenido de ventanas. Los tcclazos y clics de ratón que son codificados son, a final de cuentas, una im pfem entación directa de los eventos del negocio en el modelo. Para el diseñador interno, las políticas del negocio establecidas en el diccionario de eventos proporcionan las razones para la lógica del negocio, las cuales serán codificadas en el sistema. El diccionario de eventos es el lugar principal en donde se descubrirán las mismas políticas y reglas que aparecen en diferentes eventos que conducen a identificar y extraer com ponentes de softw are reutilizables en el diseño interno.
¿QUÉ SIGNIFICA "MANEJADO POR EVENTOS"? Si observa i a etiqueta de la envoltura de casi cualquier herram ienta de desarrollo GUI actual, verá la afirmación "m anejado por eventos” . Esto ha llegado a ser un lugar com ún en nuestro vocabulario, ai igual que la palabra "N U E V O " en las bolsas de detergente para ropa. Pero, ¿que significa realm ente manejado por eventos?
¿QUÉ ES UN EVENTO?
81
En una interfaz gráfica de u su tirio, m anejada por eventos significa que el program a res ponde directam ente a los clics del ratón y al teclado, tan pronto como suceden. Ahora, cual quiera que haya salido de secundaria después de 1985 puede ver esto y decir “hall” . Para el resto de nosotros, los dinosaurios, esto representa el cam bio fundam ental en la forma en que los hum anos se com unican con las com putadoras. Cientos o m iles de aplicaciones m ainfram e todavía adornan el panoram a mundial actual, alojadas en una tecnología que tiene lim itadas vías de acceso hacia el procesador. En el m un do tradicional de la “pantalla verde”, el usuario teclea una pantalla llena de datos mientras el procesador ignora com pletam ente que algo está sucediendo. Sólo cuando el usuario oprim e Kntrar, 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ó.
Capítulo 4 / EL MODELO DE EVENTQS
82
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 detectable 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
Capítulo 4 / EL MODELO DE EVENTOS
86
formas para dividir una lista de eventos, posteriorm ente en este capítulo en la sección: “O rga nización del modelo de eventos.”
El diccionario de eventos Una lista de eventos es de muy poco valor para el analista o diseñador sin el diccionario de eventos. Las entradas del diccionario de eventos para cada evento definen su im portancia en el negocio y sus parles com ponentes. La figura 4-4 m uestra un evento conform e hace su camino a través del sistem a en un diagram a de contexto. A esto se le llam a el hilo de un evento o tran sacción. Está definido m ediante el diccionario de eventos.
I’i¡>lira 4-4. Un hilo de evento.
Hl evento sucede en un m om ento específico en el am biente, dentro del agente externo. El sistema no puede causar la ocurrencia del evento, sin em bargo, posteriorm ente veremos que el sistem a puede “poner una carnada” en el am biente para que sucedan eventos. La ocurrencia del evento está com pletam ente bajo el control del agente extem o. El estím ulo es el flujo de d a tos de entrada que activa el evento. La actividad es el procesam iento realizado por el sistema para producir la re sp u e sta adecuada. El ílujo de respuesta consiste de datos enviados desde el sistema, de regreso al am biente para producir un efecto en el negocio. El diccionario de eventos reem plaza gran parte del detalle que fue anteriorm ente incrus tado en el modelo de procesos nivelados, modelado en las técnicas tradicionales de análisis es tructurado. L a figura 4-5 m uestra una entrada de ejem plo del diccionario de eventos para el evento E l alm acén envía el pedido del cliente. Identificador (ID) dei evento puede ser un número, pero le recom iendo nuevam ente que no hay que hacer que ese núm ero sea significativo de alguna manera. Un identificador asigna do en foraia aleatoria perm ite que se cam bie el nom bre del evento sin tener que cam biar su identificador. E l lector de la lista de eventos ni siquiera tiene que ver al identificador actual del evento. Cada vez que he tratado de num erar los eventos en form a cronológica, el método siem pre falla tan pronto com o descubro eventos que pueden suceder sim ultáneam ente o cuando ol vido un evento y trato de añadirlo posteriorm ente. El n o m b re del evento es una oración clara del evento en palabras que el usuario puede comprender. E stá especificada en la sintaxis sujeto-verbo-objeto cada vez que es posible. Pronto veremos que esto perm ite ordenar la lista de eventos por sujeto o por objeto. Tal vez quiera identificar el sujeto y el objeto de cada evento com o propiedades separadas para facili tar posteriorm ente este tipo de ordenamiento.
LOS PRODUCTOS DEL MODELO DE EVENTOS
ID del e v e n to :
87
150 El almacén ertvia el pedido del cliente
D es c rip c ió n :
Cuando el almacén envía los productos term inados al cliente, se identi fica la compañía transportadora y se actualiza la cantidad enviada de cada concepto en ei pedido dei cliente. Si la cantidad total enviada es igual a la cantidad solicitada, entonces se cierra e! concepto de pedido. Si todos los conceptos del pedido han sido satisfechos completamente, entonces se cierra el pedido completo. Por lo general, los pedidos no son factura dos sino hasia que se han cerrado completamente. Ei sistema produce un número de guía del transportista para acompañar este envió.
E s tím u lo :
Identificación del pedido del cliente Identificación de la compañía transportista, numera de vehículo Fecha de envío, concepto del pedido enviado, cantidad enviada
A ctiv id a d :
Crear una instancia del envío de pedido usando el ID del pedido del cliente, el ID de la compañía transportista, la fecha de envío y el número de ven ículo. For each concepto enviado Crear una instancia del envío de concepto de pedido usando el ID del concepto de pedido y la cantidad enviada. If la suma de la cantidad enviada para cada envió de con cepto de pedido asociado con el concepto de pedido >= la cantidad solicitada de concepto de pedido. Actualizar el estado de concepto de pedido = cerrado End if ■ End for each If estado de concepto de pedido = cerrado para todos los conceptos del pedido. Actualiza - estado del pedido - cerrado End if Im prim ir la guía de transporte usando los dalos "enviar a" del cliente, envío del pedido, conceptos de envío del pedido, compadra transportista.
R es p u es ta :
Guía de transporte
E fecto;
El transportista puede salir del lugar una vez que tiene en su poder la g ira. Si eí pedido ha sido cerrado completamente, entonces el pedido del cliente está listo para facturarse.
Figura 4-5. L’rt ejemplo de entrada del diccionario de eventos.
1 .a descrip ció n del evento inform a al lector, en térm inos claros y simples, cuáles son las políticas del negocio para el cvcnlo. Si los usuarios no leen m ás que la descripción, deberán ser capaces de verificar si se capturó la esencia de su actividad dentro del negocio. La descripción del evento también se vuelve a usar posteriorm ente en la docum entación del diseño. Por ejem plo, cuando se diseña una disposición de ventana, al igual que cualquier ot.ro objeto del mode-
88
Capítulo 4 / EL MODELO DE EVENTOS
lo, se incurre en la obligación de definirla. La parte m edular de cualquier definición de dispo sición de ventana es la descripción de los eventos que son reconocidos por ésta. No hay nece sidad de volver a teclear todas las políticas del negocio en la docum entación del diseño, pruebas, ayuda y material de capacitación. Sim plem ente se les tom a de los m odelos de análi sis y se añaden los elem entos de diseño físico. La sección de estím ulos del diccionario de eventos identifica los datos que se requieren para activar el evento. Todos los eventos necesitan algún tipo de flujo de datos de entrada, lis te puede tomar la form a de un flujo de datos clásico, con elem entos de datos discretos, o de un flujo de control, el eual no contiene datos sino solam ente un m ensaje del am biente que le dice al sistema "hazlo” . Ln el ejemplo no tenem os que alim entar toda la inform ación acerca del p e dido del cliente otra vez al sistema. Ya está ahí, presum iblem ente a causa de un evento p red e cesor E l cliente coloca pedido. E l estím ulo sugiere que el pedido solam ente necesita ser identificado, y la inform ación relevante sobre el pedido puede ser recuperada por las activida des que la necesitan. Los estím ulos son datos. Encontram os a estos datos representados en al m enos otros dos m odelos relacionados. En el diagram a de contexto los estím ulos de eventos pueden ser representados com o uno o m ás flujos de datos que entran al sistem a. Tenga cuidado de no su poner que hay una correlación de uno a uno entre los flujos de datos y los estím ulos de ev en tos. Los flujos de datos pueden estar agrupados arbitrariam ente p o r conveniencia gráfica del diagram a, pero el estím ulo del evento debe ser muy específico p ara el evento del que se tra te. El m odelo principa! en donde se definen los datos es el m odelo de inform ación. En el si guiente capítulo verem os que todos los datos de los flujos de estím ulos, com binados con todos los datos de los flujos de respuesta, com prenden los requerim ientos de inform ación del sistema. La a c tiv id a d sucede dentro del sistem a. Este es todo el procesam iento que el sistema debe hacer para convertir la entrada del estím ulo en una repuesta adecuada p ara el evento. La sección de actividad debe serle familiar. Es una m iniespecificación del proceso. H ay muchas form as para docum entar la actividad de un evento. En la figura 4-5 escogí la escritura de una m inies pee i fie ación corta de ejem plo usando un estilo de pseudocódigo para indicar las políticas del negocio para el evento. Para muchos eventos sim ples todo lo que se necesita es una m iniespecificación breve y el m odelo de in form ación, y con esto ya se tiene lo suficiente para continuar con la creación del prototipo y el diseño. Para eventos más com plejos se necesitará definir el proceso con m ayor detalle. Para nuestro evento de ejem plo, La bodega envía el p ed id o del clien te, se podría h a b er trazado un diagram a evento-entorno para especificar la sección de actividad. C ualquier buena técnica de m odelado de procesos funcionará. La diagram ación de flujos de datos es extrem adam ente útil para la división de procesos com plejos en com ponentes com prensi bles. La figura 4-6 m uestra un diagram a de evento-entorno para la bodega envía el pedido d el cliente. El m odelador debe definir cada sím bolo que se coloca en el diagram a de flujo de d a tos. É ste m uestra gráficam ente el proceso general de la actividad del evento, y perm ite que se divida la actividad en partes m anejables escribiendo una m iniespecificación para cada proceso prim itivo del diagram a. En la práctica he encontrado que el diagram a evento-entor no sólo se necesita cuando una m iniespecificación detallada para la sección de actividad se excede en varias páginas de texto. Para este ejem plo una sección de actividad léxica deberá ser suficiente.
LOS PRODUCTOS DEL MODELO DE EVENTOS
89
C o n te nido del envío
Figura 4-6. Un diagram a de evento-enlom o.
E ste enfoque del em pleo del m odelo de eventos para definir un requerim iento del proce so del sistem a difiere ligeram ente de algunas técnicas históricas del modelado de procesos, sin em bargo, está firm em ente arraigado en trabajos anteriores de M cM enem in y Palm er.5 Ei pro cesam iento requerido por las GUIs y los sistem as cliente/servidor actuales no es menos com plejo que los sistemas m ainfram e antiguos. D e hecho, estos sistemas hacen más en la form a de edición en pantalla, validación y de ayuda al usuario en general que lo que jam ás hubieran po dido hacer las pantallas verdes. Cuando se tiene la probabilidad de que un sistem a actual auto m atizará una mayor parte del negocio que antes, se tiene que com prender más acerca del “procesam iento” . La diferencia en las aplicaciones GUI es que gran parte del procesam iento está m ucho más fragm entado que antes. Los usuarios pueden ejecutar partes individuales de las políticas del negocio haciendo clic en la ventana. No tienen que esperar a oprim ir la tecla
Entrar. En mi propia experiencia sobre el desarrollo de sistemas de negocios cliente/servidor a gran escala, he encontrado que la sección de actividad del diccionario de eventos cubre ade cuadam ente una gran parte del modelo del proceso del sistem a de inform ación. En cualquier sistem a puede darse el caso en el que la riqueza de los requerim ientos de proceso se eleva más allá del punto en que una especificación de texto sola ya no es adecuada. H ay una variedad de técnicas de especificación de procesos disponibles bien conocidas, ciertas y probadas. No veo razón para inventar una nueva. El papel de la diagram ación de flujos de datos ha dism inuido en años recientes, pero la técnica puede ser muy útil para im poner una organización en siste mas muy grandes o cuando se aclaran procedim ientos internos particularm ente com plejos. El diagram a de flujo de datos no hace suposiciones acerca de cuál program a u objeto evenluaim 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.
Capítulo 4 / EL MODELO DE EVENTOS
90
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 implemcntació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 reutilizable. En el diseño de la aplicación, esta política podría ser im plem entada com o un objeto m oni tor de casam ientos separado en un sistem a orientado a objetos, podría ser codificado com o un procedim iento alm acenado en el servidor de base de datos o hasta podría ser designado como un m ódulo de biblioteca que responda a los requerim ientos, o una función en un sistem a es tructurado en form a m ás tradicional. En este punto del análisis se puede elegir el registrar la regla com o su propia mi ni es pee i fie ación de proceso y sim plem ente hacer referencia a ella des de cada sección de actividad de eventos (por ejemplo, ‘‘llam ar la regla de casam iento em plea do/gerente"), o dejar las políticas com pletam ente explicadas en cada entrada del diccionario de eventos y luego revisar los eventos, com o un paso separado, con el objeto de localizar iodos los procedim ientos potencial m ente reutilizables. Algunas reglas de negocio simples están muy centradas en datos (por ejemplo, la fecha de inicio debe ser tnenor o igual a la fecha de term inación), y pueden ajustar muy bien en la definición de atributos en el m odelo de inform ación (tratado en el capítulo 5). Otras reglas del negocio están más centradas en el proceso, y son difíciles de m odelar usando la diagram ación en ti dad-relación tradicional. Algunos m odeladores de inform ación prefieren una notación se m ántica de m odelado que perm ite que se identifiquen las relaciones com o m utuam ente exclu sivas. Esto funciona, pero tiende a añadir una capa de com plejidad al m odelo de inform ación que puede hacer que sea difícil m anejarlo a gran escala. Algunos partidarios del análisis orien tado a objetos asignan reglas del negocio directam ente a los objetos. Yo veo esto com o una de cisión que involucra com prom isos de diseño y, por lo tanto, es prem atura en la fase de descubrim iento. Prefiero registrar las reglas del negocio en la sección de actividad de los even tos que los causan.
LOS PRODUCTOS DEL MODELO DE EVENTOS
91
L a sección de re sp u e sta del diccionario de eventos identifica los datos requeridos por el usuario para lograr el efecto deseado en el am biente de negocios. D esde nuestro punto de vis ta de caja negra del usuario, si se pone un estím ulo de entrada se espera una respuesta particu lar. N uestro ejem plo de la figura 4-5 m uestra una guía de envío com o la respuesta deseada al evento La bodega envía pedido del cliente. Los reportes, ya sean im presos o desplegados vi sualmente, son flojos de respuesta típicos para los sistemas de negocios. La m ejor forma para especificar un reporte es m ediante una ilustración de la disposición deseada y un m odelo de in form ación para m ostrar la m anera en que están organizados los datos fuente. Las respuestas a los eventos tam bién aparecerán en el modelo de contexto, pero tenga cuidado, al igual que ios flujos de estímulos no hay una correlación uno a uno entre una res puesta y un flujo de datos de salida en el diagram a de contexto. M uchos eventos tienen puntos de decisión, ios cuales pueden producir una o más respuestas diferentes para el mismo evento. Otros eventos, tales com o las que sim plem ente actualizan inform ación guardada interna m ente en el sistema, pueden no tener flujo de respuesta anotado en el modelo de contexto. Un ejem plo es un evento de actualización de tabla, tal com o m ercadotecnia añade un nuevo p ro ducto. Este evento inserta una nueva instancia del producto, pero no hay respuesta aparente del sistema a excepción del acuse de recibo de que el nuevo registro de producto fue guardado sa tisfactoriamente. En estos casos m e gusta escribir “guardar acuse de recibo” en la sección de respuesta del diccionario de eventos para que el lector sepa que no se ha om itido una respues ta im portante. El efecto es la poscondición deseada del am biente después de que ha recibido la respues ta. AI igual que el evento, el efecto tam bién sucede en el ambiente. El efecto no es parte del sistem a autom atizado, pero es de gran im portancia para los usuarios. El único propósito del sis tema es producir el efecto deseado en el mundo real. Com o teenólogos nunca debem os perder de vista la razón principal por la que nos están em pleando. Si los usuarios del negocio pudie ran llegar directam ente del evento al efecto sin tener que involucrar ninguna com putadora o program adores m olestos, estarían absolutam ente encantados.
Matrices de eventos Una vez que se tiene una lista de eventos para el proyecto, hay varias m atrices que pueden re lacionar ios eventos con otras partes del modelo de negocios. Trataré a las m atrices de eventos a mayor detalle en el capítulo 8 sobre arquitectura, pero con esto quiero que tengan una idea de hacia dónde vamos. La m ayoría de los negocios grandes opera en más de una ubicación. Estas diversas ubi caciones pueden estar alojadas en el mismo edificio o pueden estar dispersas por todo el m un do. La idea fundam ental de la com putación cliente/servidor em presarial es enlazar todas las ubicaciones del negocio en una red bien integrada. Un elem ento im portante en este esfuerzo es la com prensión de dónde ocurre cada evento. Los eventos pueden ju g a r un papel principal en la determ inación de los requerim ientos de distribución de datos y procesos para un sistem a cliente/servidor. La m atriz de eventos/ubi cación del negocio (figura 4-7) m uestra cuáles eventos deben ser reconocidos en cada ubica ción del negocio, listo le dice que esas ubicaciones necesitarán capacidad de acceso a la com putación para capturar estos eventos. L a matriz, CRUD (Crear, Leer, Actualizar, Horrar) de eventos/entidades (figura 4-8) m ues tra cuáles eventos crean, leen, actualizan o borran instancias de las entidades en el modelo de in
Capítulo 4 / EL MODELO DE EVENTOS
92
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.)
2 c QJ u
z o >-
1
5
(J
E ve n to /u b ica ció n del negocio
Qi
O
¿
E l d ie n to h a ce pedido
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
E l d e p a rta m e n to de p ro d u cció n asig na pedido
X
a> Líi '5 03 Q>
& CC
vi 03 ■o c O
H cu >
■D tíi rtJ c CL' >
"D tíi ÍD ET CU >
X
X
X
tíi ca
‘c o ~ñ CJ cu
re c re a.
del N o rte
>-
=> CC
Planta de C a ro lin a
_l LU
a CE
!
1
P ia n e a eió n lle n a el p ed ido ticl cliente
X
La planta en vía el p ed ido del d ie n te
X
X
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
|
X 1 i
Evento/e nticad
cu c cu
o Zí '■a
ÜJ
□_
CRU
c Q. CU 73 O 15 cu a_
O T3 TJ CL' Cl <33 -c O El (¡3 O o o
C
U
RU
R
E? departa mefíto de producción asigna pedida
R
R
R
C
C
Plgne«»or ¡tena el pedido del cliente
R
R
R
RU
RU
La p-snia e^víc & pecWo rieí d»etrle
R
R
R
RU
RU
Coni3f>¡iiriad
R
R
RU
R
RU
ei pedida deJ diente
Mercad otee rile e n /s e< CctBloga por correo
1
O c i) > = CJ •ti
5
m c t
u íc
S '<5. Í5
í8
E '£
3 m C 2 1—
V T3 O
íz
(O "L_ tí
S o 5 o
¡
C
E? departamento de crédito aprueba pedido
£f diente hace pedido
Transacciones de inventare de producios terminados
Figura 4-7. Una m atriz de eventos/ubicación del negucio.
CR
CR
CRUD
CRUD
CRU
R SS5K3SBSSS
F ig u ra 4-8. U na m atriz CRUD de evento/entidad.
CRU
¡ 1 1 s 1
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-ubjeto. Un em pleado en el m ostrador de recepción puede decir algo com o lo siguiente: “Acmé Supply Com pauy envía un cam ión de entregas rojo cada m artes p o r la mañana. Bob pone la copia am arilla de su lista de em barque encim a de m i charola de entrada. Después del alm uer zo tecleo la lista de em barque en el sistem a GURBNTT.” El analista de negocios rápidam ente convierte esto a el proveedor entrega m ercancías y escribe el evento y una descripción con base en el relato del usuario. Luego adquiere una co-
94
Capítulo 4 / EL MODELO DE EVENTOS
pía de la lista de em barque para exam inar los elem entos de datos que com prenden los estím u los del evento. La siguiente pregunta lógica es encontrar lo que hacc el sistem a G U RBN IT con la inform ación de las listas de em barque, cuál es la respuesta deseada por el usuario y los even tos subsecuentes. El analista inteligente siempre preguntará al usuario si algo no es convenien te o está mal en el proceso actual y estará buscando nuevas oportunidades. En proyectos grandes, o en aquellos en donde el factor clave es obtener el consenso, el analista puede elegir la realización de sesiones de JA R (requerim ientos de aplicación conjun ta) formales. D urante estas reuniones la lista de eventos prim era y el modelo de inform ación se obtienen a partir de un grupo selecto de usuarios por un facilitador en una serie de sesiones de grupo y ejercicios de arranque rápido. Para un análisis más cercano y personal, una gran for m a para descubrir eventos es sentarse junto a los usuarios y observarlos hacer su trabajo du rante un rato. Para los usuarios que puedan lener problem as con las abstracciones más formales del análisis se puede usar un prototipo de papel sim ple para obtener los requerim ientos tanto para el m odelo de eventos com o para el de información.
El plan general Un plan general bien hecho incluirá un conjunto de eventos a nivel conceptual. La lista de eventos que norm alm ente se incluye en un plan g en e ral describe las responsabilidades del sis tema a grandes rasgos. K1 analista de negocios descubre inevitablem ente más eventos y más variaciones sobre los eventos durante el análisis detallado. Sí el plan general no incluye una lista de eventos explícita, sin duda incluirá evidencias de ia existencia de eventos. Los planes generales del proyecto incluyen frecuentem ente una sección a la cual m en ciono como los “m andam ientos". G eneralm ente, ésta es una lista de requerim ientos que co m ienzan con la frase “E l sistem a deberá Considere esto com o eventos antiguos que están esperando que algún analista ilum inado los descubra. Por ejemplo, el plan general puede decir, “El sistem a debe im prim ir un recibo para cada transacción de e f e c t i v o Usando lo que sabe acerca de los eventos, ¿cuál com ponente de un evento es el recibo? Un recibo impreso es la respuesta deseada del sistema. Si el recibo es la respuesta, ¿en tonces cuál es el evento? Se espera que alguien en algún m om ento envíe una transacción de efectivo al sistem a y se supone que éste debe hacer algo al respecto.
Documentación del sistema existente Si se es afortunado y posee docum entación sobre los sistemas heredados que se están reem pla zando, puede apostar que están llenos de eventos. Toda pantalla de entrada o reporte represen ta estímulos y respuestas, evidencian que un evento de negocios sucede. Cualquier script de prueba existente que pueda ser “desenterrado” de la biblioteca del sistem a debe hacer un buen trabajo para asociar los estím ulos con la respuesta esperada.
El modelo de contexto También puede derivar eventos de otros m odelos existentes. Si ya tiene un diagrama de con texto del sistema puede determ inar el evento o conjunto de eventos que intervienen para cada flujo de datos de estím ulo del sistem a y para cualquier flujo de respuesta del sistema.
TIPOS DE EVENTOS
95
El modelo de información M ediante las “entrevistas'’, los eventos pueden incluso derivar al modelo de inform ación. Si el sistem a especifica en el plan general que hay que recordar cualquier elem ento de datos dado, algún evento debe haberlo puesto ahí. La figura 4-10 m uestra un pequeño fragm ento de un ERD (diagram a en ti dad-reí ación que se tratará detalladam ente en el siguiente capítulo). Nos podem os preguntar, “¿que eventos intervienen para la existencia de cada sím bolo en el diagra ma?" Podem os suponer que una nueva instancia de P edido se crea cuando sucede el evento El cliente coloca pedido. Exam inando la cardinalidad que dice que un pedido es colocado por uno y sólo un cliente, sabemos que la relación “Pedido colocado por el cliente” también se crea al mismo tiempo, A hora que hem os establecido la m anera en que se crea un pedido, podem os am pliar nuestra búsqueda de eventos preguntando cuáles eventos actualizan pedidos y com enzar a buscar cualquier evento que elim ine pedidos.
Figura 4-10. Fragm ento E R D para el evento El cliente coloca pedido .
La cardinalidad del lado derecho de la relación también es una pista sobre posibles even tos. El m odelador de inform ación ha indicado que un cliente puede colocar de cero a muchos pedidos. El cero es particularm ente interesante, debido a que im plica que una instancia de cliente puede crearse sin una instancia correspondiente de pedido. Tal ve/, esta com pañía trata de obtener clientes potenciales que tienen una alta probabilidad de que coloquen un pedido. Probablem ente registran la inform ación del cliente pero no aceptan un pedido sino hasta que el cliente pasa por un procedim iento de autorización. También podría im plicar que todos los pedidos de un cliente se pudieran eliminar, sin elim inar al cliente. Sin importar cuál sea la ra zón, la lista de eventos debe ser capaz de llevar cuenta de cualquier cosa que se vea en el m o delo de inform ación. Si se encuentran entidades, atributos o relaciones en la inform ación que no se pueden explicar, entonces se han olvidado algunos eventos o el m odelo tiene algún error.
TIPOS DE EVENTOS Los eventos pueden clasificarse en varios tipos. La com prensión del patrón asociado con cada tipo de evento le da al analista una ventaja adicional cuando determ ina el com portam iento ade cuado del sistem a y ayuda en el descubrim iento de eventos subsecuentes. D eterm inados tipos de eventos tienen características y patrones similares. E l reconoci miento de patrones es uno de los elem entos clave para el reuso. M ediante la detección de un patrón fam iliar que hem os visto antes podem os reutilizar nuestro conocim iento acerca del p a trón. La reutilización no es solam ente aplicable al código. También se aplica a los modelos de negocios. D e hccho, gran parte de ía reutilización que puede ser aprovechada en un proyecto de desarrollo de aplicaciones, viene de tener un modelo del problem a del negocio. Los patro nes son mucho más reconocibles en los modelos que en la form a en que están en el código fuente instalado.
96
Capítulo 4 / EL MODELO DE EVENTOS
Eventos inesperados La m ayoría de los eventos en los sistemas de inform ación de negocios son inesperados. Un evento inesperado significa que, para cualquier instancia dada d d evento, el sistem a nunca sa be cuándo sucederá y ni siquiera si sucederá. El abuelo de todos los eventos inesperados para la m ayoría de los negocios es El d ie n te coloca pedido. (El departam ento de m ercadotecnia puede ponerse un poco a la defensiva sohre este enunciado y argum entar que hay una proba bilidad estadística de que cualquier cliente dado colocará un pedido dentro de un tiem po deter m inado. A menos que el sistema, de hecho esté especificado para hacer esta predicción, El cliente, coloca pedido sigue siendo un evento inesperado.) Ejem plos de eventos inesperados incluyen: El cliente coloca pedido El cliente cancela pedido El departam ento de adquisiciones com pra una nueva planta La gerencia solicita un reporte de ventas ad hoc El departam ento de m ercadotecnia introduce una nueva línea de pro duelo E l departam ento de ventas anuncia un increm ento de precios Las características principales que tienen estos eventos en com ún son que d sistem a no tiene la responsabilidad de predecir o preguntar por su existencia. Si nunca sucede, el sistema sim plem ente pasará todo el día sin hacer nada. Sin em bargo, cuando sucede se supone que el sistem a debe cobrar vida y hacer algo interesante.
Eventos esperados Para un evento esperado, el sistem a determ ina un periodo en el cual anticipa que el evento d e be suceder. Un evento llega a ser esperado cuando un evento predecesor ha puesto un m om en to lím ite en el sistema, antes de que el evento esperado deba ocurrir. El evento todavía ocurre fuera d d sistem a en el am biente, y ia única diferencia es que el sistem a puede identificar la ins tancia o instancias particulares de los eventos por los que está esperando.
Eventos temporales Kl tipo m ás com ún de evento esperado que se encuentra en los sistemas de negocios es activa do por el paso d d tiempo. Los eventos activados por el tiem po son llam ados eventos tem pora les. Estos siempre son esperados, debido a que algún evento predecesor debe establecer la ealcndarización dentro del sistema. Piense sobre la calendan zación com o sí fuera un temporizador, el cual puede ser puesto en una base absoluta, para que se calendarice que el evento succda 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 estados de cuenta mensuales
En el ú ltim o día de cada mes, el departamento de cuentas por cobrar envía estados de cuenta mensuales a todos los clientes que no tienen saldo en cero
Absoluta, el ultim o día de cada mes
Tiem po para notificar a la planta de la salida de embarcaciones
Cinco días antes de la partida calendari¿ada de la embarcación, se envía un listado final a la planta de producción donde aparecen todos los pedidos que deben estar en el muelle
Relativa, cinco días ames de la fecha calendarizada de partida de la embarcación
Tiem po para enviar aviso de cambios de aceite al cliente
Si el cliente no ha regresado en ios 80 días posteriores a su últim o cambio de aceite, se le envía por correo un recordatorio
Relativa, 80 días después del últim o servicio de cambio 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 calendarización que el evento ha sucedido, entra en acción y dispara otro proceso para que m aneje la actividad del evento.
C ú lu rid ü fiz tic ió ri
F ig u ra 4-12. DFD para, un evento reconocido indirectam ente.
98
Capítulo 4 / EL MODELO DE EVENTOS
fin el caso de eventos temporales, el flujo de entrada es el Tiempo, A unque el sistem a de com putadora contiene un reloj, el sistem a mismo no controla el paso del tiempo. H a sido una tradición, desde hace mucho en el modelado de contexto el que no se m uestre un flujo de d a tos llam ado Tiem po entrando al sistema. Está declarado com o universalm ente disponible para todos los sistemas de inform ación. Los eventos reconocidos indirectam ente no están lim itados a los eventos tem porales o esperados. A unque este libro está orientado principalm ente hacia el desarrollo de los sistemas de inform ación de negocios, el concepto de eventos tiene sus raíces en los sistemas de tiempo real. Los sistemas de tiem po real se usan en el control y moni torco de m aquinaria y tienen un conjunto m ucho más rico de reconoce dores de eventos que los sistemas de negocios. Los even tos en los sistem as de tiem po real pueden ser puestos en movim iento por la caída o el alza de la presión en un tanque, o por un producto que llega a un punto de inspección en la línea de producción. Estos eventos pueden ser esperados o inesperados. L a m ayoría de los eventos en un sistem a de inform ación en línea serán directam ente re conocidos. Esto significa que es responsabilidad del usuario decirle al sistema que el evento ha sucedido. El reconocim iento directo de eventos se manifiesta, por lo general, como un botón de com ando o un concepto de menú en la ventana de la aplicación.
El "pseudoevento" El nom bre com pleto de un pseudoevento es “la no ocurrencia de un evento esperado” . Kn tér minos simples, un pseudoevento “ sucede” cuando falla la ocurrencia de un evento esperado. A primera vista parece que esto viola la prim era prueba de un evento, "el evento ocurre''. Esta es la razón por la cual la frase dice, “un evento sucede, en un momento determinado”. Es la cláusula “m om ento determ inado” la que nos perm ite m antener en nuestra lista a los pseudoeventos. Para que uno pase la prueba de evento, su falta de ocurrencia debe ser detectable por el siste m a en un m om ento determ inado. La aparición es determ inada por la expiración de un marco de tiempo, acoplada con la falla de que el evento se presente por sí mismo a la entrada del sis tema. [ií sistem a no puede erear eventos. El efecto de un evento, tal com o el departam ento de facturación fa ctura el pedido del cliente, puede servir de carnada o persuadir al am biente para el siguiente evento esperado en la cadena, el cliente paga el pedido. A unque el sistem a ajusta un periodo de espera (tal com o 30 días a partir de la fecha de facturación), no hay ninguna ga rantía de que el cliente vaya a pagar la factura. Hs este tipo de patrón el que produce el pseu doevento. Los pseudoeventos deben tener un evento esperado asociado. Al igual que todos los eventos esperados, son precedidos en el tiempo por algún otro evento que tiene establecida la expectativa. Los pseudoeventos son a veces ignorados y om itidos en la lista, pero son muy im portantes. Muy frecuentem ente encontrará que hay políticas de negocios m ucho más com ple jas, asociadas a la falta de la aparición de un evento esperado que su ocurrencia ordinaria. El evento E l cliente p aga factura es un asunto aburrido para la mayoría de los sistemas. Hl em pleado de cuentas por cobrar aplica el pago y el saldo pendiente se reduce. Si sucede el cliente fa lla en p agar fa ctura después de 30 días, el sistem a puede tener que hacer cargos pos teriores y enviar un recordatorio cortés. Si sucede el cliente fa lla en pag a r factura despues de 60 días, se le acumulan más intereses por m orosidad y se le envía un recordatorio menos cor tés. Si el cliente todavía no ha pagado después de 90 días, el sistem a puede requerir que se no tifique al departam ento legal para un em bargo a media noche.
ORGANIZACIÓN DEL MODELO DE EVENTOS
99
Cada evento de la lista de eventos debe ser clasificado com o inesperado o esperado. P a ra los eventos esperados siempre se debe preguntar, "¿le preocupa al negocio si no sucede?". Si el sistem a es responsable de las políticas asociadas con el pseudo evento, es probable que se tenga que hacer mucho más trabajo en el proyecto. Si el sistema no es responsable de la detec ción de los pseudoeventos, yo hago una nota sobre ellos en el diccionario de eventos del even to esperado asociado. Esto perm ite que los dem ás m iem bros del proyecto sepan que la pregunta ha sido hecha y contestada.
Revisión de los tipos de eventos Los eventos se clasifican en dos tipos principales: inesperados o esperados. La m ayoría de los eventos de un sistem a de inform ación de negocios en linca serán inesperados. Los sistemas en tiempo real m anejan una cantidad m uchísim o mayor de eventos esperados. La clasificación en estas dos categorías es importante, debido a que sistem áticam ente conduce al analista a un conjunto de preguntas: ¿El evento es inesperado o esperado? Si el evento es esperado, ¿Es un evento temporal esperado relativo a otro evento o a un tiempo absoluto? ¿Le preocupa al sistem a si no sucede (el pse.udoeventoJ? ¿Cuál es el evento predecesor que establece la expectativa? Para los eventos inesperados o esperados, ¿El am biente es (reconocimiento directo) o el sistem a (reconocimiento indirecto) el responsable del reconocim iento del evento? ¿Cuáles son los eventos predecesores en !a cadena? ¿Cuáles son los eventos sucesores en la cadena? El hacer estas preguntas le ayudará a crear un modelo más com pleto del com portam ien to deseado del sistema. I .a distinción entre eventos inesperados y esperados también le ayuda rá en la determinación de la secuencia cronológica adecuada de eventos cuando com ience a organizar la lista de eventos.
ORGANIZACIÓN DEL MODELO DE EVENTOS El modelo de eventos será com pletam ente consum ido en todos los pasos subsecuentes del aná lisis, di serio y pruebas. El modelo de eventos representa un cam bio fundam ental en la organi zación de los requerim ientos del negocio. Tradicionalm entc, cl m odelo de proceso jerárquico fue la estructura principal para m antener los requerim ientos. El modelo de procesos fue representado com o un diagram a de descom posición o un con junto uniform e de diagram as de flujos de datos. D urante la fase de diseño estos procesos esen ciales se transform aron en una gráfica de estructura, la cual proporciona un marco jerárquico de los program as 3GL que podrían ser construidos. La form a del modelo de análisis jerárq u i
Capítulo 4 / EL MODELO DE EVENTOS
100
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
P
I . I NI -:
:í :
CM\‘ T I.IN R
4:
■■■I
H: I 3
RACií
l i l i
SIEXT
¡SiüSfeííífefeSí ííííai; í Óí í í í S í í "¡í í : etíísi.«JSí«iss."a
P I12
LA SI
s íí .í í.Kfit’SSSiíí*
as*
F ig u ra 4-13. Pantalla verde para Mantenimiento de descuentos del cliente.
A hora im agine que tom a el gran program a que se representa m ediante la gráfica de es tructura de la figura 4-14 y divídalo en partes pequeñas, cargándolo en una escopeta y dispa rándolo en una ventana. El resultado podrían ser pequeñas partes de código, fragmentadas com o perdigones y repartidas entre todos los objetos que están contenidos en la ventana. La figura. 4-15 m uestra la m ism a aplicación de m antenim iento de descuento de clientes alojada en una ^ entana GUI. Lo que era un program a estructurado y predecible ha sido dividi do en fragm entos pequeños de código que pueden ser ejecutados independientem ente a discre ción del usuario sim plem ente tecleando o haciendo clic con el ratón.
ORGANIZACIÓN DEL MODELO DE EVENTOS
101
F ig u ra 4-14. Gráfica de estructura de Mantenimiento de descuento de clientes.
F ig u ra 4-15. Ventana G U I para Mantenimiento de descuento de clientes.
El campo ID de cliente ha sido reem plazado por una búsqueda de nom bre de cliente que aceptará cadenas nulas, parciales o com pletas y abrirá una lista de nom bres de clientes concor dantes entre los cuales puede seleccionar el usuario. (Uso en este libro el icono de signo de in terrogación [?J para diferenciar este com portam iento del de una lista desplegable.) La necesidad de recordar los códigos de línea de producto ha sido elim inada perm itiendo la m is
102
Capítulo 4 / EL MODELO DE EVENTOS
m a forma de selección que para el campo de cliente. La ventana m ism a contiene código para abrirla, cerrarla, m overla y redi mencionar! a. Un botón de com ando perm ite que el usuario guarde su trabajo en cualquier momento. H1 modelo de eventos proporciona m ucha más flexibilidad para el análisis para organi zar este modelo. Debido a que el am biente de destino es m ucho inás aleatorio y aplanado, es útil tener la m ism a capacidad en la organización de los m odelos de análisis. E sta sección exa m ina diferentes formas en que puede organizarse el modelo de eventos para que ayude al ana lista y al diseñador hacia la m eta de construir un sistem a G U I cliente/servidor.
Ordenar los eventos en el tiempo U na de las formas más obvias para organizar una lista de eventos es ordenar los eventos en fo r m a cronológica (figura 4-16), A prim era vista la técnica es muy simple. Los eventos son orde nados en la form a en que generalm ente suceden. Los eventos de la lista ordenada están enlazados en una cadena de eventos. Todas las cadenas de eventos com ienzan con un evento inesperado.
Ei cliente coluda pedido El departamento de crédito confirm a el lím ite de cré dito del cliente El cliente paga el anticipo sobre cl pedido Ei gerente de ventas aprueba el pedido El departamento de producción program a el pedido La planta produce el pedido La planta envía ei pedido Es tiem po de enviar estados de cuenta mensuales El cliente paga el saido
Figura 4-16. L ista de eventos ordenada cronológicam ente.
El ordenam iento de una lista de eventos de acuerdo al tiem po hace que sea muy fácil de leer y validar para los usuarios. El orden de los eventos frecuentem ente reproduce la form a en que le han explicado el trabajo. La cronología de los eventos también le da una oportunidad excelente para determ inar los eventos predecesores y sucesores, identificar los eventos espera dos en contra de los inesperados y buscar pseudo eventos que puedan estar faltando en la lis ta. Una vez que se lanza a esta em presa, tal vez encuentre que el ordenam iento de eventos cronológicam ente no es tan sim ple com o parece a prim era vista. En vez de tom ar al ejemplo de la figura 4-16 com o si fueran actos de fe, com encem os haciéndonos algunas preguntas. A esto se le llam a “entrevistar al m odelo” . D espués de hacer la lista cronológica inicial, el siguiente paso com o analista podría ser com enzar a preguntarle más al usuario: ‘'¿El departam ento de crédito siempre tiene que aprobar el crédito de cada pedido o se puede aprobar por anticipado hasta cierto límite'?1’ “¿Todos los pedidos requieren un anticipo?”
ORGANIZACIÓN DEL MODELO DE EVENTOS
103
“¿A lgún d ie n te d ig e pagar todo por anticipado (elim inando la necesidad di; los dos úl tim os eventos)?” “¿Q ué sucede si la planta no puede calendar izar el pedido en un tiem po razonable?” “¿En qué puntos puede el cliente cancelar el pedido?” “¿Están todos los pedidos sujetos a la aprobación del gerente de ventas o solam ente los grandes?” “¿Q ué pasa si el cliente no paga?” “¿Q ué pasa si se rechaza el crédito9” “¿Q ué pasa si el gerente de ventas no aprueba el pedido?” D ependiendo de la respuesta que se reciba, la lista de eventos puede hacerse más com plicada. Tal vez encuentre que un gran porcentaje de los pedidos avanzan a través de la cade na en forma lineal sin problem as, pero otros siguen una diversidad de rutas de excepción. Los pseudo eventos pueden redirigir la cadena de eventos hacia desviaciones alternas o callejones sin salida. A lgunos eventos pueden suceder fuera de secuencia y, en cambio, otros deben se guir una cronología prescrita. Cuando llega el momento de crear una interfaz para este sistema, el diseñador necesita ser capaz de proporcionar fácilm ente la cadena de eventos norm al, pero m antener el m anejo de las excepciones especificadas de una form a razonable. En el siguiente capítulo se presentará un modelo crítico, el diagram a de transición de estados, el cual hacc un buen trabajo para m os trar gráficam ente las rutas de cadenas de eventos com plejas. El ordenam iento de eventos en forma cronológica es muy útil com o herram ienta para va lidar el modelo con los usuarios. Es poco probable que sea capaz de crear una sola cronología para todos los eventos en un sistem a de negocios grande. Por ejemplo, los eventos de m ante nim iento de tablas, tal com o el adm inistrador del sistem a añade un nuevo país, no tienen vir tualm ente una relación útil con los eventos que se refieren a los pedidos de clientes o las transacciones financieras. Sin em bargo, la técnica trabaja extrem adam ente bien dentro de un área de interés particular. M ediante el exam en de la lista de eventos ordenada se puede saber cuáles eventos deben preceder a otros y cuáles son opcionales. El ordenam iento cronológico facilita la detección de eventos esperados y la identificación de pseudo eventos, los cuales pueden faltarle a la lista. Todo negocio tiene excepciones, y son estas rutas de excepción las que com plican el ordena miento cronológico. E l ordenam iento de los eventos en relación con el tiempo es una forma ex celente para descubrir excepciones a las reglas al principio del proyecto y evitar posteriorm ente costosas om isiones. M odelos adicionales, tales com o el diagram a de estado-transición, que se trata en el siguiente capítulo, se necesitarán para ordenar la secuencia de eventos particular m ente confusa.
Ordenamiento por sujeto La sintaxis sujeto-verbo-objeto de los nom bres de evento nos proporciona la habilidad para agrupar eventos por el sujeto que inicia el evento (figura 4-17). E sta técnica vuelve a poner en evidencia el mismo tem a del alcance expandido contra el reducido que se presentó en el capí tulo 3. La lista de eventos es directam ente sensible a cualquier elasticidad en la frontera del m odelo de contexto.
104
Capítulo 4 / EL MODELO DE EVENTOS
Eventos de cliente: El cliente coloca pedido El cliente paga anticipo sobre el pedido El cliente cancela el pedido El cliente recoge un pedido El cliente falla en recoger un pedido Ef cliente paga ei saldo que debe El cliente falla en pagar el saldo que debe El cliente cambia de nombre El cliente cambia de ubicación El cliente presenta una queja por calidad
Eventos de la Planta: La planta calendariza el pedido La planta produce el pedido La planta envía el pedido...
!
F ig u ra 4-17. Listo de eventos ordenad;! por sujeto.
Una lista de eventos de alcance expandido es com pletam ente adecuada en la fase de aná lisis, en especial cuando hay oportunidad para cam biar la organización del negocio. Kn el ca pítulo 3 hay un ejemplo de una función de captura de pedidos que podría ser m ovida de las oficinas centrales a las oficinas de ventas rem otas debido a la facilidad de la tecnología de co m unicaciones y la am plia aceptación de la com putadora personal. Antes de que se finalice tal decisión, prefiero indicar los eventos usando el sujeto de alcance expandido, el cliente coloca pedido. El alcance expandido tiene varias ventajas. En prim er lugar no hace suposiciones sobre la estructura organizacional final de las personas que usarán el sistema. M antiene abiertas las opciones de im plem entación. También perm ite que se ordene la lista de eventos por sujeto y se agrupen todos los eventos que son originados por cl m ism o sujeto (en este caso, el cliente) y se les exam ine para ver si están com pletos, los patrones y la redundancia posible. D espués de que se ha finalizado la decisión de im plem entación en relación con cuáles grupos de usuarios tendrán la responsabilidad de interacíuar directam ente con el sistema, el su jeto puede ser establecido en una form a de alcance reducido. El cliente coloca p edido se con vierte en la oficina de ventas captura el pedido. El ordenam iento por sujeto en una lista de eventos de alcance reducido le da al diseñador de interfaz una gran cantidad de inform ación para organizaría. Perm ite que el diseñador cree agolpam ientos personalizados para ubicar fun ciones en una proxim idad adecuada para los usuarios del sistema. Para m ejorar cl rigor del diccionario de eventos le sugiero que establezca dos propieda des separadas para el sujeto del evento. U na es el iniciador lógico del evento y la oíra es el transportador de la inform ación al sistem a que ha sido indicado por el negocio (figura 4-18). Esto perm ite que se ordene por iniciador o por transportador sin cam biar el nom bre del even to. El iniciador se descubre exam inando el evento m ediante el alcance expandido. El transpor tador está basado en una decisión de im plem entación y de organización por el negocio, y tal v e / no se conozca sino posteriorm ente en el proyecto.
ORGANIZACIÓN DEL MODELO DE EVENTOS
Evento: Iniciador: Transportador:
El diente coloca el pedido Cíiente Asistente de Ventas
Evento: Iniciador: Transportador:
El cliente recoge podido Cliente Empleado de oficina de entregas
105
F ig u ra 4-18. E ntradas en el diccionario de eventos para iniciador y transportador.
El ordenam iento de listas de eventos por sujeto es una técnica poderosa. M ediante el ini ciador de alcance expandido del evento, la lista ordenada m uestra el papel com pleto represen tado por ei sujeto en el contexto del sistema. Veremos en el siguiente capítulo. “El modelo de inform ación” que esto puede ser particularm ente útil para descubrir los elem entos de datos que tal vez el sistem a requiera recordar acerca del iniciador. La lista puede ser verificada fácilm en te por expertos en el tem a del sujeto. Tam bién señala patrones que pueden ser útiles en la d e term inación de que grupo de usuarios debe representar el papel de transportar físicam ente los estím ulos del evento hacia el sistema. Una ve/, que han sido definidos los grupos de usuarios óptim os, el ordenam iento de la lista de eventos por transportador se convierte en una herram ienta valiosa para el diseñador de la aplicación, com o verem os en el capítulo 6 “El prototipo de interfaz” y en el 11 “Diseño de la interfaz externa". L a identificación de todas las tareas de cada grupo de usuarios perm i te también que se planeen los esfuerzos de creación de prototipos, prueba, entrenam iento y do cum entación.
Ordenamiento por objeto Suena razonable que si hay beneficios al ordenar la lista de eventos por sujeto, tam bién puede haber ventajas al ordenar la lista de eventos por objeto (figura 4-19). En este caso utilizo el tér mino "objeto” para referirm e al sustantivo que recibe la acción del verbo en la oración,' Hi ob jeto del evento representa una entidad del mundo r e a l atributo o abstracción de información, tal com o pedido, factura, producto o cuenta de cliente. El objeto puede ser un solo elemento de dato com o en el transportista cambia la últim a fecha de recepción. Hn forma alterna, el ob jeto puede representar muchos elem entos de datos de m uchas entidades, com o en el caso de ei cliente coloca pedido o la gerencia solicita ei. reporte de venías semanal.
'
Una v e / vi una lista de eventos que estaba ordenada por verbo. Fisto puede producir algunos resuHados ex traños (especialmente si la lista contiene eventos tales como el contador ejecuta los repartes de. fin de. mes junio con el citado ejecuta a muerte a la fila de presos). Yo creo que el analista estaba tratando de separar ovemos que creaban información en el sisíema Lie los que solicitaban dalos. Esto se logra en mejor forma con una matriz CRUD de evento/entidad.
106
Capítulo 4 / EL MODELO DE EVENTOS
Eventos de pedido: Eí cliente coloca pedido Ef gerente de ventas aprueba e! pedido El cliente cancela pedido El d iente recoge el pedido El cliente falla en recoger el pedido El departamento de producción calendariza e! pedido El almacén surto el pedido Eventos de la lista de precios: El departamento de mercadotecnia establece una nueva lista de precios El gerente de ventas solicita la lista de precios actual El gerente de ventas solicita el reporte de tendencias de precios
i l t t T K S i s V f l á S r i s s S f e W í S í i s k í ; í í.¡
'¡ f í i : 7 i p i
F ig u ra 4-19. Lisia ele eventos ordenada por objeto.
Kn los sistemas orientados a objetos, el térm ino “objeto” representa una construcción de program ación que se parece a una entidad del mundo reai o a una abstracción de inform ación en sus datos, procesos y com portam iento observable. No estoy im plicando que todo objeto de la sintaxis de la lista de eventos se convertirá en un objeto de un sistem a de negocios orienta do a objetos, sin embargo, hay una gran probabilidad de que m uchas de las clases de objetos del sistema se encuentren en la lisia de eventos como sujetos o com o objetos en la estructura de las oraciones. Tendré más que decir acerca de los objetos del negocio posteriorm ente en el capítulo 12 sobre el diseño de com ponentes internos. F.l truco para ordenar la lista de eventos por objeto es determ inar el objeto principal so bre el que actúa el evento y asignar los nom bres de objetos en forma consistente. Esta técnica no va a ser aplicable para todos los eventos del sistema. Su principal ventaja es identificar todos los eventos de los objetos principales del sistema. Es correcto tener varios eventos aisla dos que no parecen caber con los demás. Un método más riguroso para relacionar eventos con objetos es la creación de una m a triz CRUD de evento/entidad (figura 4-8). Los eventos se listan en un lado de la matriz y las entidades del modelo de inform ación se listan en el otro lado. En cada celda se indica si el evento crea, lee, actualiza o elim ina una instancia de la entidad. Com o veremos en el capítulo sobre el modelado arquitectónico, la m atriz CRUD de evento/entidad puede ser muy útil para determ inar los requerim ientos físicos de sistemas muy grandes y am pliam ente distribuidos. La técnica puede ser excesiva para aplicaciones pequeñas localizadas, y tal vez encuentre que el ordenam iento de 1a lista de eventos por objeto satisface sus necesidades. Ordenar 1a lista de eventos por objeto puede producir algunos beneficios específicos. La lista ordenada puede pasarse a los expertos sobre el tema del objeto para que vean si está com pleta y correcta. Veremos en cl capítulo sobre prototipos de la interfaz que el diseñador en lí nea necesita saber cuáles eventos son capaces de ser ejecutados por el usuario una vez que ha adquirido el objeto del neszocio en la ventana.
ORGANIZACIÓN DEL MODELO DE EVENTOS
107
Para proyectos que son com pletam ente 0 0 (orientados a objetos), éste es el prim er p a so para catalogar los objetos del negocio. Le sugiero en gran m edida que si su proyecto va a ser com pletam ente 0 0 se tome el tiempo para crear un modelo de inform ación, un m odelo de eventos y la matriz CR U D de evento/entidad y los use com o base para catalogar la m ayoría de sus objetos del negocio. Sin este nivel de rigor los objetos son determ inados a veces por “quien grita más fuerte" en la sesión de diseño de grupo y pueden estar sujetos a arranques de pensam iento creativo. Tal vez ya se haya dado cuenta de que ordenar una lista de eventos por objeto, es mucho más fácil si se tiene a la mano el modelo de inform ación al cual pueda referirse. Es virtualm en te im posible crear un modelo de eventos com pleto y útil sin crear sim ultáneam ente el modelo de inform ación. También es poco probable que el m odelo de contexto pueda crearse sin la crea ción de una buena parte del m odelo de eventos. É sta es la razón por la que llamo a estos even tos los “tres grandes” . Ellos forman las bases del análisis del proyecto y se hacen m ejor en form a iterativa y concurrente.
Eventos nivelados Para sistemas muy grandes el analista necesita alguna forma de agrupar eventos de una m ane ra que tenga sentido. Los eventos pueden ser descom puestos o nivelados, al igual que el mo delado de procesos tradicional. HI reto es que el alcance de cualquier evento dado está sujeto a la interpretación del modelador. El analista siem pre debe estar consciente del nivel de detalle de cada fase de un proyec to de desarrollo. Los eventos, al igual que los modelos de procesos tradicionales, tienen una je rarquía implícita. He definido cuatro niveles principales de eventos que encuentro muy útiles para ayudarm e a organizar mis m odelos: el nivel, conceptual, el nivel da negocios, el nivel de diálogo y el nivel de diseño (figura 4-20). El nivel conceptual es útil para la planeaeión del proyecto. El nivel de negocios, junto con un modelo de inform ación, es el corazón y el alm a del esfuerzo de análisis. La creación tem prana de un prototipo del proyecto, introduce el nivel de diálogo que com ienza la transi ción hacia el diseño. El nivel de diseño com prende todas las decisiones tom adas por los desa bolladores acerca de la m anera en que el sistem a será construido físicam ente para reconocer y reaccionar ante el evento del nivel de negocios lógico.
El nivel conceptual El nivel conceptual es adecuado para las fases del plan general del proyecto y planeaeión del proyecto en general. Se pretende que los eventos establecidos a nivel conceptual definan las principales áreas funcionales del sistema. El cliente coloca pedido es frecuentem ente un even to de nivel conceptual en la mayoría de las grandes com pañías, debido a que el proceso de so licitar productos o servicios puede ser muy com plejo. Tan pronto com o el analista entra a los detalles de este evento, pronto encuentra obvio que este evento está a un nivel dem asiado ge neral para un análisis y diseño útil. M uchos proyectos optan por evitar la sintaxis del evento y etiquetan a los eventos del nivel conceptual con un nom bre de área funcional, tal com o captu ra de pedidos, cuentas p or cobrar y contabilidad. listas áreas funcionales pudieran haber sido nom bradas fácilm ente el cliente coloca pedido, el cliente paga factura, es tiempo para conta bilizar ventas.
108
Capítulo 4 / EL MODELO DE EVENTOS
Nivel conceptual
Mivef de negocios
Cliente coloca
El cliente calnca pedido prelim inar
pedido
Nivel de diálogo El representante de ventas captura el en cabezado del pedido
Nivel de diseña Representante de ventas... nace clic en Nueve p e di ::lñ,
El representante de ventas captura la fe cha de envío solicitada
El representante de ventas solícita con firmación del pedido El gerente de ventas confirm a el pedido
El gerente de ven tas solicita pedidos no confirm ados
L
El gerente de ventas confirm a pedidos
captura pedido, hace clic en suarda hace clic en Fecha;.' nr;
:oi
captura petición, hace clic en Suarda
Gerente de ventas... hace clic en / r ic o n tr a r p o r:. de: :;in c o r.f: rn -i: , revisa lista en línea, selecciona órdenes por confirmar, hace clic en f-.jn '.limar,
hace clic en cierra la ventana.
Ü
La oficina de logís tica calendarlza el pedido para envío
El agente de logísti ca solicita calcndarización de pedido
r
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 transporte disponible
El agente de logísti ca asigna pedido a espacio
revisa resultados, modifica excepciones seleccionadas, hace clic en r, cierra la ventana.
F ig u ra 4-20. Niveles de eventos.
El nivel de negocios hi nivel conceptual de el d ie n te coloca pedido nos apunta en la dirección correcta. El análisis detallado d d área de negocios descubre una gran veta de eventos relacionados y más detalla dos que caen bajo su sombra. Estos eventos están al nivel del negocio. Kste es el nivel que es más adecuado para el modelado de eventos durante la fase de análisis, debido a que correspon de a lo que los usuarios del negocio consideran una tarea com pleta. Al nivel de negocios d ob-
ORGANIZACIÓN DEL MODELO DE EVENTOS
109
jetivo principal es descubrir todos los requerim ientos esenciales detallados del sistem a sin di señar el diálogo de interfaz. Cuando los eventos del nivel conceptual son descom puestos en eventos del nivel de negocios pueden tom ar la form a de cadenas de eventos o subtipos. Las cadenas de eventos son varios eventos en sucesión que com prenden el evento de n i vel conceptual lógico. E l cliente coloca pedido puede dividirse en una cadena tal com o el clien te coloca un pedido prelim inar seguido de el gerente de ventas confirma pedido, la oficina de logística calendariza el envío. Los eventos del nivel de negocios fueron dem asiado detallados para m encionarlos en el plan general del proyecto, pero caen claram ente bajo los auspicios de el cliente coloca pedido. Los subtipos de eventos son variaciones del mismo evento. E l cliente del banco solicita un crédito puede dividirse en subtipos del evento tales com o el cliente del banco solicita cré dito para automóvil, el cliente del banco solicita crédito para embarcación, el cliente del b a n co solicita crédito hipotecario para casa. El nivel de negocios producirá m uchas perm utaciones diferentes del mismo evento. Por ejemplo, en un sistema punto de venta de recepción de pagos, el evento el cliente paga m er cancía puede descom ponerse en los subtipos: El cliente paga con cheque El cliente paga en efectivo El cliente paga con tarjeta de crédito Los subtipos del evento ponen en evidencia dram áticam ente a todas las versiones del evento que el sistema tendrá que reconocer. Esto es importante debido a que conduce al análisis para descubrir que los datos de estímulo requeridos y las políticas del negocio asociadas con la sección de actividad para cada subtipo del evento son diferentes. Si el cliente paga con cheque tendrán que capturarse el número de cheque y el número de cuenta, y se deberá verificar que ha ya fondos por medio de una línea telefónica. Si el cliente paga con tarjeta de crédito, el sistema necesita saber el tipo de tarjeta de crédito, su num ero y la fecha de expiración, y verificar el sal do de crédito por medio de un servicio en línea diferente. Para las transacciones en efectivo no se requiere ninguno de estos datos ni procesos. Como analista tiene la opción de docum entar los eventos del negocio al nivel de subtipo o superdpo en el modelo de eventos. Con cualquier m étodo que escoja habrá un com prom iso. Si crea una entrada del diccionario de eventos separada para cada evento de subtipo incurrirá en algunas redundancias para cualquier estím ulo, actividad o respuesta que sea idéntica entre los subtipos. El pasar todos los subtipos hacia una sola entrada del diccionario de eventos tam bién es aceptable, pero tal vez tenga que incluir enunciados de casos m utuam ente exclusivos en las secciones de estím ulos y actividades. En el ejem plo de la figura 4-21, la definición de estím ulos tiene que diferenciar cuáles elem entos de datos corresponden a cuáles subtipos. La sección de actividad tam bién tendrá que indicar cuál procesam iento es exclusivo para cada subtipo. Tam bién vem os que los pagos por cheque y tarjeta de crédito necesitan un evento que interviene antes de que pueda term i narse la transacción de com pra lógica. El sistem a tiene que hacer una llam ada telefónica al servicio de verificación y esperar una autorización, Kl resultado de la visita del cliente a la tienda puede variar dram áticam ente dependiendo de si el evento subsecuente resulta ser el servicio de verificación autoriza la transacción o el servicia de verificación rechaza la tran sacción.
10
Capítulo 4 / EL MODELO DE EVENTOS
ID de evento:
37
Evento:
Eí cliente paga mercancía con cheque, en efectivo 0 con tarjeta de crédito
Descripción:
Después de que el cajero le dice el total a payar al cliente, el cliente hará el pago en efectivo, con cheque personal o con tarjeta de crédito. Los che ques y tarjetas de crédito se verifican por m edio de un servicio en línea.
Estímulos:
If efectivo Cantidad entregada if cheque Cantidad entregada Número de cheque Número de cuenta barcaria if tarjeta de erudito (cantidad exacta solamente! Tipo de tarjeta de crédito Número de cuenta Fecha de expiración End if
Actividad:
Leer cantidad total qi;e se debe If efectivo Registrar la cantidad recibida Calcular el cambio que se debe dar Im prim ir recibo If cheque Registrar cantidad recibida, número de cheque, número de cuenta bancaria Llamar por teléfono al servicio de verificación de cheques If tarjeta de crédito Registrar tipo rie tarjeta de crédito, número de cuenta, fecha de expiración Llamar por teléfono al servicio de verificación de tarjetas de crédito End if
Respu esta:
If efectivo Recibo = ID de la tienda, fecha, hora, cantidad que se debe, cantidad re cibida, cambio que se debe dar. If cheque (enviar al servicio ríe verificación de cheques) cantidad recibida, núme ro de cheque, número de cuenta bancada, ID de la tienda. If tarjeta de crédito (enviar al sen/icio de verificación de tarjetas de crédito) cantidad que se debe, tipo de tarje:a, número de cuenta, fecha de expiración, ID de la tienda. End if
Efecto:
Si es efectivo el cliente ha pagado todo. Si es cheque o tarjeta de crédito, el cajero y el cliente están esperando autorización.
F ig u ra 4-21. 1.a entrada del diccionario de eventos de supcrúpo debe ser de tres entradas separadas.
ORGANIZACIÓN DEL MODELO DE EVENTOS
111
Después de tratar de crear un diccionario de eventos para el supertipo (figura 4-21), que da dan> que las diferencias entre los subtipos sobrepasan sus sim ilitudes. Yo optaría por hacer las entradas del diccionario de eventos separadas para los eventos de subtipo de este caso. Los subtipos también aparecerán nuevam ente en el siguiente capítulo. Los que se encuentran en el modelo de eventos es probable que se reflejen en los subtipos dei modelo de inform ación. Q ué tanto se deberán aplicar niveles al modelo de eventos, puede ser un tem a para un d e bate intelectual, sin embargo, la experiencia pronto guía al analista haeia una solución prácti ca. Pocos eventos de la lista producirán entradas del diccionario de eventos m ás com plejas, y eventos más detallados tendrán especificaciones sim plificadas pero habrá muchos más de ellos. Mi regla práctica general es sim ilar a la heurística para la diagram ación de flujos de d a tos. Cuando la sección de actividad com ienza a exceder de una a tres páginas de especificacio nes, o cuando se están introduciendo num erosos enunciados de casos (case) en los flujos de estím ulo y respuestas, probablem ente se necesita descom poner más al evento, ya sea m edian te subtipos o buscando una división lógica en la cadena. Sí la lista de eventos es gigantesca, y la sección de actividad es realm ente escasa, es posible que se esté com enzando a diseñar cl diá logo de inlerfaz y que se haya descendido más allá del nivel de negocios.
El nivel de diálogo U na de las tareas principales del diseñador de interfaces es determ inar el nivel adecuado de diá logo entre el usuario y el sistema. LI nivel de diálogo tom a cada evento del negocio y lo divi de en un diálogo entre el usuario y el sistema, con base en el poder de la tecnología, el nivel de habilidades del usuario y la unidad de trabajo adecuada para la tarea de negocios que se tiene. Para ilustrar este punto tomemos dos eventos de una tienda de departam entos. El prim er evento, el proveedor firma un nuevo contrato de precios, sucede cuando alguno de los provee dores de la tienda de departam entos firm a un acuerdo exclusivo para proveer a la tienda de un descuento establecido por abajo de su precio normal. Los térm inos del acuerdo van a ser cap turados en el nuevo sistema de com putadora. Digamos que el acuerdo lo captura un em picado en el departam ento de cuentas por pagar y que tiene 15 años de experiencia en com putación. Si hay diez elem entos de datos en los estím ulos para este evento, es probable que el diseñador de interfaces sea capaz de ponerlos todos en una sola ventana. El evento de negocios ha sido im plem entado en el sistema sin haberlo dividido en fragm entos de diálogo más pequeños. Un segundo evento, un cliente pregunta p o r el estado de un pedido pendiente, va a ser im plem entado por m edio de una term inal en un kiosco a la entrada de la tienda. Los clientes pueden consultar directam ente el estado de la m ercancía disponible en la tienda y hasta ver si el artículo deseado ha sido incluido en los pedidos pendientes. Este evento requiere también unos cuantos elem entos de datos, tales com o el departam ento, el tipo de vestimenta, el nombre de la marca, el color y la talla. Debido a que la term inal del kiosco va a ser usada por el público en general, y no por un “usuario poderoso’7profesional, los diseñadores pueden dividir el evento en un diálogo más “dosificado” entre los hum anos y la com putadora. En este caso el diseñador puede dividir el evento para que la com putadora pregunte por separado cada parte de la inform ación. Por ejem plo, el usuario puede apuntar prim ero el departam ento que desea y la com putadora le p reg u n tará el tipo de artículo que quiere, Lste fragm ento sólo califica com o un evento a nivel de diálogo. Ls sim plem ente una pequeña pieza del evento de negocios, pero el diseñador ha op tado por crear un diálogo para hacer que la com putadora sea más fácil de usar por el cliente promedio.
112
Capítulo 4 / EL MODELO DE EVENTOS
El nivel de diálogo com ienza por lo general en el prototipo tem prano (capítulo ó) y se cúm plela en el diseño de interfaz externa detallado (capítulo 11). En este nivel la lista de eventos y el diccionario de eventos se aprovechan com pletam ente para diseñar la interfaz adecuada. C ada evento se divide en una conversación entre el usuario y la com putadora con base en la tecnología disponible, el nivel de habilidades del usuario y la unidad de trabajo adecuada. Al nivel de diálogo los eventos son dem asiados para m anejarlos de una m anera prác tica por m edio de una lista de eventos y de un diccionario de eventos. El diagram a de n av e gación, el prototipo de interfaz y la disposición de ventanas son m odelos m ucho m ejores para m ostrar el com portam iento del sistem a propuesto. M ediante la lista de eventos y del diccionario de eventos com o base para el diseño de la interfaz, se realiza la ingeniería del com portam iento adecuado en el producto. C ada ventana o ju eg o de ventanas desarrollado debe ser rastreable a los eventos del nivel de negocios lógicos para los que fueron diseñados a res ponder.
Ei nivel de diseño Hl últim o nivel en la jerarquía de eventos son los teclazos y clics de ratón actuales que tendrán que codificarse para im plem entar el evento. Al nivel de diseño, el diálogo del evento es descom puesto todavía más hacia la acción específica que debe realizar el usuario para informar com ple tam ente al sistem a que el evento ha ocurrido. El nivel de diseño incorpora la navegación actual, los nom bres de botones y conceptos de menú y el posicionam iento específico de los cam pos en cada ventana. Las herram ientas adecuadas para este tipo de diseño detallado son el diagram a de navegación de ventanas, la disposición de ventana, la especificación de diseño GUI que describe la activación y com por tam iento de cada control de la ventana y la presentación y reglas del negocio para los datos mismos. Veremos en los siguientes capítulos que la interfaz de usuario puede ser construida a partir del modelo de eventos del negocio y del modelo de inform ación m ediante un proceso confiable y repetible.
RESUMEN El modelo de eventos es el pegam ento que m antiene juntas todas las piezas del análisis, dise ño, construcción y prueba. La lista de eventos incluye la razón por la que usted ha sido contra tado. El negocio necesita ser capaz de responder a eventos del mundo real, y es responsabilidad del personal de tecnología de la inform ación el proporcionarle los productos que sirven a esa necesidad. El modelo de eventos contiene una lista de eventos y un diccionario de eventos. Siem pre que sea posible, los eventos de la lista son mencionados en una sintaxis sujeto-verbo-obje to. El diccionario de eventos proporciona la parte m edular de la especificación del proceso para el sistema. Para cada evento de la lista el analista tiene la obligación de definir su significado en texto claro y conciso. parte técnica del diccionario de eventos contiene una definición de los datos de estím ulo requeridos para activar el evento, la actividad realizada por el sistem a pa ra form ular la respuesta adecuada y los datos contenidos en esa respuesta. A dem ás, se docu menta el efecto sobre el am biente para que se pueda com prender lo que los usuarios están tratando de lograr.
EJERCICIOS
113
La m ayoría de los eventos de negocios son inesperados. El sistem a nunca sabe cuándo sucederá un suceso particular. Algunos eventos son esperados. Un evento predecesor ha esta blecido alguna ventana de espera dentro de la cual el sistem a anticipa la aparición del evento. Es muy importante que el analista pregunte si al sistem a le preocupa que el evento no suceda, e incluir el “pseudoevento” en la lista. Los eventos esperados en un sistem a de negocios pue den ser eventos tem porales, significando que son activados p o r la m edida del paso del tiempo contra un calendario. Sin em bargo, la m ayoría de los eventos de un sistem a de negocios se apo yarán en el usuario para que inform e directam ente al sistem a que el evento ha sucedido. El modelo de eventos es un docum ento poderoso que es aprovechado com pletam ente a lo largo del proyecto. El modelo de inform ación, que es la base para el diseño de la base de da tos subyacente, se construye en form a sim ultánea con el modelo de eventos catalogando los datos requeridos para cada evento. El prototipo de interfaz declara disposiciones de ventanas candidatos con base en la capacidad de la tecnología, la habilidad de los usuarios, la com ple jid ad y secuencia de los eventos y el carácter de los datos requeridos. Los eventos tam bién tienen un papel principal en las decisiones arquitectónicas. Se pue den usar m atrices de eventos para planear los requerim ientos de hardw are con base en cuáles eventos suceden en diversas ubicaciones de negocios distribuidos. El diccionario de eventos es nuevam ente aprovechado en la fase de diseño detallado mientras el diseñador determ ina las ru tas de navegación, especificaciones de mentís y botones, clases de objetos, funciones de fondo y procedim ientos alm acenados para ejecutar las políticas del negocio para el evento. El modelo de eventos tam bién se convierte en la base para la creación de planes de prue ba. El diccionario de eventos ya.contiene una asociación entre los estím ulos requeridos y las respuestas adecuadas que pueden ser expandidas fácilm ente a escenarios de prueba. El modelado de eventos tiene sus raíces en el análisis estructurado tradicional. L a técni ca se ha puesto al frente actualm ente debido a que los sistemas que estam os construyendo son m ucho m ás aplanados que las estructuras jerárquicas de antaño. La lista de eventos y el d ic cionario de eventos han probado ser m odelos de desarrollo GUI poderosos. El térm ino m ane ja d o p o r eventos se usa para describir a los sistem as GUI, debido a que los patrones de navegación del usuario y el flujo de trabajo es mucho más im predecible ahora que está arm a do con un ratón. L a clave para el buen diseño GUI es la com prensión de la m anera en que el sistem a d e be com portarse cuando responde a los eventos de negocios e incorporarle la suficiente flexibi lidad al diseño para m anejar varios eventos y secuencias no tradicionales. Esto no quiere decir que el diseño de ventanas GUI perm ita que cualquier cosa ocurra. U na tarea significativa del diseñador G U I es decidir lo que el usuario no puede hacer en un m om ento dado. Un modelo de eventos sólido ayuda a organizar esta tarea.
EJERCICIOS 1. ¿Cuáles de los siguientes eventos son esperados o inesperados en un sistem a de ad m inistración de pedidos típico? a) El cliente coloca pedido b) El gerente de crédito aprueba pedido
114
Capítulo 4 / EL MODELO DE EVENTOS c) El cliente c a n illa el pedido d) La bodega surte el pedido e) Rl cliente falla en pagar la factura 2, M aureen es el agente de com pras de la vinícola Villa St. Emily. Su trabajo es revisar órdenes de com pra que han sido capturadas en el sistem a por la oficina del cam po y aprobarlas o rechazarlas. Las órdenes de com pra ya están en el sistema, por lo tanto, ¿cuál es el estím ulo para la entrada del diccionario de eventos para el gerente de p e didos de com pra aprueba pedido de com pra? ¿Es el identificador de pedido de com pra y el estado de aprobación o son todos los criterios de selección que pueda usar M aurcen para obtener una lista de órdenes de com pra en la ventana? 3. En la vinícola Villa St. Emily hay una regla del negocio que indica que si un pedido en proceso tiene su precio de acuerdo con la lista y si la lista de precios cambia antes del envío, la orden debe ser revisada por un gerente de ventas para conservar el pre cio antiguo o volver a aplicar el nuevo precio al pedido. ¿Dónde debe ser docum enta da esta regla de negocios en los modelos de análisis?
RESPUESTAS 1. a) El cliente coloca pedido es, por lo general, un evento inesperado en la mayoría de los sistemas de negocios. Pocos negocios conocen por anticipado euál cliente co locará cualquier pedido particular en un m om ento específico. b) El gerente de crédito aprueba p edido es un evento esperado, suponiendo que es tá precedido por el evento el cliente coloca pedido, el cual establece una ventana de espera dentro de la cual deberá ser aprobado el pedido. c) E l cliente cancela el pedido es inesperado. d) La bodega surte el pedido es esperado, a m enos que la bodega esté surtiendo los pedidos al azar. e) El cliente falla en pagar la factura es, de hecho, la no ocurrencia de un evento es perado, el cliente paga factura, o en otras palabras es un pseudoevento. 2. Los estím ulos podrían ser el identificador de orden de com pra y el estado de orden de com pra con un valor de “aprobado” . La actividad del evento podría actualizar el estado del pedido de com pra identificado a “aprobado". (Es posible que no haya res puesta requerida del sistema para este evento.) En el modelo de eventos sólo necesi ta hacer notar que el usuario necesita una form a para adquirir la orden de com pra para indicar su aprobación. Se puede usar el prototipo para determ inar exactam ente la m anera de lograr esta tarea. En este ejemplo, el nivel de diálogo es mucho más in teresante que el evento de nivel de negocios de peso ligero. En el diseño de la inter faz tai vez se le quiera dar al agente de com pras una forma para recuperar todos los pedidos de com pras del sistem a que requieren aprobación usando una diversidad de criterios de selección. Una vez que se encuentra en la ventana una lista de pedidos de compra, tal vez se perm ita que el usuario apunte a uno (o tal vez más de uno si es
RESPUESTAS
115
adecuado) y ponga el estado a “aprobado” por medio de un botón de com ando o un elem ento de menú, lie visto algunos equipos de provéelos que no quedan a gusto de jando la fuñe ion de “exanim ación” de este evento fuera del diccionario de eventos. Mi sugerencia en este caso es crear otro evento, el agente de com pras examina órde nes de com pra y listar todos los diversos criterios de selección bajo los estímulos pa ra ese evento en vez de especificar el evento de aprobación sin haber dicho la manera en que las órdenes de com pra se recuperan en el sistema. 3. Un buen lugar confiable para docum entar la regla podría ser el evento de negocios "el departam ento de m ercadotecnia cambia la lista de precios actual". De esta for ma la regla de negocios se cita en el evento exacto que la llamará. Si la regla fuera llam ada por más de un evento podría estar docum entada en un lugar y simplemente referida por nom bre en las secciones de actividad del evento que ejecutan la política.
C a p ítu lo
5
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 CASEautomatizadas. Hl rom bo se ha elim inado en favor de una sola línea para representar relaciones. Prm clPal razón por la que el rom bo perdió interés es que ocupa dem asiado espacio en la pantalla de la com putadora. Chen, 1976. CASI: son las siglas tic Ingenie.™ de Software Asistida por Computadora.
120
Capítulo 5 / EL MODELO DE INFORMACIÓN
F igu ra 5-1. Notación Chen.
Algunos (le los prim eros que adoptaron la técnica de Chen tuvieron m ucho éxito en el modelado de sus requerim ientos de datos. Otros experim entaron problem as en la fase de di seño, debido a que las bases de datos relaciónales todavía no habían obtenido su lugar en el mercado. Las restricciones del archivo plano o de las bases de datos jerárquicas de ese tiempo frecuentem ente dieron lugar a desviaciones dram áticas del m odelo de datos lógico cuando se im plem eniaba un diseño. A ctualmente, con la llegada de ia tecnología de bases de datos relaciónales modernas es posible y deseahle im plem entar una base de datos que se parezca mucho a la estructura de los datos en el mundo real. Las bases de datos relaciónales han mejorado continuam ente su veloci dad y habilidad para m anejar en form a eficiente varias uniones de tablas. Estas mejoras, junto con la disponibilidad de espacio de disco más barato han elim inado la m ayoría de las críticas sobre el modelado de datos planteadas por los escépticos iniciales. La estructura del modelo de datos también ha sufrido algunas m ejoras desde el tiempo de Chen. La m ayoría de las herram ientas CASK hacen razonablem ente un buen trabajo de m anejar el modelo de datos, pero desafortunadam ente los proveedores que están en com pe tencia han introducido una diversidad de notaciones, H1 térm ino modelado de información se ha vuelto una moda, debido a que ei térm ino dalos im plica un conjunto de hechos, pero infor mación implica que los hechos tienen alguna relevancia para cl negocio más allá de su misma existencia. No soy muy quisquilloso acerca de euál térm ino se use. El térm ino m odelado de objetos se ha sido utilizado en un intento de parecer más orientado a objetos pero este térm ino lleva consigo una connotación más com pleja de procesos y elem entos de com portam iento, así com o una desviación o suspensión de las reglas tradicionales de norm alización. Por esta razón, incluso en un proyecto con un lenguaje de destino orientado a objetos, prefiero construir un modelo de información para docum entar mis requerim ientos de datos, en especial, cuando está involucrada una base de datos relacional. La actividad de catalogar objetos es una tarea natural que se da a continuación.
LOS COMPONENTES DEL MODELO DE INFORMACIÓN Un modelo de inform ación com pleto que sea lo suficientemente detallado para que sea útil en d diseño subsecuente o en las decisiones de compra de paquetes de software debe incluir lo sieniente. KI resto de este capítulo proporcionará definiciones detalladas para cada componente. K1 diagram a entidad-relación m ostrando todas las entidades denom inadas, relaciones nom bradas y la cardinalidad m ínim a y m áxim a de cada relación en am bas direcciones. Los diagram as grandes deben dividirse para asegurar su legibilidad. J.as estim aciones de v o lu m e u y re te n c ió n estim adas para cada enttdado.
LOS COMPONENTES DEL MODELO DE INFORMACIÓN
121
Un listado de atrib utos para cada entidad. Una definición escrita y clara de cada entidad, relación y atributo. Las propiedades de cada atributo incluyendo: opcionalidad, tipo de dato, rango, unidad de m edida, precisión y valores restringidos. D iagram as de estad o-tran sición para cada atributo de estado o ciclo de vida de enti dad relevante. U na diversidad de m atrices de entidad.
Si esto parece mucho pedir, lo es. Este modelo proporciona las bases detalladas para todas las decisiones de diseño de datos que vienen a continuación, incluyendo el diseño de base de datos físico, la distribución de los datos y hasta la disposición de ventanas y reportes. Un modelo de inform ación llam ado de “alto nivel’ el cual solam ente incluye un diagram a hecho a la carrera sin atributos ni definiciones no tiene ninguna utilidad para el diseñador o para el equipo que va a com prar el paquete de software. Sin tom ar en cuenta si se construye o se com pra el software, aquí es donde el proyecto debe entrar a los detalles latosos de los requeri m ientos del negocio. Es m ejor tomarse el tiempo necesario para construir el m odelo de inform ación ahora, que el sufrir las consecuencias de tom ar posteriorm ente decisiones mal inform adas.
El diagrama entidad-relación El elem ento gráfico principal del modelo de inform ación es el diagram a ERI) (entidadrelació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.
Capítulo 5 / EL MODELO DE INFORMACIÓN
122
Contacto con cl cliente
Empleado
Representa a
Está representado por
Fue
tomado
Tomó
por
||
Cliente
Colocó
■Q ^
Fue colocado por
Es el área geográfica de
Contiene
Concepto
Fue
de pedido
Pedido p e d id o en
Fue perlido en
Se encuentra
en
Solicita la entrega de
Es ei precio Región de mercado
Precio de producto
>3— Se vende en
Producto
F igura 5-2» U n ejem plo de diagram a cutí dad-reí ación.
Las entidades son representadas gráficam ente com o un rectángulo. El nom bre de la enti dad se coloca dentro de él. Im agine que el rectángulo contiene m uchos puntos. C ada punto rep resenta una instancia individual de la entidad. Ninguna instancia independiente es representada dos veces (figura 5-3).
Figura 5-3. Cada m iem bro de una culi dad es único.
Cuando se crea una entidad, al igual que cualquier otro objeto en ei modelo, se tiene la obligación de definirla- Kscriba el nom bre de la entidad y luego escríba una definición clara. Trate de im aginarse m entalm ente si la definición describe adecuadam ente a las instancias del
LOS COMPONENTES DEL MODELO DE INFORMACIÓN
123
mundo real de la entidad. Lea la definición y vuelva a exam inar el nom bre de la entidad para ver si ha escogido el mejor. C onlorm c crea el m odelo, tal vez llegue a estim aciones de volum en y retención de la entidad. El volumen es la cantidad de instancias de la entidad que puede esperar el negocio, tal com o la cantidad de clientes, cantidad de pedidos por año, cantidad de proveedores. La reten ción es qué tanto tiempo se necesita m antener en línea cualquier instancia dada de la entidad. Estas estadísticas llegarán a ser importantes posteriorm ente en el diseño de la arquitectura y la aplicación, por lo que si ahora encuentra la inform ación es bueno incluirla con la definición de la entidad.
Relaciones Los m iem bros de la entidad son muy sociables. Las instancias de las entidades se asocian cons tantem ente con otras entidades. Los clientes colocan pedidos, los pedidos pueden tener varios conceptos de pedido, cada uno asociado con un producto, el cual puede estar asociado con un saldo de inventario, y así sucesivamente. A estas asociaciones se les llam a relaciones. Una relación se traza com o una línea entre una entidad y otra. Im agine que la línea conecta los “puntos" o las instancias de una entidad con las instancias de otra. En la figura 5-4 vem os una relación entre la entidad Persona y la entidad P erro.} La relación puede leerse en cualquier dirección. AI leer de izquierda a derecha usamos el nombre que está encim a de la línea, “la per sona poseyó un perro” . A! leer de derecha a izquierda usam os el nom bre que está abajo de la línea, “el perro ha sido propiedad de la persona” .
Poseyó Ha sido propiedad de
Figura 5-4. O rientación horizontal.
Para las relaciones que se m uestran vertical mente (figura 5-5) o en ángulo, im agine la relación horizontal girada en sentido del reloj. El nom bre que estaba en la parte de arriba ahora se lee de arriba hacia abajo al lado derecho. El nom bre que estaba en la parte inferior ahora se lee hacia arriba del lado izquierdo. Tal vez haya observado que nom bré esta relación en pasado. Al igual que cualquier otra palabra que usam os en un m odelo, los nom bres de las entidades y relaciones necesitan ser muy precisos para expresar el mismo significado a cada lector. Si se supone que la relación repre-
:í
Debo dar crédito a Meilir Pagc-Jones por su ejemplo famoso a nivel mundial 1.a persona posee pena, que ha ■ sido puesto en serv icio muchas veces para ilustrar muchos conceptos de modelado de información.
124
Capítulo 5 / EL MODELO DE INFORMACIÓN
F igura 5-5. Orientación vertical. senta a todos los perros que alguna vez haya poseído el propietario, el tiem po pasado es a d e cuado. Si la relación está restringida únicam ente al o los perros que posea actualm ente, se deberá usar el tiem po presente. Todavía mejor, los nom bres de relación pueden ser m odifica dos para que sean todavía m ás descriptivos, tal com o “ la persona alguna vez ha poseído perro” o “la persona actualm ente posee perro” . A dem ás de nom brar la relación tam bién se tiene la obligación de definirla escribiendo una oración clara. Los nom bres de relación son extrem adam ente im portantes debido a que son capaces de expresar mucho de las políticas y eí significado del negocio cuando son nom bradas adecuada m ente. I,e ruego que evite nom bres am biguos tales com o Puede tener, Está relacionado a o E stá asociado con. El hecho de que se haya trazado una línea ya inform a al lector que existe una relación o asociación. Este tipo de nom bres descuidados es casi tan útil com o el nom brar Entidad a cada entidad.
Cardinalidad de ¡a relación H ay una restricción im portante que se declara gráficam ente en las relaciones en cl diagram a entidad-relación y se le llam a cardinalidad, la cual representa qué tantos de una cosa se rela cionan con otra. La cardinalidad de la relación es particularm ente im portante debido a que form a la base de m uchas decisiones de diseño. La cardinalidad se expresa con un valor para un m ínim o y un máximo. El valor m ínim o describe si la relación es opcional o requerida. El valor m áxim o describe si la relación es singular o plural. D ebido a que las relaciones se indi can en am bas direcciones entre las dos entidades, la cardinalidad m ínim a y m áxim a tam bién debe ser indicada en am bas direcciones. Esto significa que para cada relación del modelo se requieren cuatro punios de cardinalidad para expresar adecuadamente la naturaleza de la rela ción (m ínim o y m áxim o en am bas direcciones}.4 Explorem os las diferentes facetas de la car-
4 Es cierto que ¿s los grandes modelos de información a nivel conceptual, que se usan para la planeación y no para cl diseño detallado poede bastar únicamente con el establecí miento de la cardinalidad máxima. Sin embargo, fiiaivln se pasa al análisis y diseño detallado se necesitan los cuatro puntos de cardinalidad para expresar adecuadamente las reglas del negocio que necesitan hacerse cumplir en la estructura de base de datos y tal vez también en la interfaz.
LOS COMPONENTES DEL MODELO DE INFORMACIÓN
125
dinalidad de la relación usando nuestro ejem plo de “ la persona actualm ente p o see perro” (figura 5-6).
Figura 5-6. Relación sin notación de cardinalidad.
U na vez que se ha establecido en el plan general que el sistem a debe recordar cuáles per sonas poseen actualm ente cuáles perros, las siguientes cuatro preguntas que se presentan son: 1. ¿D ebe una persona poseer un perro? 2. ¿Puede una persona poseer m ás de un perro? 3. ¿D ebe un perro ser siem pre propiedad de una persona? 4. ¿Puede un perro ser propiedad de m ás de una p ersona a la vez? La pregunta 1 está diseñada para obtener la cardinalidad m ínim a cuando se lee de izquierda a derecha, de entidad A a entidad B. ¿Hn nuestro sistema, está una persona forzada a ser propietaria de algún perro? D e ser así, ¿qué pasa si el perro se m uere o se escapa? ¿D ebe m os correr del pueblo al individuo que no tiene perro? ¿Lo debem os acosar hasta que obtenga un nuevo perro? ¿D eberem os darle un reem plazo? La pregunta 2 está diseñada para determ inar si la m ism a instancia de la entidad A puede participar en relaciones con varias instancias de la entidad B al m ism o tiempo. Cuando quedan determ inadas las respuestas a las preguntas 1 y 2, el analista puede poner la cardinalidad m í nim a y m áxim a cu el diagram a para expresar la regla del negocio. La notación gráfica para la cardinalidad m ínim a es un cero que significa, “opcional” , o un uno que significa “requerida” . La notación para la cardinalidad m áxim a es un uno, que sig nifica “solam ente uno” o un par de patas de cuervo significando “m uchos” . L a figura 5-7 m ues tra las cuatro com binaciones posibles y su denom inación más aceptada.
M ín
M áx
N o ta c ió n g r á fic a
------ Of(X --------------- HK
C ero
- a -
uno
—
C ero
- a -
m uchos
-----------------------
Uno
- a -
uno
Uno
- a -
m uchos
--------------------------
Figura 5-7. Notaciones para la cardinal idad de la relación.
126
Capítulo 5 / EL MODELO DE INFORMACIÓN
La notación de cardinalidad se coloca directam ente en la línea de relación a la derecha del nom bre de relación que modifica. Si hem os determ inado que una persona puede poseer cero o m uchos perros, podría expresarse gráficam ente com o la figura 5-8.
Posee actualmente Pe rsona
"
Es actualm ente propiedad de
CK
Perro
fig u ra 5-8. Relación con cardinalidad mínima y máxima en una dirección.
Para leer el diagram a se com ienza diciendo el nom bre de la prim era entidad, seguido del nom bre de la relación adecuada en la dirección que se está leyendo, seguido de la notación de cardinalidad y. por últim o, el nom bre de 3a segunda entidad. En la figura 5-8 leemos “la per sona posee actualm ente de cero a muchos perros” . Sólo hem os term inado a medias con la cardinalidad de la relación. Tenemos todavía que responder a las preguntas 3 y 4, las cuales nos dirán la cardinalidad en la dirección opuesta. La pregunta 3 com ienza con la entidad perro y se lee hacia atrás, hacia persona, preguntando si la relación entre un perro y su dueño es opcional o requerida. La implicación de negocios de una cardinalidad m ínim a de ccro es que perm itirem os perros sin dueño en el sistema. La pregunta 4 se refiere a si perm itirem os una custodia m últiple de perros, o si el propie tario del perro siempre es solam ente una persona. Observe que la relación se llama es actual m ente propiedad de. Podríam os obtener una respuesta diferente a nuestra pregunta si la relación significara fue alguna vez propiedad de. Suponiendo que el negocio nos dice que un perro puede ser actualm ente propiedad de una sola persona, y que un perro debe tener un propietario para ser un perro de interés, podem os term inar nuestro diagrama colocando la cardinalidad de la relación mínima y m áxima para el lado opuesto de la relación (figura 5-9). '
Figura 5-9. Relación con los cuatro puntos de cardinalidad.
Hn resum en, la cardinalidad de la relación está expresada por la cantidad de ocurrencias m ínim a y m áxim a perm itida entre una instancia de la entidad A y las instancias de la entidad R- Para describir com pletam ente la naturaleza de la relación, tam bién se debe determ inar la cardinalidad entre una instancia de la entidad B y las instancias de la entidad A. Los pares de cardinalidad se colocan en el diagram a en los extremos de la relación. Cuando se lee el dia grama se com ienza por el nom bre de la entidad A seguido del nom bre de la relación entre la entidad A y la entidad B. seguido de la cardinalidad que está más cercana a la entidad B y, por último, el nombre de la entidad B (figura 5-10). Este proceso es exactam ente inverso para la lectura en la dirección opuesta.
LOS COMPONENTES DEL MODELO DE INFORMACIÓN
127
F igura 5-10, L ectura de. la cardinalidad de la relación.
Hay varias notaciones gráficas para la cardinalidad de la relación. Yo prefiero la notación de palas de cuervo debido a que es muy intuitiva para el lector; utiliza un “ 1” para “ uno”, un “0" para “cero” y el signo que todos recordam os de nuestras clases de m atem áticas de con juntos, Sin im portar cuál notación se use, asegúrese de que los cuatro puntos de cardinalidad de la relación estén expresados gráficam ente en el diagrama. La cardinalidad m ínim a y m áxim a debe .ser expresada en am bas direcciones para definir adecuadam ente la regia del negocio. Para reafirm ar la im portancia de este punto perm ítam e ilustrar la m anera en que el diseñador utiliza esta información. D igam os que nuestros usuarios de negocios nos han dicho que un perro debe ser propiedad de una y sólo una persona. U na persona debe poseer al m enos un perro y posible mente m uchos. La regla del negocio podría ser expresada com o se m uestra en la figura 5-11.
Posee actualmente Es actualm ente propiedad de
Figura 5-11. La persona debe poseer al menos un perro.
l-s responsabilidad del diseñador de la base de datos, la im plem entación de esta relación en un esquem a de base de datos físico. D urante el diseño de la base de datos relaciona!, m uchas, si no es que todas las entidades del modelo de inform ación se convertirán en tablas. (Verá más sobre este lem a en el capítulo 9.) D ada la relación de la figura 5-11, no es aconse jable (y hasta se ve mal) cl colocar la clave prim aria perro en la tabla persona com o clave externa debido a que requeriría un grupo repetido. Es aceptable (y práctica común) poner la clave prim aria de la tabla persona en la tabla perro, debido a que solam ente habrá una persona que representa al propietario de cada perro. Por supuesto, si el negocio declara alguna vez que se acepta una custodia conjunta de perros, el diseño falla. O bserve que las cardinal idad es m áx imas de esta relación indican cuál tabla física obtiene la clave externa. La cardinalidad mínima entre perra y persona indica que la clave prim aria de persona será requerida com o clave externa en la tabla perro. Tal vez m ás interesante es la relación entre persona y perro. La cardinalidad m ínim a del lado “m uchos” de la relación no es forzada por la integridad referencial en los sistemas de
128
Capítulo 5 / EL MODELO DE INFORMACIÓN
adm inistración de bases de datos relaciónales. La regla de negocios de que una persona debe tener a] m enos un perro tendrá que ser codificada en el sistema. El diseñador dispone de varias posibilidades. Cuando se captura una nueva persona en el sistem a, el diseñador puede elegir desactivar la opción G u a r d a r hasta que el usuario especifique al m enos un perro. Tampoco se le perm itiría al usuario elim inar el ultim o perro de una persona. B1 reto de hacer cum plir esta regla m e llevaría con seguridad a explicarle a ios usuarios las consecuencias de su decisión, y a volverles a preguntar si quieren que la regla se haga cum plir en su sistem a. L a cardinalidad de las relaciones tiene un im pacto extrem adam ente poderoso en el diseño de la base de datos y la aplicación. El costo de com eter un error en el modelo puede ser muy alto posteriorm ente.
Atributos El tercer com ponente principal del m odelo de inform ación son los atributos, que represen tan a todos los elem entos de datos del sistem a. C ada hecho acerca de una entidad constituye un atributo separado. No hay una notación gráfica estándar para los atributos, debido a que generalm ente son dem asiado num erosos para listarlos en un diagram a entidad-relación. Por lo general, los atributos se proporcionan en listas separadas que acom pañan a cada entidad. A lgunas herram ientas CASH perm iten que se im prim an los atributos listados dentro del cuadro de entidad en el BRD, sin em bargo, esto puede hacerse inm anejable conform e crece la lista. El siguiente ejem plo tom a el evento de negocios el cliente deja cosas en la lavandería y m uestra la m anera en que cada elem ento de dato involucrado en la transacción puede ser atribuido a una entidad del modelo de información.
Ejemplo: atribución de elementos de datos a tipos de entidades Tomemos un momento para husm ear en la vida privada de un agente viajero, Slick Pitchman. Slick ha estado viajando por la región vendiendo aspiradoras caseras portátiles de las que se ha reportado que son lo suficientem ente poderosas com o para succionar gatos pequeños. Después de haber liberado a los ciudadanos de Dodge County de varios de sus queridos felinos en una desafortunada dem ostración en ese lugar, ha tenido que hacer una retirada a W inthorp del otro lado de las montañas. Su prim er asunto de negocios es llevar sus camisas y saco a la lavandería local. Cruza la puerta y pone en el m ostrador quince cam isas blancas idénticas y un saco sport de pana polvoso. La em pleada lo ve sospechosam ente y le pregunta si es nuevo en el pueblo. Slick no lo sabe, pero está a punto de convertirse en una instancia de la entidad Cliente. La em pleada necesita recolectar determ inados hechos acerca de Slick y lo que trae a lavar, hila escribe su nom bre, apellido y el núm ero telefónico de su m odesto motel. A nota que hay que lavar quince cam isas, y un saco necesita lavado en seco. También hace una nota acerca de las manchas rojas peculiares y ía abundancia de pelo de gato que tendrá que elim inar del saco, A Slick le da una nota fechada y num erada con el precio indicado en una esquina. La em pleada le prom ete que su ropa estará lista al día siguiente, después de las 5:00 p.m., y eon cortesía rechaza su invitación a cenar. La figura 5-12 sum ariza la lista de elem entos de datos requeridos por el sistem a para, reconocer y responder a este evento.
LOS COMPONENTES DEL MODELO DE INFORMACIÓN
129
Nom bre del cliente A pellido del cliente Núm ero telefónico actual del cliente Fecha de recepción Núm ero de recibo Fecha prom etida Hora prom etida Más un grupa repelido de: Tipo de prenda Cantidad de prendas; Servicio requerido Precio del servicio Instrucciones especiales
F igura 5-12. Elementos de datos para el evento el cliente deja cosas en la lavandería.
Los elem entos de dalos de cualquier problem a de negocios pueden atribuirse a tipos de entidades por medio de un proceso llamado normalización.^ La norm alización es un conjunto de métodos heurísticos desarrollado por lidgar F. Codd a principios de los setenta para exten der la expeetativa de vida de las aplicaciones representando los dalos en un formato relacional no redundante. Los sistemas que tienen bases de datos bien norm alizadas son capaces de per m itir extensiones a los datos, funcionalidad y cambios en la naturaleza de las consultas con un m ínim o de trastornos. Los principios de norm alización de Codd son las bases del diseño de bases de datos rela ciónales. La m eta del modelo de inform ación es crear una representación lógica de los reque rim ientos de datos norm alizados del sistem a, y dicho en otras palabras, guardar cada cosa en un solo lugar. Para este fin Codd nos proporciona tres niveles de forma norm al, inteligente m ente titulados prim era fo rm a norm al, segunda form a norm al y tercera fo rm a ñor m al.k Los datos no norm alizados son una colección al azar de datos con grupos de registros repetidos dislribuidos por todos lados. La figura 5-13 m uestra los datos de nuestro ejemplo de tintorería sin normalizar. Parece com o si recibo hubiera sido designado com o la clave prim aria de este conjunto desordenado,7
s
Codd, 1972.
f>
1¡ay niveles de normalización adicionales, pero en la práctica la mayoría de los analistas se detienen cu la tercera forma normal.
'
F.l término clave primaria se usa para el o los campos que ubican en forma única a un registro en una tabla física o archivo. L'na clave externa es una clave primaria que está incrtislacia en una tabla dife-rente (o en la misma) (de ahí su nombre, ex teína), paracnlay.ar líosregistros proporcionando una refe rencia hacia la tabla en la. cual es clave primaria, til término idenüficador único se usa para los atribulóte) y reiación(es) que pueden emplearse para identificar una instancia específica de una entidad.
130
Capítulo 5 / EL MODELO DE INFORMACIÓN
Nom bre del campo
Valor
Recibo Nom bre A pellido Núm ero telefónico Fecha de recepción Fecha para entrega Hora para entrega Tipo de prenda Tipo de servicio Cantidad Precia unitario Tipo de prenda Tipo de servicio Cantidad Prccio unitario Instrucciones especiales
1376 Sllck PiLchman 555-4567 6-17-05 6-10-95 5:00 PM Camisa de hom bre Lavandería 15 $1.00 Saco sport Lavado en seco 1 $7.50 Mancha, pelos de gato
Figura 5-13. Pedido de tintorería no norm alizado.
Primera forma norm al En la prim era fo rm a norm al no hay grupos de atributos repetidos. Para lograr la prim era form a norm al prim ero se m ueven los registros repelidos a un grupo aparte y se asocia con los dem ás datos por m edio de una relación. En un diseño de base de datos tísico. la clave prim aria del prim er grupo, núm ero de recibo, se inserta en el segundo grupo com o clave externa para enlazar los registros. Hn ei modelo de inform ación la relación gráiiea entre entidades es suficiente para inform ar al lector de la asociación. Las claves externas no se m uestran com o atributos en las dem ás entidades. E sta om isión se adhiere al concepto de diferim iento seguro. M ientras la base de datos no haya sido diseñada físicam ente, la clave prim aria de cualquier entidad dada puede ser terna de debate, y por lo lanío el repartirla po r todo el m odelo com o clave externa en otras entidades es prem aturo y no aconsejable. La figura 5-14 muestra nuestro pedido de tintorería en la prim era form a normal. El pedido todavía puede ser identificado en forma única por el núm ero de recibo, pero los servi cios individuales solicitados requieren el núm ero de recibo, el tipo de prenda y el tipo de ser vicios para identificar en form a única una instancia de concepto de pedido'. La figura 5-15 muestra el diagram a entidad-relación para nuestro pedido de tintorería en su prim era forma normal. L a prim era forma norm al resuelve el problem a antiguo de los grupos repetidos en con juntos de datos. En la prehistoria del diseño de base de datos el analista trataba de adivinar el núm ero má.ximo de grupos repelidos y establecía la cantidad de colum nas que se nece sitaban en un a rc h i\o no norm alizado. Todos los participantes en el negocio jurarían sobre la tum ba de su abuela que ningún cliente llevaría más de cinco tipos de prenda diferentes de
LOS COMPONENTES DEL MODELO DE INFORMACIÓN
131
una sola vez. Inevitablem ente, tan pronto como cinco grupos repetidos fueron grabados en piedra para siem pre en el sistem a, el prim er cliente con seis tipos de prendas habría desfilado por la puerta. PEDIDO Recibo
Nom bre
Apel Ii do
Múmero telefónico
Fecha de recepción
Fecha de entrega
hora de entrega
1376
Slick
Pitchman ?íi-
555-4567
6-17-95
6-18-95
5:00 PM
CONCEPTO DE PEDIDO Recibo jet;)
Tipo de prenda
Tipo de servicio
Cantidad
Precio unitario
1376
Camisa de hom bre Saco sport
Lavado
15
SI .00
Ninguna
Lavado en seco
1
$7.50
Mancha, pelos de gato
1376
Instrucciones especiales
1 ■í :"í
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.
Pedido
■T4 1 1
Contiene Fue pedido en
Concepto de pedido
Figura 5-15. E R D para el pedido de tintorería en prim era form a norm al.
Segunda forma norma! En la segunda fo rm a norm al, para los registros que tienen claves prim arias con catenadas. todos los atributos que no son clave son dependientes com pletam ente en form a funcional de la totalidad de la clave primaría. La seg u n d a fo rm a n o rm al trata el problem a de los registros que tienen claves primarias que están com puestas por varios elem entos de datos. Cuando se tienen claves concatenadas, cada elem ento de datos del. registro debe ser funcional mente dependiente de la clave com pleta y no de sólo parte de la clave. En nuestro concepto de pedido en 1a prim era forma normal, la clave prim aria está com puesta de número de recibo, tipo de prenda y tipo de servicio. Observe que el precio unitario no es totalm ente dependiente de la clave com pleta. El precio unitario actual puede determ inarse usando el tipo de prenda y el tipo de servicio. Parece que este nego cio necesita una lista de precios para los servicios que proporciona. Podemos quitar precio unitario de concepto de pedido y ponerlo en una tabla con tipo de prenda y tipo de servicio. A unque esto satisface los requerim ientos sintácticos de la segunda
132
Capítulo 5 / EL MODELO DE INFORMACIÓN
forma normal, presenta un problem a al negocio debido a que el precio unitario podría ser cam biado en la tabla tipo de servicio, haciéndola incapaz de consultar precios históricos asociados con cada concepto de pedido. Por esta razón le sugiero fuertem ente que califiquem os el precio unitario de la tabla tipo de servicio com o precio unitario actual cobrado por el negocio. N ece sitam os tam bién incluir el precio unitario en concepto de pedido y también calificarlo como precio unitario de p edido , el cual representa el precio unitario cobrado en el m om ento en que se lom ó el pedido. Hl precio unitario actual depende solam ente de tipo de servicio y tipo de prenda. FJ precio unitario de pedido depende de tipo de servicio, tipo de prenda y recibo. El precio unitario es un ejemplo de redundancia aparente. Si nom bram os a am bos atri butos precio unitario pudieran parecer redundantes, pero en realidad no lo son. H e visto casos en donde uno u otro de los atributos han sido elim inados del modelo en aras de erradicar toda la redundancia, Hl sistem a resultante fue problem ático. Para evitar un abuso de norm alización se debe definir cada atributo del m odelo. En este caso de precio unitario la definición sólo haría resaltar que el precio unitario del pedido es ligeram ente diferente del precio unitario indicado en la lista de precios de tipo de servicio. Las figuras 5-16 y 5-17 muestran nuestro pedido de tintorería en la segunda form a normal. PEDICiO Recibo
Nom bre
A peflirio
Núm ero telefónico
Fecha de recepción
Fecha de entrega
Hora de entrega
1376
Slick
Pitchman
5 55-4567
6-17-95
6-18-95
5:00 PM
..
CONCEPTO DE PEDIDO Recibo ice}
Tino de prenda Ice)
Tipo de servicio (ce)
13/6
Camisa de hom bre
Lavado
1376
Saco sport
SSÍHJSSSSSK5ÍÍiWíüí
Cantidad
Precio unitario
15
$1.00
Ninguna
$7.50
Mancha, pelos de gato
Lavado 1 en seco iSSStiMREiSIS'Sí^aíSÍSk&aií'iíaKiií; ií
Instrucciones especiales
ÍIPU DE SERVICIO Tipo de servicio
Tipo de prenda
Lavado
Camisa de hom bre
$1.00
Lavado en seco
Saco sport
$7.50
Precio unitario actual
i 1 I i
fe
«aamiiiaiaíywBffiK¿«®»*SS&SS.SÍÍÍS¡SSÍ
F ig u ra 5-16. El pedido de tintorería en la segunda form a norm a!.
La segunda forma normal elim ina los elem entos de datos que no son com pletam ente dependiente^ de una clave concatenada y los coloca en su propia tabla. Debido a que la regla para la segunda form a normal está lim itada para los conjuntos de datos que tienen claves de varias columnas, no una distinción tan obvia com o la prim era o la tercera form as normales.
LOS COMPONENTES DEL MODELO DE INFORMACIÓN
133
F igura 5-17. ERD para el pedido de tintorería en la segunda forma normal.
Tercera forma norma! En la tercera fo rm a norm al cada atributo es funciona luiente dependiente de la d a v e , ía clave com pleta, y de nada m ás que la el ave.B (Se elim inan las depen dencias transitivas.) Si exam inam os la disposición de datos que tenem os hasta este m om ento, todavía podemos encontrar un problem a. El nombre, apellido y número telefónico del cliente no son en realidad atributos de] pedido. Son atributos del cliente. Desde un punto de vista técnico, esta m os desperdiciando espacio cuando toda esta inform ación tiene que repetirse para cada pedido que se coloca. D esde un punto de vísta del negocio nos falta la habilidad para consultar con precisión todos los pedidos de un cliente dado debido a que cl nom bre del cliente puede estar escrito en form a diferente en cualquier pedido dado. Podemos resolver e! segundo problem a asignando a cada cliente un número de cliente único. Sin em bargo, el problem a de redundan cia de datos todavía existe m ientras no tomemos los atribuios que son transitivam ente depen dientes de número de cliente fuera del pedido y los pasem os a su propia entidad. G ran parte de los datos del sistem a pueden ser transform ados a la tercera form a norm al rápidam ente, si sim plem ente se turna el tiem po para jugar un juego al que Hamo “¿Eres mi m adre?” E res m i madre l'uc escrito por P.D. Eastm an y publicado por prim era vez en 1960, y es un libro que enseña el reconocim iento de patrones a niños pequeños relatando el cuento de un poHuelo que salió del cascarón mientras su m adre andaba fuera recolectando lombrices. El polluelo com ienza a hacer preguntas por el jardín preguntándole al gatito, a ia gallina, al perro, a la vaca, al carro, al bote, al avión y al bufido1-* si son su madre. Por inspección sim ple el pollueio (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 eslropear toda la trama
lo que
es un "bufido", le sugiero que adquiera un ejemplar del libro.
No
quisiera
134
Capítulo 5 / EL MODELO DE INFORMACIÓN
lo tanta no pueden ser su madre. Cuando el polluelo se reúne por últim o con su madre, es com pletam ente obvio para todos que el polluelo pertenece a su mamá, debido a que ambos son pájaros. Gran cantidad de los atributos que andan flotando por el sistem a pueden ser reunidos con sus entidades madres si sim plem ente se toma uno el tiempo de usar una fuerte dosis de sentido com ún y preguntarse, “¿eres tú mi m adre?” ¿Es nombre del cliente un atributo de pedido*! No, es un atributo de cliente. A la m ayoría de nuestros clientes les dieron nom bre sus padres mucho antes de que decidieran llevar algo a lavar a nuestro establecim iento. Su nombre no es un atri buto de su pedido de tintorería. ¿El número telefónico del cliente es un atributo del pedido'? No, es el núm ero en donde se puede localizar al cliente. Ks claram ente dependiente del cliente. Con un poco de sentido com ún podem os tener rápidam ente gran parte del modelo en su tercera form a normal pregun tándonos si el atributo pertenece realmente a la entidad. Tóm ese el tiempo para probar esto con su modelo de inform ación. M uchos de los atributos de los modelos representan entidades del m undo real. Si sim plem ente visualiza la entidad y sus características 110 es difícil clasificar un gran porcentaje de los atributos correctam ente. Luego el equipo puede discutir sobre los difí ciles. Las figuras 5-18 y 5-19 muestran nuestro pedido de tintorería en la tercera forraa nor mal. Los atributos que son dependientes del cliente han sido m ovidos a una entidad cliente. D ebido a que no existe un identificador lógico adecuado para cliente, se ha añadido un número de cliente. R ecuerde que sólo estoy incluyendo las claves externas para ilustrar las formas nor males. E 11 un m odelo de inform ación las relaciones bastan para com unicar el enlace entre las entidades. La decisión de colocar el número de cliente en el pedido es una decisión de implem entación y deberá diferirse hasta el diseño de la base de datos. Es im portante para cada uno de los profesionales de la industria de la inform ación estar al menos fam iliarizado con los conceptos de normalización. Sin em bargo, no le digo que siem pre debe estar listo por si estando en un elevador alguien le lanza una pregunta rápida sobre la segunda forma normal con respecto a sus datos. Conform e se desarrollan sus habilidades del m odelado de inform ación se encontrará atribuyendo instintivam ente las entidades en algo muy parecido a la tercera form a normal. Presento la norm alización en este capítulo debido a que es en lo que están sustentados el m odelo de inform ación y los conceptos de base de datos relaciónales. En la práctica no es nece sario dar vueltas a la m anija de la m áquina de norm alización cada vez que se necesitan orga nizar los datos. El analista debe saber lo que significan sus datos y cóm o van a utilizarse para hacer un buen trabajo de m odelado de inform ación o, com o le gusta decir a M eilir Page-Jones, la norm alización es una solución sintáctica para un problem a sem ántico.10 U n pequeño porcentaje de la población que practica el modelado de inform ación usará la norm alización com o una técnica form al para la organización de un m ar de datos heredados confusos. La m ayoría de las personas em pleará sim plem ente las reglas de norm alización como nn m étodo para probar al modelo de inform ación term inado. Es mi deseo sincero que usted asimile el concepto, lo lleve en su m ente y pase sus días creando subconscientem ente m odelos de im orm ación elegantem ente normalizados.
Además. Pa^e-Jnn& dice. ~1^ normalización es una técnica de corrección de cirores para los modelos de Hiftinnairián rrc Liru> iZ-ctucí de conam ccitííi’' Estoy completamente de acuerdo
LOS COMPONENTES DEL MODELO DE INFORMACIÓN
135
CLIENTE N ú m e ro “jk cí.i ente 100
Nom bre
A pellido
Núm ero telefónico
Siick
Pitchman
555-4567
SS.IO PEDIDO Recibo
1376
Núm ero de cliente {ce} 100
Fecha de recepción
Fecha de entrega
Flora prom etida
6 77-95
6-18-95
5:00 PM
Í.~;rs-f-iTí V---j
! <
CONCEPTO DE PEDIDO Recibo (ce)
Tino de prenda (ce!
■ino de servicio (ce!
1376
Ca misa de hom bre
1376
Saco
sp ort
Cantidad
Precio unitario
Lavado
15
SI .00
Ninguna
Lavado Hn seco ' ....... ^ ^
1
$7.50
Mancha, pelos de qato
'• ••<<•• ^-v . -.i?-.:
Instrucciones especiales
TIPO DE SERVICIO Tíd o
de servicio
Tipo de prenda
Lavado
Camisa de hom bre
$1.00
Lavado en seco
Saco sport
S7.50
Precio unitario i actual
n "í
.
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
1
■ '
C apítulo 5 i EL MODELO DE INFORMACIÓN
136
Cardinalidad de los atributos Tal vez haya deducido de la sección sobre norm alización que cada atributo del modelo oblicué un nom bre y una clara definición escrita. Las definiciones de atributo escritas crean un d ic cionario de datos que se usan m ientras dure el sistema. U na propiedad im portante de los atributos es la cardinalidad del atributo, la cual declara qué tantas instancias d d atributo pueden aplicarse a una sola instancia de su entidad. H ay dos puntos de cardinalidad para cada atributo, un valor m ínim o y un valor m áxim o. El valor m ínim o puede ser cero o uno. U n m ínim o de cero declara que el atributo es opcional p ara cualquier instancia dada de la entidad. Un m ínimo de uno dice que el atributo es requerido. E sta es una parte de inform ación crítica debido a que determ inara cuáles colum nas son capaces de alm acenar nulos en el diseño de base de datos. El valor m áxim o puede ser uno o m uchos (o alguna cantidad de lím ite superior fija m ayor que uno). E l valor máximo está diseñado para decim os si el atributo se está repitiendo para cualquier instancia de la entidad. La cardinalidad m áxim a es im portante debido a que ayu dará a elim inar grupos repetidos y hacer que el modelo se tenga en la prim era form a normal. M uchos m odeladores de inform ación experim entados tienen el reflejo condicionado de regis trar sus m odelos en al m enos la prim era form a norm al, por lo que los grupos repetidos son elim inados autom áticam ente. En este caso, sólo se necesita registrar si un atribulo es opcional o requerido, debido a que la m áxim a cardinalidad siem pre será uno. Regresando a nuestro ejem plo “p ersona posee perro”, exam inem os algunos atributos que pueden asociarse con un perro. Puede ser que en nuestro sistem a esté planeado que haya que recordar el número de licencia , nombre, peso, año de nacimiento, tipo de vacunación y fecha de vacunación. E3 número de licencia h a sido indicado com o identificador único.
Entidad:
PERRO
A trib u to s : N ú m e ro d e lice n c ia (ID ) N o m b re Peso A ñ o d e n a c im ie n to T ip o d e v a c u n a c ió n Fecha d e v a c u n a c ió n
THJ F igura 5-20, Atributos de la entidad perro
M ediante la asignación de la cardinalidad de atributo encontram os que número de licen cia es requerido. No aceptarem os perros sin licencia en nuestro sistema. C ada perro tendrá solam ente una licencia. E l negocio tam bién ha insistido en que nombre del perro es requerido, y un perro sólo puede tener un nom bre. E l peso es opcional y sólo estam os interesados en el peso actual. E l año de nacimiento es opcional y nuevam ente sólo habrá un año de nacim iento para cualquier perro.
LOS COMPONENTES DEL MODELO DE INFORMACIÓN
137
Sin em bargo, el tipo de vacunación y \slfecha de vacunación pueden no tener valores si et perro nunca ha sido vacunado, pero puede tener varios valores si el perro ha recibido muchas aplicaciones. La cardinalidad de! atrifento resultante puede ser expresada m ediante una notación abreviada a la izquierda del nom bre del atributo (figura 5-21). El valor m ínim o se indica a la izquierda y el valor m áxim o a la derecha.
E n tid a d :
PERRO
f igura 5-21. Cardinalidad de atributos.
La alarm a de violación de la prim era form a normal ahora ya debe estar apagada. El tipo de vacunación y Ya fecha de vacunación necesitan ser m ovidas hacia una entidad aparte para elim inar el grupo repetido. Cuando uno o m ás atributos de una entidad se convierten en una entidad propia, a esto se le llam a tipo de entidad atributiva.
Tipos de entidad atributiva U n tipo de entidad atributiva es una entidad que cobró vida com o un atributo o conjunto de atributos de otra entidad. Debido a que está íntim am ente ligada con su entidad madre, no puede existir p o r sí sola. La figura 5-22 m uestra el diagram a entidad-relación para perro y nuestra nueva entidad vacunación de perro.
H a recibido Fue a d m in is tra d a a
-CK
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-' o-0-'
Núm ero de iicí-jiida (¡Di ¡Nombre Peso Año de n a cim icnlfi
I % Entidad:
VACUNACION DE PERRO
!
Atributos:
1-1 I-"'
l
Tipo de vacunación FcchadtiVrH^unydón
±
i
Idervtificador único Fue adm inistrado a.PERRO + tipo de vacunación + fecha de vacunación
Figura 5-23, Atributos paru. perro y vacunación de perro.
La cardinalidad de atributo para tipo de vacunación y fecha de vacunación ha cam biado ahora. La cardinalidad de la relación de cero a muchos se encarga del grupo repetido. La cardinalidad 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 entidadrelació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. \,
V
Vacunación de perro
J
f i g u r a 5-24. D os versiones tic la notación de tipo de entidad atributiva. L a figura 5-25 m uestra un tipo de entidad atributiva com ún, precio de producto. La enti dad producto tiene un atributo llamado precio que por sí m ismo tiene los atributos fecha de ini cio y fecha de tenninación. La mayoría de los negocios tiene un requerim iento de conservar
LOS COMPONENTES DEL MODELO DE INFORMACIÓN
139
los precios pasadsis, presentes y futuros, causando que este grupo de atributos se repita para cualquier instancia de producto. H! tipo de entidad atributiva viene nuevam ente al rescate como una buena solución para este problema.
Figura 5-25, Producto y el tipo de entidad atributiva precio de producto.
Definición de atributos En este capítulo, hasta ahora hemos visto que cada atributo requiere las siguientes propiedades: N o m b re:
Un nom bre conciso y com prensible que se apegue a la nom enclatura de datos de s l i establecim iento.
Definición:
U na oración escrita clara y com pleta del significado del atributo y de su propósito y uso en el sistema. La definición debe ser verificable por los usuarios pretendidos del sistem a. M ucha de la ayuda en linca a nivel cam po y las definiciones dentro de la docum entación del sis tem a escrita deben ser derivablcs de las definiciones de atributos.
C ardinalidad:
La cardinalidad del atributo tiene dos valores, un m ínim o y un m á ximo. H1 valor m ínim o es cero o uno. D eterm ina si el atributo es opcional para cualquier instancia dada de la entidad. El valor m áxim o es uno o m uchos. D eterm ina si el atributo puede repetirse para cada instancia de la entidad.
Además de estas propiedades, el analista debe tam bién registrar: Tipo de dato: L1 tipo de dato describe la longitud y los valores válidos para el atri buto. Se pueden usar tipos ele datos SQL estándar tales com o Char( L), Intcger, D ecirnal(l 1.2). Varchar(200), de acuerdo con la convención de tipos de datos estándar de su establecim iento." También puede crear abstracciones de tipos de datos estándar tales como: .
I lasta ahora en el capítulo-ha quedado implícito que se tiene un conjunto de estándares publicados sobre la nomenclatura y abreviatura y un conjunto de tipos de datos estándar en el establecimiento. La palabra “estándar" también implica que hay alguna penalidad para quien no se apegue a ello. Si su establecimiento de IT no ha establecido esto, no tiene caso continuar mientras no se haya hecho. Sin estándares los esfuer /os del modelado de información rápidamente caerán en el caos.
140
Capítulo 5 / EL MODELO DE INFORMACIÓN SÍ/N O : u n cam po de un carácter cuyos, valores válidos son “S ” y “N” ” D IN LRO : un carrrpu D EC IM AL( 11,2) con nueve dígitos a la izq u ier da y dos a la derecha para usarse para todos los atributos de m oneda local. Sin im portar cuáí método se use para asignar tipos de datos, es im por tante que se lugre un nivel de consistencia razonable a través de todo el modelo que le servirá bien en el diseño de base de datos. Rango:
Si los datos son num éricos se deben especificar los lím ites superior e interior del rango (por ejem plo, p e so del perro debe ser m ayor que cero y m enor a 500 kilos.) -
U nidad de m edida:
M e gusta incluir la unidad de m edida en el nom bre del atributo, tal 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 restringidos:
M uchos valores en sistemas GUI se convertirán en listas desplegables. Sus valores están restringidos a un conjunto de palabras o caracteres particulares y son lo suficientemente invariables para que se necesite una tabla de referencia separada. Por ejemplo, los valores para el estado de pedido pueden ser “pendiente, confirmado, por surtir, surtido, em barcado y facturado” . Los valores deben listarse en el modelo de infor mación para que puedan ser diseñados en la interfaz y en la lógiea de la aplicación.
H ay gran cantidad de inform ación a recopilar acerca de cada atributo en el sistema. Aquí es donde se encuentra la mayor parte de la definición detallada de los requerim ientos del mismo, l.'n modelo de inform ación bien elaborado con definiciones de atributo detalladas, acom pañado con un modelo de eventos robusto le dará una gran riqueza de conocim iento a par tir de la cual puede construir aplicaciones que satisfacen las necesidades del negocio. Desde este punto en adelante en el proyecto hay poco o ningún uso para un modelo de inform ación de “alto nivel". N ecesita ir hacia los detalles.
ENTIDADES ASOCIATIVAS
141
ENTIDADES ASOCIATIVAS Si un tipo de entidad atributiva es una entidad que cobró vida com o un atributo o conjunto de atributos acerca de otra entidad, entonces tal vez haya supuesto que un tipo de entidad asocia tiva es una entidad que cobró vida to m o una asociación o relación entre dos o más entidades. Hagamos un sim ple ejem plo para ilustrar la m anera en que se derivan los tipos de entidades asociativas y luego hagam os referencia a un ejem plo clásico de un sistem a de negocios real.
Ejemplo de la derivación de tipos de entidad asociativos Digamos que nuestra em presa ha sido contratada para analizar un problem a en una granja av íco la local. Encontramos que nuestra granja avícola está ubicada en la intersección de cuatro autopistas estatales, dos que van del norte al sur y dos del este al oeste. Debido a un reciente increm ento en el tráfico y a la desafortunada ubicación de la granja, ha habido una tasa de m or talidad inusualm ente alta debido a que los pollos parecen estar absolutam ente decididos a cruzar los caminos. Nuestro trabajo es crear un sistem a de inform ación que lleve cuenta de cuáles pollos cruzan cuáles cam inos y recolectar estadísticas acerca de las condiciones al momento del cruce, y la tasa de éxito de la em presa. La base de datos se utilizará para tener una solución para este desconcertante problem a. (Si en este proyecto se hubiera hecho un plan general probablem ente se hubieran im aginado que bastaría una sim ple cerca.) Prim ero identifique cl(los) evento(s) que crea(n) la asociación. Kn este caso Pollo intenta cruzar el cam ino es el culpable. Registre y defina las entidades que representan las cosas fun dam entales y tangibles en el mundo real. Pollo y cam ino caen en esta categoría (figura 5-26),
Pollo
Camino
Figura 5-26, Se comienza can los tipos de entidad fundamentales.
Una vez que se ha trazado una entidad es buen hábito definirla inm ediatam ente. La definición de cam ino es fácil, pero pollo puede ser más difícil, ¿Se va a crear un registro para cada uno de los polios de la granja o sólo para aquellos que tratan de cruzar el cam ino? Lo que en realidad se está verificando es cuál evento o eventos crean instancias de las entidades fun dam entales del modelo. Este es un asunto muy importante. 1.a m ayoría de los errores que he visto en los m odelos de inform ación se deben a denom inación inadecuada y definiciones pobres, las cuales llevan frecuentem ente a que diversos miembros del equipo del proyecto hagan suposiciones diferentes acerca del sistema. Por orden de la gerencia, declarare que pollo significa “solam ente los pollos que han tratado de cruzar al m enos una vez el cam ino” . (Debe mos hacer una referencia cruzada en nuestro registro de diccionario de eventos para Pollo intenta cruzar el cam ino en este momento para asegurarnos que se haya ordenado que los po llos novatos hayan establecido su identidad en el prim er intento de cruce.) Ahora que ya se han establecido las entidades fundam entales, se establece una relación entre ellas. Se le nombra en am bas direcciones y se definen los cuatro punios de cardinalidad.
142
Capítulo 5 / EL MODELO DE INFORMACIÓN
La. cardinalidad resultante (figura 5-27) nos m uestra que los pollos deben cruzar al menos un cam ino para que sean registrados en el sistema, y que pueden cruzar muchos cam inos siempre y cuando les dure la suerte. Además, los caminos no necesitan ser cruzados antes de que hayan sido registrados en el sistem a y cualquier cam ino dado puede ser cruzado muchas veces (por muchos pollos).
l isu ra 5-27, Una relación muchos a muchos.
A este patrón se le llam a relación m uchos a muchos. Perm ite que una sola instancia de cualquier entidad este asociada con varias instancias de la otra entidad. U na relación de m uchos a m uchos sucede cuando una instancia de la entidad A puede estar relacionada con varias instancias de la entidad B, y una instancia de la entidad B puede estar relacionada con varias instancias de ía entidad A. Las relaciones m uchos a m uchos añaden una gran cantidad de com plejidad al diseño de un sistema. El primer problem a se encuentra en el diseño de la base de datos relaciona!. Salte mos a la fase de diseño e im aginem os que tenemos una tabla pollo y una tabla camino. Para im plem entar la relación el pollo cruzó cam ino usando claves externas, el diseñador de la basede datos rclacional no puede colocar el núm ero de pollo en la tabla camino, o el número de camino en la tabla pollo. Para arreglárselas con este tem b lé diseño, los usuarios tendrían que añadir un renglón redundante a cada tabla cada v e/ que sucediera un cruce (o lo que es peor, llam ar al departam ento de IT y hacerlos que agreguen algunas colum nas adicionales). Es pro bable que tal diseñador de base de datos relacional sea asesinado dentro de unas cuantas horas por el equipo de programación. El último asunto angustiante es que no tenem os lugar en donde guardar atributos tales cuma: fech a de cruce, razón del cruce, dirección del cruce, condiciones de! tráfico, éxito en el cruce. Estos no son atributos ni de pollo ni de camino. D e hecho, son atributos de la relación cruzó. La evidencia está mostrando que tenemos otra entidad em ergiendo en nuestro modelo, la cual es un tipo de entidad asociativa. Se utiliza un tipo ile entidad asociativa po r las siguientes razones: \ . Para, resolver relaciones m uchos a m uchos 2. Para guardar atributos adicionales que son característicos de la relación y no de la_s entidades participantes 3. P ara perm itir que una relación participe en otras relaciones. Promueva la relación para que se convierta en una entidad. La notación gráfica para un tipo de entidad asociativa es un rombo dentro del cuadro. Este es un legado de la notación Chen, la cual m uestra las relaciones con rombos. Esta pista gráfica inform a inm ediatam ente al
ENTIDADES ASOCIATIVAS
143
lector que la entidad cobró vida com o una relación. I ,a entidad debe ser nom brada y definida. En este easo he escogido el nom bre cruce y lo he definido com o ‘ una instancia de un solo intento de un pollo para cruzar uno de los cuatro caminos que rodean a la granja” (figura 5-28).
Figura 5-28. La relación m uchos a m uchos .se resuelve en un tipo de entidad asociativa.
Ahora tenemos dos relaciones a d efin ir una a cada lado de la entidad asociativa. D ebido a que ya utilizam os el nom bre de la relación prim aria para ta entidad asociativa, la denom i nación de las relaciones secundarias puede requerir algún truco. El diagrama resultante de la figura 5-29 m uestra que la relación muchos a m uchos ha sido reem plazada con relaciones uno a muchos.
Inició Fue iniciad o por
Figura 5-2í>, La cardinalidad resultante para la entidad asociativa cruce.
Emerge un patrón importante. Observe que la cardinalidad que conecta a pollo y camino con la entidad asociativa es de "uno a uno7', listo se debe a que la relación no puede existir sin sus punios finales. También observe que la uno a muchos y cero a m uchos original todavía existe, pero ellos han cruzado. La figura 5-30 m uestra la manera en que la cardinalidad de una relación m uchos a m uchos se resuelve típicam ente usando un tipo de entidad asociativa.
Figura 5-30. Bt típico patrón de resolución de m uchos a m uchos.
Capítulo 5 / EL MODELO DE INFORMACIÓN
144
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 1-1 1-1 0-1 0-1
N úm ero de pollo (ID) Nom bre Peso Fecha de nacim iento Velocidad prom edio
Entidad: Atributos:
CRUCE 1-1
0-1 1-1 0-1
1-1
Fecha y hora del cruce Razón d e lcru ce Dirección del cruce Condiciones de tráfico Satisfactorio
Identificador único = Fue iniciado por.POLLO + Se llevó a cabo en.CAMINO + Fecha y hora del cruce
Figura 5-31. Atributos para pollo, camino y cruce.
Supongam os que decidim os prom over a razón de cruce para que se convierta en una entidad a fin de que los usuarios puedan controlar la lista de razones válidas. El tipo de enti dad asociativa cruce nos da la habilidad de perm itir que la relación original participe en otras relaciones. Podem os sim plem ente conectar a la entidad cruce con la entidad razón del cruce (figura 5-32,1. Ahora, veam os si este patrón es adecuado para sistemas más com plejos. Supongamos que nuestro pollo ha sido transform ado a cliente y que el objeto de sus deseos no es un camino sino en vez de ello es un producto o servicio proporcionado por la com pañía.
ENTIDADES ASOCIATIVAS
145
Pollo
F igu ra 5-32. L os tipos de e ntidad asociativa pued en particip ar en otras relaciones.
□ tente
Producto
Figura 5-33. Cliente y producto son tipos de e ntidad fundam entales.
Identifique el evento o eventos que son de interés. En este caso propondré el cliente ordena producto. R egistre y defina las entidades que representan a las cosas tangibles y fun dam entales en d m undo real, cliente y producto. R ecordará i a discusión sobre la definición de pollos, La definición de cliente es similar. D ebe decidir cuándo un cliente se convierte en un cliente en su sistema. ¿Es cuando hace su prim er pedido, cuando solicita crédito o tam bién se registrarán clientes potenciales? (No sé la respuesta correcta para su com pañía, pero para nosotros lo será cuando coloque su prim er pedido, para que podam os term inar este libro.) E stablezca una relación entre cliente y producto y determ ine los cuatro puntos de cardi nalidad (figura 5-34), A hora puede com enzar a resolver las relaciones m uchos a m uchos pro m oviéndolas a un tipo de entidad asociativa. Lo que emerge es el fam oso tipo de entidad asociativa pedido (figura 5-35).
Figura 5-34. Una relación m uchos a m uchos.
F ig u r a 5-35. L as relaciones m uchos a m uchos se resuelven con el tipo de entidad asociativa
146
Capítulo 5 / EL MODELO DE INFORMACIÓN
D ebem os ser muy precisos cuando coloquem os la cardinalidad de estas relaciones. Los clientes pueden colocar uno o tal vez m uchos pedidos. Un pedido es colocado por uno y sola m ente un cliente. Sin em bargo, los pedidos pueden solicitar uno o más productos, v los pro ductos pueden ser solicitados en cero o muchos pedidos. ¡Tenemos todavía otra relación m uchos a m uchos (figura 5-36)1 Las relaciones m uchos a m uchos no siempre se resuelven en un paso.
F igura 5-3fi. La cardinalidad resultante todavía incluye una relación m uchos a m uchos
1 Repetim os el proceso una vez más para resolver la relación m uchos a m uchos entre pedido y producto. Em erge concepto de pedido para representar los diversos productos que pueden ser solicitados en una sola instancia de pedido. La figura 5-37 m uestra el fragm ento KRD term inado. Este patrón importante se repite una y otra vez a lo largo de cualquier sistem a en donde los clientes adquieren los productos o servicios de negocios o del gobierno. Verá que este patrón emerge a lo largo de este libro. (Una vez quede im presionado por las sim ilitudes entre los modelos de inform ación de un sistem a de ventas y un sistem a para la suprema corte. La tínica diferencia era que los clientes de la corte no se presentaban voluntariam ente y que la corte estaba dando sentencias de prisión en vez de productos.)
F ig u r a 5 -3 7 . F.i patrón cliente-pedido clásica
Es im portante resolver todas ías relaciones muchos a m uchos en el modelo lógico antes de diseñar la base de datos. M ediante el descubrim iento de tipos de entidad asociativa se crea una entidad m adre para lodos los atribuios que son característicos de la relación. El tipo de entidad asociativa tam bién perm ite que la relación original participe en otras rela ciones.
SUPERTIPOS Y SUBTIPOS
147
Tal vez la razón más im portante para reconocer estos objetos en la fase de análisis es que pueden com plicar severam ente el diseño. I.os tipos de entidad asociativa darán com o resultado intersecciones de tablas en la base de datos relaeional, añadiendo una unión de tabla adicional para enlazar a los miembros que participan en la relación. Ellos requerirán ventanas adicionales y reportes m ás com plejos. Los tipos de entidad asociativa presentan al diseñador de GUI algunos retos de navegación interesante, en especial si la naturaleza de m uchos a m uchos de la relación es la excepción en vez de ser la regla.
SUPERTIPOS Y SUBTIPOS En el mundo real m uchos objetos pertenecen a una clase sim ilar, pero elJos m ism os tienen características divergentes. Los aviones, trenes y autom óviles son ejem plos de la clase vehículo. pero claram ente tienen diferentes características y com portam ientos. A lgunas de las entidades del m odelo seguirán un patrón similar. En forma colectiva caen en una cate goría am plia llam ada el supertipo,. dentro del cual cada instancia com parte una cantidad lim i tada de atributos sim ilares y puede participar en las m ism as relaciones. El supertipo puede dividirse en varias categorías llam adas subtipos, los cuales son agrupam ientos dentro de! supertipo que tienen atributos que son únicos del subtipo y no son com partidos con todas las instancias del supertipo. ) -os subtipos tam bién pueden participar en relaciones que son exclu sivas del subtipo. El supertipo/subtipo más com ún y frecuentem ente más com plejo en la mayoría de los sistemas de negocios es la entidad cliente. Los clientes vienen en m uchas formas y tamaños. Tome, por ejemplo, a los clientes de una em presa m anufacturera internacional típica. Los datos requeridos para los clientes de exportación .son diferentes que los de los clientes locales. Los clientes que son responsables del pago pueden ser diferentes de los clientes que efectivam ente reciben los em barques de m ercancías. Los clientes pueden ser internos o externos a la organi zación. Los clientes extem os pueden ser com pañías com erciales que operan a nom bre del cliente real. La com prensión y el modelado de la estructura del cliente es frecuentem ente una de las tareas más difíciles del modelado de inform ación que enfrenta una organización. Otros candidatos probables para subtipos incluyen a los productos y servicios proporcionados por la com pañía y los diferentes tipos de em pleados, contratistas y proveedores de servicios involu crados en el negocio. Hay varias notaciones disponibles para los subtipos. 1.a figura 5-38 muestra tres de las notaciones más populares. La prim era es un simple diagram a de descom posición de la entidad en donde se m uestra que vehículo puede ser un avión, un tren o un autom óvil. La segunda notación usa una variedad bastante com ún para expresar que “un vehículo puede ser un avión” , pero “un avión es un vehículo” . La tercera notación anida las entidades subtipo dentro de la entidad supertipo. Esto es particularm ente cóm odo debido a que ahorra espacio en la pantalla de la herram ienta CASE. Los atributos que son com unes a todas las instancias del supertipo se guardan en la enti dad supertipo. No son repetidos en la entidad subtipo. La relación supertipo/subtipo declara que cualquier entidad subtipo hereda todos los atributos de su supertipo y participa en cualquier relación que esté asociada al supertipo.
Capítulo 5 / EL MODELO DE INFORMACIÓN
148
Vehículo
Vehículo Avión
Tren
Avión
Au tornóvl!
Tren Vehículo A u to m óvil Es Puede un ser un
Avión
Es Puede ser un
Tren
Es Puede ser un
A
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 pertipo 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.
Capítulo 5 / EL MODELO DE INFORMACIÓN
150
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 créCito aprueba el crédito El cliente cancela cl podido confirmado
Confirmad o
k
^
—
Eí almacén determina que no hay existencia del articulo
El cliente cannala el pedido pendiertp de surtir
Pendiente de surtir
El almacén surte el pedido El almacén surte el pedido pendiente de surtir
S u r t id o
El cf'ünte cancela pedido surtido
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 m
101 101 101 101 Toí ioT ~1o í 101 101 ' '■
:9931 19932 f1 e 1-9934 :993E¡ 9936 =9937 j9338 j-9939 ::(
Acmé Beverage Si Rocket Fuel, Inc. 12/21/96 JoeJoe'í Pizza 12/21 /9E¡ The Slug F’it Bar ii; finll 12/21 /96 Fern'i Department Store 12/22/96 The Lobby S'hoppe 12/22/9S Washington Plaza Association 12/22/3E; The Metra Cafs 12/22/96 Acmé Beverage &Pocket Fuel, Inc. 12/22/96 37th Street Investors ' 12/22/96 V- j i
-
‘j
i I
i
527.50ÉTentative 09. OOiCorififmed 465.15ÍShipped '■ ; 2E..450.12ÍFilled 1,126.88 Ei.ack-Ordered . 1S.21 Canceíed G54. i;cí Confirrned . 951.21; Tentative ; 1,854.0Cjüonfirrfied Í S lí
-C a n c d O ix fe ''J
F ig u ra 5-41. D isposición de ventana para Order Selection.
j
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
X
El d e p a rta m e n to de p rod ucción asigna pedido
X
X
Planta de C alifo rn ia
El d e p a rta m e n to de crédito a p ru e b a ped id o
X
Ventas en Londres, RU
X
Ventas en M iam i, FL
El cliente hace ped id o
Ventas en Boise, ID
E vento /u b ic a c ió n del negocio
Oficinas c e n tra les Neeva York, N Y
153
■a
ra c ra
Q_
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
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
i
Figura 5-42. Una matriz de evento/ ubicación del negocio.
V,
2¿ 53 O
E vento/entidad El cliente hace pedido
T3 T¡ Cl t) ■3 O a. ;5 CL
5 u
Pedido de planta
Q
o "O r¡ o Cl CJ T3
3 x
o. c ti ÍT3 z oo o¡ U ’C
K
*1 u» °(D co ® c o ü'C "O ü n¡ ^ ÍD 1- C a C •= C QJ P > i£ £ t>
"c § £ tu E ¡= o o a « ’c « o 2 c M C í V ro ¿ c [
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
M ercadotecnia envía el catá lo g o por correo
R
V
s (C LL
JC a ■c c a
CRU
CRU
ÍC
F igura 5-43. Una matriz CRUD de evento/entidad.
Teniendo estas dos matrices se puede derivar una tercera. Si el evento sucede en la u b i cación del negocio, entonces los datos requeridos d d evento tam bién deben estar accesibles en esa ubicación. La m atriz CRUD de ubicación de negocio/entidad despliega los requerim ientos de distribución de datos (figura 5-44).
154
Capítulo 5 / EL MODELO DE INFORMACIÓN
F ig u r a 5-44. U na m atriz C R U D ubicación del negocio/entidad.
U na variación de la m atriz CRUD evento/entidad es la m atriz de actualidad evento/enti dad (figura 5-45). Los valores de las celdas m uestran qué tan viejos pueden ser los datos para cualquier evento dado. Por ejemplo, la inform ación de crédito dcl cliente debe ser 0 horas vieja para el evento el departam ento de crédito aprueba pedido. En forma similar, la direceión de envío dcl cliente debe ser 0 horas vieja para el evento la planta envía pedido de cliente. Por otro lado, los datos pueden ser hasta 48 horas viejos para el evento mercadotecnia envía catá logo p or correo. Esta inform ación le dará a los arquitectos del sistem a un sentido de qué tan rápidam ente necesita replicar o transportar datos alrededor de un sistem a am pliam ente dis tribuido. La m atriz CRUD autorización de usuario/entidad (figura 5-46) es una variante de la m atriz CRUD evento/entidad. En vez de eventos la matriz m uestra a los grupos de usuarios que están autorizados para llevar a eabo los eventos. Las entradas duplicadas son sumarizadas en una m atriz que m uestra cuáles grupos de usuarios están autorizados para crear, leer, actua lizar y borrar cuáles entidades. El resultado es una m atriz que forma la base para la autorización de usuarios para el sistem a de adm inistración de base de dalos relacional.
ESTRATEGIAS DE ARRIBA HACIA ABAJO Y DE ABAJO HACIA ARRIBA El m odelo de inform ación, el modelo de eventos y el modelo de contexto form an los “tres grandes” modelos de análisis, juntos cubren los requerim ientos de datos, de com portam iento, de proceso y de frontera del sistema. Todo lo que falta es poner una cara a la interfaz con algunos prototipos de interfaz para validar los requerim ientos esenciales. Quiero enfatizar que aunque este libro presenta al contexto, los eventos y la inform ación en form a secuencial en capítulos separados, en la práctica estos m odelos se construyen
ESTRATEGIAS DE ARRIBA HACIA ABAJO Y DE ABAJO HACÍA ARRIBA
O Cl
c. a ’C o a a. c 0) (3 c ao o O TJ
U) en o
-Sí £ 73 »=■ C l) E X < 31 0) u X « é t: ° c ■r, .2 u -z
'A Í sC2•— [/) c ^«g < c m t c a; E £ P > r C E 1- S CL
Cliente
O T3 O a.
n ■6
Pedido de plañía
o T3 ■o
•35 □_
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
24
24
24
0
0
0
0
0
2¿
24
0
D
0
0 0
0 0
Evento/ervJdad
sutlíj
el ce did o del cliente
La planta envía ni pedido def cliente C on ta b ilid ad factura cl pedido deí d ie n te M ercadotecnia envía el catálogo p o r correo
Ó
155
n
i
IB
| i
■o
3 o * LL
c c u
0
0
I ü
|
4EÍ bsSSHSifcíáS
Figura 5-45. Una matriz de actualidad evento/entidad.
F igura 5-46. L'na matriz CRUD de autorización de usuario/entidad.
.
sim ultáneam ente. E s cuestión de gusto personal con cuál com enzar, pero es casi im posible ter m inar uno sin haber realizado buena parte de los otros dos. Además, verem os en el siguiente capítulo que el prototipo de interfaz puede ser derivado en gran m edida a partir de los “tres grandes” modelos. Sin em bargo, lo que he encontrado en la práctica es que esto también tra baja a la inversa. El prototipo de interfaz tam bién puede ayudarle a derivar y term inar a los “tres grandes”.
156
Capítulo 5 / EL MODELO DE INFORMACIÓN
Entonces, ¡'.cómo se com ienza con el m odelo de información'? H ay varias form as hacerlo. Se puede em plear una estrategia de abajo hacia arriba buscando en el modelo de eventos todas las cosas principales acerca de las cuales el sistem a necesita recordar algo. Esto llevará a enti-' dades de sujeto-área, tales com o cliente, pedido y producto. U na vez que ya se tienen las entidades principales de las principales áreas funcionales se puede com enzar a definir subtipos y re finarlas. Cliente puede ser dividido en varios subtipos. El pedido acabará posiblem ente com o encabezado del pedido, concepto de pedido, envío p ro gramado, concepto de envío program ado. La entidad producto se descom pondrá en los diver sos subtipos de productos y relaciones con las estructuras de precios, relación de m ateriales y especificaciones de fabricación. Eventual m ente el enfoque de arriba hacia abajo avanza desde entidades de áreas de interés grandes hacia entidades refinadas m ás granulares y después hasta los atributos. Un enfoque de arriba hacia abajo funciona bien cuando se está creando un modelo de inform ación a nivel em presarial para la planeación de inform ación estratégica. También es útil a nivel de proyecto si el sistema heredado proporciona pocas pistas sobre los elem entos de datos nece sarios para el nuevo sistema. U n enfoque de abajo hacia arriba com ienza con los atributos y, usando los conceptos de norm alización (y una buena dosis de “¿eres tú mi m adre?” y sentido com ún) agrega los hechos del sistem a en grupos de entidades. Un enfoque de abajo h acia arriba es adecuado cuando se está enfrentando el m ar de datos am orfo de un sistem a heredado no norm alizado. Se recopilan todos los datos y sim plem ente se les “tritu ra” atribuyendo sistem áticam ente los elem entos de datos a sus tipos de entidad adecuados y estableciendo las relaciones y la cardinalidad. Yo utilizo un enfoque interm edio, construyendo mi inform ación por m edio de incre m entos graduales. M e gusta tener primero una idea burda de mis entidades principales y luego com enzar a hacer algo de modelado de eventos. D eterm ino los elem entos de datos requeridos para cada estím ulo y respuesta y los asigno a mi modelo de inform ación, refinándolo m ientras avanzo, Al final solam ente modelo la inform ación que necesita el sistem a, y he tomado en cuenta la manera en que cada atributo se crea y aprovecha en el sistema. Es im portante reconocer que los modelos de inform ación no respetan las fronteras de proyecto. Los datos son el activo com partido m edular de cualquier organización. El esfuerzo de modelado de la inform ación debe estar lim itado por algún sentido de alcance. El modelo de eventos y el modelo de contexto proporcionan esas fronteras. Sin poner algún tipo de límite, el m odelo de inform ación puede expandirse infinitam ente conform e se avanza hacia afuera hacia otras áreas de interés y eventualm ente más allá de las fronteras de la organización. Esta desventaja va en am bos sentidos. AI mismo tiempo que se están lim itando los esfuerzos de modelado al alcance del proyecto, también se debe estar consciente de que otros proyectos necesitan los datos. El prim er proyecto cliente/servidor de la organización puede ser también ía prim era base de datos com pletam ente relacional. Si éste es el caso, se tiene una oportunidad fantástica para norm alizar los datos de la organización. Esta es una responsabili dad trem enda debido a que la base de datos para el prim er proyecto cliente/servidor frecuente m ente está enfrentada con el m odelado de entidades m edulares tales com o cliente y producto. Por supuesto, esto significa que el prim er proyecto recibirá el golpe del costo del m odelado de gran parte de los datos del negocio, lo cual hará subir los costos en form a desproporcionada. Sin embargo, si .se hace un buen trabajo de modelado de inform ación en el prim er proyecto, los proyectos subsecuentes obtendrán los beneficios de unas bases sólidas.
RESUMEN
157
Los negocios que ya tienen un modelo em presarial y bastante experiencia sobre bases de datos relaciónales tienen una m ejor probabilidad de éxito en su prim er em presa cliente/servi dor que aquellos que todavía no han instituido una adm inistración de recursos de dalos sólida.
RESUMEN L a im portancia del modelo de inform ación trasciende a un solo proyecto. Los datos son el activo de inform ación central del negocio y deben ser m odelados y manejados con prudencia. Los com ponentes principales de un modelo de inform ación son las entidades, las relaciones y los atributos. Las entidades son personas, lugares, cosas o ideas abstractas acerca de los cuales el sis tema necesita recordar hechos. Las instancias de una entidad se agrupan debido a que com parten características com unes y exhiben com portam ientos similares. Las entidades son representadas com o rectángulos en el diagram a ERD (entidad-relación). Cada entidad debe ser nom brada y definida cuidadosamente. Las relaciones representan las asociaciones entre entidades. U na relación se traza como una línea entre una entidad y otra en el ERD. La relación debe ser nom brada en ambas direc ciones. Al leer de izquierda a derecha se usa el nom bre que está encim a de la línea y al hacerlo de derecha a izquierda, el que está abajo, hsta regla se aplica para las relaciones verticales. Sim plem ente gire el diagram a en sentido de las m anecillas del reloj (figura 5-47).
Figura 5-47. Un ejemplo de diagrama entidad-relación.
158
Capítulo 5 / EL MODELO DE INFORMACIÓN
La cardinalidad de la relación expresa la cantidad m ínim a y m áxim a de ocurrencias de la relación que pueden darse entre instancias de la entidad. U na relación puede suceder para una instancia de una entidad una y sólo una vez, una o m uchas veces, opcionalm ente un a vez (cero o una) o cero a m uchas veces. La cardinalidad de la relación se usa para determ inar la estructura de clave externa de la base de datos física. Es muy im portante que el modelo exp rese los cuatro puntos de cardinalidad, m ínim o y m áxim o en amhas direcciones, para cada relación. Una relación de muchos a m uchos es aquella que perm ite m ultiplicidad en am bas direc ciones. listas relaciones pueden com plicar severam ente a un sistem a y deben ser resueltas transform ándolas en tipos de entidad asociativa. Un tipo de entidad asociativa es aquel que com ienza com o una relación pero es pro m ovido para convertirse en una entidad a fin de que pueda tener atributos propios y participar en relaciones adicionales. Cada hecho acerca de una entidad constituye un atributo separado. La cardinalidad de los atributos declara qué tantas instancias del atributo pueden aplicarse para una sola instancia de su entidad. Cada atributo debe suceder solam ente una vez para cada instancia de la entidad. Se debe especificar si es opcional o requerido. Si el atributo se repite deberá ser prom ovido a un tipo de entidad atributiva. Los atribu tos que son dependientes de su clave de entidad, la clave com pleta y nada más que la clave, se dice que están en la tercera forma normal. Los atributos deben ser nom brados cuidadosam ente de acuerdo con la nom enclatura de su establecim iento. C ada atributo debe tener una definición escrita clara y com pleta. A dem ás de ia definición escrita, se debe especificar el tipo de dato, los lím ites superior e inferior de rangos num éricos, unidad de m edida, precisión y lista de valores restringidos si es que se aplica. A lgunas entidades tienen grupos de instancias que por sí m ism as com parten caracterís ticas y com portam ientos com unes que no son com partidos por todos los miembros de esa enti dad. A éstos se les llam a subtipos. Los subtipos pueden tener atributos y participar en relaciones que son únicas del subtipo y heredan autom áticam ente todos los atributos y rela ciones del supertipo. El diagram a de transición de estados establece un enlace im portante entre el modelo de inform ación y el modelo de eventos. Se usa para m ostrar cuáles eventos alteran el estado de una entidad. Las entidades pueden usarse en una diversidad de m atrices. L a m atriz CRU D evento/entidad m uestra cuáles eventos crean, leen, actualizan o borran instancias de cada enti dad. La m atriz CR U D de entidad/ubicación de negocios m uestra los requerim ientos de d is tribución de datos lógicos de la organización. La m atriz CRUD de autorización de usuario/entidad m uestra cuáles grupos de usuarios están autorizados para crear, leer, actualizar y borrar cuáles entidades. La matriz de actualidad evento/entidad nos dice qué tan viejos pueden ser los datos para cualquier evento dado. El m odelo de inform ación puede construirse usando un enfoque de arriba hacía abajo, de abajo hacia arriba o interm edio. Es im portante lim itar los esfuerzos dentro del contexto del proyecto que se está trabajando, pero estar consciente constantem ente de que el modelo de inform ación es com partido por todos los proyectos. Si está interesado en determ inados datos es muy probable que otra aplicación que esté dentro o fuera de la organización tenga que ver con los m ism os datos. El modelado de inform ación sólido es uno de los secretos del éxito cliente/servidor.
EJERCICIOS
159
EJERCICIOS 1. U n desarrollador en una com pañía de seguros de vida encontró una vez un curioso conjunto de datos en la base de datos del sistem a heredado. L a colum na de edad del asegurado contenía valores positivos y negativos. P reguntándose el porqué sus clientes podrían tener años de edad negativos, el desarrollador siguió la pista hacia la fuente de la anom alía y se sorprendió con la razón que encontró. ¿Puede im agi narse cuál era? 2. E n un sistem a m ainfram c baneario heredado un desarrollador encontró un com en tario todavía m ás curioso incrustado entre m iles de líneas de código no docum en tado. Hl com entario aislado decía: “Código de nexo del d ie n te : 0 - desconocido, 1 = m asculino, 2 = fem enino, 3 = otro". E l valor “3” estaba referido en el código valias veces. ¿Puede adivinar cuál problem a de m odelado de inform ación causó esta situación extraña? 3. Los clientes frecuentem ente tienen m uchas direcciones de las que debe llevar cuenta el sistem a. Por esta razón dirección del d ie n te aparece frecuentem ente en el m odelo de inform ación com o un tipo de entidad atributiva de la entidad cliente. Los em pleados tam bién tienen varías direcciones, y tam bién los proveedores. ¿P odría considerar m alo el que se pusieran todas las direcciones del sistem a en una sola entidad llam ada dirección y enlazarla con las dem ás entidades adecuadas, tales com o cliente, p roveedor y empleado'} 4. Los usuarios de una em presa de im presión de cheques rae dijeron una vez que los cheques pueden com prarse con hasta seis opciones adicionales, tales com o un logotipo personalizado o el nom bre del cliente bajo la línea p ara la firma. L a p an talla de captura de pedidos tiene seis colum nas de códigos de opción junto a cada concepto de pedido en donde se pueden solicitar las opciones adicionales que co rresponden a seis colum nas de códigos de opción de la tabla concepto de pedido. En este m om ento debe apagar las sirenas de alarm a en su m ente de m odelador de inform ación. ¿Q ué es lo que se hizo mal en este caso? 5. ¿Puede existir un tipo de entidad asociativa con una sola entidad conectada a él?
RESPUESTAS 1, El sistem a guarda la edad en form a literal en la base de datos y guarda la fe c h a de nacim iento en un cam po separado. C ada noche se ejecuta un program a p o r lotes para d eterm inar si alguien ha celebrado su cum pleaños e increm entar la edad en un año. D esafortunadam ente los analistas de sistem a fallaron en el reconocim iento de la fe c h a de m uerte o si ha m uerto com o atributos del asegurado en la póliza, por lo que un program ador intrépido decidió insertar un signo negativo al inicio del cam po de edad para indicar a los asegurados que ya no estaban con nosotros. De esa form a el program a por lotes de felicitación en cum pleaños sabía que tenía que saltarse esos registros, ya que los m uertos no se haecn más viejos. 2. Los m odeladores de inform ación han fallado en identificar subtipos adecuada m ente para los clientes en clientes hum anos y clientes no hum anos tales com o las em presas. D ebido a que no había form a para distinguir entre los dos, el progra-
160
Capítulo 5 / EL MODELO DE INFORMACIÓN m ador necesitó una form a para no lom ar en cuenta los atributos que pertenecen a los hum anos y que no poseen las com pañías y viceversa. D ebido a que los n ego cios no son ni m asculinos ni fem eninos vio u na oportunidad para crear un código de sexo de cliente con valor de “3” para identificar a los clientes de negocios, em pacando dos datos en un solo cam po. El resultado fue una revoltura por toda la aplicación cada vez que los clientes necesitaban ser distinguidos p o r su tipo. 3. Este es un error com ún de m odelado de inform ación al que le llamo acum ulación p o r tipo de dalo coincidente y no p o r razones del negocio. La única razón aparente por la que un m odelador pudiera agrupar las direcciones en una sola gran entidad es porque todas tienen una dirección de calle, ciudad, estado y código postal. Sería igual de razonable que el am ontonar todos los precios del sistem a en una entidad llam ada dinero. U na prueba verdadera para ver si el concepto es válido es definir la entidad dirección y ver si tiene algún sentido para el negocio. L a definición pudiera ser ‘'una ubicación física en el m apa en donde se encuentra una persona o com pañía de interés para el sistem a, se hacen pagos de pensión alim enticia, se hacen negocios, se recibe correo, se reciben facturas o se aceptan em barques” . En la m ayoría de los sistem as de negocios esta definición no tendría sentido. Las direc ciones de los em pleados no tienen relación con las direcciones de los clientes y, por lo tanto, no pertenecen a la m ism a entidad. P ocos negocios tienen algún interés en saber cuáles em pleados tam bién son clientes del negocio y adem ás requieren un m antenim iento com pleto en tiem po real de los datos relacionados p ara haccr válido este esquem a. Sin em bargo, sería perfectam ente válido crear un objeto de dirección reutilizable, el cual recupera y presenta inform ación de direcciones en la interfaz de una form a estandarizada, 4. Los seis códigos de opción de concepto de pedido form an un grupo repetido, lo cual viola la prim era form a norm al. Lo que es m ás im portante, investigando un poco m ás encuentro que m uchas personas de la com pañía creen firm em ente que los cheques sólo tienen espacio para seis opciones. D e hecho, no hay un lím ite v e r dadero para la cantidad de personalizaciones que se podrían ordenar sobre los cheques, y los clientes rutinariam ente ordenan seis, ocho o nueve opciones. Las opciones adicionales estaban siendo tecleadas en la sexta colum na de la vieja pan talla de captura de pedidos com o “código de opción 99 - m isceláneos'’ y se les hacía referencia en un cam po de com entarios y se cotizaban m anualm ente. E n con secuencia, esta em presa no tenía idea en realidad de qué tantas opciones de cada tipo se estaban vendiendo. La solución fue prom over a opciones de concepto de pedido para que se convirtiera en un tipo de entidad atributiva y perm itir un a ca n tidad ilim itada de cargos adicionales en un concepto ele pedido. 5. No, Un tipo de entidad asociativa es, por definición, el resultado de u na asociación (relación) entre dos entidades (o una relación recursiva m uchos a m uchos de la m ism a entidad). No puede existir sin referencias explícitas a todos los puntos finales de la relación original.
C a pítu lo
6
EL PROTOTIPO DE INTERFAZ
INTRODUCCIÓN A hora entramos a lo divertido, id capítulo 6 presenta el concepto de la creación de prototipos. En algunos establecimientos, la creación de prototipos es un eufemismo para "codifique algo rá pidamente y vea si los usuarios lo aceptan”. Dentro de estas páginas 110 encontrará este enfoque. E 11 vez de ello 1c propongo que un prototipo se puede construir bien. Un prototipo exitoso co m ienza con un objetivo establecido de lo que se quiere aprender al hacerlo. Una vez que se com prende lo que se quiere lograr, se puede seleccionar una técnica de creación de prototipos (de alta tecnología o de tecnología básica) que sea la más costeable para lograr el objetivo. En este capítulo trataré los pros y contras de la creación temprana de prototipos y discutiré razones vá lidas para los enfoques de tecnología básica y alta tecnología. Luego cambiaremos nuestra aten ción a la form a en que pueden usarse los modelos de análisis para hacer la ingeniería de la interfaz del sistema. El modelo de eventos le perm ite agrupar eventos con base en el usuario que los inicia, la secuencia de los eventos y ios objetos a los cuales se aplican. El modelo de iní'or-
161
Capítulo 6 / EL PROTOTIPO DE INTERFAZ
162
m ación proporciona un mapa, organización al de los datos que deben aparecer en la interfaz de usuario. Las relaciones del modelo de inform ación influirán en gran m edida la disposición de las ventanas. También veremos que la creación de prototipos puede realizarse en muclias etapas durante el proyecto. Se puede usar com o una técnica para descubrir y validar los requerim ien tos en cuanto a eventos del negocio y de información para crear los “tres grandes” modelos. D u rante la fase de diseño se pueden crear prototipos que reflejen las diversas decisiones de navegación y de control de usuario que se tendrán que hacer antes de codificar la aplicación.
¿QUÉ ES UN PROTOTIPO? lista aceptado generalm ente que un prototipo es un modelo a escala o facsímil de lo real, pero no tan funcional para que equivalga al producto final. Los prototipos se presentan en muchas formas y tamaños, Hn la industria automotriz, los prototipos de autos pueden ir en com plejidad desde un modelo tallado en madera hasta un vehículo m otorizado real que se puede conducir. El m isino rango de com plejidad resulta cierto para los sistemas de software. El prototi po puede ser tan sim ple com o un conjunto de disposiciones de pantallas en hojas de papel pe gadas en la pared, o tan sofisticado com o programas de softw are anim ado que perm iten que los usuarios hagan clic en los botones e introduzcan datos. Un prototipo puede ser útil en diferentes fases del proyecto. El objetivo del prototipo d e be ser claro en cada fase. D urante la fase de análisis se puede usar un prototipo para obtener los requerim ientos del usuario. En la fase de diseño un prototipo puede ayudar a evaluar m u chos aspectos de la im plem entación seleccionada.
El propósito det prototipo I -a creación de prototipos siempre debe realizarse con un objetivo de aprendizaje específico en mente, liste capítulo se enfoca en la m anera de crear disposiciones de ventanas utilizando los modelos de contexto, de eventos y de inform ación para la creación tem prana de prototipos en la fase de análisis. En la fase de análisis de un proyecto, la principal directiva del prototipo es d eri var y validar los requerim ientos esenciales, m anteniendo abiertas, al m ism o tiem po, las opciones de im plem entación. El esfuerzo de creación de prototipos durante el análisis se enfoca en el contenido de in form ación de la ventana y los eventos del negocio. Ksto significa que los asuntos de diseño co mo la disposición, navegación, determ inación de la unidad de trabajo adecuada para el usuario y la fijación de cada uno de los botones y controles GUI finales son todavía prem aturos y pue den posponerse. Se com enzarán a formar opiniones y a recopilar inform ación acerca del dise ño definitivo del producto, pero esto no es el propósito de la creación de prototipos mientras se recopilan ios requerim ientos. Cuando se revisa un prototipo de la etapa de análisis con los usua rios ha\ que mantenerlos informados de la directiva principal. Si los usuarios mencionan asun tos del diseño hay que escribir sus com entarios y regresar el foco de atención al contenido y los eventos del negocio. Se regresará posteriorm ente al diseño GUI más adelante. Veremos en los capítulos 10 y 11 que hay m uchas cosas más en una GUI que el contenido de la ventana.
¿QUÉ ES UN PROTOTIPO?
163
Beneficios de la creación temprana de prototipos Más que cualquiera de los tres grandes” modelos, cl prototipo de interfaz realmente introduce a los usuarios en el proyecto. Por prim era vez el sistema tiene una “cara” . Inevitablemente, después de ver el prototipo, alguien le dirá al analista acerca de un evento que hasta ese momento no se había mencionado. lam bién añadirá conceptos de datos a la ventana que no se m encionaron du rante las entrevistas y posiblemente elimine algunos por irrelevantes. Por esta razón encuentro que es imposible terminar realmente el modelo de información o el modelo de eventos mientras no se tenga un prototipo. Llevándolo un poco más allá, el prototipo puede usarse eomo una he rramienta de entrevista para derivar, de hecho, los modelos de información y de eventos. La creación de prototipos también causará que salgan a la superficie los asuntos de los procesos del negocio. Cuando un sistem a cliente/servidor com ienza a inm iscuirse en los que antes eran del dominio de la com putadora personal, tal vez encuentre personas que realizan las mismas tareas en formas radicalm ente diierentcs. E l nuevo sistema puede elim inar la captura de datos redundantes en hojas de cálculo o en sistemas auxiliares o alterar o elim inar la des cripción de trabajo de alguien, lil prototipo es frecuentem ente la prim era vista clara del usua rio del futuro am biente de trabajo, i -a creación de prototipos también hará evidentes asuntos técnicos en un punto del pro yecto cuando todavía hay tiempo su fie icute para haccr algo al respecto. Las disposiciones de ventanas pueden ser m apeadas hacia el modelo de inform ación para obtener un sentido de qué tan com plejo puede ser el acceso a los datos. Recientem ente encontré un ejemplo dramático de un prototipo de ventanas que puso en evidencia un m olesto problem a tecnológico. Un gru po de soporte de ventas requería una ventana de proyección de inventarios muy saturada de elem entos que era capaz de desplegar los saldos de inventarios pasados, presentes v proyec ciones futuras. " El m odelo de inform ación indicaba que se requería una gran cantidad de uniones de ta blas com plejas y de cálculos para poner los datos en la pantalla. El cuello de botella potencial sobre el desem peño había pasado .inadvertido hasta que no se había creado el prototipo. L! analista pasó esta ventana a un equipo técnico que fue capaz de tom arse su tiempo para en contrar una form a para hacer que iuncionara, evitando una crisis de codificación de último minuto. El prototipo también permite que se exploren ambientes de destino posibles. Tal vez una in terfaz gráfica de usuario no sea lo óptimo para su aplicación particular, Se puede explorar la ma nera en que se vería la interfaz con sistemas basados en plurna, dispositivos portátiles pequeños, lectores de código de bairas, una página Web o las antiguas pantallas verdes de caracteres. Es im portante que los usuarios estén lo suficientem ente familiarizados con la tecnología de destino para evaluar las disposiciones sin confundirse. Para los usuarios que nunca han vis to una GUI se les deberá dar una introducción y una dem ostración con varias aplicaciones GUI. estándares, tales com o un procesador de palabras o una hoja de cálculo, o tal vez hacer una de mostración de otra aplicación G U I que se tenga en su establecim iento. Los usuarios necesitan com prender que pueden tener varias ventanas abiertas, datos re levantes en las barras de títulos y tener la habilidad de arrastrar ventanas para quitarlas. D e 110 hacerlo así, tal vez los usuarios insistan en prácticas que fueron com unes en los días de las pan tallas verdes, tales como' la inform ación repetitiva de encabezado en la parle superior de cada pantalla.
164
Capítulo 6 / EL PROTOTIPO DE INTERFAZ
Las desventajas de la creación de prototipos Al igual que todo lo bueno, la creación de prototipos tiene sos desventajas. A unque todavía se están recopilando requerim ientos, el prototipo dirige al proyecto hacia el diseño. Los analistas deben recordar constantem ente la directiva principal y usar el prototipo para derivar y validar los requerim ientos mientras difieren con seguridad las decisiones detalladas de diseño. Insisto en esta separación, debido a que el análisis ya es suficientem ente difícil sin la distracción que causan asuntos de navegación, ergonom ía o lo que es peor, de codificación. Para m over cualquier parte dcl proyecto hacia el diseño, prim ero es im portante tener bien definidos los modelos de inform ación y de eventos. El diseño detallado de la interfaz puede h a cerse en form a sim ultánea con los esfuerzos del m odelado arquitectónico y el diseño de base de datos que vienen a continuación de la term inación de los modelos de análisis. Sin em bargo, todas estas tareas serán severam ente obstaculizadas y plagadas con trabajo extra, si los m ode los de inform ación y de eventos no han sido bien com prendidos. Tenga cuidado de 110 prom eter en el prototipo características que 110 pueda proporcionar. El paradigm a de la GUI viene eon una gran cantidad de características y controles, con la m eta de 110 usarlos todos, sino de utilizarlos en donde son adecuados. En mi primer proyecto diente/servidor, en el prototipo, prom etim os una ingeniosa característica de arrastrar y soltar. Cuando se llegó a la codificación final encontram os bastante problem ática la función de arras trar y soltar en las herramientas de desarrollo. Nos arrepentimos de haber prom etido ese estilo de navegación particular, porque los usuarios se habían enam orado de la idea y no adm itirían ninguna otra alternativa aunque se hubiera podido realizar por muchos otros métodos. La co dificación se llevó el doble de lo que se esperaba y las pruebas fueron una pesadilla. A partir de esc momento, m antuvim os los prototipos simples y relativam ente neutrales sobre los asun tos de navegación. En la fase de diseño detallado nos concentram os en las características GUI que ya sabíam os que habíam os dominado. Tal vez el peligro más grave de la creación tem prana de prototipos, es que el gerente del proyecto puede soltar las riendas a los program adores. Liberados de las cadenas del análisis pueden dejar a un lado todas las pretensiones de modelado y em pezar a codificar el sistema. En un proyecto de un tam año apreciable esto significa el desastre. U na de las premisas básicas de este libro, es que las aplicaciones el i ente/servidor son más com plejas y requieren m ucha más inteligencia de ingeniería que sus contrapartes m ainfra me. A lo largo de años de prueba y error, estoy com pletam ente convencido de que la genera ción actual de herram ientas de desarrollo, es más cara de m odificar que una especificación de diseño bien realizada. U 11 paso de diseño particular producirá una especificación que permite que el gerente del proyecto reparta el esfuerzo de program ación entre varios program adores, y perm ite la prueba independiente de la aplicación por un equipo de supervisión de calidad. Sin una especificación de diseño, todos los esfuerzos subsecuentes de prueba o docum entación d e berán esperar hasta que el program ador entregue el código terminado. La especificación de di seño es uno de los productos más costeables de todo el proyecto.
¿Qué tan detallado debe ser el prototipo? Ila\ dos corrientes en ¡o que se refiere a la creación de prototipos. U na prom ueve un prototi po codificado de alta tecnología que evenlualm ente evolucionará hacia un sistem a terminado. El sistema se codifica en forma progresiva, com enzando con la disposición de interfaz y aña diendo luego más y más detalles para dar mayor vida al sistema.
¿DE DÓNDE VIENEN LAS VENTANAS?
165
L a otra cree que estos prototipos llamados de alta tecnología son dem asiado caros y que los m ism os beneficios pueden obtenerse a partir de disposiciones baratas de tecnología básica hechas en un procesador de palabras, en una herram ienta de dibujo, en un pedazo de papel, en un pizarrón blanco o en una herram ienta CASE. En esle punto de 1.a evolución de las herramientas de software yo soy un firm e creyente de los prototipos de tecnología básica. Incluso esta clase de prototipo de tecnología básica se vuelve a utilizar en la especificación del diseño y en el script de prueba. La razón por la que pro muevo la creación de prototipos de tecnología básica tiene que ver con la alta velocidad para lo grar el objetivo de aprendizaje y cl bajo costo de hacer cambios. Recuerde que el objetivo principal de la creación de prototipos en la fase de análisis es recopilar y validar requerim ientos, mientras se posponen decisiones de diseño detalladas. La creación de prototipos de tecnología básica es barata, rápida y satisface cl objetivo de aprendi zaje. M uchas de las principales herramientas de desarrollo GUI (a las que coloco crt la catego ría de alia tecnología) todavía insisten en que se debe instalar una base de datos relactonal antes de hacer ventanas que sean capaces de ser reutilizadas en la aplicación final. E sta dependencia sobre las tablas dirige el costo de hacer cam bios al prototipo así com o fuerza la creación de un diseño de base de datos en un momento del proyecto en que todavía no se ha term inado el m o delo de inform ación. A unque este enfoque puede funcionar en aplicaciones muy pequeñas, no puede escalarse a una m etodología costeable para los proyectos más grandes. El método de creación de prototipos de tecnología básica m inim iza el fenóm eno llam a do “orgullo del autor” . Entre más tiempo se le perm ita a un program ador trabajar en un dise ño, es menos probable que tenga ganas de cambiarlo. El prototipo de tecnología básica asegura que se haga una inversión em ocional pequeña antes de que el producto esté listo para ser revi sado y corregido por los usuarios o por cl resto del equipo de desarrollo. Hay razones legítim as para la construcción de un prototipo de alta tecnología funcional y animado. Un pequeño esfuerzo de construcción aislado, puede ser muy instructivo si el equi po de desarrollo o los usuarios no han trabajado anteriorm ente con una aplicación GUI. En es ta situación, la construcción del prototipo debe ser tratada com o un laboratorio de investigación y desarrollo con objetivos de aprendizaje claros y un alcance lim itado a u n a p e q u e ñ a parte del sistema. BI objetivo es hacer que los desarrollad ores y usuarios se fam iliaricen con el am bien te de destino para que en el futuro puedan recordar las abstracciones sin tener que construir ca da pieza del producto para com prenderlo. Para la creación de prototipos baratos de alta tecnología, cualquier herramienta de trazado o hasta un procesador de palabras pueden hacer un trabajo razonable para imitar una disposición de ventana. Los equipos de proyecto han creado plantillas muy exitosas para objetos tales como barras de desplazamiento, barras de título, menús, botones y campos, facilitando cortar y pegar para hacer una nueva disposición en cuestión de minutos. U na vez que se han creado varias plan tillas de ventana con la herramienta seleccionada, es muy fácil copiarlos para ventanas subse cuentes asegurando un patrón de disposición común a lo largo de la aplicación.
¿DE DÓNDE VIENEN LAS VENTANAS? Las m etodologías estructuradas de ingeniería de software han estado plagadas en el pasado por abismos entre el análisis y el diseño en donde han caído m uchos proyectos para no resurgir nunca. Yo prefiero ver la transición del análisis al diseño com o un cam bio gradual en donde los modelos llegan a ser más parecidos ai diseño con cada decisión que se toma. El prototipo
166
Capitulo 6 / EL PROTOTIPO DE INTERFAZ
de interfaz es el primer paso hacia cl cam po del diseño. Para com enzar el prototipo retom are m os nuestros m odelos de análisis. Las ventanas son la m anifestación física de los flujos de estím ulo y respuesta de los eventos del negocio para los que se ha escogido la im plem entación por medio de una .interfaz gráfica de usuario. El primer paso es decidir cuáles eventos se prestan a ser representados en una GUI. Se puede com enzar volviendo a ver el modelo de contexto. A hora que ya se com prende mucho acerca del sistema, se está listo para dar ideas acerca del transporte físico de los datos hacia y desde la aplicación. Puede utilizar cl modelo de contexto com o una ayuda gráfica, exam ine los estímulos, respuestas y agentes externos de cada evento. Considere si la interfaz debe ser en línea, diri girse a una im presora o m áquina de fax, hacia un intercam bio electrónico de datos, hacia otra base de datos o hacia otro medio de transporte (figura 6-1).
Bu i'ó tic-'! -i; r ti i [<> do d ie n te
Figura 6-1. l.'n diagram a de contexto con anotaciones de los m ecanism os de transporte.
El modelo de contexto define la frontera de la interfaz. Se tendrá que diseñar un m eca nismo de transporte para cada estím ulo y respuesta que cruza la frontera. 1.os datos que cruzan la interfa7 están declarados en el modelo de eventos por los estímulos y las respuestas. La or ganización y definición de los datos pueden encontrarse en el modelo de información.
EL PROTOTIPO INICIA EL DIÁLOGO HOMBRE-MÁQUINA Im agine que nos han contralado para diseñar una m áquina de cajero automático. (Suponga que ninguno de nosotros ha salido de su cubículo desde hace veinte años y. por lo tanto, nunca ha
EL PROTOTIPO INICIA EL DIÁLOGO HOMBRE-MÁQUINA
167
visto una m áquina para entregar dinero en electivo.) Tenemos algunos modelos de análisis en borrador del problem a dcl negocio y se nos ha pedido que los transform em os e.n un prototipo de interfaz. La figura 6-2 m uestra el diccionario de eventos para el cliente del banca solicita retiro de efectivo.
¡D d o l e v e n t o :
005
¡
E v e n to :
E l c li e n t e d e l b a n c o s o l ic i t a r e t ir o d e e f e c t iv o
1
D e s c r i p c ió n :
U n c li e n t e d e l b a n c o p u e d o r e a r a r e f e c t iv o ríe s u c u e n t a i d e n t i f ic á n d o s e a s í m is m o y a s u n ú m e r o d e c u e n t a b a r r e a r ía , i n d ic a n d o e l tip o d e c u e n t a y la c a n t id a d q u e q u i e r e r e t ir a r . E l b a n c o v e r i f ic a r á q u e d is p o n e d e lo s f o n d o s s u f i c i e n t e s y le e n t r e n a r á e f e c t iv o y u n r e c ib o e n d o n d e a p a r e z c a la c a n t id a d r e t ir a d a , !a f e c h a , la h o r a y el n u e v o s a ld o .
E s t ím u l o :
N ú m e ro
ce
c u e n ta ,
N IP
{n u m e ro
de
i d e n t i f ic a c ió n
p e r s o n a l) ,
tip o
do
c u e n t a { c h e q u e s o a h o r r o s ) , c a n t id a d a r e t ir a r . A c tiv id a d :
V a l i d a r q u e l¿f c u e n t a e x i s t a * V a l i d a r N IP V a l i d a r q u e h a y a f o n d o s s u f i c ie n t e s C r e a r t r a n s a c c i ó n d e r e t ir o E n t r e g a r e f e c t iv o
ja
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 * 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
R e s p u e s ta :
respurisE^del
en el diseño finar.
E l a c u s e d e r e c ib o d o l r e t ir o { n ú m e r o d e c u e n t a , t ip o d e c u e n t a , n o m b r e d e l c li e n t e , f e c h a , h o r a , s u c u r s a l , ID d e t r a n s a c c i ó n , tip o d e la t r a n s a c c i ó n , c a n t id a d d e la t r a n s a c c i ó n ( m a t e r ia l = e f e c t iv o ) .
E fs e to :
E l c li e n t e t ie n e s u e f e c t iv o y s u c u e n t a h a s id o r e d u c id a d e a c u e r d o c o n la c a n t id a d r e t ir a d a .
Figura 6-2. Registro del diccionario de eventos para el cliente del banco solicita retiro de efectivo .
Nuestro director técnico del proyecto ha leído un artículo acerca de la com putación clien te/servidor y nos ha llegado con la brillante idea de instalar un monitor, un teclado y un ratón al lado deí banco. Con nuestros cerebros en la posición de “apagado’' podremos crear una venta na prototipo para reconocer este evento sim plem ente acom odando los elem entos de datos de
168
Capítulo 6 / EL PROTOTIPO DE INTERFAZ
estímulo en cl espacio de trabajo de ia ventana. Los datos de respuesta serán regresados al usua rio por medio de la impresora y, por lo tanto, no se necesitan datos de respuesta significativos en la pantalla. La ilustración que se muestra abajo m uestra los resultados de nuestra obra maestra de diseño. ¿Satisface este prototipo los requerim ientos esenciales tal y com o son definidos por los modelos de análisis? Parece que sí. ¿Es bueno este diseño de prototipo? ¡No, no tiene sentido!
Los m odelos de análisis no pueden ser transform ados mecánicam ente en un prototipo de interfaz sin una actividad cerebral adicional. Los m odelos esenciales perm anecen callados acerca del nivel de experiencia de los usuarios a los que se dirigen. En el caso de nuestra in terfaz de m áquina de dinero en efectivo es poco probable que el cliente de banco típico se to m e cl tiempo para teclear su núm ero de cuenta, tipo de cuenta, N IP y cantidad a retirar. M uchos de los clientes del banco ni siquiera saben mecanografiar. Los diseñadores de m áquinas de cajeros autom áticos del mundo real se enfrentan a un vector de calidad que insiste en que la interfaz debe ser utilizablc por cualquier cliente que ten ga desde cinco hasta ciento cinco años. Para acom odar este requerim iento los diseñadores tie nen que dividir el (lujo de estím ulos esenciales en una serie de diálogos. Las máquinas de cajero autom ático m ás m odernas han llevado a la descom posición de los eventos del negocio que intervienen en el diálogo a un extremo lógico. Solicitan un dato a la vez seguido de una actividad de edición y de una respuesta del sistem a que pide el siguiente dato. Cada fragm en to del diálogo es un evento po r derecho propio.
EL PROTOTIPO INICIA EL DIÁLOGO HOMBRE-MÁQUINA
169
E l d ie n te del banco solicita retiro de efectivo = Hl clien te d el b an c o in se rta la ta rje ta de la cu en ta E l d ie n te d d banco te cle a su N IP El clien te del banco se lec cio n a el tip o de cu en ta E l d ie n te d d b an co in d ic a la ca n tid a d a re tira r El nivel de detalle de estos eventos está manejado por consideraciones de diseño y se re quiere que el conjunto com pleto de eventos del diálogo satisfaga el único evento a nivel de n e gocio, Por esta razón es excesivo un registro de diccionario de eventos para cada evento del diálogo. Rl prototipo de interfaz se convierte en una ayuda visual superior. La figura 6-3 m ues tra un prototipo razonable para el evento el d ie n te d d banco solicita retiro de efectivo con ba se en cl nivel de habilidad del posible usuario.
F ig u ra 6-3. U n p r o t o ti p o q u e resp eta cl n iv e l de habilidad del usuario.
El objeto de este ejem plo es ilustrar que el prototipo de interfaz es una actividad de d i seño. Es muy difícil evitar los asuntos de facilidad de uso una vez que se com ienzan a definir las ventanas. Tenga en mente la directiva principal del prototipo del análisis para derivar y va lidar los requerim ientos esenciales. N ecesitará resolver una determ inada parte de asuntos de fa cilidad de uso a fin de que el prototipo no sea rechazado rápidam ente por los usuarios, pero trate de m antener abiertas las opciones de diseño. Como veremos posteriorm ente en este libro, hay una gran cantidad de consideraciones que intervienen en una interfaz bien elaborada y que son posterga bles hasta la etapa de diseño detallado. Éstas incluyen determ inar la unidad de tra bajo adecuada para el usuario, cl tipo de ventana, la navegación y los puntos en los cuales se debe escribir el trabajo en la base de datos.
Capítulo 6 / EL PROTOTIPO DE INTERFAZ
170
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?
iseíIs is t e m a
N o m b re d e e v e n to
M ó d u lo s
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
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.
t r a d i c io n a l
! 8
EL PROTOTIPO INICIA EL DIÁLOGO HOMBRE-MÁQUINA
171
Los sistemas estructurados en form a organización;]! suponen que las descripciones de trabajo de las personas están bien divididas a lo largo de las fronteras políticas de la em presa (figura 6-6). La interfaz se estructura de acuerdo a ello. Cada ventana se encuentra, por lo g e neral, en un lugar de la aplicación, por ejemplo, el calendario de reservaciones diarias sólo puede encontrase bajo el icono de resec a cio n e s en el menú principal. La aplicación de reser vaciones también incluye toda la funcionalidad requerida para la creación, modificación y can celación de reservaciones.
M enú p r in e ijia l
I n f o r m a c ió n
In f o r m a c ió n
in fo rm a c ió n
d e l p a u m n tn
medica
d e m a lu s L ü rtiH
Ríaservadones.
^______ J
c l L
J1i g u r a 6 - 6 . Lina a p l i c a c i ó n e s t r u c t u r a d a en f o r m a o rganizaciurm l.
U na estrategia para controlar el acceso de usuarios en una aplicación estructurada organizacional mente es proporcional1la rnisrna aplicación a todos pero variar su acceso dependiendo de su autoridad para iniciar diversos eventos, lisia es la implementación más común en el am biente cliente/servidor debido a que hace que sea muy fácil el control de versiones cuando to dos tienen cl mismo software. La desventaja es que un solo usuario, tal corno el doctor, liene que familiarizarse con varios subsistemas principales para encontrar las ventanas que necesita. Se presentan problem as en las aplicaciones estructuradas organiza cío nal mente cuando la actividad del trabajo actual del usuario cae fuera de las fronteras políticas tradicionales. lisio ha llegado a ser cada ve? más com ún en las em presas actuales; q Lie dan “mayores facultades” a sus em picados. Una alternativa a la estructura organizacional es el em pacar en las aplicaciones a las ventanas que están relacionadas con iniciadores de eventos específicos (figura 6-7). La ventaja principal de este método es que el usuario obtiene mi lugar de com pras de una sola vi
172
Capítulo 6 / EL PROTOTIPO DE INTERFAZ
sita para los eventos de los cuales es responsable. A dem ás, el tam año de la aplicación es físi cam ente más pequeño y el usuario no necesita aprender la m anera de navegar en las partes no usadas de la aplicación. La desventaja es que el control de versiones subsecuente de las m ejo ras de softw are tendrá que adm inistrar la construcción y distribución de ejecutables varios y dispares hacia diferentes sitios clientes.
Figura 6-7. Una aplicación organizada por transportador.
Continuarem os para ver que el diseño está lleno de m ediaciones y com prom isos. El agrupam iento de eventos por transportador ayuda a que el diseñador haga prototipos de orga nizaciones diferentes para la m ism a aplicación, yendo desde la descom posición funcional tra dicional hasta em pacados heterogéneos basados en las necesidades de usuarios individuales. El agrupam iento de eventos por iniciador (por ejemplo, “cliente”) también puede ser muy revelador. M ediante la determ inación de la fuente últim a de datos se puede ser capaz de extender la captura de datos o la presentación resultante más allá de la organización tradicio nal y llegar hasta al cliente. Los ejem plos creativos incluyen la obtención de boletos en forana electrónica en aplicaciones de aerolíneas, trenes subterráneos y estaciones de tren y la coloca ción de pedidos por m edio de Internet.
Agrupación de eventos por objeto Una de las formas más poderosas para utilizar un modelo de eventos es agrupar los eventos por objeto. La sintaxis del nom bre del evento es sujeto-verbo-objeto. El objeto representa a la co sa del mundo real sobre la que se reaiiza eí evento. Tomemos nuestro venerable evento el clien te coloca pedido. El objeto pedido puede ser representado en el modelo de datos por varias entidades. En la figura 6-8 en un ERD (diagram a en ti dad-re] ación) vemos una estructura de d a los típica para pedido, en donde un cliente puede colocar pedidos para v an o s productos y solicitar una o más entregas de esos productos a lo largo del tiempo. Por fav o r tome en cuenta que la palabra objeto está severam ente sobrecargada en nues tra industria. Objeto (o más precisam ente clase) puede ser una representación de un solo tipo de entidad o una abstracción que representa varios tipos de entidades, o hasta puede ser que no tenga representación en el modelo de información. También puede tratarse de una am plia v a riedad de construcciones de program ación que solam ente están orientadas a ¡a implementación.
EL PROTOTIPO INICIA EL DIÁLOGO HOMBRE-MÁQUINA
173
En el contexto de este capítulo la palabra objeto se refiere ai nom bre o nom bre modificado en el nombre de evento que representa una abstracción del negocio para la cual pueden ser repre sentados datos relevantes con una o más entidades en el modelo de inform ación.
Figura 6-8. Un KRD dcl pedido.
Kl agolpam iento y exam en del modelo de eventos junto con el modelo de inform ación es el prim er paso para descubrir y catalogar las clases del negocio en un diseño orientado a ob jeto s. Bsto se refiere a proyectos que están enfocados hacia im plem entaciones orientadas a objetos. Pospondré una discusión com pleta de este tem a hasta el capítulo 12 sobre el diseño de com ponentes internos. h l agolpam iento de eventos por objetos nos lleva al paradigm a objeto-acción, el cual es un cam bio en el diseño general de las interfaces de usuario que ha estado ocurriendo durante muchos años. Las prim eras investigaciones sobre la facilidad de uso de diferentes diseños de pantalla revelaron que es más intuitivo y eficiente cuando los usuarios adquieren prim ero un objeto en la pantalla y luego le dicen a la com putadora la acción que hay que aplicar. Los pri meros lenguajes de program ación en línea frecuentem ente motivaban ha hacer exactam ente lo contrarío. La figura 6-9 m uestra el menú principal para una im pleincntación acción-objeto. El menú principal de una aplicación acción-objeto típica necesitaría que el usuario d e clarara el tipo de acción que pretende realizar. Puede teclear A P para “A ctualizar Pedidos” y oprim ir E ntrar. El program a podría llam ar a una pantalla de actualización de pedidos en blan co (figura 6-10). Luego el usuario podría identificar el pedido que quisiera actualizar teclean do una clave tal como el núm ero de pedido, en la parte superior de la pantalla y volviendo a oprim ir E ntrar. Luego la pantalla recuperaría el pedido y se podría em pezar a trabajar. Kste ti po de diseño soportó un am biente, en donde las tareas del usuario eran extrem adam ente repe titivas. Podría perm anecer en la m ism a pantalla y teclear pedidos todos el día. tecleando datos de montones de hojas de entrada. Hoy reconocem os que la m ayoría de los trabajos de los usuarios son más com plejos. Al poner autom atización hasta las líneas frontales de la organización, el movim iento repetitivo de los departam entos de captura de datos antiguos ha dado paso a las fuerzas m ás aleatorias del mundo real. Kl personal de ventas recibe llamadas de clientes haciendo nuevos pedidos, cam bios al trabajo que se está realizando y cancelación de pedidos existentes. El paradigm a obje
174
Capítulo 6 / EL PROTOTIPO DE INTERFAZ
to-acción establece que los usuarios deben ser capaces de seleccionar una lista de objetos de la base de datos, seleccionar uno o más de ellos y luego especificar la acción que quieren aplicar.
Figura 6-9. Un m enú principal a cc ió n -o b je ta
F ig u ra 6-10. La pantalla para actualización de pedidos.
EL PROTOTIPO INICIA EL DIÁLOGO HOMBRE-MÁQUINA
175
La figura 6-11 muestra una ventana que soporta cl paradigm a objeto-acción. lil usuario puede teclear vatios criterios de selección opcionales en la parte superior de la ventana, los cua les le permiten recuperar una lista de pedidos cuando hace clic en el botón Find. La lista se despliega en la parte inferior de la ventana.
Figura (í-'ll. La ventana Ordcr Selectiort.
Se puede seleccionar el objeto que se desee haciendo clic en los renglones del conjunto resultante. La línea de botones de com ando (o menú en algunas aplicaciones) contiene todas las acciones que pueden llamarse desde esta ventana. El usuario prim ero selecciona el objeto y luego aplica la acción. Para actualizar un pedido, el personal de ventas sim plem ente encuentía el pedido en la lista y hace clic en el botón Open. Luego se abre ia ventana Order M ai tile nance con los datos llenados a partir de su selección (figura 6-12). La interfaz gráfica de usuario también soporta una extensión importante al paradigma objeto acción. Cuando el usuario lia seleccionado al objeto, la interfaz es lo suficientem ente in teligente para inform arle cuáles acciones son legales en cualquier momento con base cu la au toridad del usuario y el estado actual del objeto. Los botones de com ando y conceptos de menú son rutinariam ente desactivados (puestos en gris) en la interfaz cuando la acción es ilegal pa ra el objeto seleccionado, lista puede ser una Larca difícil para un program a y virtualm enle im posible de probar a menos de que se tenga un diagram a de estado-transición. 1.a figura 6-13 m uestra una lista de eventos que han sido agrupados por objeto. El obje to del evento puede determinarse, por lo general, mediante una inspección simple. Frecuentemen te los eventos afectarán a más de un objeto. Un enfoque mucho más riguroso es producir una matriz CRUD (Crear, Leer, Actualizar, Borrar) evento/entidad para determinar cuáles entidades son afectadas por cada evento, sin embargo, no siempre se requiere este nivel de detalle.
176
Capítulo 6 / EL PROTOTIPO DE INTERFAZ
F ig u ra fi-12. La ventana Order Mainíenance
Nombre del evento
Transportador
Objeto
El cliente coloca pedido
Representante de ventas
Pedido
■ Representante de ventas
Pedido
El cliente cancela pedido
Representante de venias
Pedido
El departamento de producción asigna pedido
Gerente de producción
Pedido
E! departamento de d istiih u d ó o registra el pedido
Representante de reservaciones marítimas
Ped'do, reservación
La planta envia cl pedido
Empleado de embarques
Pedido, envío
El yerente de ventas solicita repode de pedidos
Gerente de ventas
Pedido
I I cliente pregunta sobre ei esiado del pedido
Representante ríe ventas
Pedido
El cliente modifica 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 organizacional de los datos es dictado por la cardinalidad de la relación en el diagram a entidad-re lación. Si un pedido puede tener varios conceptos de pedido, uno para cada producto pedido, entonces se podría esperar una relación encabezado-detalle clásica en la ventana de m anteni miento de pedidos (figura 6-14).
Figura 6-14, El modelo de información guía la disposición de los datos en líi interfaz.
178
Capítulo 6 / EL PROTOTIPO DE INTERFAZ
Si hay esp ad o para desplegar ambas entidades en la m ism a ventana, la entidad de pedi do puede ser acom odada en la parte superior y una sección Lipo cuadrícula puede desplegar ca da instancia de concepto de pedido en la parle inferior de la ventana. Si hay dem asiados atribuios para que quepan en form a agradable en lina ven Lana, se deberán em plear varias ven tanas para desplegar la inform ación. Para cam pos ac tu a liz ab as evite a toda cosía las barras de desplazam iento para ver los cam pos que han quedado ocultos a la derecha o en la parte m ie n o r de la ventana. Los usua rios frecuentem ente rechazan las ventanas desplazables que tienen cam pos actualizables ocul tos (figura 6-15).
F ig u ra 6-15. Uso inadecuado de las barras de desplazam iento vertical y h o rizo n tal.
Las barras de desplazam iento vertical son mejor em pleadas para listas grandes en donde se regresan más renglones de los que caben en la pantalla. I -as barras de desplazam iento hori zontal también deben reservarse para las listas no actualizables cuando la cantidad de colum nas regresadas excede la anchura del desplegado. Cuando se usan listas de desplazam iento horizontal es un buen hábito usar ventanas estilo cuadrícula que perm iten que los usuarios reacom 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 venurna 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 e lI S e fe c tío n Y Ce Ss Ss B
| O ce-ari R id ei l Ü e e a n R id ei i O c e a n R idsr ¡ O c e a r Seetkei í Gceart Seefcer ¡! Ocean Vision i U cean Loaner Ü c e a n lo -a n e i
Igg
Ocean Cruuei
ÍK Í »
V>4
V-jNCCHJY€'i. 8 L
m . . _ .. IB 1 0 3 6 _ _ _ JV 24 ¡8 1 0 3 6
ÍV 2 2 "
¡8147 B147
Vancouveí, BC Tácoros, WA
812
Vancogvei. 8C S a n Francisco.. CA Los A n g e le s , CA S ár¡ D ieg o , CA
'“ TvaT
T ac e
... jV34~‘
tbcs
ÍV 3 3
íT a c c m a , W A tSar* F fa n c R c o , CA
'BC12
t dcs-an^iira, .} iShímíso, JP
1
Stw B £0, JF ; % T ag ^ n o u ra . J! ■% iSbtm izo. JP §í ^ S a n F ran cisco V a n c c w e r, B V d n c o u v e r, B
F ig u r a 6-16. l.’so adecuado de las barras de desplazam iento vertical y horizontal.
F ig u ra 6-17. Un fragm ento E R D de mi sistem a tic facturación.
A unque las decisiones de navegación finales se pospondrán hasta la etapa de diseño d e tallado, es correcto difundir la situación en el análisis dem ostrando las m uchas formas en que puede m anejarse la navegación. Los usuarios pueden estar suponiendo una navegación de una sola ruta de ventana a ventana (figura 6-l.K). K1 analista podría preguntar, ¿qué tantas facturas tienen m ás de un concepto en reali dad? Si el usuario indica que la m ayoría de las facturas sólo tienen un concepto, entonces el diseñador puede ayudarles saltándose una pantalla. K1 modelo de inform ación sim plem ente in dica que se perm ite más de un concepto. No establece la norma. Cuando el usuario hace clic en el botón Conceptos de fac tu ra ... de m antenim iento de factura, en vez de recuperar a ciegas la ventana selección de concepto de factura, el sistema podría contar prim ero las instancias de concepto de factura. (Este enunciado SQL ha probado ser bastante rápido.) Si el sistem a regresa un conteo de “uno”, la aplicación abre la ventana m antenim iento de concepto de factura, y si el sistem a cuenta más de uno, se le presenta al usuario una lista de conceptos entre los que puede escoger. La figura 6-19 muestra la navega ción sim plificada.
180
Capítulo 6 / EL PROTOTIPO DE INTERFAZ
El analista también puede determ inar que una cantidad significativa de consultas; sobre factura se hacen al nivel de concepto de factura y no al de encabezado de factura. Bi botón Conceptos de factura... también podría ser colocado en la ventana selección de fa ctu ra , per mitiendo que los usuarios dejen a un lado com pletam ente a la ventana m antenim iento de fa c turas y vayan di r e d ám enle al nivel de concepto.
Figura 6-18. Navegación de una. sola rala.
F ig u r a 6-19. R ulas de navegación para facturas de un solo concepto y de varios conceptos.
RASTREABILIDAD DE REQUERIMIENTOS
181
Las interfaces gráficas de usuario perm iten una gran variedad de diseños de arreglos de navegación, razón por la que insisto en m antener abiertas las opciones mientras todavía se es tán recopilando y validando los requerim ientos. Si se enfrenta a un grupo de usuarios que es tán obsesionados en la navegación, la dem ostración de varias rutas de navegación para su disposición de ventanas, frecuentem ente elim inará sus preocupaciones. Tam bién aclarará consideraciones de diseño im portantes que pueden usarse posteriorm ente, y ayudará a que los usuarios regresen al tema. El m odelo de inform ación es una guía crítica para la disposición de ventanas. Proporcio na un m apa de la cardinalidad entre grupos de datos. Además de la estructura de los datos, el diseñador de interfaz también necesita com prender las estadísticas del m undo real que están tras la cardinalidad para evitar la creación de interfaces que fuerzan a ios usuarios a seguir las raras rutas de excepción, en vez de la norma,
RASTREABILIDAD DE REQUERIMIENTOS
R
A
A
A
RA
El departamento de crédito aprueba pedido
RA
El departamento de producción asigna pedjdo
RA
Contabilidad factura el pedido del oliente
Concepto de factura
RA
W"O
Mantenimiento de concepto de factura
La planta envía el pedido deJ cliente
A
c o o TD ‘OT3 'ü 1?> u 0) d Q.
Mantenimiento de factura
RA
R
a a <3>
Selección de factura
Mantenimiento de pedido en planta
R
Mantenimiento de pedido
La planta satisface el pedido del cliente
Evento/ventana EJ cUente coloca pedido
Selección de pedido
Selección de pedido en planta
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.
Figura 6-20, U na m atriz cvento/ventana. Para los eventos que se activan por otros m étodos, tales com o la recepción de una trans m isión EDI (intercam bio electrónico de datos), el nom bre del objeto de interfaz adecuado pue
182
Capítulo 6 / EL PROTOTIPO DE INTERFAZ
de indicarse en el mismo eje que se usa para ios nom bres de objeto de ventana. Este docum en to proporciona a los usuarios, instructores y probadores un índice de las ventanas que inician y ejecutan eventos del negocio. También proporciona una prueba para la term inación de las ac tividades de diseño de interfaz prelim inares y asegura tanto a los usuarios com o a los gerentes que se han tom ado en cuenta todos los eventos especificados. El gerente también puede usar el contador de ventanas term inadas para hacer estim aciones sobre el diseño y ei esfuerzo de imp]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 ventana/enüdad, m ostrando cuáles ventanas necesitan los servicios de datos para eada entidad.
MANTENIMIENTO DE LOS MODELOS EN SINCRONÍA CON EL PROTOTIPO El prototipo de interfaz necesita m antenerse en sincronía con ios demás modelos. Cuando se descubren nuevos eventos durante la revisión del prototipo deberán añadirse al modelo de eventos. T.os errores que se encuentran en el modelo para ios eventos existentes deben corre girse. Los elem entos de datos que no están representados en el modelo de inform ación deben añadirse y los atributos que se encuentren en el lugar equivocado deberán m overse a su enti dad adecuada. Las herram ientas CA SE podrían ayudar mucho para encargarse de mantener los m ode los en sincronía. U na herram ienta CA SE debería tratar a un evento de negocios com o un obje to independiente capaz de tener propiedades y relaciones con otros objetos en el depósito de herram ientas CASE. El usuario del CA SE debería tener la habilidad para m odelar gráficam en te los estímulos y respuestas de cada evento eom o parte del modelo de inform ación. Para cada atributo la herram ienta debería perm itir que el analista especificara nombres de rótulo prede term inados a usar cuando se despliega el atributo en un campo de form ato libre o en un form a to de columnas. La creación de una propuesta de disposición de ventana debe ser tan fácil eom o la selec ción de un evento o una lista de eventos y la declaración de que deben ser reconocidos en una ventana. Con el modelo de eventos y el modelo de inform ación enlazados, la herram ienta C A SE ya .sabe cuáles atributos necesitan ser capturados en la pantalla y tam bién sabe la relación entre las entidades representadas. Esto debiera proporcional' al m enos una lista de atributos co nocidos que el diseñador podría arrastrar haeia la disposición de ventana, o mejor, generar una disposición preliminar, basado en los atributos de estím ulo y respuesta y en la cardinalidad en tre sus tipos de entidad (figura 6 -2 1). Si el diseñador arrastra un atribulo del área de encabeza do de una ventana haeia el área de detalle, la herram ienta debería ser lo suficientem ente am igable para preguntarle si también quisiera mover el atributo en el modelo de inform ación subyacente. Las herram ientas CASE nunca serán capaces de leer nuestros pensam ientos. El di seño prelim inar generado por una com putadora podría parecerse mucho a la horrible interfaz de la m áquina de cajero autom ático que se mencionó al inicio de este capítulo. Sin embargo, podría dar al diseñador un punto inicial y proporcionar las capacidades de rastreabilidad y equi librio que tanto se necesitan entre los diversos modelos. L a tecnología CA SE ha aliviado m uchas de las actividades m undanas del desarrollo de sistemas, tales com o el dibu jo de gráficos y la generación del esquem a de base de datos. Al m o mento de escribir esto todavía tienen un largo cam ino en térm inos de ayudam os a crear proto
TÉCNICAS PARA LA REVISIÓN CON LOS USUARIOS
183
tipos de interfaz en la etapa de análisis, así com o m odelar los eventos de negocios en un am biente de negocios distribuidos, fin ausencia de la herram ienta CASE de nuestros sueños, el analista todavía tiene ia responsabilidad de m anejar estas tareas a la antigua.
F ig u r a 6-21. Las relaciones entre eventos, entidades y disposiciones de ventanas.
TÉCNICAS PARA LA REVISIÓN CON LOS USUARIOS Los prototipos pueden sor muy instructivos durante su construcción, pero su valor real se ob tiene cuando se revisan con los usuarios finales. Hay que inform ar a los usuarios el objetivo de aprendizaje específico antes de presentarles el prototipo. Lo m ejor es revisar el prototipo en persona para observar las reacciones de los usuarios. No caiga en la tram pa de sim plem ente en viar por correo los docum entos del análisis a los usuarios y solicitarles su aprobación en un tiempo definido. A unque los usuarios estén geográficam ente remotos, se puede em plear una variedad de tecnologías tales com o la conferencia por video, el enlace de PC rem otas o hasta cl viejo teléfono para revisar el proyecto en conjunto con el equipo. Muchos proyectos son muy satisfactorios en el m om ento de revisar prototipos en el pa pel sin incurrir en el costo de haber construido un producto codificado que trabajara. Si. se uti liza un proyector de transparencias con las disposiciones de ventanas, se invita a los usuarios a utilizar plumas de colores para sim ular la captura de datos. Conform e llenan los campos, el
184
Capítulo 6 / EL PROTOTIPO DE INTERFAZ
analista puede indicar cuáles elem entos de datos serán de captura en formaLo libre, en listas desplegables o seleccionados en m enús desplegables. L a m ayoría de los usuarios será capaz de validar el contenido de la ventana y de asegurar que los eventos sean capturados adecuadam en te con este método de creación de prototipos de tecnología básica. Cualquier sugerencia de d i seño detallada que se haga durante la sesión deberá escribirse para considerarla posteriorm ente. Incluso asuntos de diseño detallados tales com o la navegación, la ergononiía o la facili dad de aprendizaje de un diseño de interfaz pueden probarse en papel. U na técnica es no dar al usuario ningún entrenam iento previo sobre la form a de utilizar la interfaz. Luego el usuario lle na el form ato de diseño de interfaz y hace “clic” en los bolones con un lápiz. El facilitador po ne una nueva disposición frente al usuario para sim ular la apertura de una ventana. M ediante la observación del sujeto al tratar de usar la interfaz,, el diseñador puede ver si la interfaz es in tuitiva y las partes en las que se tienen problem as. Los cam bios sugeridos por el usuario en un cuestionario pueden realizarse rápidam ente en el prototipo de papel y probarse de nuevo. Una buena técnica de creación de prototipos para la revisión de la navegación es pegar las ilustraciones de las disposiciones de ventana en un pizarrón blanco (figura 6-22). Con el m o delo de eventos com o guía, el diseñador lleva a los usuarios a través de cada evento del nego cio que usa las diversas ventanas. Los usuarios y el diseñador trazan las rutas de navegación entre las ventanas para cada evento principal utilizando m arcadores de colores. Con todas las ventanas candidato a la vista, los usuarios obtienen una apreciación sobre qué tantos datos es tán involucrados y pueden hacer sugerencias relevantes sobre la forma óptim a para navegar por la aplicación. Si una sugerencia se desecha, la ruta sim plem ente se borra en el pizarrón blanco.
F igu ra 6-22. Una sesión de navegación en el pizarrón blanco.
Los beneficios de utilizar prototipos de tecnología básiea es que la m ayoría del análisis y gran parte de la inform ación de diseño puede ser recopilada sin incurrir en el costo de cons truir un producto funcional. Los prototipos de tecnología básica son baratos de construir y fá ciles de M odificar. Cuando un producto sufre varias iteraciones de prototipos en papel antes de
RESUMEN
185
su construcción inicia] es mucho más probable que la versión beta de ese producto sea más cer cana a lo que se pretende. Cuando se revisan prototipos de tecnología básica o alta tecnología con los usuarios también es importante imple mentar algún nivel de control de versiones para que se pueda recuperar la última versión aceptada, en caso de que no les gusten las ideas más recientes.
RESUMEN Un prototipo es un modelo creado para probar algún aspecto de un diseño de producto propues to. Los diseñadores de automóviles no tienen solamente una sesión de creación de prototipos y tampoco los diseñadores de software. Cada prototipo debe tener un objetivo de aprendizaje específico. Una vez que ha sido establecido el objetivo de aprendizaje, un buen ingeniero de software buscará el método más expedito para derivar el prototipo. En la mayoría de los casos la creación de prototipos en papel es todavía más barato que incurrir en el costo de construir una interfaz funcional, incluso con las herramientas GUI actuales de apuntar y hacer clic. Cuando las herramientas de desarrollo evolucionan al punto en donde se pueden derivar fácil mente prototipos significativos a partir de modelos abstractos, tales como los modelos de in formación y de eventos, entonces las balanzas de costos pueden moverse a favor de prototipos funcionales animados. El prototipo de interfaz puede usarse en la fase de análisis del proyecto para validar el mo delo de información y el modelo de eventos a fin de asegurarse de que los requerimientos del usuario se hayan comprendido en forma adecuada. También puede emplearse como un método para derivar el modelo de información con base en los datos que piden los usuarios en la venta na. Inevitablemente también sucederán refinamiento de eventos y el descubrimiento de nuevos eventos durante las sesiones de revisión del prototipo con los usuarios. La creación de prototi pos también pondrá en evidencia asuntos de proceso del negocio, en especial, cuando la fronte ra de automatización empresarial sea empujada hada áreas que anteriormente eran dominio de procesos manuales y de paquetes de computadora personal de escritorio. También se harán evi dentes asuntos técnicos potenciales, tales como los cuellos de botella de desempeño, mientras todavía es tiempo en el proyecto para resolverlos sensiblemente. La creación de prototipos tam bién puede usarse para explorar la apariencia y sensación de diferentes ambientes de destino sin tener que comprometerse con una tecnología en particular. El modelo de eventos proporciona una lista de todos los eventos ante los que tiene que responder el sistema. Para los eventos que tienen que ser comunicados a la máquina por me dio de la interfaz en línea se puede desarrollar un prototipo usando como base al modelo de eventos. Los estímulos y respuestas de cada evento contienen los elementos de datos que se re quieren pasar a través de la interfaz. En la sección de actividad pueden indicarse elementos de presentación adicionales y tal vez se tengan que mostrar más datos para hacer que la interfaz sea agradable, informativa y amigable. La conversión de un evento de negocio a una ventana o conjunto de ventanas involucra frecuentemente la división del evento esencial en un diálogo entre el hombre y la máquina. El nivel de detalle del diálogo dependerá en gran medida de la capacidad del usuario. El modelo de eventos es una herramienta importante para organizar la interfaz de usua rio. Los eventos pueden ser agrupados por sujeto o por transportador para crear áreas genera les de un solo lugar para los usuarios. El agrupamiento de eventos por objeto conduce al paradigma objeto-acción. Al usuario se le permite señalar un conjunto de objetos de la base de
Capítulo 6 / EL PROTOTIPO DE INTERFAZ
186
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 diagramació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 reingenicría del negocio. En términos del diagram a de la figura 7-1, cuando se m ueven los límites deí software debe haber cam bios en la capa de procedim ientos m anuales y, a veces, hasta en la capa de políticas del negocio. En los proyectos cliente/servidor m ás exitosos, el negocio se ha tom ado su tiempo para redefinir sus políticas y procedim ientos en anticipación a la nueva fron tera del softw are untes del análisis y diseño detallado del sistem a de software. E sta estrategia alinea a todos los usuarios con los nuevos procesos dcl negocio con soporte visible de los más altos niveles de la organización. D esafortunadam ente no todos los establecim ientos tienen la fortuna de contar con tal ad ministración visionaria. Frecuentem ente los proyectos cliente/servidor se inician sin conocer com pletam ente los cam bios culturales que van a activar. Dichos negocios pagan un alto precio por su reingeniería de proceso cuando se hace en forma sim ultánea o después de un caro es fuerzo de desarrollo de software. Cuando el analista se aventura en el hábitat del usuario se enfrenta rutinariam ente con prácticas contradictorias, políticas no declaradas y puntos de vista divergentes sobre la m ane ra en que debería m anejarse el negocio. El plan general del proyecto puede pedir una fuente consolidada de inform ación de clientes, pero el gerente de la planta se rehúsa a perm itir que los neanderthales de las oficinas centrales actualicen sus registros de clientes y los arrogantes y descuidados altos directivos de las oficinas centrales están indignados de que la planta rehú se a reconocer su omnisciencia, hste tipo de conflicto es típico. Cuando se encuentran las per sonas y el software, el analista se enfrenta a fronteras de alcance vagas, una gran cantidad de hojas de cálculo personales que no habían sido descubiertas anteriorm ente, peticiones de repor tes diferentes y partes interesadas que defienden vehem entem ente su visión de la realidad. E l analista no tiene la autoridad para resolver los asuntos que ocurren en la capa de procedim ientos m anuales y, ciertam ente, en la capa de políticas del negocio. ¡Es totalm ente responsabilidad del analista hacerlos salir a la superficie! Es im portante que separemos en nuestras mentes las responsabilidades de un analista contra las de un programador. La respon sabilidad del program ador es escribir un código que satisfaga los requerim ientos de la especi ficación y que esté libre de errores. La responsabilidad del analista es descubrir problem as del negocio y definir los requerim ientos que los resolverán. Ks correcto que un program ador igno re un asunto de negocios.1 Hablando estrictam ente no es su problem a. ¡Es negligencia profe sional que un analista ignore un asunto de negocios! Hl analista está en una posición difícil. Tiene la responsabilidad profesional de señalar las lagunas que hay en el procedim iento manual y en la capa de políticas del negocio que pue den im pedir que la capa de software se com porte en form a efectiva. Sin embargo, no tiene la autoridad para resolver esos asuntos. A esto se debe que, com o parte del proceso de estableci miento del plan general del proyecto, el negocio debe establecer un proceso de resolución de asuntos del negocio.
tiste enunciado tan enfático tiene la pretcnsión de trazar una distinción clara entre el papel del programador y el papel dcl analisla. Aunque estos papeles puedan ser representados por la misma persona en un proyecto, las responsabilidades son completamente diferentes.
192
Capítulo 7 / DAR LOS TOQUES FINALES A LA FASE DE ANÁLISIS
EL PROCESO DE RESOLUCIÓN DE ASUNTOS DEL NEGOCIO El plan general del proyecto deberá contener los nom bres del conseja de usuarios. Este equi po está com puesto por los usuarios del sistem a y sus supervisores inm ediatos. E stas son las m ejores personas para resolver asuntos que están dentro de la capa de procedim ientos m anua les al nivel operacional del negocio. Al resolver sus propios problem as es muy probable que acepten las soluciones. Para asuntos que es incapaz de resolver el consejo de usuarios, o p a ra aquellos que requieran una decisión de políticas, se necesita un co m ité directivo. El com i té directivo resuelve los asuntos a los niveles tácticos y estratégicos del negocio. También es la suprem a corte para la resolución de los asuntos que es incapaz de resolver el consejo de usuarios. Sus m iem bros deben incluir a quienes forjan la política y a las partes interesadas en el sistem a a los niveles más altos de la organización que tienen la autoridad para tom ar deci siones clave. Debe ser obvio que cl com ité directivo sólo debe ser m olestado con los asuntos más tras cendentes, tales com o “¿debe hacerse la facturación en las instalaciones de producción o con solidarse en las oficinas centrales?” Los asuntos más m undanos, tales com o “¿debe el usuario ser capaz de acreditar y volver a em itir varias facturas a la vez o de una en una?”, pueden de jarse al consejo de usuarios. Fl trabajo del analista es docum entar el asunto y añadirlo a la lista de asuntos centraliza dos del proyecto. La lista de asuntos es propiedad del gerente del proyecto. Uno de los traba jo s del gerente del proyecto es elim inar los obstáculos que pueden im pedir el avance de su equipo. El gerente del proyecto es responsable de encam inar los asuntos a través del proceso de resolución. Hsto involucra convocar al consejo de usuarios o al com ité directivo periódica mente y asegurarse de que el negocio alcance la resolución de cada asunto. Esto involucra fre cuentem ente un cierto grado de luchas políticas y torceduras de brazo. El gerente del proyecto tendrá m ucho m ayor anclaje en el negocio si el proceso de reso lución de asuntos se encuentra en el plan general del proyecto y ¡a resolución a tiem po de los asuntos está identificada com o un factor de éxito crítico. En algún punto, si suficientes asun tos tapan la tubería, el gerente del proyecto puede publicar el hecho de que el proyecto está v a rado hasta que ei negocio asum a sus rcsponsabildades.- Esto funcionará solam ente si el negocio está educado desde el inicio acerca de su pape] cu el proyecto de desarrollo. En caso contrario, el gerente parecerá com o un quejum broso e inútil y el negocio nonca resolverá sus problem as. El papel del analista es proporcionar al negocio la suficiente inform ación acerca deí asunto para que quienes son responsables puedan tom ar una decisión inform ada. Para el segui m iento de los asuntos he encontrado efectivo el siguiente formato. A lgunos paquetes de soft w are para adm inistración de proyectos o para seguim iento de defectos incluyen elem entos de datos sim ilares, o se puede crear una aplicación sim ple usando cualquiera de los productos de bases de datos relaciónales populares. .
-
He visto que vanos ta c a o s gerentes rie proyectos usan diversas tácticas, que vun (testic la distribución de co ira ) e le c m iiñ c ti h a a a ei envío de nna lista de asuntos no resueltos y de las personas que eslán posponien do su resolución. A unq ue e x tra ñ a , la humillación pública tiende a producir alguna acción.
DOCUMENTACIÓN DE LOS ASUNTOS DEL NEGOCIO
193
DOCUMENTACIÓN DE LOS ASUNTOS DEL NEGOCIO Para cada asunto se debe capturar la siguiente inform ación:
N úm ero de seguim iento: F re cu en tem en te se u sa un n ú m e ro secuencia!. E ste n ú m e ro sirv e co m o cl id e n tifica d o r único del asunto.
Título: E l título del asunto deberá ser una frase corla que proporcione el significa do esencial del asunto, frecuentem ente planteada com o pregunta (por ejem plo, “¿D eberá consolidarse la facturación en las oficinas centrales?” , o “¿querrán los agentes de ventas obtener sus propios reportes de com isiones en línea en vez de re cibirlos en papel por correo?”). A u to r: E l autor es el nom bre del m iem bro del equipo del proyecto que descubrió el asunto. Por lo general es el analista. F e c h a d e d e s c u b rim ie n to : lis la fecha en que se descubrió el asunto.
Descripción: lil asunto deberá explicarse detalladam ente para que no se requiera ninguna otra investigación y para com prender la naturaleza del problem a. Prefiero estructurar la descripción del asunto de la siguiente manera:
Antecedentes: Son cl contexto de] problem a. Es seguro suponer que el lector está fam iliarizado con el negocio, pero tal vez no tenga la m ism a profundidad de detalle que el analista que ha estado inm erso en un área de tem a particular. Incluya una breve sinopsis del área funcional del negocio en donde exista el problem a y la parte de la aplicación afectada. P ro b le m a : Indique el problem a en térm inos claros y concisos.
Impacto: Indique el im pacto de no hacer nada. Si se perm ite que el problem a continúe, cuál será el resultado para el proyecto y para el negocio.
Opciones y recomendaciones de solución: A m uchas personas no Ies gusto tom ar decisiones. El escoger alternativas es m ás fácil. E s m uy probable que el analista ya sepa lo que debe hacerse y sim plem ente necesite aprobación de una autoridad superior para realizar el cam bio. Si hay varias opciones, valore los pros y contras de cada una. Incluya una recom endación si tiene una o pi nión de la que está convencido. A sig n ad o a: N om bre al equipo o individuo del negocio a quien ha sido asignado el asunto para su resoiución.
i echa de asignación: R egistre la fecha en que el asunto se pasó al equipo de reso lución.
Resolución: D ocum ente la decisión tom ada por el equipo de resolución. t e c h a d e reso lu c ió n : Registre la fecha en que el equipo del proyecto recibió la re solución. R e su e lto p o r: A veces cl asunto será resuelto por una autoridad superior a aquella a quien se le asignó, lis útil registrar si tom aron la decisión los em pleados de línea o c¡ presidente de la com pañía.
194
Capítulo 7 / DAR LOS TOQUES FINALES A LA FASE DE ANÁLISIS
Tal vez experim ente un sentimiento de que ya lo ha visto cuando se trata de la descrip ción del asunto. El enunciado del problem a, el impacto de no hacer nada y la presentación de opciones de solución salen directas del marco de trabajo de tom a de decisiones que se presentó en el capítulo del plan general. De hccho, el analista puede enfatizar su recom endación me diante la evaluación de opciones de solución con hase en los criterios establecidos en el plan general, en particular la habilidad para satisfacer los objetivos del proyecto y el costo y apli cación de los vectores de calidad. U na de las primeras cosas que pregunto cuando me uno a un proyecto es la lista de asun tos. En las prim eras etapas de análisis, un proyecto saludable tendrá una gran veta de asuntos sin resolver. ¡Esto es bueno! Significa que los analistas andan por ahí haciendo preguntas. Si se tuviera que registrar la cantidad de asuntos no resueltos durante cl tiem po que dura el provecto, la gráfica debería ser sim ilar a la figura 7-2,
del proyccto
Figura 7-2, AsumiiK no resueltos pendientes.
En el prim er día del proyecto la cantidad de asuntos no resueltos es cero. N adie ha hccho todavía preguntas. Conform e los analistas avanzan y analizan deberán presentarse gran canti dad de preguntas que se escriben com o asuntos no resueltos, Kn un proyccto saludable la can tidad de asuntos no resueltos se elevará rápidamente. Conform e el gerente del proyecto guía a los asuntos no resueltos a través de] proceso de resolución, la cantidad de asuntos resueltos deberá com enzar a sobrepasar a la de los no resuellos. Eventualm ente la cantidad de asuntos no resueltos deberá caer conform e el negocio logra una visión com ún sobre la m anera en que operará su nuevo mundo. La parte medular dei trabajo de un analista es hacer preguntas, escribir esas preguntas, ir a buscar las respuestas y escribir las respuestas. I..as respuestas generarán más preguntas y cada una de ellas se escribirá. El objetivo es llegar tan rápido com o sea posible de un estado de profunda ignorancia a un estado de sim ple ignorancia (figura 7-3).
RESUMEN DE LOS PRODUCTOS DEL ANÁLISIS
195
Figura 7-3. Moviéndose de un estado de profunda ignorancia a uno de ignorancia simple.
Cuando se está en un estado de profunda ignorancia no se sabe qué no se sabe. En un estado de ignorancia simple se sabe lo que no se sabe. Dicho más claro, no se puede manejar un estado de profunda ignorancia debido a que se está com pletam ente ciego ante los asuntos que se pueden presentar. Un gerente que está en estado de profunda ignorancia liega a trabajar cada día para encontrar bombas explotando por todos lados del proyecto. Un gerente en un estado de ignorancia simple tiene una lista de los asuntos principales que han sido descubier tos y puede adm inistrarse con esa lista. Puede estim ar que tanto avance está im pedido y desa rrollar un plan para resolver los asuntos. La lista de asuntos resueltos llega a ser un docum ento im portante para la fase de entre nam iento c imple me litación dcl sistema. Los cam bios hechos en la política y procedim ientos del negocio reflejan la diferencia entre las formas antigua y nueva de hacer negocios. La lista de asuntos proporciona un medio del proyecto para recordar porqué se hicieron las cosas en la forma en que se hicieron y quienes estuvieron involucrados en las decisiones, lis probablemente un buen tiempo para com enzar a diseñar cualquier pane del sistema en donde los modelos de análisis están llegando a su térm ino y los asuntos resueltos están claram ente sobrepasando a los no resueltos.
RESUMEN DE LOS PRODUCTOS DEL ANÁLISIS El propósito del análisis es definir los requerim ientos esenciales del usuario referentes a nego cios. Es un paso crítico para com prender las necesidades del negocio antes de diseñar solu ciones técnicas. La fase de análisis de un sistem a cliente/servidor GUI incluye las siguientes actividades.
196
Capítulo 7 / DAR LOS TOQUES FINALES A LA FASE DE ANÁLISIS
Establecer un p la n g en e ral para el negocio, el cual articula las metas y objetivos; del proyecto en térm inos claros, concisos y m ensurables. Hay que asegurarse que am bas partes hayan logrado el consenso sobre los objetivos y que se hayan puesto de acuerdo por escrito en sus papeles y requerim ientos de desem peño respectivos. Además, definir el alcance del área de estudio por medio de la creación de un modelo de contexto y la cual se valida con la base de usuarios adecuada. Definir los eventos ante los cuales debe responder el sistema, corno está establecido en el plan general. Los eventos se escriben en la lista de eventos y se definen detalladam ente en el diccionario de eventos, Para cada evento, el diccionario de eventos incluye el significado del evento, los datos de estím ulo requeridos para iniciar el evento, la actividad a realizar para for mular la respuesta adecuada y los datos de respuesta que son esperados por los usuarios. K1 efecto de cada evento se docum enta para llevar cuenta de lo que el sistem a está tratando de lo grar en el mundo real. Crear un m odelo d e in fo rm ació n , el cual com prende todos los elem entos de datos que se planea que el sistem a debe recordar. lil modelo de inform ación no respeta las fronteras del proyecto y, por lo tanto, se requiere un fuerte sentido del alcance para determ inar cuáles son los datos relevantes, lil modelo de inform ación puede construirse en form a progresiva defi niendo ios datos requeridos para cada estím ulo y respuesta de cada evento. Poner una cara al sistema creando un prototipo de interfaz. El objetivo prim ario del es fuerzo de creación de prototipos en las etapas de análisis de un proyecto es derivar y validar los requerim ientos del sistema esenciales m ientras se dejan abiertas las opciones de implementació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
8
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
Kigur;] S-2. U n a arquitectura cliente/servidor de tres niveles.
Figura 8-3. Una arquitectura cliente/servidor de n niveles.
Servidor central
206
Capítulo 8 / EL MODELO ARQUITECTÓNICO
I a arquitectura de n niveles está llegando rápidam ente a ser la norma en la mayoría de las organizaciones, conform e las redes de área local, las redes de área am plia, Internet y World Wide Web están entrelazadas. La distinción entre cliente puro y servidor puro casi se elimina en tales am bientes, haciendo que cliente/servidor sea más un patrón conceptual que es aplica do a cada transacción al m om ento de su ejecución. Para efectos de sim plificación, gran paite de este capítulo supondrá una arquitectura cliente/servidor de dos niveles, en donde varios clientes PC hacen peticiones a un servidor de datos central, listo nos permitirá explorar algunas de las características más com unes y funda m entales del am biente cliente/servidor sin ponernos quisquillosos sobre Ja term inología.
CAPAS DE SOFTWARE CLIENTE/SERVIDOR Para tratar el despliegue del softw are a través de una arquitectura de hardw'are de varios n iv e les prim ero debem os separar la aplicación de softw are en sus capas. H1 in terio r de la apli cación del negocio puede ser agrupado en al menos tres categorías principales, la capa de presentación, ta capa lógica del negocio y la capa de adm inistración de dalos,- La figura 8-4 m uestra un evento de negocios conform e pasa a través de las tres capas de una aplicación de software.
Capa de presentación
Capa Iónica de! negocio
F ig u ra 8-4. C apas de softw are.
t 'liando se dcspliep.E uní ¿aplicación a irn vas d¿; varios ni velos da hardware, aparece una cuarta capa de soft ware, que maiicía las comunicaciones de máquina a máquina.
CUENTE PESADO, SERVIDOR PESADO
207
La ca p a de p re se n ta c ió n se encuentra en el borde del sistem a de software. Su trabajo es capturar los estím ulos de eventos externos y realizar algún grado de edición sobre los datos en trantes. También está encargada de la presentación de la respuesta del evento hacia el mundo exterior. Ll softw are de presentación casi siempre se encuentra en una m áquina cliente, tal co mo una PC. pera ésta no es una regla estricta. Las PCs pueden utilizarse para em ular pantallas de maiiiCrame con muy poca lógica de presentación residiendo en el cliente. Hl paradigm a del lenguaje de la capa de presentación está cada vez más orientado a objetos. El am biente de ven tanas de la mayoría de los sistemas operativos cliente tiende por sí mismo en form a natural a las estructuras de objetos. L a c a p a lógica del negocio contiene el código que ejecuta y hace cum plir las políticas del negocio. Las reglas y las regulaciones, así com o los cálculos internos, se encuentran en la capa lógica del negocio. Hl softw are que ejecuta la lógica del negocio es la capa m ás cam bian te. Puede encontrarse en los clientes remotos, en el servidor central o en cualquier otro lugar intermedio. M uchos de los pros y contras presentados en este capítulo se enfocan sobre la ubi cación de esta capa de la aplicación. A l m om ento de escribir esto, eí paradigm a del lenguaje para la capa de negocios es un revoltijo. La tendencia es un m ovim iento hacia las estructuras orientadas'a objetos. El grado de orientación a objetos em pleado en la capa lógica del negocio es altam ente dependiente del lenguaje seleccionado o de la herram ienta de desarrollo. Hs com pletam ente posible tener com ponentes 3GL, 4GL y objetos m ezclados dentro de la m ism a apli cación. La capa d e administración de datos proporciona acceso a ios dalos corporativos. M a neja las peticiones sim ultáneas de lectura y escritura a la base de datos, así com o la sincroni zación de los elem entos de datos distribuidos. Gran parte de la capa de adm inistración de datos seguirá a la ubicación física de los datos. La decisión de distribuir o centralizar la base de da tos determ inará gran parte de la ubicación de la capa de adm inistración de datos. Para la ma yoría de los sistemas de negocios el paradigm a de base de datos es la base de datos relacional. La m ayoría de los datos recopilados por los negocios se ajusta perfectam ente al formato de co lumnas y renglones del paradigm a relacional. Los proveedores de bases de datos relaciónales tam bién están respondiendo a la presión de extender sus bases de datos para que m anejen d a tos no estructurados, tales com o los de m ultim edia, sonido, video y objetos de hipertexto.
CLIENTE PESADO, SERVIDOR PESADO H a aparecido un térm ino en cierta forma políticam ente incvrn-cUj que se utiliza para definir la filosofía de una aplicación en relación al lugar en donde se encuentra la parte más grande de la capa lógica de negocios de la aplicación. Cliente pesado (servidor delgado) significa que la parte im portante del softw are se ejecuta en la m áquina cliente, y el servidor eslá relegado a dar los dalos com o esclavo cuando se los soliciten y regresarlos a la base de datos cuando cl clien te se lo instruye. Servidor pesado (cliente delgado) describe una asignación de tareas en donde el cliente está restringido a la presentación de la interfaz y a una edición mínima, mientras que la mayor parte de la lógica del negocio para cl cum plim iento de las reglas se ejecuta en el servidor cen tral. Por supuesto, ésta es una vista excesivam ente sim plificada del mundo, debido a que las arquitecturas clientc/servidor de n niveles pueden soportar capas de software muy com plejas con depósitos pesados por toda la red, pero el térm ino nos ayuda a reconocer las tendencias fi losóficas de un lenguaje de program ación particular.
208
C apítulos ! EL MODELO ARQUITECTÓNICO
La prim era generación de m uchas herram ientas J e desarrollo el iente/servidor GUI popu lares asum ieron una arquitectura de softw are de dos niveles cuando se desarrollaron por pri mera vez. Las prim eras versiones de paquetes tales com o Pow erB uilder3 , y Visual Basic®, m otivaron un enfoque de cliente com pletam ente pesado (figura 8-5). La lógica del negocio es taba íntim am ente atada a la capa de presentación de ¡a aplicación. M ediante la introducción de conceptos orientados a objetos, tales com o la herencia (que se trata en el capítulo 12), muchas de estas herram ientas han sido muy buenas para la explotación de la reutilización de estructu ras de objetos, los cuales adm inistran la presentación de la interfaz.
Figura 8-5. El enfoque de d ie n te pesado.
Respondiendo a las demandas del m ercado sobre lenguajes de desarrollo más flexibles, las herram ientas de desarrollo GIJ1 de segunda generación reconocen la necesidad de separar a la presentación de la lógica del negocio. Hsra división proporciona varias ventajas, reusabiiidad, portabüidad y m antenibüidad. I .a razón más am pliam ente prom ovida es la reusabilidad. I .as clases de presentación son extrem adam ente fáciles de reut.ilizar debido a que son muy me cánicas por naturaleza.’ Por otro lado, las clases de negocios, son muy com plejas. U na clase de negocios, tal com o diente, representa muchos papeles diferentes dentro de la organización. Fil objetivo es crear clases que hagan cum plir todas las reglas del negocio para una clase de nego cio particular, \ que también sean capaces de rcutilizar el código en cualquier lugar de la apli cación que tenga que ver con la clasc. Para lograr código reutilizablc en esta capa se requiere un alto grado de disciplina de ingeniería de software. Aquí se usa la palabra duse para significar una dase dt: objetos en un sistema orientado a objetos.
CUENTE Y SERVIDOR PESADOS
209
Ua purlabilidad es una segunda razón im periosa para separar el código que maneja la pre sentación del código que ejecuta la lógica del negocio. U na vez que es dividido de la interfaz, el código de la lógica del negocio puede ser reubicado en diversos niveles de la arquitectura cliente/servidor para lograr un desem peño óptim o. La habilidad para mover la lógica del nego cio p o r la arquitectura cliente/servidor perm ite que el negocio aproveche las mejoras en velo cidad de procesam iento de m áquinas particulares y com plem ente la arquitectura de hardw are con un com ponente más rápido sin tener que volver a escribir grandes secciones de la aplica ción (figura 8-6).
Figura 8-6. L;t lógica, de negocios trasladada, del cliente a un servidor de archivos. Una tercera razón para acorralar la lógica del negocio en su propio conjunto de clases es tratar de m antener las reglas del negocio en un lugar en vez de tenerlas desperdigadas por to da la interfaz. La gran ventaja de esta estrategia es la reducción del efecto de propagación de onda al hacer cam bios de m antenim iento y mejoras al sistema. La tendencia en los lenguajes de desarrollo es perm itir que el proyecto balancee las de m andas de la aplicación contra la arquitectura de hardware. K1 que la disposición resultante se asemeje a un cliente pesado o a un servidor pesado deberá ser producto de decisiones de inge niería bien fundam entadas basadas en los vectores de calidad del proyecto, y no en un resulta do de las restricciones del lenguaje de desarrollo seleccionado. E s im portante reconocer las tendencias del lenguaje de desarrollo seleccionado y asegurarse de que se ajusten a las necesi dades de los requerim ientos esenciales.
210
Capítulo 8 / EL MODELO ARQUITECTÓNICO
RECOPILACIÓN DE ESTADÍSTICAS Y RESTRICCIONES Determ inar la arquitectura correcta para el sistem a involucra el dim ensionam iento de la capaci dad de cóm puto para el problem a. Los modelos de análisis esenciales proporcionan un marco de trabajo confiable para la estimación de los requerim ientos de cóm puto del sistema terminado. El prim er acto del modelado arquitectónico es llenar ese marco de trabajo contabilizando cosas.
Recopilación de estadísticas para el modelo de información Se requieren dos tipos de inform ación esenciales para estim ar el tam año de una base de datos, el tam año de las colum nas y la cantidad de renglones estim ados que se acumularán a través del tiempo, listos son núm eros relativam ente simples de obtener. Para determ inar el tam año de las colum nas de datos se hace referencia al tipo de dato que ya ha sido registrado para cada atri buto. Sim plem ente se sum a la cantidad de bytes de cada atributo de la entidad y luego se aña de la cantidad de bytes de la clave prim aria y de las claves externas im plicadas en las relaciones. (Tratarem os la traducción del m odelo de inform ación hacia una base de datos reíacional 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 relaeional 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é tanios conceptos solicita el cliente por pedido puede decir “uno", debido a que es todo lo (f„e aceptará el sistema antiguo.
212
Capítulo 8 / EL MODELO ARQUITECTÓNICO
Recopilación de estadísticas para el modelo de eventos El sistem a es bom bardeado constantem ente con eventos de negocios. A lgunos eventos son m u cho más críticos que otros, por lo que la habilidad del sistem a para responder rápidam ente es de sum a importancia. El m odelo de eventos puede ser com entado con estadísticas qu e captu ran la tasa del evento y el tiem po de respuesta deseado p ara el evento. Ú n poco de sentido com ún puede ayudar mucho en térm inos de qué tantas estadísticas se pone uno a recolectar. Los eventos que afectan las transacciones principales del negocio son los más críticos. Eventos tales com o el cliente coloca p ed id o, el pasajero reserva boleto de avión, es tiempo p ara fa ctu ra r pedido, el tren se acerca a la estación, el cliente solicita ei es tado del pedido, el corredor coloca pedido de com pra de acciones, el dem andante presenta d e m anda civil, son el pan nuestro de cada día de sus respectivos negocios. Si un evento, tal com o la com pañía transportista cam bia de dirección, sucede casi cada dos años en el área, probablem ente no necesite un escrutinio intenso. Se puede establecer un conjunto genérico de pruebas de desem peño para la m ayoría de los eventos m undanos que sim plem ente actualizan tablas de control. Para los principales eventos de transacciones de negocios del sistem a se necesita reco lectar la tasa prom edio del evento, la tasa pico y el periodo de tiem po pico. Tomemos un ejem plo de la Joe-Joe’s Pizza D elivery Company, joe-Joe entrega pizzas desde varias cocinas que están distribuidas a través de una gran área m etropolitana. Para pedir una pizza los clientes lla man a un núm ero telefónico central. Los pedidos de pizza son despachados autom áticam ente a la cocina que está m ás cercana al cliente para asegurar que se entregue un a pizza caliente a tiempo en su puerta. joe-Jo e se ha hecho una reputación por su buena com ida y su fantástico servicio. E l se senta por ciento de los clientes de Joe-Joe son clientes iterativos, y ese porcentaje está aum en tando. La m ayoría llam a desde su casa o desde sus teléfonos de autom óvil, por lo que ha instalado softw are de identificación de llam adas para buscar en ¡a base de datos el perfil del cliente m ientras se recibe la llam ada. Para cuando la persona que atiende el servicio a clientes tom a la llam ada, ya se tiene en pantalla el perfil de consum o de pizza anterior de quien llama. Joe-Joe está considerando el perm itir que los clientes coloquen pedidos directam ente desde sus com putadoras caseras vía Internet. E l evento de negocios más significativo de Joe-Joe es el cliente coloca p edido de pizza. En el caso de Joe-Joe, vende un prom edio de 875 pizzas diarias entre las diez de la m añana y las dos de la m añana del siguiente día. Es bastante fácil hacer los cálculos y determ inar que la tasa de eventos prom edio es de cerca de 55 pizzas por hora. Se lleva aproxim adam ente dos m i nutos el que un cliente haga un pedido de pizza. Con un nuevo pedido viniendo a cada m inu to, uno puede extrapolar que Joe-Joe necesita un sistem a capaz de responder tres llamadas telefónicas sim ultáneam ente (una entrando, otra a medias y otra colgando). ¿Pero que no hay algo m alo en esto? [Un sistem a tan mal concebido probablem ente pondrá a Joe-Joe fuera del negocio en m enos de un mes!
Tasas de evento irregulares Las tasas de evento prom edio sólo pueden decir el nivel norm al de un evento. También necesi tam os conocer las tasas pico. Como tal vez sospechó, los clientes de Joe-Joe no piden sus piz zas en un patrón uniform e desde la m añana hasta la noche. H ay muy poca actividad antes de las 11:30 a.m., y luego hay un gran pico conform e la gente se dispone a tom ar su alm uerzo en
RECOPILACIÓN DE ESTADÍSTICAS Y RESTRICCIONES
213
la ciudad (figura 8-8). Hl negocio se cae después de la 1:30 p.m., luego se acelera rápidamente a las cinco de la tarde y luego desciende después de las nueve de la noche. Para com plicar las cosas, el patrón de pedidos varía en viernes, sábado y dom ingo. En la tarde del viernes el pico dura mucho más en la noche, y lo mismo sucede el sábado. El sábado y el dom ingo tienen pi cos de almuerzo mucho m ás pequeños, pero un negocio m ás constante a lo laigo de la tarde.
Figura 8-8, Patrón de tasa de eventos para el cliente coloca pedido de pizza.
Dimensionamiento dei sistema para la tasa pico Joe-Joe tiene un dilem a arquitectónico crítico, ¿D eberá el tam año del sistem a ser capaz de m a nejar su tasa pie o más alta para que ningún cliente obtenga una señal de ocupado o se duerm a en la e sp e ra ! Si se dim ensiona para la capacidad pico se tendrá capacidad ociosa desperdicia da gran parte d d día. Si se dim ensiona el sistem a para m enos que la capacidad pico se tendrán d ie n tes que irán con la com petencia para conseguir su cena. Estas decisiones no son fáciles y no debe tom arlas la IT sola. El ejem plo de Joe-Joe's Piz za ilustra un patrón de eventos irregular en donde el d ie n te es un actor principal. Si cl sistema no puede m anejar los picos se afectará al cliente. A menos de que el eosto sea prohihitivo la m ayoría de las organizaciones prefiere gastar dinero para dim ensional el sistem a cercano al pi co para evitar incom odidades o pérdidas de clientes.
Mueva el pico A lgunas com pañías han inventado soluciones creativas para tratar de alisar cl pico de algunas tasas de eventos. A lgunos corredores de acciones cobran una com isión m ás alta a sus d ien tes para operar sus ordenes de acciones en la cola de prioridad durante las horas pico. Los clien tes que no quieren pagar el costo adicional perm iten que espere su transacción en la cola ñor-
212
Capítulo 8 / EL MODELO ARQUITECTÓNICO
Recopilación de estadísticas para el modelo de eventos El sistem a es bom bardeado constantem ente con eventos de negocios. Algunos eventos son m u cho más críticos que otros, por ío que la habilidad del sistem a para responder rápidam ente es de sum a importancia. El modelo de eventos puede ser com entado con estadísticas que captu ran la tasa del evento y el tiem po de respuesta deseado para cl evento. Un poco de sentido com ún puede ayudar m ucho en térm inos de qué tantas estadísticas se pone uno a recolectar. J ,os eventos que afectan las transacciones principales del negocio son los más críticos. Eventos tales com o el cliente coloca pedido, el pasajero reserva boleto de avión, es tiempo para fa ctu ra r pedido, el tren se acerca a la estación, el cliente solicita el es tado del pedido, el corredor coloca pedido de com pra de acciones, el dem andante presenta d e manda civil, son el pan nuestro de cada día de sus respectivos negocios. Si un evento, tal com o la com pañía transportista cam bia de dirección, sucede casi cada dos años en el área, probablem ente no necesite un escrutinio intenso. Se puede establecer un conjunto genérico de pruebas de desem peño para la m ayoría de los eventos m undanos que sim plem ente actualizan tablas de control. Para los principales eventos de transacciones de negocios del sistem a se necesita reco lectar la tasa prom edio del evento, la tasa pico y el periodo de tiem po pico. Tomemos un ejem plo de la Joe Joe’s Pizza D elivery Com pan y. Joe-Joe entrega pizzas desde varias cocinas que están distribuidas a través de una gran área m etropolitana. Para pedir un a pizza los clientes lla m an a un núm ero telefónico central. Los pedidos de pizza son despachados autom áticam ente a la cocina que está más cercana al cliente para asegurar que se entregue una pizza caliente a tiempo en su puerta. Joe-Joe se ha hecho una reputación por su buena com ida y su fantástico servicia. El se senta por ciento de los clientes de Joe-Joe son clientes iterativos, y ese porcentaje está aum en tando. L a m ayoría llama desde su casa o desde sus teléfonos de autom óvil, por lo que ha instalado softw are de identificación de llam adas para buscar en la base de datos el perfil del cliente m ientras se recibe la llamada. Para cuando la persona que atiende el servicio a clientes tom a la llamada, ya se tiene en pantalla el perfil de consum o de pizza anterior de quien llama. Joe-Joe está considerando el perm itir que los clientes coloquen pedidos directam ente desde sus com putadoras caseras vía Internet. El evento de negocios más significativo de Joe-Joe es el cliente coloca p edido de pizza. En cl caso de Joc-.Ioe, vende un prom edio de 875 pizzas diarias entre las diez de la m añana y las dos de la m añana del siguiente día. Es bastante fácil hacer los cálculos y determ inar que la tasa de eventos prom edio es de cerca de 55 pizzas por hora. Se lleva aproxim adam ente dos m i nutos el que un cliente haga un pedido de pizza. Con un nuevo pedido viniendo a cada m inu to, uno puede extrapolar que Joe-Joe necesita un sistem a capaz de responder tres llamadas telefónicas sim ultáneam ente (una entrando, otra a medias y otra colgando). ¿Pero que no hay algo m alo en esto? ¡l'n sistem a tan mal concebido probablem ente pondrá a Joe-Joe fuera del negocio en menos de un mes!
Tasas de evento irregulares Las tasas de evento prom edio sólo pueden decir cl nivel normal de un evento. También necesi tamos conocer las lasas pico. Com o tal vez sospechó, los clientes de Joe-Joe no piden sus piz zas en un patrón uniform e desde la m añana hasta la noche. Hay muy poca actividad antes de las 11:30 a.m., y luego hay un gran pico conform e la gente se dispone a tomar su alm uerzo en
RECOPILACIÓN DE ESTADÍSTICAS Y RESTRICCIONES
213
la ciudad (figura 8-8). El negocio se cae después de la 1:30 p.m., luego se acelera rápidam ente a las cinco de la tarde y luego desciende después de las nueve de la noche. Para com plicar las cosas, el patrón de pedidos varía en viernes, sábado y domingo, Bn la tarde del viernes el pico dura m ucho m ás en la noche, y lo mismo sucede cl sabado. El sábado y el dom ingo tienen pi cos de almuerzo mucho más pequeños, pero un negocio más constante a lo largo de la tarde.
F ig u r a 8-8. Patrón de tasa de eventos para el cliente coloca pedido de pizza.
Dimensionamiento del sistema para la tasa pico Joe-Joc tiene un dilema arquitectónico crítico. ¿D eberá el tam año del sistem a ser capaz de m a nejar su tasa pico más alta para que ningún cliente obtenga una señal de ocupado o se duerma en la espera? Si se dim ensiona para la capacidad pico se tendrá capacidad ociosa desperdicia da gran parte del día. Si se dim ensiona cl sistem a para m enos que la capacidad pico se tendrán clientes que irán con la com petencia para conseguir su cena. Estas decisiones no son fáciles y no debe tom arlas la [T sola. El ejemplo de Joe-Joe's Piz za ilustra un patrón de eventos irregular en donde el cliente es un actor principal. Si el sistema no puede m anejar los picos se afectara al cliente. A m enos de que el costo sea prohibitivo, la m ayoría de las organizaciones prefiere gastar dinero para dim ensionar el sistema cercano al pi co para evitar incom odidades o pérdidas de clientes.
Mueva el pico A lgunas com pañías han inventado soluciones creativas para tratar de alisar el pico de algunas tasas de eventos. A lgunos corredores de acciones cobran una com isión m ás alta a sus clientes para operar sus órdenes de acciones en la cola de prioridad durante las horas pico. Los clien tes que no quieren pagar el costo adicional perm iten que espere su transacción en la cola ñor-
214
C apítulos / EL MODELO ARQUITECTÓNICO
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 icspucsta 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. Miami 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.
EL
MODELO ARQUITECTÓNICO
a
c 4J >-
oí UJ 'o
c ^ aj £ ü >
J y stu
u_
cü
£ Líi
E
ra
= cc en 03 T3 c
i
c ca c
c
a> cj
O 2
c o >
>
c >
El cliente coloca pedido
X
X
X
X
El departamento de crédito aprueba pedido
X
El departamento de produr.ción asigna pedido a la planta
X
Evento/ubicación del negocio
1 Planta de California
C apítulos /
216
La planta llena el pedido del diente
X
La planta envía el pedido del cliente
X
Contabilidad factura el pedido del cliente
X
Mercadotecnia envia el catálogo por correo
X
ca c
"5 ca U O T3 ti -^ -2 z
JE a> ü_ T5
X
x
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 enliaad atributiva que forman al cliente. Hi proyecto puede escoger si crea matrices usando tipos de entidades discreüis del modelo de inform adún o las agrega en objetos conceptuales, si es que son usados por cl even to como una unidad lógica.
DETERMINACIÓN DE LOS REQUERIMIENTOS DE DISTRIBUCIÓN
217
RU
RU
CRUD
CRUD
RU
ñu
R
El departam ento de producción asigna pedido
R
R
R
La planta llena el pedido del cliente
R
R
R
La planta envía el pedido del cliente
R
R
R
Contabilidad factura el pedido del cliente
ñ
R
Rü
fi
RU
Mercadotecnia envía el catálogo por correo
R
Cliente
C
RU
Concepto de factura
CR
C
U
El cliente coloca pedido
Factura
Transacciones de inventario de productos terminados CR
CRU
El departam ento de crédito aprueba pedido
Evento/entidad
Transacciones de inventario de materias primas
Concepto de pedido de planta C
Concepto de pedido
C
Pedido
Pedido de planta
j
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.
CRU
CRU
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 potenciajes. Antes de que encerremos a los fanáticos de la centralización de datos y a los fanáticos de la distribución de ciatos en un cuarto para que se griten entre ellos, unas cuantas estadísticas pueden ayudar para que cada facción defienda su caso. Cada negocio tendrá patrones de utilización diferentes para su sistema. Esta es la razón por la que no hay una arquitectura umversalmente “correcta”. La solución arquitectónica que emer ge para nuestro ejemplo de la Nihilist Toy Company es adecuada para ellos sólo por que toma en cuenta su distribución geográfica única, los voiúmenes de datos y las tasas de eventos. A n tes de discutir los pros y contras de las soluciones centralizadas contra las descentralizadas en contremos unas cuantas cosas más acerca de nuestro proveedor de juguetes finos.
218
Capítulo 8 / EL MODELO ARQUITECTÓNICO
Figura 8-11. Matriz CRUD ubicación de negocio/enLidad. La matriz de la figura 8-12 muestra la intersección entre eventos y entidades. Pero en vez de indicar creación, lectura, actualización o borrado en las celdas, se inserta un número para mostrar qué tan actuales deben ser los dalos para el evento. Para aquellas entidades que son creadas o actualizadas por el evento, un cero indica que la base de datos debe reflejar instan táneamente la actualización más reciente. Para las entidades que son leídas por el evento el nu mero puede ser mayor que cero, indicando que es aceptable que ios datos sean ligeramente más viejos. Una matriz de actualidad puede llevar a malas interpretaciones, y en realidad requiere de algunos comentarios previos antes de que tenga sentido para el lector. En este ejemplo hemos descubierto que aunque el departamento de producción lee la di rección de envío del cliente en el proceso de asignación de pedidos a las plantas, no le preocu pa si la dirección es correcta al cien por ciento. (¿1 razonamiento de producción es que la dirección de envío rara vez cambia tan dramáticamente para que se afecte la producción de un pedido de cliente en una costa de los Estados Unidos en vez de la otra. El negocio también nos ha informado que la dirección de envío tiene un papel pequeño en la asignación de pedidos a las plañías, y que frecuentemente el pedido de un cliente puede ser dividido con partes fabri cadas en ambas plantas. Una vez que la planta ha recibido el pedido de planta , los cambios subsecuentes que se hagan al pedido o al concepto de pedido no son inmediatamente relevantes. Los clientes rara vez cancelan pedidos después de que han sido programados para producción. Si un cliente can cela un pedido en el último momento, los gerentes de la planta han encontrado que menos cos toso dejar que la producción del día se realice como estaba programada y colocar el producto en el inventario de bienes terminados es más costeablc que interrumpir la producción. Por lo tanto, necesitan pedidos de planta al día, pero el pedido principal del cliente puede tener un día de antigüedad.
219
24
0
0
de factura
f í
& i s
V.
Concepto
0
i:
Factura
0
Transacciones de in ventario de materias prim as
0
Transacciones de in ve n ta rio de productos te rm in ad o s
0
Concepto de pedido de pfanta
0
de planta
0
Pedido
Concepto
El d ie n to coloca pedido
P edido
E vento/entidad
C liente
de pedido
DETERMINACIÓN DE LOS REQUERIMIENTOS DE DISTRIBUCIÓN
1
i £
El d e p a rtam e n to de crédito aprueba pedido El departam ento de producción asigna pedido
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 0
deí cliente Contabilidad factura el pedido del cliente
0
24 0
24 0
0 0
i
0 0
H0
0
ñ i
M ercadotecnia envia
ñ
48
el catalogo po r correo 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 enlo 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.
0
0
0
0
Ventas en M ia m i, FU
0
0
0
Ventas en Londres, RU
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
0
0
de factura
0
Concepto
0
0
Factura
Transacciones de in ventario de materias prim as
de in ventario
Concepto
de productos term in ad o s
Pedido de planta
0
Ventas en Boise, ID
Transacciones
Concepto
Oficiña central en Nueva York, NY
Ubicación de negocio/entidad
Cliente
Pedido
de pedido de planta
Capítulo 8 / EL MODELO ARQUITECTÓNICO
de pedido
220
0
0
0
0
F igura 8-13. Matriz de actualidad ubicación de negocio/entidad.
Dirección
Límite de crédito
Crédito
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
Oficina central en N ueva York, N Y
Figura 8-14. Matriz CRUD ubicación de negocio/atributo del cliente.
disponible
Dirección de com pra
CRU
atributos del cliente
de envío Dirección
CRU
Ubicación d e negocio/
ID de cliente
Nombre del cliente
de facturación
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.
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.
C apítulo 8 / EL MODELO ARQUITECTÓNICO
222
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.
C apítulos / EL MODELO ARQUITECTÓNICO
224
CLIENTE: - base de datos A ID d e l
U) co c E 2
r *
Red
H o r a d e ú lti-
f e r r o v ia r i a
m a d e sc a rg a
N o m b r e d e l c lie n t e
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
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
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
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
B c
L ím i t e d e c r é d it o
c lie n t e
L
tu c C L I E N T E - b< s e d e d a t o s B c É
N ú m e ro
ID d e l
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
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
N 2341
H e rb T e m k e y
55 5 -4 6 1 2
c lie n t e
;> ■H 2 4 3 2
S e te p u e e fe e n c o n t r a r
|
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 c lie n t e
c T> j’ i 05 C a;
N o m b r e d e l c lie n t e
L im i t e
Red
de c ré d ito
f e r r o v ia r i a
H o r a d e ú lt i 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
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
G2412
S a l ' s M a n ila
F a rm
$ 1 2 0 ,0 0 0
N
1 7 :0 0
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
Chidten
-
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-
C apítulos / EL MODELO ARQUITECTÓNICO
226 CLIENTE
base de dates A
ID d e l d ie n t e "
N o m b r e d e l s íie n t e
L ím i t e
Red
d e c r é d it o
te r r o v la r l a
H o r a d e ú lt i 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 N ú m e ro
ID d e i c lie n t e -
N a m b r e d e l c lie n t e
C o n ta c to d e m e r c a d o te c n ia
t e le f ó n i c o
H 2432
C u r t a in Ir o n W o r k s , L td .
B ill D u n la p
5 5 5 6541
B6547
A u s tln T o x Ic W a ste
B u d F a rn w o rth
5 5 5 -1 1 4 4
E2334
B a r r y 's G o ld W a t e r C o .
N a n c y N a n p lt h
5 5 6 -4 2 3 1
N2341
D a y G l o N u c l e a r F a c l l it le s
H e rb T e m k e y
5 5 5-461 2
Figura 8-19. Fragme n t ac i ó i¡ m ezc 1ada. term inación de los requerim ientos de disco, ya que. cuando los dalos están distribuidos física mente. el tam año del registro y las tasas de eventos le perm itirán estim ar el tráfico de red. Las estadísticas capturadas para el modelo de eventos incluyen la tasa promedio del evento, los p a trones de tasas pico para tasas de eventos irregulares y las expectativas de tiempo de respues ta para el evento. A rm ados can estas estadísticas, el siguiente paso es aplicarlas a la topología del sitio del negocio. Varias matrices han probado ser útiles para el modelado de este aspecto del sistema. La m atriz de evento/ubicación de negocios mapea a ios eventos en la ubicación de negocios en donde son reconocidos. La m atriz CRUD evento/entidad, derivada de la sección de análisis del diccionario de eventos, suma riza los requerim ientos de acceso de datos para cada evento. La matriz CRUD de ubicación de negocios/entidad es una matriz derivada que muestra cuáles u bi caciones de negocios requieren cuál tipo de acceso de dalos, con base en el hecho de que even tos específicos han sido asignados a esos sitios, listas son las matrices más útiles e importantes para la declaración de la distribución de eventos y la derivación de los requerim ientos de d is tribución de dalos. U na vez que han sido determ inados los requerim ientos de acceso de datos dei negocio, inform ación adicional ayudará para que el equipo del proyecto tome buenas decisiones arqui tectónicas. La matriz de actualidad de evento/entidad y la m atriz de actualidad de ubicación de negocios/entidad m uestran que tan "vieja” puede ser una entidad para cualquier evento y ubi cación de negocios dados. Esto puede ayudar a decidir si se necesita la sincronización en tiem po real de ¡os datos distribuidos o si es suficiente una ratina de actualización por lotes. Dado el tamaño de los registros de datos, la tasa de eventos que crcan, leen, actualizan y borran esos registros y la distancia entre sitios de negocios, el equipo puede ahora explorar
DETERMINACIÓN DE LOS REQUERIMIENTOS DE DISTRIBUCIÓN
227
las opciones arquitectónicas. Las estrategias de distribución de datos varían desde la centrali zación com pleta hasla la distribución com pleta. Para sistem as a nivel em presarial, lo más p ro bable es que se em plee algún grado de fragm entación vertical, horizontal o mezclada. Para cualquier selección que haga, los m odelos de análisis esenciales le perm iten elaborar una so lución basada en el balanceo de las necesidades del negocio con las restricciones de la tecn o logía seleccionada. L’na vez que el proyecto ha determ inado la distribución en área am plia o global, es tiem po de enfocarse en los asuntos de área loeal de un sistem a cliente/servidor, "
DETERMINACIÓN DE LOS REQUERIMIENTOS DE DISTRIBUCIÓN LOCAL ENTRE UN CLIENTE V UN SERVIDOR Una vez que se han determ inado cuáles datos deben residir locaim ente, dentro dei alcance de una red de área local, es tiempo de atacar los m uchos temas que se presentan cuando se em pican vanas com putadoras para realizar tareas dentro de un sitio geográfico. Al igual que las decisiones de distribución de área am plia que acabamos de tratar, no hay una respuesta “co rrecta para la asignación de procesos o datos a un cliente, servidor departamental, servidor m ainfraine o servidor de minicom putadora. Si se pudiera reducir el modelado arquitectónico a una etiqueta podría decir; Toda solución tiene un problem a.7 ^ Cada despliegue posible de nuestro modelo esencial “perfecto” hacia el mundo im per fecto de la tecnología tendrá alguna desventaja. El propósito del resto de este capítulo es resal tar los com prom isos que se presentan cuando se mueven partes de la aplicación de la com putadora de escritorio hacia el servidor o viceversa. M ediante la com prensión de los com prom isos se tendrá la capacidad para tom ar decisiones de ingeniería bten fundamentadas, eva luando el impacto que pueda tener cualquier esquem a arquitectónico potencial sobre la habilidad de resolver los requerim ientos del negocio. M uchos lenguajes y herram ientas de desarrollo tienen una predisposición hacia la orga nización de cliente pesado o servidor pesado. Conform e se hagan más portátiles los lenguajes de codificación veremos menos este fenómeno. Com encem os viendo los pros y contras de un cliente pesado contra una aplicación de servidora pesada. '
Pros y contras del cliente pesado contra el servidor pesado Las aplicaciones cliente pesadas son aquellas en donde ia mayor parte del procesam iento se realiza locaim ente, por lo general en una PC de escritorio. La m ayoría de las herramientas po pulares de desarrollo GUI realmente prom ueven las aplicaciones de cliente pesado, debido a que sus xcripts fueron diseñados específicam ente para la PC. En la figura 8 -20 vemos una tran sacción mientras pasa a través de una típica arquitectura de cliente pesado.
t ’vi viejo dicho popular ruriianio dcteni errado por Meilir Page-Jones.
228
Capítulo 8 / EL MODELO ARQUITECTÓNICO
F igura 8-20. Una transacción en una arquitectura de cliente pesado.
L a captura y edición de datos se realiza en el cliente. Si el usuario com ete un error se le inform a inm ediatam ente. L a aplicación de interfaz edita inm ediatam ente el tipo de dato ade cuado, los rangos de fecha y num éricos y valida los valores de listas restringidas. La aplicación cliente tam bién hace cum plir una am plia variedad de regías del negocio. Esto involucra el dar al usuario pistas visuales para distinguir entre cam pos opcionales y requeridos con base en el estado del objeto que está siendo actualizado. La aplicación tam bién usa los valores de estado y el conocim iento de nivel de autorización del usuario para activar y desactivar botones de co m ando y elem entos de menú. U na aplicación de cliente pesado extrem a tam bién ejecutará cualquier cálculo que se ne cesite realizar, en vez de usar procedim ientos almacenados en el servidor. El servidor sim ple m ente recibe datos e instrucciones para crear, leer, actualizar o borrar valores en tablas específicas. El sistem a de adm inistración de bases de datos, que reside en el servidor, hace cum plir la integridad referencial, la autoridad del usuario, el tipo de dato correcto y los cam pos requeridos, sin embargo, todos estos factores ya han sido editados por una aplicación de cliente pesado bien elaborada. En el lado de salida de un a transacción, por ejem plo un a con sulta, los datos son enviados desde el servidor hacia el cliente, en donde pueden ser ordenados, filtrados, form ateados y desplegados ante el usuario feliz. Ahora que ya he presentado el escenario del cliente pesado, hagám oslo a un lado para exponer sus puntos fuertes y débiles. Es bastante obvio que la m áquina cliente debe ser capaz
DETERMINACIÓN DE LOS REQUERIMIENTOS DE DISTRIBUCIÓN
229
de poner algún tipo de presentación en un monitor, por lo que podem os tom ar la presentación cu pantalla como una tarca preordenada dei cliente. Pasando a la edición, la decisión de editar el tipo de dato adecuado en el cliente es de bajo costo y alto rendim iento. Cualquier herram ien ta de desarrollo GUI decente tiene la habilidad de leer el tipo de dato de la base de datos de de sarrollo y proporcionar la edición dcl tipo de dato en el cliente sin tener que codificarlo a mano. Si el campo tiene un tipo de dato de fecha en la base de datos, entonces la aplicación cliente sólo debe aceptar formatos de fecha válidos, e inform ar al usuario rápidam ente si es que trata de dar un valor incorrecto. Un cam po de carácter, tal com o estado del pedido, puede tener so lam ente un conjunto de valores restringido. Kn este caso, la aplicación de presentación deberá hacer cum plir la asignación de los valores del campo, ya sea poniéndolos autom áticam ente o permitiendo que el usuario seleccione valores desde una lista. Esta edición de bajo costo pre viene que errores de captura en eí cliente lleguen al servidor. El ubicar una regla del negocio en el cliente o en el servidor no es tan claro. U na regla sim ple tal com o '‘la fech a de expiración de la Unta de precios no debe ser m enor que. su fech a de entrada en vigor” es una edición de campo cruzado com ún en las aplicaciones de negocios. Se pueden obtener todo tipo de resultados raros si. se perm ite que cl usuario establezca listas de precios que term inan antes de comenzar. ¿D ónde se debe hacer cum plir esta regla? ¿En la aplicación de interfaz dcl cliente o en cl sistem a de adm inistración de base de datos dcl ser vidor? Ambas selecciones tienen sus méritos. Para hacer cum plir la regla en el cliente se ten dría que escribir una línea de código que se activara cuando el usuario trate de guardar la lista de precios. (También se podría poner cl código de edición en el cam po de fecha de expiración para atrapar el error tan pronto com o sucede. Sin embargo, no olvide que cuando el. usuario es tá equipado con un ratón puede teclear la fecha de expiración antes de teclear la fecha de ini cio, haciendo problem ática la revisión de edición a nivel cam po y con la posible confusión dcl usuario.) M ediante la detección dcl error en el cliente, la aplicación es capaz de dar oportuni dad al usuario de arrepentirse antes de incurrir en el costo del envío de datos al servidor. Hay una am plia expectativa entre los usuarios GUI de que una interfaz moderna debe contener ta les características, satisfaciendo ese adjetivo am orfo “am igable al usuario” . AI hacer cum plir esta regla inocua sobre la fecha en el cliente se reduce el tiempo que se necesita para que el sisLema inform e al usuario que ha com etido un error. Rcducc el tráfico de red potencial debido a que elim ina la necesidad de que el servidor inform e al cliente que ha re cibido datos erróneos. Por otro lado, al colocar la regla de negocios únicam ente en el cliente, las dem ás aplicaciones que acceden el m ismo dato deben incluir una regla idéntica para asegurar su cum plimiento. A quí se encuentra uno de los grandes dilemas de la arquitectura cliente/servidor. Las re glas del negocio están diseñadas para proteger la integridad del activo de inform ación de la com pañía. El software cliente necesita acceso inmediato a tales reglas para satisfacer las ex pectativas de una interfaz am igable, pero los dalos del servidor necesitan estar protegidos con tra actualizaciones erróneas hechas por aplicaciones que pueden ignorar las reglas. Si la base de datos puede ser accedida por una am plia variedad de aplicaciones (por ejemplo, la om ino sa “com putación de usuario final”), esto lo llevará hacia la filosofía de servidor pesado de po ner las reglas del negocio en el servidor, ya sea en procedim ientos alm acenados o en código personalizado. La heterogeneidad del hardw are cliente también puede em pujar a un provecto hacia la ím plem enlaeiún de servidor pesado. D igam os que el servidor de base de datos necesita ser ca paz de resolver las consultas y actualizaciones de las estaciones de trabajo, laptops, palm tops.
C apítulos / EL MODELO ARQUITECTÓNICO
230
teléfonos y televisión interactiva. No hay suficiente poder de p r o c e s a m i e n t o en algunos de es tos dispositivos para hacer alguna revisión de reglas seria. Estos tipos de restricciones le lleva rán a encapsular los datos en el servidor con una capa lógica de aplicaciones del negocio a través de la cual deben pasar todas las transacciones para acceder o actualizar los datos. Las aplicaciones de servidor pesado tienen una ventaja de m antenim iento sobre las aplicaciones de cliente pesado en que todas las reglas se pueden encontrar en un solo lugar y por eso son m o dificadas mucho más fácilmente. Las reglas del negocio que están repartidas entre diferentes aplicaciones cliente pueden crear un problem a de control de versión y de m antenim iento a lo largo del camino. A ntes de que com ience a aparecer com o un partidario del servidor pesado, déjem e regre sar nuevam ente al campo del d ie n te pesado. Los usuarios actuales sim plem ente no van a tole rar a una aplicación que no prevenga errores de captura previsibles, hilos esperan que la interfaz cliente esté consciente de las reglas y los guíe en el uso de la aplicación. Actualm ente esto da com o resultado frecuentem ente la codificación de la m ism a regla en dos lugares, una en cl software cliente para perm itir el cum plim iento inmediato en la interfaz y nuevamente en el servidor para protegerse contra rebeldes renegados de otra aplicación. No hace falta decirlo, pero nadie está de acuerdo accrca de esta duplicidad. l os proveedores están trabajando duro para hacer más portátil su codificación de scripís para que, al menos, la lógica del negocio no tenga que ser codificada en dos lenguajes diferentes. ~ Liste problem a del m antenim iento de dos conjuntos de reglas del negocio es parcialm en te responsable de la popularidad de la tecnología intranet para las com pañías. El código de la aplicación reside en el servidor y el cliente lo accede al m om ento de ejecución. La ventaja es un conjunto de reglas, pero la desventaja es, por supuesto, un tráfico de red increm entado h a cia cl servidor Web. ¿Y qué hay acerca de la orientación a objetos? ¿Puede la 0 0 ayudam os a satisfacer las dem andas restrictivas de la interfaz mientras m antiene la actividad alrededor de los datos ? Se tratará la orientación a objetos en el capítulo 12, pero debem os analizar previam ente el concep to debido a que tiene relevancia en e! debate de cliente pesado contra servidor pesado.
Los objetos del negocio en una aplicación cliente pesado Se ha hecho mucho alboroto sobre las técnicas de codificación orientadas a objetos utilizadas p a ra manejar las reglas del negocio.* Jin pocas palabras, la estructura de programación envuelve los datos de un objeto (conocidos com o variables en el vocabulario 0 0 ) eon un velo de procedim ien tos conocidos públicamente, llamados métodos, a través de los cuales se canaliza todo cl acceso a los datos. A esto se le llama encapsulado, lo cual significa que si se quiere consultar o m odifi car los datos de alguna forma se debe pedir a los métodos del objeto que lo hagan en vez de uno. Tomando esta idea y siguiéndola podem os decir '‘¡tomemos todas las reglas que se rela cionan con un pedido y pongám oslas en un objeto pedido y hagamos que todas las partes de nuestra aplicación que manejan pedidos le pidan al objeto pedido que haga su trabajo!’ (Ya se que ésta es una sim plificación excesiva del proceso, pero satisface nuestro objetivo por el mo-
>
Debo tincar notar que mucho cié lo que voy a decir también puede lograrse con un buen diseño estructura do huí¡guo y llamadas a procedí míenlos remotos. La orientación aobjetos no es un ie<]uisito previo para la resolución de dilemas arquitectónicos clienie/servidor. Es simplemente una de muchas opciones de solución para cí problema.
DETERMINACIÓN DE LOS REQUERIMIENTOS DE DISTRIBUCIÓN
231
mentó.) C iertam ente tenemos el material para decidir lo que debe contener un objeto pedido h l modelo de inform ación nos dice todos los datos de los que se encarga el negocio para cada pedido. El modelo de eventos, y específicam ente la sección de actividad del diccionario de eventos, nos dice los requerim ientos p ro c e d ía le s sobre la manera de m anejar los pedidos. P a ra ilustrarlo, si se fuera a utilizar un modelo de eventos para un sistem a de cum plim iento de pedidos típico se podrían encontrar enunciados en el diccionario de eventos tales como: .Sí un pedido .ve cancela, el sistem a debe cancelar todos los em barques pen d ien tes del pedido. Si una actualización sobre un envío solicitado de un pedido cae fuera de las fechas de en trada en vigor de la lista de precios asociada, el pedido se debe volver a cotizar. Todos los pedidas deben tener una asignación de m aterias p rim a s antes de ser p ro g ra m ados para producción. Se requiere el i!) de vehículo para todos los pedidos enviados p o r vagón de ferrocarril o tráiler. E l l l) de vehículo no se necesita p a ra los pedidos que recoge el cliente. Instas leglas son mucho más interesantes que nuestra edición de datos rutinaria. Dados estos requerim ientos del negocio, un usuario podría tener derecho a esperar que la interfaz se com portara acorde a ello. Si el usuario cancela un pedido, el sistem a debería dar un acuse de recibo de que sus envíos program ados pendientes también son cancelados. Si extiende la fecha de envío del pedido mas allá del periodo de la lista de precios, la interfaz debería decirle rápida y claram ente que necesita volver a cotizar el pedido. Sí todavía no ha hecho la asignación de materias primas, cl botón o elem ento de menú que program a la producción debería estar d e sactivado, En form a similar, si está enviando por tren o por tráiler debería ser visualmente apa rente que se requiere el cam po ID de vehículo, y si el pedido es para recogerlo, el campo de ID de vehículo deberá ser desactivado o estar oculto. Al observar el m apeo de eventos hacia las ventanas candidatas en el prototipo de inter faz, podem os encontrar que diversos aspectos de un pedido son m odificados en muchísimas ventanas dentro de la aplicación. Enfocándose solam ente en el lado cliente de la aplicación, la idea de em plear orientación a objetos para manejar las reglas del negocio puede ser poderosa. Cuando una idea tan com pleja como un pedido de cliente está distribuida en tantas ventanas, cada ventana necesita acceso a la lógica del negocio que es relevante para las tareas que ahí se están realizando. Hl usuario debe esperar que las reglas se hagan cum plir en forma uniform e, sin im portar cuál ventana esté usando, ’ Una estrategia sólida es dividir el código que controla el com portam iento de las clases del negocio, tales com o pedí do y cliente, del código que controla el com portam iento de las cla ses de presentación, tales com o ventana o botón (figura 8-21). M ediante la separación de la ló gica del negocio de la lógica de presentación, cl diseñador satisface dos objetivos. La lógica del negocio ahora se encuentra en un lugar dentro de la aplicación cliente, pero todavía es ac cesible a cada una de Jas ventanas de presentación que la necesitan. Por lo tanto, la rcutilízación ’ escurridiza de la clase de negocios se loara dentro de la m ism a aplicación m ediante la reducción de la cantidad de código de lógica de negocios redun dante que se requiere para ejecutar la interfaz. La habilidad para reutilizar las clases de presen tación, tales com o ventanas, botones y controles también se incrementa, debido a que estas clases 110 tienen que preocuparse con ningún conocim iento del negocio y, por lo tanto, pueden
C apítulos / EL MODELO ARQUITECTÓNICO
232
concentrarse en lo que hacen mejor, la m ecánica de la adm inistración de un a interfaz gráfica. M uchos de los lenguajes populares de desarrollo G U I actualm ente ya soportan esto tipo de d i visión de aplicaciones.
f i g u r a 8-21. M uchas ventanas recurriendo al m ism o o bjeto de negocios
Los objetos del negocio en una aplicación de servidor pesado La división de la lógica del negocio con respecto a la lógica de presentación en el cliente per mite una mayor reutilizadón y código m enos redundante, pero todavía no resuelve la necesi dad de en capsular los datos en cl servidor con las m ism as reglas del negocio. Para resolver este problem a se necesita un lenguaje que perm ita que los objetos de presentación en el d ie n te re curran directam ente a los objetos de negocios en el servidor. Esto se m aneja con lo que se co noce com o un ORB, corredor de peticiones de objeto. Éste es un objeto que lleva cuenta de la ubicación Tísica de los objetos que son utilizados a lo largo de una arquitectura d ien te/serv i dor. Cuando un objeto de presentación, tal com o una ventana, necesita recurrir al objeto p ed i do envía su petición al corredor de peticiones de objeto, el cual dirige la com unicación hacia la m áquina adecuada en donde se encuentra el objeto de destino (figura 8-22). Los corredores de peticiones de objetos hacen que la lógica del negocio sea portátil. La gran ventaja es que las reglas d d negocio están disponibles ante la aplicación cliente sin tener que ubicarlas Tísicamente en el diente, listo perm ite el m antenim iento central de una copia de la clase de negocios que es utilizada por todas las aplicaciones que requieren acceso a los da tos. O tra beneficio enorm e es que la lógica del negocio puede m overse de m áquina a m áqui na sim plem ente m oviendo el objeto y actualizando su ubicación en el corredor de peticiones de objetos. listo perm ite que d arquitecto del sistema aproveche la nueva tecnología conform e se tiene disponible en el proyecto, redistribuyendo objetos para obtener el desem peño opüm o sin tener que volver a diseñar y codificar gran parte de la aplicación completa.
DETERMINACIÓN DE LOS REQUERIMIENTOS DE DISTRIBUCIÓN
233
Recuerde que toda solución tiene un problem a. La idea de distribuir la lógica del nego cio en el servidor y todavía tener acceso a las reglas al m om ento de ejecución en cl cliente es atractiva, pero tiene un precio, lil diseño asum e que la velocidad de la red entre el cliente y el servidor es suficiente para m anejar el tráfico adicional, im puesto al insistir que el cliente vaya a través de la línea para recurrir a las regias basadas en el servidor. La obtención en un solo lugar de las reglas acerca de un conjunto de objetos de n ego cios com plejo requiere un diseño m uy habilidoso. N inguna ventana o aplicación puede ocu parse com pletam ente de un objeto tal com o un pedido. lil tener que hacer instancias del objeto com pleto en el cliente al m om ento de ejecución y poblarlo con gran cantidad de datos desde el servidor a través de una red débil es com o tratar de chuparse un elefante a través de un p o pote. Los objetos de negocios com plejos pueden ser com parados con ia vieja fábula de los cie gos y el elefante. El cuento dice algo com o lo siguiente: A tres caballeros que no tenían buena vista un día les fue presentado un paquider mo por razones que desconozco. El prim er ciego tocó la trom pa del elefante y ex clamó: “U n elefante es com o una de esas grandes aspiradoras que se rentan en el lavado de coches. D eberé usar este elefante para i im piar mi cam ioneta.” íil segun do hom bre de visión lim itada cam inó directam ente hacia un lado del elefante. ¡Perm ítem e que te contradiga!”, protestó. “Un elefante es com o una gran pared
Capítulo 8 / EL MODELO ARQUITECTÓNICO
234
de hule. U no puede cobrar una cuota a ¡os d ie n tes de la taberna para rebotar con tra él ” El tercero, que en realidad no estaba cora pl clam en le ciego, se fue directa mente hacia los colm illos del elefante diciendo: “ Señores, podríam os hacer una fortuna conviniendo éstos en teclas de piano y baratijas decorativas , y después de eso fue rápidam ente arrestado bajo ci acuerdo internacional de las Naciones U nidas sobre las especies en peligro de extinción, por un intento delictivo de atra par un anim al protegido. Los objetos de interfaz, tales com o las ventanas, que son diseñadas para reconocer even tos de negocios específicos, son muy similares a los ciegos que encuentran al elefante. Una ventana que crea un encabezado de pedido puede estar interesada en la situación crediticia del cliente, pero tal vez no esté interesada en el nivel de inventario del producto solicitado. Una ventana que se especializa en dividir un pedido solicitado en dos em barques separados no se preocupa acerca de la situación crediticia dcl d ie n te, sino que puede depender com pletam ente de la disponibilidad del transporte. Cada ventana solam ente necesita una parte del pedido, en forma sim ilar a com o los ciegos solam ente requieren una parte del elefante. La m oraleja del cuento es que si la ventana sólo requiere una parte del elefante, digamos una trompa, un costado o un colmillo, entonces no se necesita m olestar a la aplicación con nin gún conocim iento acerca del resto del elefante. La lógica de presentación sólo debe estar cons ciente de las características del objeto que se requieren para hacer el trabajo, y el objeto de negocios no debe molestar a la aplicación haciendo que recupere datos que no necesita. El di señador necesitará en muchos casos crear servicios que accedan solam ente los datos requeri dos para cada tarea. . ., Veamos en dónde deben residir los objetos de negocios al momento de ejecución. L n a opción es ubicar los objetos de negocios en el servidor. Cualquier objeto de presentación que ejecuta en el cliente debe recurrir a los objetos del negocio a través de la red, por lo general por m edio de un corredor de peticiones de objetos. El costo de esta solución es el incremento de! tráfico de red. , Si la red es incapaz de m anejar los m ensajes entre los objetos de presentación en el d ie n te y los objetos de negocios en el servidor, entonces otra opción es crear instancias de los ob jetos de negocios en eí d ie n te al momento de ejecución para servir electivam ente a la interfaz, suponiendo que no hay un impacto aprcciable en el desem peño del m om ento de ejecución por hacerlo. En esta solución la red todavía debe ser capaz de m anejar una estam pida de datos des de la base de datos que se requieren para dar vida a los objetos. Recuerde que no hay que pa sar al elefante com pleto a través de la red para una ventana que tal vez sólo requiere una rapida vista a la uña de la pata. Una tercera opción es crear dos conjuntos físicos de las d a se s de objetos, una en el ser vidor y otro en el cliente.» La ventaja es que las reglas del negocio residen nuevam ente en el Chente para que las use la interfaz, y existe una copia idéntica cu el servidor para proteger os datos. La penalización es que nuevam ente regresam os a coordinar dos versiones íj sicas de las reglas.
Supon a o todavía que para el resto dcl libro, los dalos del sistema están alojados en una base do datos relacional 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 cacom o m Pido tiempo de respuesta en el d ie n te , y luego listaré las formas posibles pa ra r*orarln * ' r
Rápida respuesta en el cliente Para sistemas que dem andan velocidad de rayo en el cliente, hay varias formas para evitar sis temas lentos, ' ‘ Si se tienen muchos usuarios sim ultáneos, una aplicación de servidor pesado podría ha cer lento al servidor con un exceso de dem andas de procesam iento. M ediante la com pra de m á quinas cliente muy poderosas se puede distribuir gran parte del procesam iento en el escritorio, hsto reduce el trafico global de red, elim inando muchas llamadas a procedimientos remotos El costo es, por supuesto, que se paga m ucho dinero por la tecnología cliente más reciente. El echar hardware a los problem as de desem peño es frecuentem ente costeable. También es im por tante asegurarse que esté colocada una red de alta velocidad y suficiente poder de ataque en el servidor para reducir cl tiem po de espera. Al pasar nuestra atención a los datos, otras soluciones incluyen la optim ización de la ba se de datos por medio de índices o vistas para agilizar las consultas sobre las transacciones con mayor volum en. A lgunos datos con poca volatilidad pueden alm acenarse en cachés en e! clien te o en un servidor de archivos local.
Heterogeneidad del hardware cliente A lgunos negocios tienen un requerim iento de que la aplicación debe ejecutarse en una varie dad de m aquinas cliente, desde estaciones de trabajo hasta laptops, palm tops o teléfonos. Esto i orzara a la aplicación hacia una arquitectura de servidor pesado extrema para proteger la inte gridad de los datos. Las APIs (interfaces de program ación de aplicaciones) tendrán que cons truirse para perm itir que diferentes aplicaciones cliente con varios grados de inteligencia accedan al servidor. Para aplicaciones que ejecutan GU Is en estaciones de trabajo bastante in teligentes, se puede encontrar la dem anda de que muchas de las reglas del negocio que están alojadas en el servidor central también residan en el cliente al m om ento de ejecución. Píira la mayor parte de este libro estoy haciendo la suposición audaz de que eí hardw are cliente es virtualm ente idéntico en todas las máquinas, o que al m enos las diferencias son ma nejadas por cl departam ento de IT. En mi experiencia, las ligeras diferencias entre diferentes
236
C apítulos i EL MODELO ARQUITECTÓNICO
marcas de com putadoras personales pueden hacer que a veces la m ism a aplicación cliente se com porte en forma inesperada. E l departam ento de IT debe luchar por el control de la com pra y configuración de las com putadoras personales en vez de tenerlo cl negocio, y m antener una configuración de hardw are estándar aprobada para las aplicaciones que crea o adquiere. Esto incluye el establecim iento de lincamientos para el uso de una com putadora personal. Parece com o si cada com pañía tuviera al m enos un gerente errante que es famoso por llegar el fin de sem ana c instalar una copia de “ los guerreros Vomitron galácticos” de su hijo, program a que reconfigura sus archivos de sistema, dando com o resultado una llam ada reclam ando al direc tor de la IT en la m añana del lunes cuando su aplicación cliente aborta después cíe la ventana de registro. Las personas del negocio que no están dispuestas a renunciar a la PC histórica “gra tis para todos” , probablem ente no están listos para la disciplina que se requiere para la com pu tación cliente/servidor. (Vea el capítulo 13, Mito # 3: PC significa com putadora personal.)
Heterogeneidad del software cliente No todos los usuarios son responsables de los m ism os eventos del negocio y, por lo tanto, no todos los usuarios necesitan todo el softw are que se distribuye. Suponiendo que hay muchas aplicaciones que ejecutan sobre ]a m isma base de datos, el diseñador tiene la alternativa de d is tribuir una gran aplicación a todos o m uchas aplicaciones pequeñas solam ente a quienes las necesitan. La segunda alternativa tiene algunas ventajas. Cuando se divide una aplicación cliente grande en varias partes, el softw are cliente ocupa m enos espacio de disco. Cuando el usuario solicita m ejoras al software se pueden aislar los cambios en un ejecutable particular. La venta ja es de que se m olesta a m enos usuarios con una m ejora de software cuando se libera la apli cación mejorada, y no se necesitan probar las partes de la aplicación que no son afectadas. La desventaja es que toda esta partición tiene que ser adm inistrada con un control de versión ri guroso y un proceso de distribución para asegurarse de que la IT esté muy consciente de cuá les partes de la aplicación están en cada PC de usuario. Para los negocios que tienen una m ezcla de aplicaciones que com parten la m isma base de datos, que puede ser construida por diferentes grupos dentro de la IT o contener algunos pa quetes com prados, tal vez sea necesaria una solución de serv idor pesado para asegurarse de que los datos estén cncapsulados adecuadam ente con las reglas del negocio adecuadas.
Comunicación mínima de red Tal vez, algunos sitios no tengan la velocidad de red, debido al tamaño o a la distancia, para manejar volúm enes de transacciones grandes en form a efectiva. Si existe esta restricción, los arquitectos del sistem a pueden regresar nuevam ente al modelo esencial para buscar ayuda. Si se tom an los eventos m ás críticos y con m ayor volum en se traza un diagram a de flujo de datos de entorno de eveDtos para la actividad del evento, m ostrando todos los procesos y accesos al almacén de daros (figura 8-23).
237
RESUMEN
ICO Kt)
4 5 /0 ía
Figura 8-23. Lil diagrama de vecindad de eventos detallado con estadísticas.
A note en el diagram a las tasas de eventos y la cantidad de bytes representados por cada flujo de datos. Arm ado con este tipo de inform ación puede jugar a “qué pasaría si...” para ob tener una distribución de procesos cliente/servidor y datos que den com o resultado la com uni cación más baja posible. Trate de separar al cliente del servidor en el punto de flujo de datos m ínim o. Pruebe la utilización de caches locales para algunos datos en el cliente o un servidor departam ental en el lugar del cliente para reducir el tráfico con el servidor central. M ediante el modelo se pueden sim ular transacciones en una interm inable variedad de configuraciones has ta que se encuentra una que funcione.
RESUMEN Kl propósito del modelado arquitectónico es usar nuestro conocim iento de los requerim ientos esenciales del negocio com binado con las restricciones de la tecnología disponible, para obte ner una distribución adecuada de datos y el procesam iento en los diversos niveles de hardw a re de la arquitectura cliente/servidor. La aplicación de software clien te/serv id o r puede ser dividida en capas. La capa de presen tación se usa para m anejar la m ecánica de la interfaz. La capa lógica del negocio contiene. el có digo que hacc cum plir las políticas del negocio, tal com o se describen en la sección de actividad del modelo de eventos. La capa de adm inistración de datos maneja el acceso sim ultáneo a la b a se de datos, así com o la sincronización de datos distribuidos. El térm ino d ie n te pesado (servi dor delgado) se usa para describir una aplicación en térm inos generales en donde la mayor parte de la capa lógica del negocio se ejecuta en la m áquina cliente. Servidor pesado (d ien te delgado) describe a una aplicación en donde la parte im portante del procesamiento sucede en el servidor y el cliente queda confinado principalmente a labores de presentación. El modelado arquitectónico com ienza con la recopilación de estadísticas acerca del n e gocio y la docum entación de las expectativas de desem peño que restringen a eventos específi cos. Ll tamaño de la base de datos se determ ina m ediante el cálculo de la cantidad de bytes
238
C apítulos / EL MODELO ARQUITECTÓNICO
requeridos para un solo renglón de cada tabla m ultiplicado por la cantidad de renglones es perados. La cantidad de renglones esperados está en función de qué tan frecuentem ente un evento añade renglones y qué tanto tiempo se debe conservar el registro. Las estadísticas reco piladas para el tam año del registro tam bién son relevantes cuando se determ ina la carga de trá fico de red entre el cliente y el senador. Las estadísticas recopiladas para el modelo de eventos incluyen la tasa prom edio de los eventos del negocio y los patrones de tasa pico para eventos que suceden en form a irregular, lam bién se recolectan las restricciones de tiempo de respuesta para los eventos de negocios m ás críticos. La distribución geográfica del negocio se docum enta en una matriz de evento/ubicación de negocios. E sta muestra cuáles eventos suceden en las diversas ubicaciones de negocios que son geográficam ente rem otas entre ellas. M ediante la com binación de la matriz de evento/ubi cación del negocio con un m atriz CRUD evento/entidad se puede derivar una matriz CRUD ubicación del negocio/entidad, donde se muestran los requerim ientos de distribución de datos lógicos para la aplicación. Mediante la com binación de este conocim iento con el sentido de qué tan actuales deben ser los datos en cada sitie, el equipo puede com enzar la evaluación de si de be tener una base de datos centralizada, bases de datos distribuidas y sincronizadas o usar un esquem a de fragm entación para la distribución de los datos. Hl arquitecto también se enfrenta con decisiones de distribución local. Los usuarios de aplicaciones GUI modernas dem andan que m uchas de las reglas del negocio les sean visual m ente aparentes al m om ento de ejecución. Ll negocio también tiene la responsabilidad de pro teger los activos de datos, que por lo general se encuentran en el servidor, de ser actualizados por otras aplicaciones que puede ser que no estén conscientes de las reglas del negocio. Con tantas herram ientas de desarrollo y lenguajes, este dilem a puede forzar a los des arrolladores a codificar reglas en dos lugares. M uchas de las herram ientas populares de desarrollo GUI actualm ente están predispues tas hacia arquitecturas de d ie n te pesado. Conform e se hagan más portátiles los lenguajes de desarrollo podrem os ver una tcndeucia en las aplicaciones de vuelta hacia la lógica de nego cios basada en servidor y tecnología Intem et/intranet, pero esto colocará todavía mucho más dem andas en nuestras redes existentes para m anejar el increm ento de mensajes. Todo el modelado arquitectónico se refiere a com prom isos. Para elaborar la ingeniería de una solución cliente/servidor adecuada se deberá usar el modelo para sim ular transacciones a través de diversos escenarios arquitectónicos. El propósito de este capítulo es m ostrar la m a nera en que pueden usarse ios m odelos de análisis esenciales para reem plazar el tradicional m étodo de toma de decisiones arquitectónicas de "quien grita m ás fuerte, gana” . La moraleja de la historia es que “toda solución tiene un problem a” . Al estar consciente de las desventajas de cada solución, el equipo puede llegar sensatam ente a la arquitectura m enos cuestionable para satisfacer las necesidades del negocio.
EJERCICIOS L ¿.Qué factores pueden em pujar el diseño de una aplicación hacia una im plem enta ción de servidor pesado en vez de un diseño de cliente pesado? 2. ¿Q ué factores pueden favorecer al diseño de cliente pesado?
RESPUESTAS
239
3. ¿Por qué se escogería la im plem entación de una base de datos replicada en varias ubicaciones en vez de s e n 'ir a todas las aplicaciones por m edio de una sola base de datos centralizada? 4. ¿Por qué podría ser forzado a codificar una regla de negocios tanto en el cliente co mo en el servidor?
RESPUESTAS 1. Las m áquinas cliente que tienen una potencia de procesam iento relativam ente Iimitada, 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
Capítulo 8 / EL MODELO ARQUITECTÓNICO
240
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
& * ; t* *
¿ i
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.
243
TRADUCCIÓN DE UN MODELO DE INFORMACIÓN 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
^1 — Persona
(
V
-4 -
í
Create table PERSONA ID_de_persona Char(8) Nombre Char(30) Inicial Char|1) Apellido Número telefónico
245
Char(30) Char(IO)
Créate tabie PERRO Not Nuil Not Nuil,
, Not Nuil,
N úm ero,dejicencia Nombre_.del_porro Peso_en. libras Fecha_de. nacimiento
Char(S) Char{30¡ iníeger Date
Not Nuil Not Nuil,
); 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 ID_de_persona Char(8) Nombre Cha r(30) Inicial Chard} Apellido Char(30) N ú m e ro_te 1ef ó n ico
Char(lO)
Create table PERRO Not Nuil Nol Nuil,
, Not Nuil, );
Número_de_licencia Nombre del_porro Peso_.en_libras Fecha_de nacimiento " a ^ e f rr p o ig a ila s "
Char(S) Char(30) Integer Date l/H u y e r
Not Nuil Not Nuil,
“
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
Persona
---------------- —
o, ,
------------- I r -
Parro
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 proP 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 dse 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
Capítulo 9 / EL DISEÑO DE BASE DE DATOS
248
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 A ltu ra en
C ódiao
pulgadas
A nchura
Longitud
en pulgadas en pulgadas
d e producto
N o m b re de producto
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.
249
SELECCIÓN DE UNA CLAVE PRIMARIA P R O D U C TO C ódigo
T ip o da
C apacidad
de p ro d u c to N o m b ra de producto
m aterial
d s asientos pulgadas pulgadas
A ltu ra eo A nchura en Longitud
CDLD4
C herry D ro p Leaf D in m g Table
Ctierry
M DLD4
M a h o g an y D rop Leaf D ining Tabte M a h o g a n y
PLBKC
Pina Laddar Back Kitchen Chetr
Pina
PEN CT
Pina E nte rtain m e n t C enter
M B W FC
M a h o g an y B ow Front Chast
en pulgadas
4
30
36
48
4
30
36
48
1
36
18
18
Pine
ao
22
72
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
pedtdo concepto d e ped id o producto ícp> 3-0031
1
M B W FC
Precio C an tidad t
u n ita rio $ 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 Código 15 de producto de producto Nombre de producto
Altura en Anchura en Altura en | pulgadas pulgadas pulgadas
XQG12
CDLD4
Cherry Drop Leaf Dining Table
30
36
48
H2432
MDLD4
Mahogany Drop Leaf Dining Table
30
36
48
A 534 5
PLBKC
Plne Ladder Back Kitchen Chair
36
18
18
G2412
PEMCT
Fine Entertainment Center
80
22
72
N2341
MBWFC
Mahogany Bow Front Chest
48
20
28
Figura 9-10. Lü tabla producto con un identificador arbitrario.
A un con el identificador arbitrario todavía tenem os un problem a. Todos los pedidos que se colocaron antes del cam bio de nom bre de producto fueron para “M ahogany Bow Front Chest” . Los docum entos im presos en ese tiem po m ostrarían la descripción de producto an ti gua. El m ism o pedido vuelto a im prim ir después del cam bio de nom bre m ostraría el nuevo nom bre “H epplew hite D resser” . Esto puede causar todo tipo de confusiones, en especial para el cliente que colocó un pedido inm ediatam ente antes del cam bio de nombre, sólo por tener un nom bre com pletam ente diferente apareciendo en su núm ero de guía cuando envían el pro ducto. Hay varias soluciones a considerar, y el departam ento de IT debe ayudar al negocio a que com prenda ias consecuencias de cada una de ellas. La prim era solución es perm itir que el ne gocio m odifique nom bres y códigos de productos, pero para preservar la historia el código y aom brs de producto debe ser llevado en forma redundante en cada tabla que hace referencia al producto. Esio preserva cl hecho de que el renglón representa un solo producto en el mundo 3 je ha sufrido un cam bio de nombre. La figura 9-11 m uestra la tabla concepto de pedido e x -'c-hnimai redundantes, código de producto y nombre de producto que reflejan el código y d ¿I m om ento en que el producto fue solicitado. Sin em bargo, la tabla producto refle ja d código > nom bre actuales. La ventaja de esta solución es de que los reportes históricos pa ra el producto aciual no son interrum pidos, debido a que el identificador no ha cambiado.
SELECCIÓN DE UNA CLAVE PRIMARIA
251
CONCEPTO DE PEDIDO ID de No. de ID de Código pedido C. P. producto ¡cel de producto Nombre de producto
Canti • dad
3 0031
1 S3,4a0.00| ¡UU kUII
1
N2341
MBWFC
Mahogany Bow Front Chest
Precio i unitario É
PRODUCTO ID de producto
Código 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 de producto
Nombre del producto
Estado 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
HPLDR
Hepplewhite Dresser
Activo
s
F ig u r a 9-12. La tabla producto con una colum na estado activo.
252
Capítulo 9 / EL DISEÑO DE BASE DE DATOS
Debido a que no se puede cam biar cl código de producto, se le vuelve a utilizar como una clavc primaria.-' Sin embargo, com o vim os en el m odelado arquitectónico, toda solución tiene un problem a. El problem a de esta solución son los reportes históricos del producto actual. N uestro producto del mundo real, una cóm oda de caoba muy bien proporcionada con cajones y con una bella cara curvada, ahora está representada dos veces en la base de datos. Para obte ner un reporte en el que se m uestre que tantos de estos bellos artículos se han vendido, el pro gram ador debe reunir cl historial de los dos registros de producto separados. Para evitar la codificación fija de códigos de producto se debe añadir una relación recursiva de A ntes era a la tabla producto que perm ita juntar los registros (figura 9-13). El precio a pagar por esta so lución es una seria com plicación para todos los reportes que requieran m ostrar una historia contigua de los objetos del mundo real debido a la unión recursiva.
PRODUCTO Código efe producto
Nom bre del producto
Estado activo
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
Código dK producto i antiguo (ce) !
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.
253
SELECCIÓN DÉ UNA CLAVE PRIMARIA
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 pedido
N úm ero de Código de Precio concepto de pedido producto (fk) Cantidad U nitario
3-00331
1
MBWFC
1
$3,400.00
3-0031
2
PLBCC
4
$ 225.00
F igura V-14. Una clave primaria de varias columnas A lgunas tablas no tienen ningún identificador adecuado. Las tablas con un rango de fechas en la clave lógica son un ejemplo clásico. N uestra tabla producto del fabricante de m ue bles probablem ente tiene una tabla de precio de producto asociada, l^a figura 9-15 m uestra la tabla precio de producto. Bi m ismo código de producto aparece en varios renglones por que el precio varía con el tiempo. El departam ento de mercadotecnia ha dado precios para ios tres prim eros trimestres del calendario de 1996. Debido a un incremento inesperado en cl costo d e ¡a caoba, el precio del prim er trimestre para “m esa de com edor de hoja caída de caoba” aum entó añadiendo un nuevo renglón que es efectivo a partir de 16-1-96. PRECIO DE PRODUCTO
-------
Código de producto |ce)
Fecha inicial
Fecha final
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
Precio unitario
F ig u ra 9-15. La tabla p recio de producto.
Capítulo 9 / EL DISEÑO DE BASE DE DATOS
254
¿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
É
Fecha Inicial
Fecna final
Precie unitario
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
MDLD4
16-1-96
31-3-96
5 2,795.00 1
MDLD4
1-4-96
30-6-96
$ 2,849.00
MDLD4
1-7-96
30-9-96
$ 2,895.00 I
Código de producto ¡ce)
CIVL&4 "
i 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.
Capítulo 9 i EL DISEÑO DE BASE DE DATOS
256
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 ID del
ENVIAR A ........ ........................... Hora d e la últim a descarga
C alificación
clie n te (ce)
Lím ite de crédito
d e crédito
!D del cliente (ce)
H 2432
$ 500,000
Sólida
A 5345
Y
14:00
G 2412
$ 120,000
Insuficiente
G2412
N
17:00
N2341
Y
20:00
Red fe rro v ia ria
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 del diente Nombre del diente
Tipo de cliente
Límite Calificación Red Hora de la 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
G2412
Sai s Manila Chicken Farm
Ambos
N2341
Day Gío Nuclear Facilities
Enviar a
$ 120,000 Insuficiente
Y
14:00
N
17:00
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 w here
c l i fin U-:. c i i e n U : _ i c ! , ulic:r:;-.e . c l i e n t e -ti p o
t :: i en t e . i: l i e n t e j i e m b r e - " [ ;í c t u r a r
;-i"
cr
de
c Ü H r .t e
“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 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 -
n o r r .b r c d e f s c : L u r ¿ r _ n ; . i d__c l i e n L c :
258
Capítulo 9 / EL DISEÑO DE BASE DE DATOS
Solución de sólo subtipo Una tercera opción de solución para la im plem entación de entidades de supertipo/subtipo es elim inar al supertipo y crear tablas sólo para los subtipos. Esto resuelve el problem a de tener que unir al supertipo y al subtipo para tener una im agen com pleta del objeto. Sin embargo, esta solución crea un problem a para los subtipos que no son m utuam ente exclusivos. En el caso de nuestro ejem plo de cliente, para todo cliente que represente un papel doble deberá existir un renglón tanto en la tabla fa ctu ra r a com o en la tabia enviar a. Se requeriría algún enlace de re ferencia cruzada para llevar cuenta del hecho de que estos dos renglones representan al mismo cliente del m undo real. Las tablas de sólo subtipo separadas son m ás adecuadas cuando los subtipos son m utua m ente excluyen tes y se com parte muy poco com portam iento. Tomemos un ejem plo de una em presa que posee más de 3,000 autom óviles y cuatro aeronaves de la com pañía. A utom óvil y aeronave son subtipos válidos de vehículo, pero puede suceder que m uy pocas partes del nego cio, en caso de haberlas, se preocupen de hecho acerca de los vehículos en form a acumulada. Sería un muy mal diseño atiborrar m ás de 3,000 registros de autom óvil con atributos tales como envergadura y altitud de crucero recomendada.
AFINACIÓN DEL DESEMPEÑO Durante la fase de m odelado de la inform ación somos capaces de suponer el lujo de la tec nología perfecta. Todos los procesadores son infinitam ente rápidos, todos los alm acenes de datos son infinitam ente grandes y los datos están disponibles un i versal mente en todas las ubi caciones del negocio. U na vez que com enzam os a diseñar el sistem a físico tenemos que llevar nuestro modelo de inform ación a la luz del día y ver qué tan bien se porta. Si el m odelo de inform ación refleja con veracidad la form a lógica del negocio, entonces ésta es la form a m ás deseable para un diseño de base de datos física. Estoy continuam ente sorprendido por la cantidad de proyectos que se perm iten una desnorm alización frenética en anticipación de que podrán tener un problem a de desem peño. R ecuerde que un modelo de inform ación no respeta las fronteras del proyecto. La base de datos relacional contiene infor m ación valiosa que es necesaria para m uchos otros sectores de la organización. SÍ se contam ina la estructura para optim izar el sistem a para las necesidades de un program a particular, lo más probable es que se esté haciendo m ás difícil para cualquiera el acceso razonable de los datos en el futuro. El prim er paso para la afinación del desem peño es que el diseñador de base de datos vea qué tan bien se desem peñará la base de datos si se im plem enta tal com o está. N o trate de resolver problem as imaginarios. La buena afinación del desem peño se apoya en la capacidad de medir exactamente en dónde y por qué está ejecutando despacio la base de datos. Si se tiene una buena inform ación estadística acerca del am biente de destino se puede esti m ar el tiem po de respuesta del sistem a de acuerdo a las tasas de eventos y los volúm enes de datos. Si no se tienen mediciones históricas del sistem a de adm inistración de base de datos se pueden instalar algunas tablas, cargarlas con datos y probar la respuesta de las partes críticas de la aplicación. L a desnormalizaciÓQ significativa sólo debe considerarse com o un últim o recurso para la afinación del desem peño de la base de datos. Los pecados de la desnorm alización varían en su severidad, siendo el pecado de cardinalidad el p eor de todos. Veamos algunas de las técni
AFINACIÓN DEL DESEMPEÑO
259
cas que puede usar cl equipo de desarrollo para resolver el desem peño inaceptable de la base de datos. Indices adicionales. Un índice es usado por eí sistem a de adm inistración de base de datos para buscar rápidam ente la ubicación física de un registro dado. Cuando se crea la base de datos relacional por prim era vez, se establecen índices autom áticam ente para las claves pri m aria y externa de cada tabla. La recuperación se puede agilizar si se agregan índices para las tablas que son accedidas rutinar iamente m ediante colum nas diferentes a las claves primarias o externas. Estructura de la<¡ consultas SQL. Se puede obtener una mejora significativa del desem peño de la aplicación sim plem ente m ediante la com prensión de la m anera en que el optim izador de la base de datos procesa las consultas y estructurar a! SQ1 - de acuerdo a ello. Este enunciado puede parecer ignorar com pletam ente el esfuerzo de la industria para tener están dares que algún día elim inen las diferencias entre los dialectos SQL. La realidad es que cada sistem a de adm inistración de base de datos (DM BS) tiene sus propios detalles, y un equipo de desíirrolio necesita com prender las fortalezas y debilidades de su marca particular de base de datos. í-s probable que la herram ienta de desarrollo GUI y el sistem a de adm inistración de base de datos vengan de proveedores diferentes. Si se usa la herram ienta GUI para generar las con sultas, puede suceder que la herram ienta GUI no estructure al SQL en la form a m ás eficiente para el optitnizador de base de datos, aunque los proveedores digan lo contrario.7 Para com plicar las cosas, en m uchos proyectos los dcsarrolladores que al fin han adivinado las extrañas tendencias de su optirnizador ¡encuentran que se com porta diferente después de una mejora de versión! Al menos uno de los des arrollad ores de proyecto necesita tomarse el tiempo para do minar al DMBS hasta com prender cuáles consultas regresan más rápido y cuáles se atoran. He visto program adores que obtienen trem endas mejoras de desem peño en su código m ediante la reestructuración de consultas com plejas para que se procesen en form a m ás eficiente cuando llegan al servidor. U bicación tísica del disco. Se puede lograr algún grado de optim ización por medio de la forma en que están ubicados los datos físicam ente en el disco. Asf com o un automóvil nece sita un cam bio de accite con cicrta frecuencia, la base de datos deberá reconstruirse periódica mente para reorganizar los datos que se han fragm entado debido al uso y a las m odificaciones y elim inación de renglones. M uchos sistemas de adm inistración de base de datos perm iten que el adm inistrador del sistem a asigne partes de la base de datos a diferentes discos físicos para aprovechar el acceso sim ultáneo a diferentes tablas al momento de ejecución. D istribución y replicación de datos. U na razón com ún por la que las personas ansian desnorm ali/.ar sus tablas es que el acccso físico a los datos se lleva m ucho tiempo. U na solu ción posible es exam inar un particionado m ás efectivo de la base de datos a través de la arqui tectura cliente/servidor. En el capítulo 8 se trató la manera de usar el modelo esencial para llegar al particionado m enos cuestionable. Puede haber tablas adicionales que no fueron con sideradas en la ronda inicial del modelado arquitectónico y que son frecuentem ente accedidas pero lo suficientem ente perm anentes para bajarlas con seguridad a la m áquina cliente o al servidor departamental. Algunas tablas pueden ser lo suficientem ente pequeñas para cargarlas de manera total en la m em oria de la PC.
¡Hsle problema puede estar prest;ule aunque la herramienta GUI y la base de datos sean del mismo provee dor!
260
Capítulo 9 / EL DISEÑO DE BASE DE DATOS
Distribución de procesos. Otro problem a de desem peño cliente/servidor com ún em erge cuando una aplicación basada en el cliente trata de llevar una gran cantidad de datos a través de la red sólo para sum arizarla antes de presentarla o crear un reporte. El problem a de desem peño se debe probablem ente al volum en de datos que atraviesan la red y no a la estructura de la base de datos. Trazando un rápido diagram a de evento-vecindad, cí diseñador puede deter m inar si puede lograrse un particionado más efectivo. El tiempo de respuesta puede m ejorarse em pleando procedim ientos en el servidor más poderoso para sum arizar los dalos y pasar sola m ente el conjunto pequeño de resultados a través de la red. Claves externas redundantes. U no de los pasos de des norm alización m enos restrictivo es incluir claves externas adicionales en determ inadas tablas para reducir la cantidad de uniones de tabla requeridas para encontrar un registro. E sla técnica funciona en los casos en donde existe una relación encabezado/detalle que se extiende a m ás de dos niveles. La figura 9-20 m uestra un ejem plo com ún de un pedido que es enviado en m uchos em barques, cada uno con un nivel adicional de detalles del embarque.
F igura 9-20, Fragmento HRD de pedido.
U na instancia de detalles del em barque sólo describe a un embarque. U na instancia de em barque sólo es para un pedido. Por lo tanto, es derivable de esta estructura que una instan cia de detalles del embarque es para sólo un pedido. Imagine una consulta que debe regresar los detalles de embarque que están asociados con un pedido dado. Suponiendo que la tabla em barques usa un identificador arbitrario para su clave prim aria, la clave prim aria de pedido no reside en la tabla detalles del embarque. La consulta debe unir la tabla detalles del em bar que con la tabla em barques para obtener la clave prim aria del pedido, debido a que se encuen tra en la tabla em barques com o clave exlem a. Si cl desarrollador de la aplicación encuentra que la unión de embarques con detalles del embarque sería innecesaria, es una práctica segura colo car la clave prim aria de la tabla pedidos en la tabla detalles del em barque, y tam bién elim inar el costo de una unión (figura 9-21). Este tipo de desnorm alización es de hajo riesgo cuando se lim ita a la adición de otras referencias que son perm anentes y derivables.
AFINACIÓN DEL DESEMPEÑO
pRdfrio
261
-0 <
Embarque
.A.
-c<
Detalles del embarque
Figura 9-21. Una referencia redundante h a cia cl encabezado.
Colum nas calculadas. A unque los m odeladores de inform ación tradicional mente no especifican que los atributos derivables deban guardarse, puede ser de mucho interés para el desem peño guardar algunos valores que son continuam ente recalculados por la aplicación. A lgunas consultas pueden sum ar un conjunto de renglones de detalle a la velocidad del rayo, pero otras pueden m ostrar que tienen un tiempo de respuesta inaceptable. El guardar valores calculados es un com prom iso. D esplaza el costo de calcular el núm ero de la función de lectura hacia las funciones de creación, actualización y elim inación. K1 resultado será que las seleccio nes son más rápidas, pero el tiempo que se necesita para insertar, actualizar o eliminar renglones será m ás lenlo. debido a que cada acción que afecta los valores de detalle debe actualizar el va lor calculado. Para cualquier colum na derivada que se decida a guardar se debe ser capaz de garantizar la precisión de ese núm ero para cualquiera que pueda escoger leerla en cualquier momento. Vistas aplanadas. El último recurso de la desnormal izaci.ón es crear vistas aplanadas de los datos. I .a desnormali¿ación es más efectiva cuando se limita a las funciones de reporte de alto volum en de una aplicación. Es particularm ente problem ática y peligrosa cuando se em plea en áreas de la aplicación que sufren actualizaciones constantes y dinámicas. Un método para la creación de vistas o extractos para reportes es unir previam ente tablas, tal com o la adición de inform ación de la tabla de clientes a la tabla de facturas, l,a técnica se enfoca en cl lado “ uno" de una relación uno a muchos para poner inform ación derivablc más cercana a la tabla de destino. Esto crea colum nas redundantes en la base de datos, pero está di señado para evitar la unión de una gran cantidad de tablas para llegar a un solo conjunto de resultados (figura 9-22), Otro método es aplanar las relaciones encabezado/detalle (figura 9-23). Esta técnica se concentra en eí lado “m uchos" de una relación uno a muchos. D a com o resultado valores de datos de inform ación de renglones redundantes para las colum nas de encabezado que deben repetirse en cada renglón de detalle. Este tipo de desnorm alizacm n radical debe quedar reservado para las funciones de reporte de alto volum en de la aplicación. Deberá evitarse en el procesam iento de transacciones en vivo. Una vez que una transacción ha llegado a determ inado punto en su cielo de vida, tal com o cuando es facturada, muchos de sus datos son perm anentes y ya no pueden ser cam bia
262
Capítulo 9 / EL DISEÑO DE BASE DE DATOS
dos. La creación de extractos grandes aplanados de este tipo de datos os una buena solución para muchas de las funciones de reporte de tin de m es que trabajan a partir de una "fotografía” de los datos tom ada en un m om ento fijo. FACTURA (vista aplanada) Número de factura
ID de diento (ce) Mombre del diente
'
Código tic es'ado !ce}
Nombre del estado
Fecha 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
t
Redundante con la tabla CLIENTE
12-21-96 -•-A '■
%•ü ■í¿ •? i'síSWs
Redundante ton ¡a tabla ESTADO
Figura l)-22. Hl “ lado de uno” en tina vista aplanada.
CONCEPTO DE FACTURA (visla aplanada! N ijjrn ro dfc factura (Cü)
Número do concepto
Fecha de factura
ID del cliente (ce)
Código de producto
Cantidad
Precio 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
12-001 OOí !?¥'^ J ¿«VjV.Í.V *•’ •*j?*tf-j.
12-21-96 1
H2432
LJ567
45
S 3 /4
i
i
t t
Información repetida de la tabla FACTURA
F igu ra 9-23. El “ lado Je m uchos’ en una vista aplanada.
1.a idea de desconectar las tablas que se requieren para cl reporte de las que se usan para el procesam iento de transacciones es un tem a central en el concepto alm acén de datos. Un alm acén de datos es una base de datos separada del sistem a (o sistemas) de producción que se m antiene >intTonizacia con datos de producción o se actualiza periódicam ente. Ll almacén de datos está diseñado y optim izado específicam ente para consultas y reportes. H ay m uchas he rram ientas de almacén de dalos nuevas y em ocionantes que perm iten que los usuarios recu peren fácilm ente sus propios datos, los manejen en el cliente, creen reportes y pasen inform ación a los dem ás por m edio de correo electrónico o por Internet.
AFINACIÓN DEL DESEMPEÑO
263
Las herram ientas de alm acén de datos han llegado a ser populares por varias razones. Si cl sistem a de procesam iento de transacciones está muy norm alizado, el almacén de datos puede estar parcialm ente desnorm alizado para proporcionar acceso m ás rápido y soporte a las con sultas de usuarios finales. Si hay varios sistemas de procesam iento de transacciones antiguos en la com pañía, llenos de archivos y tablas desnorm alizados, el alm acén de datos puede ser d i señado para que esté todavía más norm alizado que los sistemas de producción, proporcionando un lugar en donde los usuarios pueden encontrar datos consolidados y de detalle sin tener que m eterse en los laberintos de sus sistemas heredados. M ediante la separación de las tablas que se usan para las consultas de los alm acenes de datos de las que se usan para ia producción se reduce el estrés sobre los recursos en la base de datos de producción y se dism inuye la cantidad de usuarios simultáneos que pueden tratar de lle gar a los m ism os datos de producción. También proporciona la opción de ubicar por completo el alm acén en otra máquina para elim inar totalm ente el impacto que pueden tener los grandes trabajos de reportes sobre la m áquina de procesam iento de transacciones. L a n z a 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 rnoinloreado. La adquisición de hardw are es un caso clásico de presupuesto estrictam ente monitoreado. 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.
264
Capítulo 9 / EL DISEÑO DE BASE DE DATOS
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 identificador 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?
Capítuio 9 / EL DISEÑO DE BASE DE DATOS
266
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 procedin 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 ID :: QK0G2 P SS ¡03> :
ORDEft fiNTRY XSXXSXX
ORDEfí._NBR: 12-Q Ü 3 4 CUST_NBR: 83~3421~H A D D R _ L I : 700 JJ Á £ D R I íIN B
2 : ^U X ^E
fifi
ORDE5R DATE; ± 2 / 2 1 / [J A V A TS T1UT COFFÜE SHOfc]
¡LOO_______________________
CITY;
L lí í f i
S T : jSA
PRD CD
ÜL Ü2. D3
PRD DE3C
OTV
WHOLS SEAN- - 20 I B B£ FAÍ'ÉR F I lT E f t 1 00 0 CT PAPER CÍJPS S 0 2 / 2 0 0 CT
10 D 50 _10.
TAS_C
P F l HEÍliF
£7.
P r? F IR S T P F 10 SACX
B3T
ItJV_CD: 3!rwr tWTTPJí: N30
O R D TYPE:
D X fi
D LV M P H :
D IS C _ C D :
4M 5
CRB. CD:
5 T O R g _ N B P .:_ L 0
SLSPR SNi
p r .p
2XP: 9S 01Ü -Q 123
USfXT PRICE 9 5 .0 0
S2T PRICE
E¡A
§
EA EA
% 25,aa
9 5 0 0 .0 0
£50.00
S 6 ,5 0 SUS_TOTAt» TAS TOTAL
__ 6 5 .0 0 9 8 1 5 .0 0
0,00 9 8 1 5 ,OD
RCPT: Y
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.
Capítulo 10 / CONCEPTOS DE INTERFAZ GRÁFICA DE USUARIO
270
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.
272
Capítulo 10 / CONCEPTOS DE INTERFAZ GRÁFICA DE USUARIO
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."
CRITERIOS PARA EL BUEN DISEÑO GUI
273
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".
Capítulo 10 / CONCEPTOS DE INTERFAZ GRÁFICA DE USUARIO
274
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 i OceanRideF Ür:ean Rider Ocean Rider Ucean Seek-íi Linean Seeker Ocean Vision Ocean Loaner Hi-iean Loaner Ocean Cruiser
Í V m m eÁ V 24.... ..... B1036 B1096 V24 B1036 V24 V28 *1*7 _ B147 V2£¡ B12 ......... V22 GC8 V34 E¡C6 V34 EC12 V39
Vancouver, BC
Tacema, WA San Francisco, CA Vancouver, BC i Tacema, WA Vancciover, BC ;San Francisco, CA Los Angeles, CA San Diego,. CA
1-2020-4 1-2024-1 2-5053-1 11-2031 -1 4-2120-1 1-2Ü63-1 2-5143-1 2-5201 -1 Í3-5G65-:: ■ iJ
■±l'J
- 'f f if o L Í '- A ^en 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-
CRITERIOS PARA EL BUEN DISEÑO GUI
275
h S - ^ T r í T C SUS VentaaaS SS han PUt:St0 Cn b Ian c a súl° Para descubrir que han carabiado 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^a que bíiscai 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
Capítulo 10 / CONCEPTOS DE INTERFAZ GRÁFICA DE USUARIO
276
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 9931
d -í s i í m
-----
O
;Acmé Beverage St Flocket Fitd, Inc.!112/21/96
:
527.50jTentative SS.COjConHimed
101 _ J 101 :3932
¡JoeJoe's Pizza
|1 12/21/96
;
101
¡9933
iThe Slug Pit Bar & Giill
112/21/96
;
Toi
I9934
Fem's Department Store
¡12/22/96
101
9935
The Lobhy Shoppe
12/22/96.
101
9936
:Washington Plaza A?sociation
101
:9937
;The Metro Cafe
Í9938
■Aorne B 3vera ge ít Rocket Fue], Inc. Í12/2 2/96
101
" ¡9939
' 37th Street Investors
465.15?Shipped 26,450.12jFi!led 1,126.8S Back-Qrdered 1G.2i; Canceled
H > 2/22/96 ] l 2/22/96
101
¡12/22/36
.
654.78 Confiirried 391.21' T entative
*
1,654.00jCcinfi[rned
Figura 10- 6, Una ventana objeto-acción típica.
í?¡
CRITERIOS PARA EL BUEN DISEÑO GUI
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
278
Capítulo 10 / CONCEPTOS DE INTERFAZ GRÁFICA DE USUARIO
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.
CRITERIOS PARA EL BUEN DISEÑO GUI
279
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 102304
Cód transp
5S023 |
03
Fecha_ped
Núm plañía
| 21-12-96
Cód_pHr ven
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 .
TB A SiSííJilH :
Q¿
OF.DEKJ.WSS: 1 2 / ; 1 / 9 6
PLANT__NSR:
¿¿
B L S _ E F .S H ¡
ilE L P
PFS F IR S T
PP10
BACK
rK T R P .]
BST
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.
*
Selección d é l clie n te
t
Man
0
M a n ív ittir: T ra n s fe r I íV;* Jk, ttanheira 3 li**í& rc lle E Co. Ma npcmrej: T ampo ¡ca r i es , MaTVUÍ a cttt rjkn-cj I n t é t-jia ^io 1M anutacturEC? N atLonal Manwa Refuse Ccimpany / M anzatta staamworks / M anzatta T ra n sís*: Co»
« *
k. i
* \
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.
CRITERIOS PARA EL BUEN DISEÑO GUI
281
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 Se !'■i s e Se Se L¡_se Se H lse Se
= "carr.i ó n ”
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 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 " req-.r. e r e non¡brn d e com par i a Lrciiiívoorziñl.ü 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 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 " r e q u i e r e regiG T.ro d e c o n te n e d o ri:: ~ é 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 " 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 ¿nioVaira) KI ejc i f m é to d o
gc
em b arq u e
:jll.:;ra ,
L c n g iu .id ,
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 peao a é r e o | Er±d i f
Li i m i t e de
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^airienie" 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".
CRITERIOS PARA EL BUEN DISEÑO GUI
283
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
D V001X
L a C ro ss e
B e tty
Sue
BSL
&
D V023X
G a rn ro d
R u s s o ll
D a v id
RDG
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
¡
9 i :*3
1
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
j
Sue LaCíoss
F ig u ra 10-13. La nueva ventana
,-
Order lleader.
v;; ,t
Capítulo 10 / CONCEPTOS DE INTERFAZ GRÁFICA DE USUARIO
284
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.
;t
Para un estudio a fondo ¿obre estos principios, vea tialitz, 1994.
1%0 >
1973.
CRITERIOS PARA EL BUEN DISEÑO GUI
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.
Capítulo 10 / CONCEPTOS DE INTERFAZ GRÁFICA DE USUARIO
286
- ; 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»
'!
^ " - - i i r r 1” ".r^'77Ts''T[;^"'V^7’'^rT^.7;^5ir’í ^fo*'
•
á | 2 -5 * * P Í
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.
CRITERIOS PARA EL BUEN DISEÑO GUI
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 « « c M M o f d . n Z m . ¡ n 5 ú t í,e
L“ « * “ * 10- 17
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
____ ____ ____
_|__ ^ ;
Í S nv :ía l ¡
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
|
o p o rtu n id a d para cancelar estos tip o s efe acciones.
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
= =
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 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
y
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 1 - U1^ a i
¡ El com a n d o ;'¡
:■'i.-v w n an m ^ in r ^de im u . .... se btl u Uhtí para q uritita rr n datos base ^de datos 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
• M --datos debe ser cci explícitaLdyyUUCatlaMacción de C i;í í:5;i ■' en la basn de obVia. Nunca auardta Hatnc 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
^ i s u r a 10-17. C aracterísticas de una GDI indulgente.
288
Capítulo 10 / CONCEPTOS DE INTERFAZ GRÁFICA DE USUARIO
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 mem 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
290
Capítulo 10 / CONCEPTOS DE INTERFAZ GRÁFICA DE USUARIO
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.
COHESIÓN DE VENTANAS
291
! 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 DE VENTANAS
293
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 subeonjunto 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.
Capítulo 10 / CONCEPTOS DE INTERFAZ GRÁFICA DE USUARIO
294
M sü E S
¡ D i d e i S e íe c tio n - S a íe s P e í son
1101
;>
:
fi1r¡:L::%J.;Sii.iíí
iffira/íi/ffi f:WfcT*I'.0 f Xii'í f S 'S i - J i j f « í i
........
101
9931
Actvie Gev?iage ¡i Flocl-et Fue!, kic. 12/21/96
j 101
‘9932
ÍJoe Joe's Pizza
12/21/36
i 'iqtT
!9933
¡TheSlugPíBffiM jrill
12/21/36
101
9934
Ifetrh Department Store
1 2 /2 2 /*
i 101 J
3935 _|The Ubby Shoppe
12/22/96
E 101”"
9336
¡Washington Plaza Assoeraibrt
12 / 22/se
= 101
;3937
'The Metro Cafe
12/22/%
; 101
9938
¡Acmé Beverage & Rocket Fue!, Inc. 12/22/36...
:
' ^ |o ^ Ñ n ^ b S 3 ^ S Í |s ^ ¥ > V > .yk"- ■
,■.
Í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
527.50 TetiUiiivé
Requestecf
BS.ffijConfirmed
¡Requested
465.15ÍShipped
lAuthorijed
’Authorized . , , 1,12£.8E(Back-0 fdered (Requeíted
26,450.1 ¿¡Füted
16.21 [Cancelad
_
¡Caneced
654.7EjConfirmed
iRequested
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^ait *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
296
Capítulo 10 / CONCEPTOS DE INTERFAZ GRÁFICA DE USUARIO
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ó.
COHESIÓN DE VENTANAS
297
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! ■
: ■Sports
:
.
.
Tips from TIM 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.
298
Capítulo 10 / CONCEPTOS DE INTERFAZ GRÁFICA DE USUARIO
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.
300
Capítulo 10 / CONCEPTOS DE INTERFAZ GRÁFICA DE USUARIO
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 autodocumenta.) 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
306
Capítulo 11 / EL DISEÑO DE INTERFACES EXTERNAS
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 do navegación de ventanas
Disposición de ventana
_L
í z Descripción de ventana
Miniespecifrcación ® da ventana
Especificación 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.
Capítulo 11 / EL DISEÑO DE INTERFACES EXTERNAS
308
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 exhaustividad 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 costeable 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.
PRODUCTOS DEL DISEÑO DE LA INTERFAZ EXTERNA
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 ™
7
do las v ™ , 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 Si „
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 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 m n í ^nii hbotones r ° gen S dlagramUS dc n e g a c i ó n lo menos amontonados, y e% cn no mostrar ni manIen"!’ rotulos deSU 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 .
A
__
Ventana A
Ventana B
A
R
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.
311
PRODUCTOS DEL DISEÑO DE LA INTERFAZ EXTERNA
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-
Capítulo 11 / EL DISEÑO DE INTERFACES EXTERNAS 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.
PRODUCTOS DEL DISEÑO DE LA INTERFAZ EXTERNA
313
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 docum 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
314
Capítulo 11 / EL DISEÑO DE INTERFACES EXTERNAS
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.
PRODUCTOS DEL DISEÑO DE LA INTERFAZ EXTERNA
315
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
316
Capítulo 11 / EL DISEÑO DE INTERFACES EXTERNAS
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
PRODUCTOS DEL DISEÑO DE LA INTERFAZ EXTERNA
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 abiertas en el marco MDI.
Guardar se aplica a hojas específicas 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
318
Capítulo 11 / EL DISEÑO DE INTERFACES EXTERNAS
precios que han sido guardadas anteriorm ente en e¡ sistema. Fl diseñador tenim iento de lista de precios sea una ventana principal y selección de lisia tana de respuesta. I,a ventana de com entarios de detalle de precios se abre está en la ventana de m antenim iento. Podem os suponer que el botón está cuando el enfoque está en un solo renglón de detalle de precios.
ha hecho que m an de precios una ven desde un botón que activado solamente
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?
ID d e jis ía de precios
iD identificador
No nulo
Rcgión_de mercado
CharílO}
No nulo
Füchi) en_vigor
Fecha
No nulo
Fecha_df: expiración
Fecha
No nulo
Estado_activo
CharfS)
No nulo
¿CP o CE? ' CP CÉ apunta a fa tabla de región de mercado
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
Decirnal(9,2}
No nulo
Precio_unita rio
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.
319
PRODUCTOS DEL DISEÑO DE LA INTERFAZ EXTERNA Monten ¡miento ite lista de precios _________ Región de mercado
En vigor:
Expira:
Estado activo
Lista ríe precios: Código ríe producto
Descripción de producto
Precio unitario
Comentario de detalle
m 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
Capítulo 11 / EL DISEÑO DE INTERFACES EXTERNAS
~
^
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 ^ut; í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
#
S
H
^
’=
de selección es {* p r i i L f q u e se 1 '1^ ^ 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ñap 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 Detalles
Selección de lista dp, precios A A
Com enlarios de detalles de precios
Figura 11-16. E l diseño #2 abre primero la ventana de selección.
PRODUCTOS DEL DISEÑO DE LA INTERFAZ EXTERNA
321
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
322
Capítulo 11 / EL DISEÑO DE INTERFACES EXTERNAS
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
PRODUCTOS DEL DISEÑO DE LA INTERFAZ EXTERNA
323
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
Capítulo 11 / EL DISEÑO DE INTERFACES EXTERNAS
324
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.
PRODUCTOS DEL DISEÑO DE LA INTERFAZ EXTERNA
325
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 de línea producto |"y
Descripción de producto
Unidad de Precio Cantidad medida unitario
Subtotal
m ▼ Impuesto | Toral I G u ard a rj j
■
.
1 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.
Capítulo 11 / EL DISEÑO DE INTERFACES EXTERNAS
326
Descripción de ventana Barra de título: Menú: Tipo de ventana:
Captura de ninguno Aplicación
pedidos
|núm ero de pedido]
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.
PRODUCTOS DEL DISEÑO DE LA INTERFAZ EXTERNA
327
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 cierto y E! usuario es m iem bro del g ru po de personal de ventas auto rizado
If modo = insertar obtener siguiente número de pedido insertar dw pedido 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 tostransició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-
328
Capítulo 11 / EL DISEÑO DE INTERFACES EXTERNAS
El cliente coloca pedido
‘2? _a>
£
c
2 5
Asistente de producción
Evento/autorización de usuario
Representante de vfinlas
o
Gerente de producción
plorar el sistem a com pleto y conduce a una mayor com prensión de las diversas tareas que hay alrededor de ellos.
*•322CJ E
GJ
LU T3
8
X
El departamento de crédito aprueba pedido
X
i
El departamento efe producción asigna pedido
X
X
La planta surte el pedido del cliente
X
X
La planta envía el pedido del cliente
X
X
Contabilidad factura cl pedido del cliente Mercadotecnia envía catálogo por correo
c ‘G o ra
i
X X issd::i
i1
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 comunicacionalm 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. !^a 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.
PRODUCTOS DEL DISEÑO DE LA INTERFAZ EXTERNA
329
Figura li'23. D iag ram a de transición de estados p a ra estado de pedido.
101 101 101
9933 jlhe Slug Pit Bar !12 / 2 2 m
F igu ra 11-24. D isposición de una ventana para la
2E,450.12Fil!ed 1.126.88 Elack-Uidered
15.21 Caneeled 654.7S Carifirmed 991.21:Tentative
selección de pedido.
Capítulo 11 / EL DISEÑO DE INTERFACES EXTERNAS
330 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.
PRODUCTOS DEL DISEÑO DE LA INTERFAZ EXTERNA
331
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.
332
Capítulo 11 / EL DISEÑO DE INTERFACES EXTERNAS
Especificación de campos : Nombre de objeto:
dw pedido
Estilo de presentación:
Formato libre
Campos: Nombre de columna
Nombre de tabla
Requerido
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)
N
N
Puesto por í_clien.. selec
Visible Actúa lizable
Reglas
No mbre_de_cl lente
Cliente
s s
S
S
f_clien. selec
Dirección
Cliente
N
S
Puesto por f_clien_selec
Ciudad
Client 3
N
S
1Código de. estado
Clienta {cej
N
{Códige_postal
Cliente
N
Fecba de pedida
Pedido
S
Número de tienda
Pedido (ce)
s
s s s s
s s s s s s
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
Puesto por f. clien selec '' / Código. de_estado DDL Puesto por f_ciien_selec Fecba actual predeterminada Tienda del usuario oredetermircada
Campos: ] Nombre de columna
Nombre de tahla
11D_de_co nce pto_d e_p edld o Concepto_de..pedido (cp) ID de .pedido
Concepto_de_pedido (ce)
Número_de_línea
Concepto_de _pe d¡do
Cód igo_de_produ cto
Concepto_de_pedido (cej
Descripción de. producto
Producto
Cantidad
Concepío_de_p ed :do
Unidad_de_mcdida
Concepto de ped'do
Precio_unitario
Concepto...de ..pedido
Totaljinea
Concepto de .pedido
Impuesto
Pedido
Total
Pedido
Requerido Visible Actuaíizable
Reglas
S
N
N
Obtiene siguiente ID en nuevo renglón
s s s s s s s s s s
N
N
CE hacia íabla de pedidos
S
N
Número automático
s s
S
Selección de f_prod_código
N
Puesta por t_prod_código_selección
s
S
0 < cantidad < = 1000
s
N
Puesto por f_prod_código_selec
s
N
Puesto por f prod código selec
s
N
Precio unitario
Ftr
N
F_ca¡c_ventas impuesto
Ftr
N
Suma (tota IJÍnea) + impuesto
Figura 11-26. Un ejemplo de especificación de campos.
x
cantidad
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-
Capítulo 11 / EL DISEÑO DE INTERFACES EXTERNAS
334
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 de selección en la ventana selección de cliente y hacer clic en
Nombre de cliente parcial, región de ventas (opcional).
El sistema debe regresar un listado de todos los clientes cuyo nombre comienza con las primeras letras 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.
Error: el sistema regresó clientes sin tom ar en cuenta la región de ventas especificada.
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” .
336
Capítulo 11 / EL DISEÑO DE INTERFACES EXTERNAS 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, posicionar 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 pseudocó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
338
Capítulo 11 / EL DISEÑO DE INTERFACES EXTERNAS
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.
340
Capítulo 11 / EL DISEÑO DE INTERFACES EXTERNAS 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 especializació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.
Capítulo 12
346
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
v e n ta n a
v e n ta n a
R e d im e n sio n ar 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^a 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^uaics soporten c l concepto de variables públicas y métodos privados.
PRINCIPIOS BASICOS DE LA ORIENTACION DE OBJETOS
347
form ación que está contenida dentro de un objeto, nunca se podría estar seguro de su implcm 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.
Capítulo 12 / EL DISEÑO DE COMPONENTES INTERNOS
348
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). -.r-ins 1 : VENTANA
tot
var
•
.• .
:".“EÍÍTJ\NA
:
VKNTANA. 1U c rv o ;
: • V K M T 7 \N A .n u c v ;;;
PRINCIPIOS BASICOS DE LA ORIENTACION DE OBJETOS
349
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.
Capítulo 12 / EL DISEÑO DE COMPONENTES INTERNOS
350
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.
PRINCIPIOS BASICOS DE LA ORIENTACION DE OBJETOS
351
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 necesia tener un método correspondiente para Cerrar. Cuando cream os un objeto, ventana3, como
352
Capítulo 12 / EL DISEÑO DE COMPONENTES INTERNOS
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 de pedidos
R ec o n o c e d o r d e e v e n to s 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.
358
Capítulo 12 / EL DISEÑO DE COMPONENTES INTERNOS
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 embar¿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.
Capítulo 12 / EL DISEÑO DE COMPONENTES INTERNOS
360
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
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...
JAN
01
Concepto de embarque
J
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
DERIVACIÓN DE LAS CLASES DE LOS DOMINIOS DE NEGOCIOS
361
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.
Capítulo 12 / EL DISEÑO DE COMPONENTES INTERNOS
362
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 opcionalidad 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^e-Joncs, 19 9 1.
'
l-l acoplamiento es una medida de la dependencia de un componente de software con respecto a otro. Prepor 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.
363
DERIVACIÓN DE LAS CLASES DE LOS DOMINIOS DE NEGOCIOS
Figura 12-12. Un diagrama de elase que muestra la herencia de superclasc/subclase. ID de vehículo Capacidad de pasajeros Velocidad máxima
Compañía
Puede estacionarse legalmente en Avión
Tren
Autom óvil
Espacio de
■10................o<3 estacionamiento Está reservado
Envergadura A ltitud máxima
p a ra
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.
364
Capítulo 12 / EL DISEÑO DE COMPONENTES INTERNOS
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.
DERIVACIÓN DE LAS CLASES DE LOS DOMINIOS DE NEGOCIOS
365
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.
366
Capítulo 12 / EL DISEÑO DE COMPONENTES INTERNOS
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.
DERIVACIÓN DE LAS CLASES DE LOS DOMINIOS DE NEGOCIOS
367
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 implementado 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.
368
Capítulo 12 / EL DISEÑO DE COMPONENTES INTERNOS
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.
DERIVACIÓN DE LAS CLASES DE LOS DOMINIOS DE NEGOCIOS
369
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
370
Capítulo 12 / EL DISEÑO DE COMPONENTES INTERNOS
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
372
Capítulo 12 / EL DISEÑO DE COMPONENTES INTERNOS
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 para cualquier producto en donde el tipo_de_producto - "especialidad"
Notificar al gerente de la línea de productos
En la actualización de inventario.saldo cuando inventario.saldo caiga por abajo d eí producto.punto. de_reorden
Generar resurtido de producto
En inserción de deialle_de_plan de ventas o en actualización de detalle de_plan_de ventas.gananciasjoroyectódas o en e lim ina ción de detalle_de_plsn de venías
Volver a calcular plan._de_verilas.ganancra_.proyectada toial
F ig u r a 12-22. A ctivadores y procedim ientos de ejem plo. Tabla
Columna
Clientes
-
Concepto de pedido
Tipo de producto
Artículos de inventarío
Saldo actual
Detallo de ventas
Ganancia Proyectaría
Concepto de embarque
Ca ntidad
jí™
Inser ción
Actual ización
Flimina- Activador ción
Procedimiento
X
Nuevo Cliente
X
Producto especial X
X
X X
.,
X
Notificación a gerente de crédito Notificación a gerente de producto
Inventario bajo
Creación de pedido de inventario
Cambio de deLalle de ventas
Recúiculo de ganada total
Cambio de cantidad '
/: r
$
. . - v r í í i ^ ; J J/j'f-SÍÍÍJ:
Notificación a gerente de planta 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Ü.
Capítulo 12 ! EL DISEÑO DE COMPONENTES INTERNOS
374
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.
Capítulo 12 / EL DISEÑO DE COMPONENTES INTERNOS
376
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 rcutilizan 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 plem 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 rcingenierí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.
384
Capítulo 13 / DIEZ MITOS DEL DESARROLLO CLIENTE/SERVIDOR
ÍH£ (¿ E 6M F U W A V O T O D O S LOS y o m - o e . c e c o w la s iM reef-A r.e S pe c?.ícaí.ída9 vicnJA í. o u c
QMFí.t.'MtMre iwscere
í.tS uw '/letv H A S res?/
v ja ;.£ CL íCAn¡-LíD...
fj . D '& r.o
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
386
Capítulo 13 / DIEZ MITOS DEL DESARROLLO CLIENTE/SERVIDOR
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.
388
Capítulo 13 / DIEZ MITOS DEL DESARROLLO CLIENTE/SERVIDOR
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 Seattic 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
390
Capítulo 13 / DIEZ MITOS DEL DESARROLLO CLIENTE/SERVIDOR
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
el
393
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á deenm 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 comilcjos. 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. Ilayuna 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
402
Apéndice / ESTUDIO DEL CASO McVET
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^iCjrZLEFír'IICO BELLIDO: ^ DIRECCICT^; _1.00WEST
HARKET
J i-:r
yp^Rl KOr-'ÜKE: idJSKJ
_|
11K:^2_NÍ)I-Í3R^: DUCTi:
j
_kc)vf?Rr;; __
i
_1 C ? :
: PS1 19 1
:-íí\ za_cíjAVJ\ :
FDK: 1 - 1 - 9 7 ! K M : 1 - 1 - 9 5 i SRXQ: K JM :________ } &FXC:
12 i 03 !
T?AZA_. C l ,AV71
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 1'0Ií3I\T7i?sI0¿ : DUCIiLG£ AK'LIUTlii i-2i TAS PATAS Tj
¿ii r
a
M| F| _\
_í
•:;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.
A péndice / ESTUDIO DEL CASO McVET
404
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
ÜQ: s f i r v t r: i (3£;
de
_j
ÍHDHGA SNCvíTOFAD]
STmTTTOí; VETERiKARlüiJ: v a c : : : n a c :t ó m _
FFM Z
I T r _ A T /^ ] i^ \'r o a
r;7: PPDTDOÍ3
VISO'. .'I 'j_|KCrZ-í .
■wOHílS
a c : . c a t .a m t f n t o :
X J L A V /O Ü
l a v a jo
K A K T K M IK lE K T O
A N T 'T P r r r ^ A j i
i- l i l i
fe r r o
m a no
¿
-"... í.’i a v k : _______ |
l o w e : ______|
ik t r ü v al
l’l a v l
/
c:c j ; t e
V IS IT A
A
pzn.o
va
v a c :.:n a c t üm _ . i
(. :ae
de
ik t r ü
: r-rru o v a c
TRA7AM [ j'jKTC >1AKI-AL AMTTPTTTÁIAS r; T I\7 F P F p f il o _ | L 1K P1E Z A JEN'l'AT.
•
v a c : ; n a c .t óm _^
: ______|
E STZ:R i L I ZAR T,A W i C i K A
K Ü T 1V C
L’L A V E :_____ [
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' NOTA: ¿L, PEK7Í3 K7. HEVÜI.CÓ ~S
=
S jA R D A S
Fí
at ,frct=aí ; ¡’líSCALS KUIHTO, APT.TCAR 'l'JiKAPlA 1)^: CCLCN-A
?7P.T(:i
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.
406
Apéndice / ESTUDIO DEL CASO McVET
“ 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, supervisora 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.
408
Apéndice / ESTUDIO DEL CASO McVET
“ 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.”
410
Apéndice / ESTUDIO DEL CASO McVET
“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 vestidores 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 Keating 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 El El Ei El
cliente coloca pedido para perro em pleado pregunta qué servicios de acicalam iento se solicitaron para un perro em pleado inform a que se ha concluido con el servicio veterinario pregunta qué servicios m édicos se solicitaron para el perro 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.
414
Apéndice / ESTUDIO DEL CASO McVET
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 McVct. 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-
Apéndice / ESTUDIO DEL CASO McVET
416
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 bancario, 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.
RESPUESTAS A LOS EJERCICIOS
417
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í!-
418
Apéndice / ESTUDIO DEL CASO McVET
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 írecue 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.
RESPUESTAS A LOS EJERCICIOS
419
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
Apéndice / ESTUDIO DEL CASO McVET
420
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.)
RESPUESTAS A LOS EJERCICIOS
421
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
RESPUESTAS A LOS EJERCICIOS
423
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 ralendarizació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.
424
Apéndice / ESTUDIO DEL CASO McVET 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
RESPUESTAS A LOS EJERCICIOS
425
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.
426
Apéndice / ESTUDIO DEL CASO McVET 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
RESPUESTAS A LOS EJERCICIOS
427
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-
Apéndice / ESTUDIO DEL CASO McVET
428
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.)
RESPUESTAS A LOS EJERCICIOS 2.2
429
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 priorizar 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.
Apéndice i ESTUDIO DEL CASO McVET
430
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-
RESPUESTAS A LOS EJERCICIOS
431
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.
432
Apéndice / ESTUDIO DEL CASO McVET 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
RESPUESTAS A LOS EJERCICIOS
433
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.
Apéndice / ESTUDIO DEL CASO McVET
434
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 mem 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.
RESPUESTAS A LOS EJERCICIOS
435
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, Pendergast 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-
436
Apéndice / ESTUDIO DEL CASO McVET 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.
RESPUESTAS A LOS EJERCICIOS
437
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.
Apéndice / ESTUDIO DEL CASO McVET
438 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
Reportes de ventas
Ventas, detalles de cuentas por cobrar e inventarios
Figura A-7. Diagrama de contexto para operar establecimiento McVet.
439
RESPUESTAS A LOS EJERCICIOS
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 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
el p erro
Apéndice / ESTUDIO DEL CASO McVET
440
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-
RESPUESTAS A LOS EJERCICIOS
441
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 del evento: Descripción:
El cliente coloca pedido para perro. 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.
Apéndice / ESTUDIO DEL CASO McVET
442
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 Rccibo de pedido 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.
Respuesta: Efecto:
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.
RESPUESTAS A LOS EJERCICIOS
443
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í
444
Apéndice / ESTUDIO DEL CASO McVET
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)
RESPUESTAS A LOS EJERCICIOS
445
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.
Apéndice / ESTUDIO DEL CASO McVET
446
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: D efinición:
Ubicación McVet 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, McVct 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:
Nom bre
Requerido
Tipo de Dato
C ódiao de ubicación S
Char(2)
N o m bre de ubicación S
Char(3Q)
Definición 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. 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 de secuencia
S
'n te g e r
Cada u b ica ció n M cV e t asigna n ú m e ro s de pedido 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: D efinición:
Cliente 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 cuentacon McVet,
RESPUESTAS A LOS EJERCICIOS
447
A tributos:
Tipo Nombre
Requerido
Nú m a ro de c lie n te
de dato
Definición
Char(S)
Un id e n tific a d o ' ú n ico asignado p o r ei siste m a 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 (180)
La d ire cció n de la calle o a p artado p ostal del clie n te 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
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
de datos.
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.
448
Entidad: D efinición:
Apéndice / ESTUDIO DEL CASO McVET
Perro 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:
Nom bre
Requerido
ID de c e rro
Tipo de dato
Definición
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 do del peso d e 1perro registrado en el ú ltim o pedido
p e so en kilos
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 o esterilizada
s
Yes/No
Un ca m p o S/N que indica s: el perro ha sid o castra 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 . Valor p re d e te rm in a d o = K.
Entidad: Definición:
R a /a 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:
N om bre
Requerido
Tipo de Dato
Definición
ID de ra^a
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
RESPUESTAS A LOS EJERCICIOS
449
c o n t in u a c ió n
N om bre
Requerido
C andidato para Perro Feliz
S
Tipo de dato Yes/No
Definición Indica si la raza p u ede pasar por ei m ód u lo sanitario 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:
N om bre
Requerido
Tipo de Dato
S
CharOO)
N ú m ero de e m pleado
Definición El n ú m e ro de em p le a d o asig n a do p o r el siste m a 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.
Apéndice / ESTUDIO DEL CASO McVET
450
JJedido 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.
Entidad: Definición:
A tributos:
N om bre
Requerido
ID de c e d id o
S
Tipo de Dato
Definición
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 en kilos
Integer
Ei peso del perro y actualizado en pués de que se para reg istra r el
en kilos es registrado en la báscula el p e d id o in m e d ia ta m e n te d e s crea el pedido. SI la báscula falla 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 del problem a
N o te
Para v is ita s m éd ica s se le pide al c lie n te que 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
IMombre
Requerido
M e d ic a c ió n actual
N
in s tru c c io n e s
N
Tipo de Dato N ote
Definición Para visita s m ódicas se le pide al cliente que liste 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 .
Note
especíales
Entidad: Definición:
Indica cu a lq u ie r in stru cció n de m anejo especial pa ra e ste pedido.
Concepto de pedido 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:
Nom bre
Requerido
Tipo de Dato
Definición
ID de co n c e p to de ped id o
S
Token
Un valor asignado p o r el siste m a para Id e n tifica r en fo rm a univoca una instancia de co n ce p to de pedido.
N ú m e ro de c o n c e p to cíe pedido
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 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 c o n c e o to de pedido
S
Char(1C)
Indica la condición del co n ce p to de pedido co n form e 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
Apéndice / CASO DE ESTUDIO McVET
452 c o n t in u a c ió n
Nom bre
Requerido
Tipo de 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.
Char(4)
Base de precio
Í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.
D ecim al
Cantidad
(5,2)
El ca m p o de cantidad se usa para reg istra r la 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: Definición:
Tipo de servicio 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:
Nom bre
Requerido
ID de tip o
Tipo de Dato
Definición
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 fo rm a unívoca una in stancia de tip o de se rvicio .
de s e rvicio N o m bre de tip o de servicio
Char(2ü)
D e scrip ció n de m e rc a d o te c n ia
N o te
La descripción oficial corta por la cual se hace referencia al se rvicio en ventanas y reportes d e n tro de McVet. La narración proporcionada por el d e p a rta m e n to 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
RESPUESTAS A LOS EJERCICIOS
453
c o n t in u a c ió n
Nom bre
Requerido
Tipo de Dato
S
Char(IO)
Clase de tipo de s e rv e io
Definición Indica si el tip o de s e rvicio está clasificado c o m o 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
de se rv ic io
La cantidad de m ese s d e sp u é s de la ú ltim a vez 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
especiales
Un ca m p o de te x to en d o nde pueden darse notas 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: D efinición:
Precio del servicio 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:
N om bre
Requerido
ID de p re cio del s e rvicio
S
Tipo de Dato token
Definición Un v a lo ' asignado por el siste m a para id e n tifica r 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 ¡nic 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^a 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. Lista = UNI, /H R , /KG.
Apéndice / CASO DE ESTUDIO McVET
454 Entidad: D efinición:
Cargo extra por raza 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 Nom bre
Requerido
ID de carao
S
de Dato Token
Definición Un valer asig n a do por el s iste m a para id e n tifica r cr, fo rm a unívoca una instancia de cargos e x tras
extra oor raza
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
Precio u n itario
S
M oney
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. 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. Lista = UNI, /H R , /KG.
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.
RESPUESTAS A LOS EJERCICIOS
455
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 recepcionista 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-
Apéndice / ESTUDIO DEL CASO McVET
456
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
Sufijo:
IM : A p e llid o :
n
Número de cliente:
i
D irección:
Teléfono en el día:
E stad o :
C iu d a d :
CP:
Teléfon o en la tard e:
n: Detalles del perro:------
Perros: Seleccionar nombre:
Nombre:
Sexo:
Peso:
"[Ti H /Castrado?; Raza:
Nacimiento
Alergias:
□ ¿ M u e rto ?
Kfls
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.
RESPUESTAS A LOS EJERCICIOS
457
C aptura d o podido - [Núnii-ra dt> p edido Nom bre del cliente: Nombre del perro I .■ " ■
E stad o d e pedido]
Número de diente Sexo: Peso: ' I Q [3 ¿Castrado? | ¡ Kgs
Naturaleza del problem a
Fecha de pedido:
Re¿a: a [ ■
¿Qk para Perro feliz? -
Medicamentos actuales:
Instrucciones especiales
—Elementos de pedido:------------------------------ ------------------ .________ Tipo de servicio en linea:
Orí- Precio Precio gen unitario: de base: Cantidad:
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
Mombre del tipo de servicio
o Sólo veterinario Precio unitario actual
. . ®cl° de baSH A
w
ir
Figura A-12. L a d isposición de la ventana de selección de tipo de servicio.
Apéndice / ESTUDIO DEL CASO McVET
458
F ig u ra A -13, La disposición de la ventana de selección de cliente.
Selección del pedido Estado del pedido
r
Número de pedido:
Fecha del pedido > =
~ 'w \ i
i
n
Establecimiento:
i
Figura A-14. La disposición de ía ventana de selección de pedido
ía
RESPUESTAS A LOS EJERCICIOS
459
La últim a ventana que dibujó Pendergast fue la ventana selección de pedido. El recepcionista 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.
Evento/ubicación de negocio Ei cliente coloca pedido
X
El cliente solicita cita para cirugía
X
El acicalador reporta term inación deE servicio
X
El veterinario reporta term inación del servicio
X
El diente recoge al perro
X
¡jí*
í 1
&
X
Cliente paga factura X
X
Es tiem po de registrar la actividad en la contabilidad general El usuario solicita reportes de ventas
8 1 1 1
X
Es tiem po para facturar a clientes con cuenta de crédito
El empleado hace ei corte de caja
Oficinas centrales
Apéndice / ESTUDIO DEL CASO McVET
Ubicaciones de establecimientos
460
X
X X
Mercadotecnia actualiza precios,'servicios Mercadotecnia crea envíos por correo directo
X
El inventario cae por abajo del punto de reorden
X
X
McVet recibe abastecimientos de inventario
X
El usuario solicita saldo de inventar'o
X
X
El cliente cambia datos del perro/cliente
X
X
i S ! I 8 ¡
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-
RESPUESTAS A LOS EJERCICIOS
461
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 ) Kos-.hr^. _c.e_ubi c:.. cj.-: C har : .!■S ) T ip c _ d c. u;;.; í:^;; i c r C::ür:£>; ~ J n y_n lLii'.í?r o . ..d
id :
C h a r(B ) Cha r" í 2 0 ) Cr.ar : 2 j )
"iUL'Iad
Cediere co s !. T-e ;éiü:io_í?r__o:_;v: :i To'-ó: cr: '.a -¿i^de
"r'ible P e r r o
P7^ I MAKY KEY ,
NT7T.T. KL'LL r
I-KIMAKY KEY,
va.rc:f':¡j i ^ C har ( 3 0) , C.’1: a r. i2) f C!:ar ; ID) , "h a r [1 } ,
d em perró
'J : “Í .T l O _ p O O C: t) k i O S ds-r
: : ¿¿c i x i L - n t o
NO- MUI ,L,
(
1 D_ d e _p e-r r o
” ftí'::i:'i
tCUT,",; ;
NULL :vú~ Kl; I,!,, n c : K'JLI.-,
í!ros:.Ci Lab", e R a z a ( '.^_ác_rs.z a Tcksri XotiI'j r 9._á e _ 1i-_ríj. z a CJriar f 3 0 ) C 'ündidazo_pa.ra_.?orr _'- e : 1 7. S o r. y . v i ' : da.de n No Le ) ;
Nrjni: r e
NC.
Lah_0 C l i e n t e
Ou s t. c-r.er _Kumb rj r Ape M i d e f'.'cT.h re ! r:--.cia__r:^c] : c'j Fr í.: f i j o Su::: j o i; : re¡:: c i c r
Crc
PiUMARY 'ZrW,
>JO" NO':
o k cn C.' :\a r f 2 C i
i II L Cl ü
:J? !Y A R Y
KOT NOT
NT7V.I,,
K.Jl Y ,
Apéndice / ESTUDIO DEL CASO McVET
462
Chur ; ! NCT KULL, Yes/Ncj NCT KL'LL, K o le , NOT NULL, Yey/Nc M:,c:r;.0 ' c ^ í- í b ; KOT MüLL '-Júnior o de c ^ ie iiL e 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 H.ic-o í c l G r o r c i ' a r a z a O'"). de -axal j ; .->ex o Cí¡3 :'.r(5f;n_o_enter: l i z a d a A', e rg i ;=s
C r e ía te “ a d i é Empleado K¿-'fiero ,.¿e_c-T.p^ ea do Apc I I "I e.e Ko^ndr e L nic ia_ _ '"i.ed ; ;¡ P re fije ;ru =i ; e L n ic iaie u T: p o _ d e _ e r p I e;;dn Create
t'OHLiGM KKY fOHLiGM KEY
i C hu'■ í 10 ) C’r.cr í /. 0 j Ch .:ir (2 j ) C har ; 1) , C har ¡3) , Ch,ir-;]! , C har ¡ 4 ) Char i7 ¡
'¿ubis Tipo de.servicio
KOT Küj_._ NO'i1 KLLL, KOT KL'LL ,
i'RLKAKY KKY,
MCI' KL'LL , MOL MULL):
'
LE _ d e _ t ip o _ d e_s-s rv - c i o T oken Müi:iiji'=_áe '.I p o do s e r v i c i e Di!K;:ripi'.,i 6 n _ ¿ ü _ n o r c a d o r e c r n a C I j se_cie_..ti p e de. s e r v i c i e C h a r i l ü ! Meces de .! n l . e r v a l o _ d e _ 5 c r v i e i o 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
MCL NULL Chur ¡30 ¡ No Lo NOT NU7.L, T rd.eye r,
I^JK : r-^Asiv :
KOT N'JLL) ;
C re ía te tai;L e P e d id o ! 1■K: MARY kot k l l l TT;_de_ped' do Token Kúnit? ro _ d e _ p e d : de C har (12) NOT NU.:., MOT KUT.T,, Pecha.. df>'. p e d í de D a te n c t tct;tT:, Kb :.ado_ d e '.. p e d i d o C h ar¡lü i 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, l'ORTTGK Múr.cro de c l :en:.e Char ¡E ? 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 ) , FOIiiiGN Cód I yo...de_nbieacicr:. C'r.nr-i?.) NOT M"JLL 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 KORY.l G'J TD cíe...perro 'Token KOT NJLL Hace r e t e r e n t i ü a ¡;-arr;j í TD de . p e r r o ) , FORLi;]N 'i'o:iiaaO_pOrC har !. 1C; KOT ÑUTI. 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
KOI' K'JL.'. Tni.ec e r C:: a i" v I 0 MT¡T KULL,
KÍ'IY ,
KEY KhlY , KKY KEY
PRIMARY XZY, MCI KL'LL, NGT KULL,
RESPUESTAS A LOS EJERCICIOS
463
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
464
Apéndice / ESTUDIO DEL CASO McVET 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
RESPUESTAS A LOS EJERCICIOS
465
leyera la tarjeta. Si el cliente no tiene una tarjeta de identiíleación rápida, cl recepcionista 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.
466
Apéndice / ESTUDIO DEL CASO McVET 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.
RESPUESTAS A LOS EJERCICIOS
467
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 A u to riza ció n de usuario, n o m b re de usuario.
Parám etros de entrada: 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 Archivo
Rótulo del concepto
Activado
Im p rim ir
A rchivo
Salir
Edición
Dcshacer
Cuando se hace clic
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
Siem pre
Ejecuta Cerrar
C uando han ca m b ia d o valores de d a tos
Regresa el valor de los datos ai valor a n te rio r Corta te x to hacia el portapapeles
Edición
C ortar
C uando hay Sexto se le ccio n a do
Edición
Copiar
C uando hay te x to se le ccio n a do
Corta te xto hacia el portapapeles
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
Edición
R eportes
Lista de re p o rte s
S iem pre
disp o n ib les
D espliega una lista de los 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
Ventana
Cascada
C uando al m e n o s una hoja está abierta
~üne en mosaico las hojas abiertas
C uando al m e n o s una hoja
Pone en cascada las hojas abierta;;
está abierta Ventana
Capas
Ventana
¡hojas abiertas]
■
C uando al m e n o s una hoja está abierta
Pone en capas las hojas abiertas
C uando al m e n o s una hoja
b n lista las hojas a b ie rta s por títu lo de ventana
e stá abierta Ayuda
Ayuda
[título de la ventana] C uando el e n fo q u e es-á en una hoja
Abre ia ayuda a nivel ventana
C o n te nido
S ie m p re
A b re el c o n te n id o de la ayuda
para la hoja cue tie n e el eníoque
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
RESPUESTAS A LOS EJERCICIOS
469
Disposición de ventana —Selección de cliente Selección
Nombre del cliente:
i
m
r ~
Nombre del cliente
Nombre deJ perro:
. p; i Número de cliente
Raza:
ip ! r
Nombre del perro
~
Raza A
‘ífgss
&■ ¥M¡ ü !
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 concuerden 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.
470
Apéndice / ESTUDIO DEL CASO McVET
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 A b re p e rfil de d ie n te , m o d o - n e w
Nuevo
S ie m p re
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 .. d e _ clicn te , m o d o = n c w rengión en d w _ s e le c d ó n _ 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 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
tiu e ñ o
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 cié p e d id os
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, ren g ló n en d w _ se le cció n _ n o m b re d e cliente, ID__de_perro, rio m b re _d e _ p e rro d e _ d ie n le
RESPUESTAS A LOS EJERCICIOS
471
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 de columna
i
Nombre de tabla
Reque V isua rido lizado
Actúalizado
Reglas
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
Nombre._de ra/a
Raza
Ejecuta búsqueda de ra/a
ID de raza
Raza
Puesto por la búsqueda de raza
: A ce p ta cadena parcial
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 de columna
Nombre de tabla
Reque- Visua- A ctua ndo lizado lizado
Reglas
i
Concatenar nombre + inicial m edia + a p e 'iid o + su fijo
N
I D_de_.perm N o m bre rie raza
Raza
s
I
s
N
'
Apéndice / ESTUDIO DEL CASO McVET
472
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
RESPUESTAS A LOS EJERCICIOS
473
Disposición de ventana —Selección de pedido
Selección de pedido {Nombre dei cítente - Nombre de! perro (opcional}}
NCmerc Estaos del pecico
1“ " " "
-ec"a oel pstílcc >=
!T| i
KÚTie'o Neutro de pedico cel ci eñe
de psd cío
I |
Estab ed-nlento
II
1*1
Pecha Norrare del perre del ped do
¿stado
: mm ÉB ' ' ' SfP Ira -' PPt ' B ¡ PP Wm .. H ' ^1
.. .
:.
¡A fH
' ■ .
.
'
-
■
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.
Apéndice / ESTUDIO DEL CASO McVET
474
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 de entrada:
nú¡riero_de_ciisn[e. nom bre_d3_ciiente, id__do_porro. nom bre do perro (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 Rótulo
Activado
Cuando se hace clic
-1 us car
Siempre
Recupera dw_selección_de_.ped;do usanuo criterio ds selección
Nuevo
Abre captura da pedido usando
Abrir
If d'.'7_er!ieT1o_de_se:ecc¡cn_ce_ped¡do, nc-'r,bre_de_ d ie n to y uw__i:ri!e'io_de_selet;c ún_de_pedldo, id_de_perro son NOT NL'I l (sólo puede coeoar un nuevo pedido si el d ie n to y oí perro están nombrados en la barra de t'tu o i Cuando el enfoque está en un renglón en
Borrar
dw_selecoión_de_pedido S ie m p re
número_de_c!iente, id_ de_perro, m ode = new
Abre captura de podido usardo id_de_pedido, m ode = m odiíy 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 ' eeoido
Cuando el enfoque está or¡ un ren g ó n de dw_ seieoción_de_pedido y estaoo_dííl_pcdido = nuevo o en proceso
Ejecuta procedim iento cancela podido
Entregar
Cuando el foco está en podido donde estado_ del_oed¡do te'm inado
Abre :a ventana de entrega de p e ro íloaavía no está diseradai
RESPUESTAS A LOS EJERCICIOS
475
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 de colum na
Nombre de tabla
Klúm ero_de_c líente
C liente
iD _de_pe rro
Perro
E stado_del_pedido
Pedido
Reque- V isua A ctua rido lizado lizado N
S
N
N
H
N
S
S
Reglas
Lista = todos, nuevo, en p roceso, te rm in a d o , cancelado, cerrado, no cerrado
Fecha_dol_pedido
Pedido
N
N ú m ero _de_ped¡do
Pedido
N
E stablecim iento
U bicación M cVet
S
s s s
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 o m bre de o b je to :
d w _ s e le cció n _ d e _ p e d id o
N
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
N
Puesto por lista d e sp le gable de e stsb íecim e n to
Apéndice / ESTUDIO DEL CASO McVET
476 Campos
Reque Visua A ctua rido lizado lizado
Nombre de colum na
Nombre de tabla
!D _de .pedido
Pedido
S
N Gm e rc_d e_pe d ¡d o
Pedido
N om bre del cliente
Sóio se desp.iega
\J
N
S
S
N
s
s
N
Reglas
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
s s
S
N
S
N
-echa ,de _p e d id o
Pedido
Estado .d e L p e d id o
Pedido
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 A ND AND AND AND AND A ND AND
C lien te. Número_de... cliente = Pedido.N úm ero_de_cliünte Perro-IL5_de_perro = Pedido.ID_de._perro Pedid o .N úmero_de_e 1ie n te = Núm ero_de_cliente Pedido.ID _de_perro = ID _de _ p erw Pedido. HsLcido_dül_pedidu = Estado_del_j>edido Pedido.Fecha_del_pedido >= Fecha del_pedido Pedido. Código_de_ubieaeión = ('ódigo_de ubicación Pedid o. Nú m ero de pedido = Núm ero_de _pedido
RESPUESTAS A LOS EJERCICIOS
477
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:
Agregar perro:
Eliminar perro s [Pedido nuevo j Abrir líttima pedido
□ ¿ M u e rto ?
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.
Apéndice / ESTUDIO DEL CASO McVET
478
Miniespecificación de ventana —Perfil de cliente ! Parámetros ; de entrada:
número_c¡e_cl¡ents, id_de_.peiro, m oci
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 Rótulo
Activado
Cuando se hace clic
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 renglón de perro en
S e le ct c o n ta d o r From ped id o W h e re Pedido. ld_de_perro = ld _ d e _ p e tro 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
ow _ se ie cció n_ d e _ p e rro
del desp lie g ue . End if Pedido nueve
Si no hay ca m b io s p e n d ie n te s y perro. M u e rto NOT = S
A b re captura de p e d id o s usando n ú m e ro _ de_cüente, id_de_perro, m o d o - nuevo
Abrir últim o pedido
Si no hay ca m b io s p e n d ie n te s
A b re captura de p e d id o s usando r¡ú m ero_de_ctiente, id_de_perro, m o d e - ú ltim o _ p e d id o
Historial de pedidos
Si no hay ca m b io s p e n d ie n te s
A b re se le cció n de p e d id o usando n ú m e ro_de_clier¡te, n om b re _ de _ cü e n te, id_de_porro, n o m b re _ d e _ p e rro
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
Guaidar
p e n d ie n te s
479
RESPUESTAS A LOS EJERCICIOS 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 de colum na
Nombre de tabla
N úm ero_de_cl ¡ente
C liente
Reque V isua A ctua rido lizado lizado S
S
N
Reglas
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
N o m bre
C liente
S N
lnicial_m edia
C liente
A p e llid o
C liente
S
Sufijo
C liente
N
D irección
C liente
N
Ciudad
C liente
N
Estado
C liente
NI
Cóciiyo p ostal (CP}
C liente
N
Teléfono en el día
C liente
N
Telefono en la tarde
C lie rte
N
N o m b re de objeto:
dw _ se [e cció n _ d e oerro
s s s s s s s s s s s
S
Lista ■= Sra , Srita., Sr. y Dr.
S
s S S
s
Edición en varias líneas
S
s
Lista = abreviaturas estándares
s s S
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
Apéndice / ESTUDIO DEL CASO McVET
480 Campos Nombre de columna
Nombre de tabla
Reque V isua Actúarido lizado tizado
Número. de_eliente
Perro (FKi
S
N
Reglas
Puesto = riw_manten¡mienío_de_cliente cúme ro._de_e liente
N
;
¡D_de_perro
Perro
s
N
N
Nombre_de_perro
Perro
S
Sexo
Perro
s
S S
Castrado_ester¡;¡zada
Perro
s s 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
Perro (FK)
S
N
N
Puesto por búsqueda de raza
lü_de._raza Pecha_de_naci miento
Perro
S
Perro
N N
S
Alergias
S
S
Muerto
Perro
S
s
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
Obtiene nuevo identificador en inserción ■ : Lista = M, H
Cuadro de verificación. Marcado = S
RESPUESTAS A LOS EJERCICIOS
From W here
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 Cliente 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
481
Apéndice ! ESTUDIO DEL CASO McVET
482
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:
. Nombre del perro:
Sexo:
i r~ Peso:
1 ¡ | H ¿Castrado? ¡_ Naturaleza dei problema:
Fecha de pedido:
i
l
_ _ ... ..........
Raza: E ¿Porro feliz ük?
] Kgs. j
~
Medicamentos actuales:
__________________________i i__________________________ ____
... .
i
Instrucciones repódales:
, - Elementos de pedido:----------------------------- ---------------------------! ! Línea
Tipo de servicio
Precio Precio Origen unitario de base Cantidad
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: rip o da ventana:
i C aptura de pedido 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 de entrada:
núm ero d e p íle m e , id de_perro, id_de nedide, modr.
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
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
Agrega' elem ento
Siempre
Eximirá'
Si el enfooue es‘ á en un salo
e le m e rto
'englón en d w .nünten¡m icr;to_de
; Cuando se hace clic Abr,r selección de tipo de servicio ^ara 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
_ccnceeto_ce_Ded¡do y es‘ ,=do_de _concep‘. c_de p e d :do no = c e ra d o
M arca' e. rerg.ón de concopto_oe_;:edida cara cue sea oorrado al Guardar, elim inarlo col desplegaos
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_
Cop.ar p e d d o
Si no hay cambios s n guarcar
C o n firm a r copia
die n te, sd_de_pnrro, m odo — m e d r cac¡ó.n
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 ped.do
Guardar
Cuando el enfoque está en un renglón on d w se;ccción_de p e d :do y estado_del pediuo = nuevo o en proceso
E e c u ta r el p ro c e d im ie n to cancelar c e d id o
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
'■
Apéndice / ESTUDIO DEL CASO McVET
484
Especificación de campo —Captura de pedido d w _ n u e vo_p e d :d o
N o m bre del objeto:
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
E stilo de pre se n ta ció n :
te , perro y raza para un nuevo pedido
Campos -----------
i--
■
A ctua Reglas lizado
Nombre de columna
Nombre de tabla
Reque rido
Visua lizado
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
S
N
N
s
i R ..
N om bre_de_raza
Raza
i C andidato_para_ Perro_Fel ?
Raza
N
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
;
RESPUESTAS A LOS EJERCICIOS
485
Campos Nombre de columna
Nombre de tabla
Reque rido
V isua lizado
A ctua lizado
N ú r :c rc_de_c,iente
C liente
S
3
N
N om bre de cliente
S.ó'g se despl ega
s
c
N
! Cliente
5
N
X
K
M
\o rr.b re .m cia L m e d a
Cl ente
N
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
\
5
Reglas
C oncatenar nom bre t niela ' me-dia + apellido sufijo
H sexo = VI, rótulo css’lracc. eise r ó tjlo = esterilizada
1n_do_r3za
P e ro iF<¡
S
■\¡
N
No-nore._de_raza
Haza
S
C;
N
Elegiólo para_ Perro_Feliz
Haza
s
S
N
ID_.de pedido
Peo ¡do
N
N
O o te n e 7 nuevo :dentfieador 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
s
Es~adomdel_pedirin
Ped:do
s
r echa_.del. podino
Pedido
s
3
■~eso_del_peire._ en kilos
Pedido
N
Natu raleza
Pediao
N
Estado inicia. = nuevo Desplegarlo en la b a ra de título
1
N
Pañería a ;a fecha actual cuando nuevo
S
5
Puesto por ia báscu a o cspíu'ado per e; us-jano
N
s
S
s s
s
N
N
Puesto a código de ubica ción a c tja l cuanco nuevo
N
N
P re sto a núm ero de ernp lesdo del usuario cuando nuevo
dcl_ problem a M e d lc a c ó n .a c iu n l
Pedid o
M
lnstrucciones_ ‘
Pedido
\
Código_d r;__uh ¡■nan: n r-
Pod:do
S
Iom 3do_oor
Pacido
s
S
e sp e cia os
'
!
486
Apéndice / ESTUDIO DEL CASO McVET
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 de colum na
Nombro de tabla
Reque V isua A ctua lizado lizado rido
IU_de pedido
ConcopT.c_de_ pe d :do ÍFK;
S
S
N
d iu o
Ccncepto_ce_ podido
5
Estaao_dei_ ^cn^ept'j_de_pec¡¡dü
Conceptü_de_ oedioo
Q
S
N
ü 'ig e n
C o rcep to _ ce _ pedida
S
N
N
iSi
Reglas
=oner - aw_mar'?e'iirniento_de_. ped:da ic_dc...pedido para conceptos nuevos
Núm erc_de_ ■::o 'i c a Dto_.(i r n
üsrsdo inicia! = NEW
Despliega el p rim e" caráctar :í 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_ d e_oedidc
s
S
N
Precio de base
Canea oto_ de_Dedido
s
S
N
Cantidad
Ccncaoto de_pedido
N
S
S
Concep‘ o_
S
5
\
S
S
S
s
ID_de tipo de servicio
ae_pedido
Nom bre_de_ti po d e rse rvicio
Tipü_ ae_se^vic.o
C a m id a d _ p a g a r11
\
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
RESPUESTAS A LOS EJERCICIOS
487
c o n tin u a c ió n
Nombre de colum na
Nombre de tabla
Tasa_de_¡m pyesto_ *
Parám etro
de sve nta s
del siste m a
Reque Visua A ctua rido lizado lizado S
N
O b te n e r tasa de im p u e s ta de ve n ta s de los p a rá m e tro s del siste m a
s
IVA *
N
Reglas
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 AND AND
C 1ie n te, N ú tn ero_de e lien le = jVíím e ro_de_clien te Perro.ID _de_perro = ÍD de perro R a /a J I) de raza = Perro.ID de raza
488
Apéndice / ESTUDIO DEL CASO McVET
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
RESPUESTAS A LOS EJERCICIOS
489
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 AND
C o nce pto_dc_ped ido.ID _dc_ped ido = ID ^de jie d ld o Tipo_de_servicio.TD_de_íipo de_servicio = Coneepto_de_pedido.ID _de. ti po_dc_ser vicio
490
Apéndice / ESTUDIO DEL CASO McVET
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 Nombre dei tipo de sen/icio
Precio unitario actual
Pretio 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.
RESPUESTAS A LOS EJERCICIOS
491
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
492
Apéndice / ESTUDIO DEL CASO McVET
Campos
Nom bre de tab la
Nom bre de columna
Reque Visua- Actúa- Reglas rido
lizable [izado
i
F:itrO
-
s
s
:D_..de,/iipo._de_serv¡do
7¡po_de_ssrv¡cio
s
\
N
Nompre_ae_l¡uo de_servicio
Tipo_de_servicio
s
S
N
ID_de_cargc_extra de_/aza \ :0T MULL., desplegar n o m b 'e en ROJO
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
Base_de_preciü
~¡po_de Prccio
s
VJ
s
Botones de opción en e. en cabezado. Lista - Todo, Sóio cuidados, Sóio veterinario
Fnd ;f
fn d if 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_ de_raza
Cargo__extra._ de_raza
N
N
N
P re c io .u n ita ro _ de_cargo_e>:tra
Ca^go_extra_ de_raza
N
N
N
Base_de_précio óe_cargo_ extra
Cargo_excra_ d e jo z s
N
N
:\
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
i í
RESPUESTAS A LOS EJERCICIOS
493
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 A ND A ND
AND AND A ND
Ti po_de_ser vi cío. Activo = “S ” Precio_de servicio.ID _de_tipo_de_servicio = Tipo_de_servicio.ID _de_tipo_de_ servicio (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)) Cargo,. extra_dc_razaJD _de_lipo_de_servicio = Tipo_de_servicio.ID _de_ tipo_dc_servicio Cargo_extra_de_raza.ID _de_raza = ID _de_raza (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 subclasificación lógica que el tipo de servicio que proporciona.
