Aprendiendo UML en 24 horas

Citation preview

Si solo tiene tiempo para /as respuestas

-

-N

a

24 l e d u r n en /asque inwd@ U M horn por lmidn

I

e

L

I

Prent.ice Hall . -

Resumen de contenido PARTEl PARAINICIAR Hora l

Introducci6n a1 UML

2

Orientaci6n a objetos

3

Uso de la orientaci6n a objetos

4

Uso de relaciones

5

Agregacibn, composition, interfaces y realizaci6n

6

Introducci6n a 10s casos de uso

7

Diagramas de casos de uso

8

Diagramas de estados

9

Diagramas de secuencias

10

Diagramas de colaboraciones

11

Diagramas de actividades

12

Diagramas de componentes

13

Diagramas de distribuci6n

14

Nociones de 10s fundamentos del UML

15

Adaptaci6n del UML en un proceso de desarrollo

PARTE11 ESTUDIO DE UN CASO Hora 16

Presentaci6n del caso por estudiar

17

Elaboration de un analisis de dominio

18

Recopilacidn de las necesidades del sistema

19

Desarrollo de 10s casos de uso

20

Orientaci6n a las interacciones y cambios de estado

21

Diseiio del aspecto, sensaci6n y distribuci6n

22

Noci6n de 10s patrones de diseiio

PARTE111 V I S I ~ DEL N FUTURO Hora 23 Modelado de sistemas incrustados 24 El futuro del UML

PARTEIV AP~NDICES ApCndice A

Respuestas a 10s cuestionarios

ApCndice B

Herramientas de modelado para el UML

ApCndice C

Un resumen grhfico indice

Contenido HORA1 INTRODUCCI~N AL UML

5

Por que es necesario el UML ................................................................................ 6 La concepcidn del UML ........................................................................................7 Diagramas del UML ..............................................................................................8 Diagrama de clases ............................................................................................ 8 Diagrama de objetos ..........................................................................................9 Diagrama de casos de uso .............................................................................. I0 Diagrama de estados ........................................................................................I0 Diagrama de secuencias .................................................................................. 1 Diagrama de actividades ................................................................................ 12 Diagrama de colaboraciones .......................................................................... 13 Diagrama de componentes .............................................................................. 13 Diagrama de distribucidn ................................................................................ 14 Otras caractensticas .............................................................................................. 14 Paquetes .......................................................................................................... 14 Notas ................................................................................................................15 Estereotipos ....................................................................................................l 5 Para quC tantos diagramas .................................................................................... 16 Resumen ................................................................................................................ 16 Preguntas y respuestas .......................................................................................... 16 Taller ....................................................................................................................17 Cuestionario .................................................................................................... l 7 Ejercicios ........................................................................................................ 17 HORA2 ORIENTACI~N A OBJETOS

19

Objetos. objetos por doquier ................................................................................20 Algunos conceptos ................................................................................................ 22 . ...................................................................................................... Abstracc~on 22 Herencia .......................................................................................................... 23 Polimorfismo ..................................................................................................24 Encapsulamiento ..............................................................................................25 Envio de mensajes .......................................................................................... 26 Asociaciones .................................................................................................... 26 Agregaci6n ...................................................................................................... 28 La recompensa ...................................................................................................... 30

.

Resumen ................................................................................................................30 Preguntas y respuestas .......................................................................................... 31 Taller .................................................................................................................... 31 Cuestionario .................................................................................................... 31 Ejercicios ........................................................................................................ 32 HOW 3

HOW 5

U S 0 DE LA ORlENTAC16N A OBJETOS

33

Concepcidn de una clase ...................................................................................... Atributos .............................................................................................................. Operaciones .......................................................................................................... Atributos. operaciones y concepcidn .................................................................... Responsabilidades y restricciones ........................................................................ Notas adjuntas ...................................................................................................... QuC es 10 que hacen las clases y cdmo encontrarlas ............................................ Resumen ................................................................................................................ Preguntas y respuestas ........................................................................................ Taller .................................................................................................................... Cuestionario .................................................................................................... Ejercicios ........................................................................................................

33 34 36 37 38 40 40 43 43 44 44 44

Asociaciones ........................................................................................................ Restricciones en las asociaciones .................................................................... .. Clases de asociacion ........................................................................................ Vinculos .......................................................................................................... Multiplicidad ........................................................................................................ Asociaciones calificadas ...................................................................................... Asociaciones reflexivas ........................................................................................ Herencia y generalizacidn .................................................................................... Descubrimiento de la herencia ........................................................................ Clases abstractas .............................................................................................. Dependencias ....................................................................................................... Resumen ................................................................................................................ Preguntas y respuestas .......................................................................................... Taller .................................................................................................................... Cuestionarios .................................................................................................. Ejercicios ........................................................................................................

46 47 48 48 49 50 51 51 53 53 .54 55 55 56 56 56

AGREGACI~N.COMPOSICI~N. INTERFACES Y REALIZACI~N

57

Agregaciones ....................................................................................................... .58 Restricciones en las agregaciones .................................................................. 59 Composiciones ..................................................................................................... .59 Contextos .............................................................................................................. 59

Interfaces y realizaciones ...................................................................................... Visibilidad ........................................................................................................ ~ m b i t o............................................................................................................ Resumen ................................................................................................................ Preguntas y respuestas .......................................................................................... Taller .................................................................................................................... Cuestionario .................................................................................................... Ejercicios ........................................................................................................

How 6 INTRODUCCI~N A LOS CASOS DE US0

6l 62 63 63 64 64 64 64

67

QuC son 10s casos de uso ......................................................................................68 Importancia de 10s casos de uso .......................................................................... 69 Un ejemplo: la mkquina de gaseosas .................................................................... 69 El caso de uso "Comprar gaseosa" ................................................................ 70 Casos de us0 adicionales ................................................................................ 71 Inclusi6n de 10s casos de uso ................................................................................ 72 Extensi6n de 10s casos de uso .............................................................................. 72 Inicio del analisis de un caso de uso .................................................................... 73 Resumen ................................................................................................................ 73 Preguntas y respuestas .......................................................................................... 74 74 Taller .................................................................................................................... Cuestionario .................................................................................................... 74 Ejercicios ........................................................................................................74

Representacibn de un mode10 de caso de uso ...................................................... 76 Una nueva visita a la maquina de gaseosas ....................................................76 Secuencia de pasos en 10s escenarios .............................................................. 77 Concepci6n de las relaciones entre casos de uso ................................................ 78 . .......................................................................................................... 78 Inclusion . Extension ........................................................................................................ 79 Generalizacidn ................................................................................................ 80 Ag~pamiento.................................................................................................. 81 Diagramas de casos de uso en el proceso de analisis ..........................................81 Aplicaci6n de 10s modelos de caso de uso ..........................................................81 Comprension del dominio ..............................................................................82 82 Comprensi6n de 10s usuarios .......................................................................... Comprensi6n de 10s casos de uso .................................................................... 82 Profundizaci6n ................................................................................................ 83 D6nde estamos ...................................................................................................... 85 Elementos estructurales .................................................................................. 86 Relaciones ........................................................................................................ 86 Agrupamiento .................................................................................................. 86

. .

..

Anotacion ........................................................................................................ 86 . ........................................................................................................87 Extension ...y mis ............................................................................................................ 87 El Panorama .......................................................................................................... 87 Resumen ................................................................................................................ 88 Preguntas y respuestas .......................................................................................... 88 89 Taller .................................................................................................................... Cuestionario ....................................................................................................89 Ejercicios ........................................................................................................ 89

.

HORA8 DIAGRAMAS DE ESTADOS

91

QuC es un diagrama de estados ............................................................................ 92 Simbologia ...................................................................................................... 92 Adici6n de detalles a1 icono de estado ............................................................93 Sucesos y acciones .......................................................................................... 94 ................................................................................ Condiciones de seguridad 95 Subestados ............................................................................................................96 Subestados secuenciales ..................................................................................96 Subestados concurrentes .................................................................................. 96 Estados hist6ricos ................................................................................................ 97 Mensajes y sefiales ................................................................................................ 98 Por quC son importantes 10s diagramas de estados .............................................. 99 Adiciones a1 panorama ........................................................................................ 99 Resumen .............................................................................................................. 100 Preguntas y respuestas ........................................................................................ l01 Taller .................................................................................................................. 101 Cuestionarios ................................................................................................ l01 Ejercicios ...................................................................................................... 102 HORA9 DIAGRAMAS DE SECUENCIAS

103

QuC es un diagrama de secuencias .................................................................... 104 Objetos .......................................................................................................... 104 Mensaje .......................................................................................................... 104 Tiempo .......................................................................................................... 105 La GUI ................................................................................................................106 La secuencia .................................................................................................. 106 106 El diagrama de secuencias ............................................................................ El caso de uso ................................................................................................ 108 Instancias y genCricos ........................................................................................ 108 Un diagrama de secuencias de instancias .................................................... 108 Un diagrama de secuencias gentrico ............................................................109 Creaci6n de un objeto en la secuencia .............................................................. 112 C6mo representar la recursividad ...................................................................... l14

Adiciones al panorama ...................................................................................... l l5 Resumen .............................................................................................................. l15 Preguntas y respuestas ........................................................................................ 116 Taller .................................................................................................................. 116 Cuestionario .......................................................................... ...................... l 16 . . . Ejercicios ...................................................................................................... l17

Qut es un diagrama de colaboraciones ..............................................................120 La GUI ................................................................................................................121 Cambios de estado ........................................................................................l22 La miquina de gaseosas ....................................................................................122 Creaci6n de un objeto ........................................................................................ 124 Algunos conceptos mis ...................................................................................... 125 Varios objetos receptores en una clase ..........................................................l26 Representation de 10s resultados .................................................................. 126 Objetos activos ..............................................................................................127 Sincronizaci6n ..............................................................................................127 Adiciones a1 panorama ...................................................................................... 128 Resumen .............................................................................................................. l29 Preguntas y respuestas ........................................................................................130 Taller .................................................................................................................. 130 Cuestionario ..................................................................................................l30 Ejercicios ......................................................................................................130

Objetivos .............................................................................................................. 133 QuC es un diagrama de actividades .................................................................... 134 Decisiones. decisiones. decisiones ................................................................l35 Rutas concurrentes ........................................................................................135 Indicaciones .................................................................................................. 136 Aplicaci6n de 10s diagramas de actividades ...................................................... 137 Una operaci6n: Fibs ......................................................................................137 Proceso de creaci6n de un document0 .......................................................... 138 Marcos de responsabilidad ................................................................................140 Diagramas hibridos ............................................................................................142 Adiciones al panorama ...................................................................................... 144 Resumen .............................................................................................................. l45 146 Preguntas y respuestas ........................................................................................ Taller .................................................................................................................. 146 Cuestionario .................................................................................................. l46 Ejercicios ...................................................................................................... l47

HORA12 DIAGRAMAS DE COMPONENTES

149

QuC es un cornponente ........................................................................................ 150 150 Componentes e interfaces .................................................................................. Sustituci6n y reutilizaci6n ............................................................................ 151 Tipos de componentes ........................................................................................ 152 QuC es un diagrama de componentes ................................................................ 152 Representaci6n de un componente ................................................................ 152 C6mo representar las interfaces .................................................................... 153 Aplicaci6n de 10s diagramas de componentes .................................................... 154 Una pfigina Web con un subprograma Java .................................................. 154 Una pfigina Web con controles ActiveX ........................................................ 156 PowerToys .................................................................................................... 157 Diagramas de componentes en el panorama ...................................................... 158 159 Resumen .............................................................................................................. Preguntas y respuestas ........................................................................................ 160 Taller .................................................................................................................. 160 Cuestionario .................................................................................................. 160 . . . Ejerciclos ...................................................................................................... 160 HORA13 DIAGRAMAS DE DISTRIBUC~~N

163

QuC es un diagrama de distribuci6n .................................................................. 164 Aplicaci6n de 10s diagramas de distribuci6n ...................................................... 165 Un e q u i p domCstico .................................................................................... 166 Una red token-ring ........................................................................................166 ARCnet .......................................................................................................... 167 Thin ethernet ..................................................................................................168 169 Red inalimbrica Ricochet de Metricorn ........................................................ Los diagramas de distribuci6n en el panorama ..................................................170 Resumen .............................................................................................................. 171 Preguntas y respuestas ........................................................................................ 172 172 Taller .................................................................................................................. Cuestionario .................................................................................................. 172 Ejercicios ......................................................................................................172 HOW 14

NOCIONES DE LOS FUNDAMENTOS DEL UML

173

Estructura del UML ............................................................................................ Capa del metarnodelado: cercano y personal .................................................... El paquete de Fundamentos .......................................................................... El paquete de 10s elementos de comportamiento .......................................... Administraci6n de rnodelos ............................. :............................................ Extensi6n del UML ............................................................................................

174 175 176 178 179 179

Estereotipos ........................................................................................................ 179 180 Dependencia .................................................................................................. Clasificador .................................................................................................... 180 Clase .............................................................................................................. 181 .. Generalizaclon .............................................................................................. l81 Paquete ..........................................................................................................l81 Componente .................................................................................................. l82 Algunos otros estereotipos ............................................................................l82 Estereotipos graficos ....................................................................................l82 Restricciones ......................................................................................................l83 Valores etiquetados ............................................................................................ l84 Resumen ..............................................................................................................l84 Preguntas y respuestas ........................................................................................ l85 Taller .................................................................................................................. 185 Cuestionario .................................................................................................. 185 HORA15 ADAPTACI~N DEL UML EN UN PROCESODE DESARROLLO

187

Metodologias: antiguas y recientes .................................................................... l88 El metodo antiguo ........................................................................................ 188 El mCtodo reciente ........................................................................................ 189 Lo que debe hacer un proceso de desarrollo ......................................................l90 GRAPPLE .......................................................................................................... I91 R A D ~ :la estructura de GRAPPLE ................................................................ l92 Recopilaci6n de necesidades ........................................................................ 193 Analisis .......................................................................................................... 195 Diseiio ............................................................................................................ l97 198 Desarrollo ...................................................................................................... Distribuci6n .................................................................................................. 199 Resumen de GRAPPLE ...................................................................................... 199 Resumen .............................................................................................................. 200 Preguntas y respuestas ........................................................................................ 201 Taller .................................................................................................................. 201 201 Cuestionario ..................................................................................................

PARTE11 ESTUDIO DE UN CASO HORA16 PRESENTACI~N DEL CASO POR ESTUDIAR

203 205

Aplicaci6n de GRAPPLE a1 problema .............................................................. 206 Descubrir 10s procesos del negocio .................................................................... 206 Servir a un cliente .......................................................................................... 207 Preparaci6n de platillos ................................................................................ 215 Limpieza de la mesa ...................................................................................... 218 Lecciones aprendidas .......................................................................................... 219

Resumen .............................................................................................................. 220 Preguntas y respuestas ........................................................................................ 221 Taller .................................................................................................................. 221 Cuestionario .................................................................................................. 221 Ejercicios .................................................................................................... 222

Anilisis de la entrevista del proceso del negocio .............................................. 224 Desarrollo del diagrama de clases inicial .......................................................... 225 Agrupaci6n de las clases ....................................................................................228 229 Conformaci6n de asociaciones .......................................................................... Asociaciones con el cliente ..........................................................................229 Asociaciones con el Mesero .......................................................................... 234 Asociaciones con el Chef .............................................................................. 235 Asociaciones con el Mozo de piso ................................................................ 236 Asociaciones con el Gerente ........................................................................ 236 Una digresi6n ................................................................................................237 Formaci6n de agregados y objetos compuestos ................................................ 238 Llenado de las clases ..........................................................................................239 El Cliente ...................................................................................................... 240 El Empleado .................................................................................................. 240 La Cuenta ......................................................................................................242 Detalles generales de 10s modelos ......................................................................242 Diccionario del mode10 ................................................................................ 242 Organizaci6n del diagrama ............................................................................243 Lecciones aprendidas .......................................................................................... 243 Resumen ..............................................................................................................244 Preguntas y respuestas ........................................................................................ 244 Taller ..................................................................................................................244 Cuestionario ..................................................................................................244 Ejercicios ......................................................................................................245 HORA18 RECOPILACI~N DE

LAS NECESIDADES DEL SISTEMA

247

Desarrollo de la idea ..........................................................................................248 257 Preparaci6n para la recopilaci6n de las necesidades .......................................... La sesi6n JAD de necesidades ............................................................................258 El resultado ........................................................................................................ 261 ~ A h o r aque? ........................................................................................................ 264 Resumen ............................................................................................................. 264 Preguntas y respuestas ........................................................................................265 Taller ..................................................................................................................265 Cuestionario .................................................................................................. 265 Ejercicio ........................................................................................................ 265

HORA19 DESARROLLO DE LOS CASOS DE

267

US0

Cuidado y provisi6n de 10s casos de uso ............................................................ 268 El analisis de 10s casos de uso ............................................................................ 268 El paquete Mesero ..............................................................................................269 270 Tomar una orden ............................................................................................ Transmitir la orden a la cocina ...................................................................... 271 Cambiar una orden ........................................................................................ 272 Sondeo del progreso de la orden .................................................................. 273 Notificar al chef del progreso de 10s clientes en sus alimentos ....................273 Totalizar una cuenta ...................................................................................... 275 . . Impnmlr una Cuenta .................................................................................... 275 Llamar a un Asistente .................................................................................... 276 Casos de uso restantes .................................................................................. 277 Componentes del sistema .................................................................................. 277 Resumen ..............................................................................................................278 Preguntas y respuestas ........................................................................................278 Taller .................................................................................................................. 279 Cuestionario .................................................................................................. 279 Ejercicios ...................................................................................................... 279 HORA20 ORIENTACI~N A LAS INTERACCIONES Y

CAMBIOS DE ESTADO

281

Las partes funcionales del sistema .................................................................... 282 El paquete Mesero ........................................................................................ 282 283 El paquete Chef ............................................................................................ El paquete Mozo De Piso .............................................................................. 283 El paquete Asistente Mesero ........................................................................ 283 El paquete Asistente Chef ............................................................................ 283 El paquete Cantinero .................................................................................... 284 El paquete Encargado Del Guardarropa ........................................................284 Colaboraci6n en el sistema ................................................................................284 285 Tomar una orden ............................................................................................ Cambiar una orden ........................................................................................ 288 Sondeo del progreso de la orden .................................................................. 289 Implicaciones ...................................................................................................... 290 Resumen .............................................................................................................. 291 291 Preguntas y respuestas ........................................................................................ Taller .................................................................................................................. 292 Cuestionario .................................................................................................. 292 Ejercicios ...................................................................................................... 292

293 Algunos principios generales en el diseiio de las GUI ......................................294 La sesi6n JAD para la GUI ................................................................................296 De 10s casos de uso a las interfaces de usuario ..................................................297 Diagramas UML para el diseiio de la GUI ........................................................ 299 Esbozos de la distribuci6n del sistema .............................................................. 300 La red ............................................................................................................ 301 Los nodos y el diagrama de distribuci6n ...................................................... 301 Siguientes pasos .................................................................................................. 303 ...Y ahora. unas palabras de nuestros patrocinadores ........................................ 304 Mejorar el trabajo de la fuerza de ventas ...................................................... 304 Expansiones en el mundo restaurantero ........................................................ 305 Resumen .............................................................................................................. 306 Preguntas y respuestas ........................................................................................ 307 Taller .................................................................................................................. 308 Cuestionario .................................................................................................. 308 Ejercicios ...................................................................................................... 308

HORA21 DISENO DEL ASPECTO.

HORA22

SENSAC16N Y DISTR!BUCI~N

N O C I ~ NDE LOS PATRONES DE DISENO

309

Parametrizaci6n .................................................................................................. 310 Patrones de diseiio .............................................................................................. 312 Cadena de responsabilidad ................................................................................ 313 Cadena de responsabilidad: dominio Restaurante ........................................ 314 Cadena de responsabilidad: Modelos de eventos de 10s exploradores Web 3 15 Nuestros propios patrones de diseiio .................................................................. 317 Ventajas de 10s patrones de diseiio .................................................................... 319 Resumen .............................................................................................................. 319 Preguntas y respuestas ........................................................................................320 Taller .................................................................................................................. 320 Cuestionario .................................................................................................. 320 .............................................................................320 Ejercicios ................... . .

PARTE111 V I S I ~ DEL N FUTURO HORA23 MODELADO DE SISTEMAS

INCRUSTADOS

La madre de la invenci6n .................................................................................... Creacidn de TecnoApret6n ................................................................................ iQuC es un sistema incmstado? .......................................................................... Conceptos de 10s sistemas incrustados .............................................................. Tiempo .......................................................................................................... Subprocesos .................................................................................................. Interrupciones ................................................................................................ Sistema operative ..........................................................................................

323 324 325 327 328 328 328 329 330

Modelado de TecnoApret6n .............................................................................. 332 Clases ............................................................................................................332 Casos de uso .................................................................................................. 334 Interacciones ..................................................................................................335 Cambios de estado generales ........................................................................ 337 338 Distribuci6n .................................................................................................. Flexiones en sus rnusculos .................................................................................. 338 Resurnen .............................................................................................................. 339 Preguntas y respuestas ........................................................................................339 Taller .................................................................................................................. 340 Cuestionario .................................................................................................. 340 Ejercicios ...................................................................................................... 340

HORA24 EL FUTURO DEL UML

341

Extensiones para 10s negocios ............................................................................342 Lecciones de las extensiones de negocios .......................................................... 343 Interfaces graficas de usuario ............................................................................343 Conexiones a casos de uso ............................................................................ 344 Modelado de la GUI ...................................................................................... 344 Sisternas expertos ................................................................................................ 346 Cornponentes de un sisterna experto ............................................................ 346 Un ejernplo .................................................................................................... 348 Modelado de la base de conocirnientos ........................................................ 349 Eso es todo, arnigos ............................................................................................ 352 Resurnen .............................................................................................................. 352 Preguntas y respuestas ........................................................................................ 353 Taller .................................................................................................................. 353 Cuestionario ..................................................................................................353

AP~NDICE B HERRAMIENTAS DE MODELADO PARA

EL UML

369

Caracten'sticas en corntin ....................................................................................369 Rational Rose ......................................................................................................370 SELECT Enterprise ............................................................................................372 Visual UML ........................................................................................................374 La herramienta ideal para el modelado ..............................................................375

Diagrama de actividades .................................................................................... Diagrama de clases ............................................................................................ Diagrama de colaboraciones .............................................................................. Diagrama de componentes .................................................................................. Diagrama de distribuci6n .................................................................................... Diagrama de secuencias ...................................................................................... Diagrama de estados .......................................................................................... Diagrama de casos de uso ..................................................................................

378 380 382 382 383 383 384 385

Acerca del autor Joseph Schmuller es vicepresidente de la divisidn de Consumer Finance Technologies del Bank of America. De 1991 a 1997 fue editor en jefe de la revista PC AI. Ha escrito diversos articulos y resefias de tecnologias avanzadas de computacidn y es autor de AcriveX No experience required y Dynamic HTML Master the Essentials. Tiene un doctorado de la Universidad de Wisconsin, y es profesor adjunto en la Universidad del Norte de Florida.

Dedicatoria A mi maravillosa madre, Sara Riba Schmuller; quien me enserid a aprender por mi mismo.

Reconocimientos Escribir un libro es un proceso arduo; pero por fortuna, el equipo de Macmillan Computer Publishing 10 ha hecho m6s ficil. Es un placer reconocer sus contribuciones. Tanto el editor de adquisiciones, Chris Webb, como el de Desarrollo, Matt Purcell, me ayudaron a convertir mis pensamientos en algo legible; por encima de su gran experiencia editorial, les agradezco sus alicientes, paciencia y apoyo. Los revisores ttcnicos, Bill Rowe y Michael Tobler se aseguraron de que el contenido fuera ttcnicamente correct0 y se 10s agradezco. La editora, Susan Moore, 10s destacados artistas de Macmillan y el personal de produccion convirtieron el manuscrito y sus diversos diagramas en el libro que ahora estii leyendo. David Fugate de Waterside Productions conjugo todo el proceso. Le agradezco haberme hecho coincidir con Macmillan y haberme colocado en otro proyecto muy retribuyente. Tengo el privilegio de trabajar todos 10s dias con un grupo de excelentes profesionales en la divisi6n de Consumer Finance Technologies del Bank of America (especificamente, como miembro del grupo de Objetos y componentes reutilizables). Mi agradecimiento a mis colegas por su apoyo y cooperacion. En particular, las conversaciones con Keith Barret y Rob Warner me ayudaron a clarificar mis ideas sobre diversos puntos. Por desgracia Tom Williamson, nuestro Director de divisibn, falleci6 mientras escribia este libro. ~1 era el coraz6n y el alma de CFT, y fue un asesor, tutor, colega y amigo. Agradezco a mis queridos amigos, 10s Spragues de Madison, Wisconsin, en cuyo vecindario estaba de casualidad cuando empeck a escribir este libro y, nuevamente, a1 terminarlo. Agradezco a mi madre y a mi hermano David por su amor y por siempre estar cerca de mi, y a Kathryn por ser, por siempre, todo para mi.

Pearson Educacion Latinoamerica El personal de Pearson Educaci6n LatinoamCrica esti comprometido en presentarle 10 mejor en material de consulta sobre computacion. Cada libro de Pearson Educacion LatinoamCrica es el resultado de meses de trabajo de nuestro personal, que investiga y refina la informacion que se ofrece. Como parte de este compromiso con usted, el lector de Pearson Educaci6n LatinoamCrica 10 invita a dar su opinion. Por favor higanos saber si disfruta este libro, si tiene alguna dificultad con la informaci6n y 10s ejemplos que se presentan, o si tiene alguna sugerencia para la proxima edition. Sin embargo, recuerde que el personal de Pearson Educaci6n LatinoamCrica no puede actuar como soporte tecnico o ni responder preguntas acerca de problemas relacionados con el software o el hardware. Si usted tiene alguna pregunta o comentario acerca de cualquier libro de Pearson Educacion LatinoamCrica, existen muchas formas de entrar en contacto con nosotros. Responderemos a todos 10s lectores que podamos. Su nombre, direcci6n y numero telef6nico jamis formaran parte de ninguna lista de correos ni seran usados para otro fin, mis que el de ayudarnos a seguirle llevando 10s mejores libros posibles. Puede escribirnos a la siguiente direccion: Pearson Educaci6n LatinoamCrica Attn: Editorial Divisi6n Computaci6n Calle Cuatro No. 25, 2" Piso, Col. Fracc. Alce Blanco Naucalpan de Jukez, Edo. de MCxico. C.P. 53370 Si 10 prefiere, puede mandar un fax a Pearson Educacidn LatinoamCrica a1 (525) 5387-08 1 1. TambiCn puede ponerse en contacto con Pearson Educacidn LatinoamCrica a travCs de nuestra pagina Web: h t t p : I /W. p e a r s o n . corn. rnx

lntroduccion Todo gira en torno de una visi6n. Un sistema complejo toma forma cuando alguien tiene la vision de c6mo la tecnologia puede mejorar las cosas. Los desarrolladores tienen que entender completamente la idea y mantenerla en mente mientras crean el sistema que le dC foma. El Cxito de 10s proyectos de desarrollo de aplicaciones o sistemas se debe a que sirven como enlace entre quien tiene la idea y el desarrollador. El UML (Lenguaje Uni$cado de Modelado) es una herramienta que cumple con esta funcion, ya que le ayuda a capturar la idea de un sistema para comunicarla posteriormente a quien estt involucrado en su proceso de desarrollo; esto se lleva a cab0 mediante un conjunto de simbolos y diagramas. Cada diagrama tiene fines distintos dentro del proceso de desarrollo. El objetivo de este libro es darle, en 24 horas de estudio, las bases sobre el UML. Cada hora le presentara ejemplos para mejorar la comprensi6n e incluira ejercicios que le permitirin practicar sus reciCn adquiridos conocimientos. Dividi este libro en tres partes: la primera parte le da un panorama del UML y le explica la orientaci6n a objetos, misma que conforrna 10s conceptos fundamentales de la diagramaci6n de objetos y clases. Examinaremos 10s casos de uso (una estructura para mostrar la forma en que un sistema luciri ante el usuario, para luego mostrar corn0 hacer diagramas de esta estructura). Las horas restantes de la primera parte le permitiran trabajar con el resto de 10s diagramas UML. La segunda parte le muestra una metodologia simplificada para el desarrollo, enriquecida con el estudio de un caso ficticio. Asi, las horas de la segunda parte le mostrarin la forma en que el UML se adapta a1 context0 de un proyecto de desarrollo. Veri la forma en que 10s elementos del UML funcionan en conjunto para modelar un sistema. Por liltimo, en la tercera parte aplicaremos el UML para diseiiar patrones y sistemas incrustados, y examinaremos su campo de aplicacidn en dos keas mis. Existen diversos fabricantes que cuentan con paquetes que le permitirin generar diagramas UML y coordinarlos en un modelo. Los mis notables son Rational Rose y SELECT Enterprise, aunque cabe mencionar que Visual UML es otro digno contendiente. Microsoft esti autorizado para utilizar la tecnologia de Rational y asi comercializa Visual Modeler, un subconjunto de Rational Rose. No obstante, en este libro todo lo que necesitara sera un lipiz y papel para dibujar 10s diagramas y una sana curiosidad respecto a1 estado actual del diseiio de sistemas. i Iniciemos!

Convenciones utilizadas en este libro En 10s diagramas incluidos en este libro no utilizamos vocales con acento, ni la letra efie. Esto debido a que el alfabeto inglCs, de donde procede la mayon'a de 10s lenguajes de programacion, no 10s incluye y el empleo de esos caracteres en sus diagramas podria acarrearle problemas tanto en el UML como en el lenguaje de programaci6n que piense

Una Nota presenta interesantes secciones de informacion relacionadas con et tema que se trate.

El icono TCrmino Nuevo resalta las definiciones de vocablos nuevos y esenciales. El vocablo, en si, apareceri en cursiva.

Para iniciar Hora 1 Introduccion al UML 2 orientacion a objetos

3 Uso de la orientacion a objetos 4 Uso de relaciones 5 Agregacion, composicib, interfaces y realizaci 6 lntroduccion a 10s casos de uso 7 Diagramas de casos de uso

8 Diagramas de estados 9 Diagramas de secuencias 10 Diagramas de colaboraciones 11 Diagramas de actividades 12 Diagramas de componentes

13 Diagramas de distribucion 14 Nociones de 10s fundamentos del UML 15 Adaptacion del UML en un proceso de desarro

Introduccion al UML El UML (Lenguaje Unificado de Modelado) es una de las herramientas mhs emocionantes en el mundo actual del desarrollo de sistemas. Esto se debe a que permite a 10s creadores de sistemas generar diseiios que capturen sus ideas en una forma convencional y fhcil de cornprender para comunicarlas a otras personas. En esta hora se tratarhn 10s siguientes temas: Por quC es necesario el UML La concepci6n del UML Diagramas del UML Para quC tantos diagramas

En el context0 de este libro considere a un sistema como una combinacion de software y hardware que da una solucion a un problema de negocios. El desarrollo de sistemas es la creacion de un programa para un cliente, este irltimo es quien tiene el problema que debe ser resuelto. Un analista es el que documenta el problema del cliente y 10 comunica a 10s desarroIladores, que son 10s programadores que generaren el programa que resolvere el problema y 10 distribuiren en equipos de computaci6n.

ka'tomunicaclbn~dela idea es de sumahiportanaa! kntes del advenimiento del UML,el desarrollo de sistemas era, con frecuencia, luna propuesta a1 azar. Los analistas de sisternas intentaban evaluar 10s requerirnientos de sus clientes, generar un anA1isis de requerirnientos en algdn tipo de notaci6n que eIIos mismos cornprendieran (aunque eI cliente no 10 comprendiera), dar tal anaisis a uno o varios programadores y esperar que el p d u c t o final cumpliese con Io que el cliente deseaba. Dado que el desarrollo de sisternas es una actividad hurnana, hay muchas posibilidades de cometer errores en cualquier etapa del prt>cesq p r ejemplo, el analista pudo haber malentendido a1 cliente, es decir, probablemente produjo un document0 que el cliente no puda comprender, Tal vex e.w document0 tampoco fue cornprendido por 10s progmmadores quienes, por ende, pudiemn generar un ptograma dificil de utili7ar y no generar una soluciiin a1 problema original del cliente.

~Alguiense preguntarh por quC muchos de 10s sisternas en uso son ineficientes, engomsos y dificiles de urilizar?

Por que es necesario el UML En los principios de la computaci6n,los programadores no realizaban analisis muy profundos sobre el problema por resolver. Si acaso, garabateaban aIgo en una sewilleta. Con frecuencia comenzaban a escribir el programa desde el principio, y el c6digo necesario se escribia conforme se requen'a. Aunque anteriormente esto agregaba un aura de averttura y atrevimiento af proceso, en la actualidad es inapropiada en los negwios de alto riesgo.

Hoy en dia, es necesario contar con un plan bien analizado. Un cfiente tiene que comprender quC es lo que harfl un equip de desarrolladores; adernas tiene que ser capaz de seiialar cambios si no se han captada claramente sus necesidades (o si cambia de opini6n durmte el proceso). A su vez, el desamllo es un esfuem orientado a quipos, por 10 que cada uno de sus miembros tiene que saber quC Iugar torna su trabajo en la soluci6n final (asi como saber cud es la soluci6n en general), Conforme aumenta la complejidad del rnundo, 10s sistemas i n f o ~ t i c o stambitn d e b e h crecer en complejidad. En ellos se encuentran diversas piezas de hardware y software que se comunican a grandes distmcias mediante una red, misrna que estil vinculada a bases de datos que, a su vez, contienen enormes cantidades de informacibn. Si desea crear sistemas que 10 involucren con este nuevo milenio j ~ m manejard tanta compiejidad?

La clave estd en organizar el procesa de diseiio de tal forma que 10s analisias, clientes, desarrolladores y otras personas involucradas en el d e s m l l o del sistema IQ comprendan y convengan con 61. El UML proporciona tal organizacidn. Un arquitecto no pdria crew una compleja estructura como la es un edificio de oticinas sin crear primem un anteproyecto detallado; asimismo usred tampoco pod& generar un complejo sistema en un edificio de oficinas sin crew un plan de diseiio detallado. La idea

es que asi como un arquitecto le muestra un anteproyecto a la persona que 10 contrat6, usted deberi mostrarle su plan de diseiio a1 cliente. Tal plan de diseiio debe ser el resultado de un cuidadoso anilisis de las necesidades del cliente. Otra caracteristica del desarrollo de sistemas contemporineo es reducir el period0 de desarrollo. Cuando 10s plazos se encuentran muy cerca uno del otro es absolutamente necesario contar con un diseiio s6lido. Hay otro aspect0 de la vida moderna que demanda un diseiio s6lido: las adquisiciones corporativas. Cuando una empresa adquiere a otra, la nueva organization debe tener la posibilidad de modificar aspectos importantes de un proyecto de desarrollo que estC en progreso (la herramienta de desarrollo, el lenguaje de codificaci6n, y otras cosas). Un anteproyecto bien diseiiado facilitara la conversi6n. Si el diseiio es s6lid0, un cambio en la implementation procederi sin problemas. La necesidad de disefios s6lidns ha traido consigo la creacion de una notaci6n de diseiio que 10s analistas, desarrolladores y clientes acepten como pauta (tal como la notaci6n en 10s diagramas esquemiticos sirve como pauta para 10s trabajadores especializados en electrbnica). El UML es esa misma notaci6n.

La concepcion del UML El UML es la creaci6n de Grady Booch, James Rumbaugh e Ivar Jacobson. Estos caballeros, apodados recientemente "Los tres amigos", trabajaban en empresas distintas durante la dCcada de 10s aiios ochenta y principios de 10s noventa y cada uno diseii6 su propia metodologia para el anllisis y diseiio orientado a objetos. Sus metodologias predominaron sobre las de sus competidores. A mediados de 10s aRos noventa empezaron a intercambiar ideas entre si y decidieron desarrollar su trabajo en conjunto.

Las horas 2, "orientacion a objetos", y 4, "Uso de relaciones", tratan de la orientacion a objetos. Los conceptos de orientacion a objetos tienen un papel fundamental en el desarrollo de este libro.

En 1994 Rumbaugh ingres6 a Rational Software Corporation, donde ya trabajaba Booch. Jacobson ingred a Rational un aiio despuCs; el resto, como dicen, es historia. Los anteproyectos del UML empezaron a circular en la industria del software y las reacciones resultantes trajeron consigo considerables modificaciones. Conforme diversos corporativos vieron que el UML era litil a sus propbsitos, se conform6 un consorcio del UML. Entre 10s miembros se encuentran DEC, Hewlett-Packard, Intellicorp, Microsoft, Oracle, Texas Instruments y Rational. En 1997 el consorcio produjo la versibn 1.0 del UML y 10 puso a consideraci6n del OMG (Gmpo de administraci6n de objetos) como respuesta a su propuesta para un lenguaje de modelado estindar.

El consorcio aumentd y generd la versidn 1.1, misma que se pus0 nuevamente a consideracidn del OMG. El gmpo adopt6 esta versidn a finales de 1997. El OMG se encargd de la conse~acidndel UML y produjo otras dos revisiones en 1998. El UML ha llegado a ser el esthndar de facto en la industria del software, y su evolucidn continua.

Diagramas del UML El UML esth compuesto por diversos elementos grhficos que se combinan para conformar diagramas. Debido a que el UML es un lenguaje, cuenta con reglas para combinar tales elementos. En lugar de indicarle a usted cu6les son 10s elementos y las reglas, veamos directamente 10s diagramas ya que 10s utilizarh para hacer el analisis del sistema.

Este enfoque es similar a aprender un idiorna extranjero rnediante el uso del rnisrno, en lugar de aprender sus reglas grarnaticales y la conjugacion de sus verbos. Despues de un tiernpo de hablar otro idiorna se le facilitara la conjugacion de verbos y la cornprension de las reglas grarnaticales.

La finalidad de 10s diagramas es presentar diversas perspectivas de un sistema, a las cuales se les conoce como modelo. El modelo UML de un sistema es similar a un modelo a escala de un edificio junto con la interpretacidn del artista del edificio. Es importante destacar que un modelo UML describe 10 que supuestamente hara un sistema, per0 no dice cdmo implementar dicho sistema. A continuacibn se describirhn brevemente 10s diagramas mhs comunes del UML y 10s conceptos que representan. Posteriormente, en la parte I verh cada uno de 10s diagramas con mayor detenimiento. Recuerde que es posible generar hibridos de estos diagramas y que el UML otorga formas de organizarlos y extenderlos.

Diagrama de clases Piense en las cosas que le rodean (una idea demasiado amplia, per0 iintCntelo de cualquier forma!). Es probable que muchas de esas cosas tengan atributos (propiedades) y que realicen determinadas acciones. Podriamos imaginar cada una de esas acciones como un conjunto de tareas. TambiCn se encontrarh con que las cosas naturalmente se albergan en categorias (autombviles, mobiliario, lavadoras...). A tales categorias las llamaremos clases. Una clase es una categoria o grupo de cosas que tienen atributos y acciones similares. He aqui un ejemplo: cualquier cosa dentro de la clase Lavadoras tiene atributos como son la marca, el modelo, el numero de serie y la capacidad. Entre las acciones

FIGURA 1.2

Mi Lavadora: Lavadora

El simbolo UML del objeto.

Diagrama de casos de uso Un caso de uso es una descripci6n de las acciones de un sistema desde el punto de vista del usuario. Para 10s desarrolladores del sistema, esta es una herramienta valiosa, ya que es una tCcnica de aciertos y errores para obtener 10s requerimientos del sistema desde el punto de vista del usuario. Esto es importante si la finalidad es crear un sistema que pueda ser utilizado por la gente en general (no s610 por expertos en computaci6n). Posteriormente trataremos este tema con mayor detalle; por ahora, le mostrarC un ejemp10 sencillo. Usted utiliza una lavadora, obviamente, para lavar su ropa. La figura 1.3 le muestra c6mo representaria esto en un diagrama de casos de uso UML.

FIGURA1.3 Diagramu dr casos de uso UML.

U Lavar ropa

Usuario de la lavadora

A la figura correspondiente a1 Usuario de la lavadora se le conoce como actor. La elipse representa el caso de uso. Vea que el actor (la entidad que inicia el caso de uso) puede ser una persona u otro sistema.

Diagrama de estados En cualquier momento, un objeto se encuentra en un estado en particular. Una persona puede ser recien nacida, infante, adolescente, joven o adulta. Un elevador se mover6 hacia arriba, estara en estado de reposo o se movera hacia abajo. Una lavadora podra estar en la fase de remojo, lavado, enjuague, centrifugado o apagada. El diagrama de estados UML, que aparece en la figura 1.4, captura esta pequeiia realidad. La figura muestra las transiciones de la lavadora de un estado a1 otro. El simbolo que est6 en la parte superior de la figura representa el estado inicial y el de la parte inferior el estado final.

Diagrama de estados

UML.

0 0 0 Lavado

Enjuague

Centrifugado

Diagrama de secuencias Los diagramas de clases y 10s de objeto representan informaci6n estatica. No obstante, en un sistema funcional 10s objetos interactlian entre si, y tales interacciones suceden con el tiempo. El diagrama de secuencias UML muestra la mechnica de la interaccidn con base en tiempos. Continuando con el ejemplo de la lavadora, entre 10s componentes de la lavadora se encuentran: una manguera de agua (para obtener agua fresca), un tambor (donde se coloca la ropa) y un sistema de drenaje. Por supuesto, estos tambiCn son objetos (como verh, un objeto puede estar conformado por otros objetos). ~ Q u Csucedera cuando invoque a1 caso de uso Lavar ropa? Si damos por hecho que completd las operaciones "agregar ropa", "agregar detergente" y "activar", la secuencia seria mis o menos asi: l. 2. 3. 4. 5. 6. 7.

El agua empezarh a llenar el tambor mediante una manguera. El tambor perrnanecerh inactivo durante cinco minutos. La manguera dejari de abastecer agua. El tambor girarh de un lad0 a otro durante quince minutos. El agua jabonosa saldra por el drenaje. Comenzarh nuevamente el abastecimiento de agua. El tambor continuarh girando.

8. El abastecimiento de agua se detendri. 9. El agua del enjuague saldri por el drenaje. 10. El tambor girari en una sola direccidn y se incrementari su velocidad por cinco minutos. 11. El tambor dejarh de girar y el proceso de lavado habra finalizado. La figura 1.5 presenta un diagrama de secuencias que captura las interacciones que se realizan a travCs del tiempo entre el abastecimiento de agua, el tambor y el drenaje (representados como rectingulos en la parte superior del diagrama). En este diagrama el tiempo se da de arriba hacia abajo. FIGURAl.S Diagrama de secuencias UML.

U Manguera de agua

1

1

- Abastecirn~entode agua

C

inrnovil

L Detenerse :

Girar de un lado a otro Vaciar el agua labonosa

,i ,Reabastecer de agua -4

I t I

Detenerse

I I-

-

G~rarde un lado a otro

Vac~arel agua de enjuague

P

:

-+

Girar en un solo sentido

:

Por cierto, volviendo a las ideas acerca de 10s estados, podriamos caracterizar 10s pasos 1 y 2 como el estado de remojo, 3 y 4 como el estado de lavado, 5 a 7 como el estado de enjuague y del 8 a1 10 como el estado de centrifugado.

Diagrama de actividades Las actividades que ocurren dentro de un caso de uso o dentro del comportamiento de un objeto se dan, normalmente, en secuencia, como en 10s once pasos de la seccidn anterior. La figura 1.6 muestra la forma en que el diagrama de actividades UML represents 10s pasos del 4 a1 6 de tal secuencia.

FIGURA 1.6 Diagrama de actividades UML.

Girar el tarnbor de un lado a otro 15 minutos

A . Vaciar el agua jabonosa

I

JI iniciar el abastecimiento de a

Diagrama de colaboraciones Los elementos de un sistema trabajan en conjunto para cumplir con 10s objetivos del sistema, y un lenguaje de modelado deberii contar con una forma de representar esto. El diagrama de colaboraciones UML, diseiiado con este fin, se muestra en la figura 1.7. Este ejemplo agrega un cron6metro interno a1 conjunto de clases que constituyen a una lavadora. Luego de cierto tiempo, el cron6metro detendrii el flujo de agua y el tambor comenzarii a girar de un lado a otro. FIGURA 1.7

Cronornetro interno

Diagrama de colaboraciones UML. 2: Girar de un lado a otro

Manguera de agua

Diagrama de componentes Este diagrama y el siguiente dejarin el mundo de las lavadoras, dad0 que estiin intimamente ligados con 10s sistemas informiiticos. El moderno desarrollo de software se realiza mediante componentes, 10 que es particularmente importante en 10s procesos de desarrollo en equipo. Sin extendenne mucho en este punto le mostrark, en la figura 1.8, la manera en que el UML representa un componente de software. FIGURA 1.8 Diagrama de componentes UML.

Diagrama de distribucion El diagrama de distribuci6n UML muestra la arquitectura fisica de un sistema informitico. Puede representar 10s equipos y dispositivos, mostrar sus interconexiones y el software que se encontrari en cada miquina. Cada computadora esti representada por un cub0 y las interacciones entre las computadoras estin representadas por lineas que conectan a 10s cubos. La figura 1.9 presenta un ejemplo.

"Procesador" Pequeiio sewidor Qube 2700WG de Cobalt Networks

Diagrama de distribucidn UML.

"Procesador" Vectra VL Serie 7

"Procesador" Dell Dimension XPS R450

Otras caracteristicas Anteriormente, mencionC que el UML proporciona caracteristicas que le permiten organizar y extender 10s diagramas.

Paquetes En algunas ocasiones se encontrari con la necesidad de organizar 10s elementos de un diagrarna en un grupo. Tal vez quiera mostrar que ciertas clases o componentes son parte de un subsistema en particular. Para ello, 10s agrupari en un paquete, que se representari por una carpeta tabular, como se muestra en la figura 1.10.

FIGURA1.10 El paquete UML le permite agrupar 10s elementos de un diagrama.

i Paquete 1

El Clase 1

Notas Es frecuente que alguna parte del diagrarna no presente una clara explicacidn del porquC esta alli o la manera en que trabaja. Cuando Cste sea el caso, la nota UML sera dtil. Imagine a una nota corno el equivalente grifico de un papel adhesivo. La nota es un rectingulo con una esquina doblada, y dentro del rectangulo se coloca la explicacibn. Usted adjunta la nota a1 elernento del diagrarna conectandolos rnediante una linea discontinua.

En cualquier diagrams, podra' agregar comentarios aclaratorios rnediante una nota.

respecto a la Clase 1

Clase 1

Estereotipos El UML otorga varios elernentos de utilidad, per0 no es un conjunto minucioso de ellos. De vez en cuando disefiari un sisterna que requiera algunos elernentos hechos a la rnedida. Los estereotipos o clisCs le permiten tornar elernentos propios del UML y convertirlos en otros. Es corno cornprar un traje del rnostrador y rnodificarlo para que se ajuste a sus medidas (contrario a confeccionarse uno cornpletarnente nuevo). Imagine a un estereotipo corno este tip0 de alteracibn. Lo representari corno un nornbre entre dos pares de parkntesis angulares y despuks 10s aplicara correctsrnente. El concept0 de una interfaz provee un buen ejemplo. Una interfaz es una clase que realiza operaciones y que no tiene atributos, es un conjunto de acciones que tal vez quiera utilizar una y otra vez en su modelo. En lugar de inventar un nuevo elernento para representar una interfaz, podri utilizar el simbolo de una clase con cdnterfaz,, situada justo sobre el nombre de la clase, corno se muestra en la figura 1.12.

Un estereotipo le permite crear nuevos elernentos a partir de otros existences.

-lnterfaz* Clase 1

Para que tantos diagramas Como puede ver, 10s diagramas del UML le permiten examinar un sistema desde distintos puntos de vista. Es importante recalcar que en un modelo UML no es necesario que aparezcan todos 10s diagramas. De hecho, la mayoria de 10s modelos UML contienen un subconjunto de 10s diagramas que he indicado. iPor quC es necesario contar con diferentes perspectivas de un sistema? Por 10 general, un sistema cuenta con diversas personas implicadas las cuales tienen enfoques particulares en diversos aspectos del sistema. Volvamos a1 ejemplo de la lavadora. Si diseiiara el motor de una lavadora, tendria una perspectiva del sistema; si escribiera las instrucciones de operaci6n, tendria otra perspectiva. Si diseiiara la forma general de la lavadora veria a1 sistema desde una perspectiva totalmente distinta a si tan s610 tratara de lavar su ropa. El escrupuloso diseiio de un sistema involucra todas las posibles perspectivas, y el diagrama UML le da una forma de incorporar una perspectiva en particular. El objetivo es satisfacer a cada persona implicada.

Resumen El desarrollo de sistemas es una actividad humana. Sin un sistema de notaci6n fhcil de comprender, el proceso de desarrollo tiene una gran cantidad de errores. El UML es un sistema de notaci6n que se ha convertido en estindar en el mundo del desarrollo de sistemas. Es el resultado del trabajo hecho por Grady Booch, James Rumbaugh e Ivar Jacobson. El UML est5 constituido por un conjunto de diagramas, y proporciona un esthdar que permite a1 analista de sistemas generar un anteproyecto de varias facetas que sean comprensibles para 10s clientes, desarrolladores y todos aquellos que estCn involucrados en el proceso de desarrollo. Es necesario contar con todos esos diagramas dad0 que cada uno se dirige a cada tipo de persona implicada en el sistema. Un modelo UML indica que' es lo que supuestarnente hari el sistema, mas no c6mo 10 hari.

Preguntas y respuestas P He visto que se refiere al Lenguaje Unificado de Modelado como "UML" y como "el UML". ;Cui1 es el correcto? R Los creadores del lenguaje prefieren el uso de "el UML". P Ha indicado que el UML es adecuado para 10s analistas. No obstante, el diagrama de distribuci6n no parece ser algo muy util en la fase de analisis en el desarrollo de un sistema. ;No seria mas apropiado para una fase posterior?

R En realidad nunca serh demasiado pronto para empezar a pensar en la distribucibn (Uotras cuestiones que, tradicionalmente, se dejan para fases posteriores del desarrollo). Aunque es cierto que el analista se interesa por hablar con 10s clientes y usuarios, en las fases tempranas del proceso el analista deberia pensar en 10s equipos y componentes que constituirian el hardware del sisterna. En algunas ocasiones, el cliente dicta esto; en otras, el cliente desea una recomendacibn del equipo de desarrollo. Ciertamente, un arquitecto de sistemas encontrarh util a1 diagrama de distribucibn. P Ha mencionado que es posible hacer diagramas hibridos. ;UML, perdbn, el UML, impone limitaciones respecto a 10s elementos que podra combinar en un diagrama? R No. El UML no establece limites, no obstante, con frecuencia se da el caso de que un diagrama contenga un tip0 de elemento. Podrh colocar simbolos de clases en un diagrama de distribucibn, per0 ello no sera muy litil.

Taller Ya se ha iniciado en el UML. Ahora deberh reafirmar su conocimiento de esta gran herramienta a1 responder algunas preguntas y realizar 10s ejercicios. Las respuestas aparecerfin en el ApCndice A, "Respuestas a 10s cuestionarios".

Cuestionario l. iPorquC es necesario contar con diversos diagramas en el mode10 de un sistema?

2. iCuhles diagramas le dan una perspectiva estfitica de un sistema? 3. iCuhles diagramas le dan una perspectiva dinhmica de un sistema (esto es, muestran el cambio progresivo)?

Ejercicios l. Suponga que crearh un sistema informfitico que jugarh ajedrez con un usuario. iCufiles diagramas UML sedan litiles para disefiar el sistema? iPor quC?

2. Para el sistema del ejercicio que ha completado, liste las preguntas que formularia a un usuario potencial y por quC las hm'a.

Orientacion a objetos Es fundamental que comprenda todo 10 relacionado a la orientacidn a objetos para el proceso que realizara; especificamente, es importante que conozca algunos conceptos sobre la orientaci6n a objetos. En esta hora se tratarin 10s siguientes temas: Abstracci6n Herencia Polimorfismo Encapsulamiento o encapsulaci6n Envio de mensajes Asociaciones Agregaci6n La orientaci6n a objetos ha tomado por asalto y en forma legitima a1 mundo del software. Como medio para la generaci6n de programas, tiene varias ventajas. Fomenta una metodologia basada en componentes para el desarrollo

de software, de manera que primer0 se genera un sistema mediante un conjunto de objetos, luego podrh ampliar el sistema agregandole funcionalidad a 10s componentes que ya habia generado o agreghndole nuevos componentes, y finalmente podra volver a utilizar 10s objetos que gener6 para el sistema cuando cree uno nuevo, con 10 cual reducira sustancialmente el tiempo de desarrollo de un sistema. La orientaci6n a objetos es tan importante para el diseiio de software que el OMG (Grupo de administracidn de objetos), una corporaci6n no lucrativa que establece las normas para el desarrollo orientado a objetos, predice que 10s ingresos obtenidos por el software orientado a objetos serhn de 3 millardos de d6lares en 10s siguientes tres a cinco aiios. El UML influye en esto a1 permitirle generar modelos de objetos f6ciles de usar y comprender para que 10s desarrolladores puedan convertirlos en software. La orientaci6n a objetos es un paradigma (un paradigma que depende de ciertos principios fundamentales). En esta hora comprenderh dichos principios y verh quC es 10 que hace funcionar a 10s objetos y c6mo utilizarlos en el analisis y diseiio. En la siguiente hora, empezarh a aplicar el UML a tales principios.

Objetos, objetos por doquier Los objetos concretos y virtuales, est6n a nuestro alrededor, ellos conforman nuestro mundo. Como indiquC en la hora anterior, el software actual simula a1 mundo (o un segmento de Cl), y 10s programas, por lo general, imitan a 10s objetos del mundo. Si comprende algunas cuestiones basicas de 10s objetos, entendera c6mo se deben mostrar Cstos en las representaciones de software. Antes que nada, un objeto es la instancia de una clase (o categoria). Usted y yo, por ejemplo, somos instancias de la clase Persona. Un objeto cuenta con una estructura, es decir atributos (propiedades) y acciones. Las acciones son todas las actividades que el objeto es capaz de realizar. Los atributos y acciones, en conjunto, se conocen como caracteristicas o rasgos. Como objetos de la clase Persona, usted y yo contamos con 10s siguientes atributos: altura, peso y edad (puede imaginar muchos m&). TambiCn realizamos las siguientes tareas: comer, dormir, leer, escribir, hablar, trabajar, etcCtera. Si tuviCramos que crear un sistema que manejara informaci6n acerca de las personas (como una n6mina o un sistema para el departamento de recursos humanos), sena muy probable que incorporhramos algunos de sus atributos y acciones en nuestro software. En el mundo de la orientaci6n a objetos, una clase tiene otro proposito ademis de la categorizaci6n. En realidad es una plantilla para fabricar objetos. Imagine10 como un molde de galletas que produce muchas galletas (algunos alegm'an que esto es 10 mismo que la categorizaci611, per0 evitemos dicho debate).

Regresemos a1 ejemplo de la lavadora. Si en la clase Lavadora se indica la marca, el modelo, el numero de serie y la capacidad (junto con las acciones de agregar ropa, agregar detergente y sacar ropa), tendra un mecanismo para fabricar nuevas instancias a partir de su clase; es decir, podri crear nuevos objetos (vea la figura 2.1).

En la hora 3, "Uso de la orientacion a objetos". vera que 10s nornbres de las clases, corno lavadora, se escribiran corno Lavadora, y si constara de dos palabras se escribiria corno Lavadoralndustrial, y las caracteristicas corno nurnero de serie se escribiran corno nurneroserie.

Esto es particularmente importante en el desarrollo de software orientado a objetos. Aunque este libro no se enfoca a la programacibn, le ayudara a comprender la orientacidn a objetos si sabe que las clases en 10s programas orientados a objetos pueden crear nuevas instancias.

Lavadora

La clase hvadora (modelo original) es una plantilla pura generar nuevas instancias de Lavadoras.

rnarca modelo numeroserie capacidad agregarRopa0 agregarDetergente0 sacarRopa()

Es importante que recuerde que el prop6sito de la orientacidn a objetos es desarrollar software que refleje particularmente (es decir, que modele) un esquema del mundo. Entre mis atributos y acciones tome en cuenta, mayor sera la similitud de su modelo con la realidad. En el ejemplo de la lavadora, tendra un modelo mis exacto si incluye 10s siguientes atributos: volumen del tambor, cronbmetro interno, trampa, motor y velocidad del motor. Podria hacerlo mas precis0 si incluye las acciones de agregar blanqueador, cronometrar el remojo, cronometrar el lavado, cronometrar el enjuague y cronometrar el centrifugado (vea la figura 2.2).

Lavadora

La adicidn de atributos y acciones

a1 mode10 10 acerca a la realidad.

marca modeto numeroserie capacidad volumenTambor cronometrolnterno trampa motor velocidadMotor agregarRopa0 agregarDetergente0 sacarRropa0 agregarBlanqueador0 cronometrarRemojo() cronometrarLavado() cronometrarEnjuague() cronometrarCentrifugado()

Algunos conceptos La orientacidn a objetos se refiere a algo m b que tan s610 atributos y acciones; tambitn considera otros aspectos. Dichos aspectos se conocen como ahstraccidn, herencia, polimorjismo y encapsulamiento o encapsulacidn. Otros aspectos importantes de la orientacidn a objetos son: el envio de mensajes, las asociaciones y la agregacidn. Examinemos cada uno de estos conceptos.

Abstraccion La abstraccidn se refiere a quitar las propiedades y acciones de un objeto para dejar s610 aquellas que sean necesarias. ~ Q u Csignifica esto dltimo? Diferentes tipos de problemas requieren distintas cantidades de informacidn, aun si estos problemas pertenecen a un 6rea en com6n. En la segunda fase de la creacidn de la clase Lavadora, se podrian agregar mfis atributos y acciones que en la primera fase. iVale la pena? Valdria la pena si usted pertenece a1 equipo de desarrollo que generarfi finalmente la aplicacidn que simule con exactitud 10 que hace una lavadora. Un programa de este tip0 (que podria ser muy dtil para 10s ingenieros de diseiio que actualmente esttn trabajando en el diseiio de una lavadora) deberfi ser tan completo que permita obtener predicciones exactas respecto a 10 que ocurriria cuando se fabrique la lavadora, funcione a toda su capacidad y lave la ropa. De hecho, para este caso podrfi quitar el atributo del ndmero de serie, dad0 que posiblemente no sera de mucha ayuda. Por otra parte, si va a genera un software que haga un seguimiento de las transacciones en una lavanderia que cuente con diversas lavadoras, posiblemente no valdrfi la pena. En este programa no necesitarfi todos 10s atributos detallados y operaciones del p b a f o anterior, no obstante, quizfi necesite incluir el numero de serie de cada objeto Lavadora.

En cualquier caso, con 10 que se quedara luego de tomar su decision respecto a 10 que incluira o desechari sera una abstraccidn de una lavadora.

Herencia Como ya se menciond anteriormente, una clase es una categoria de objetos (y en el mundo del software, una plantilla sirve para crear otros objetos). Un objeto es una instancia de una clase. Esta idea tiene una consecuencia importante: como instancia de una clase, un objeto tiene todas las caracteristicas de la clase de la que proviene. A esto se le conoce como herencia. No importa quC atributos y acciones decida usar de la clase Lavadora, cada objeto de la clase heredara dichos auibutos y operaciones. Un objeto no s610 hereda de una clase, sin0 que una clase tambitn puede heredar de otra. Las lavadoras, refrigeradores, homos de microondas, tostadores, lavaplatos, radios, licuadoras y planchas son clases y forman parte de una clase mas gentrica llamada: Electrodomesticos. Un electrodomCstico cuenta con 10s atributos de intemptor y cable eltctrico, y las operaciones de encendido y apagado. Cada una de las clases Electrodomestico heredara 10s mismos atributos; por ello, si sabe que algo es un electrodomCstico, de inmediato sabra que cuenta con 10s atributos y acciones de la clase Electrodomestico. Otra forma de explicarlo es que la lavadora, refrigerador, horno de microondas y cosas por el estilo son subclases de la clase Electrodomestico. Podemos decir que la clase Electrodomestico es una superclase de todas las demhs. La figura 2.3 le muestra la relacidn de superclase y subclase.

Los electrodomt!sticos heredan 10s atributos y acciones de la clase Electrodomestico. Cada electrodomPstico es urn subclase de la clase Electrodomestico. La clase Electrodomestico es una superclase de cada subclase.

Electrodomest~co

La herencia no tiene por quC terminar aqui. Por ejemplo, Electrodomestico es una subclase de Articulos del hogar, como le muestra la figura 2.4. Otra de las subclases de Articulos del hogar podria ser Mobiliario, que tendri sus propias subclases.

FIGURA 2.4 Las supercluses tarnbidn pueden ser subclases, y heredar de otras superclases.

Articulos del hogar

Electrodornestico

Mobiliario

Polimorfismo En ocasiones una operaci6n tiene el mismo nombre en diferentes clases. Por ejemplo, podri abrir una puerta, una ventana, un peri6dic0, un regalo o una cuenta de banco, en cada uno de estos casos, realizari una operacidn diferente. En la orientaci6n a objetos, cada clase "sabe" c6mo realizar tal operaci6n. Esto es el polimorfismo (vea la figura 2.5).

FIGURA2.5 . En el polirnorjisrno, una operacidn puede tener el misrno nornbre en diversas clases, y funcionar distinto en cada una.

En primera instancia, pareceria que este concept0 es mis importante para 10s desarrolladores de software que para 10s modeladores, ya que 10s desarrolladores tienen que crear el software que implemente tales mCtodos en 10s programas de computaci6n, y deben estar conscientes de diferencias importantes entre las operaciones que pudieran tener el mismo nombre. Y podrin generar clases de software que "sepan" 10 que se supone que harin. No obstante, el polimorfismo tambiCn es importante para 10s modeladores ya que les permite hablar con el cliente (quien esti familiarizado con la secci6n del mundo que seri modelada) en las propias palabras y terminologia del cliente. En ocasiones, las palabras y terminologia del cliente nos conducen a palabras de acci6n (como "abrir") que pueden

tener mhs de un significado. El polimorfismo permite a1 modelador mantener tal terminologia sin tener que crear palabras artificiales para sustentar una unicidad innecesaria de 10s tCrminos.

Encapsulamiento En cierto comercial televisivo, dos personas discuten acerca de todo el dinero que ahorrarian si marcaran un prefijo telefbnico en particular antes de hacer una llamada de larga distancia. Uno de ellos pregunta con incredulidad: "iC6mo funciona?"

Y el otro responde: "iCbmo hacen que las rosetas de maiz estallen? LA quiCn le importa?" La esencia del encapsulamiento (o encapsulacibn) es que cuando un objeto trae consigo su funcionalidad, esta dltima se oculta (vea la figura 2.6). Por 10 general, la mayoria de la gente que ve la television no sabe o no se preocupa de la complejidad electr6nica que hay detras de la pantalla ni de todas las operaciones que tienen que ocurrir para mostrar una imagen en la pantalla. La television hace 10 que tiene que hacer sin mostrarnos el proceso necesario para ell0 y, por suerte, la mayoria de 10s electrodomCsticos funcionan asi.

Los objetos encapsulan 10 que hacen; es decic ocultan lafuncionalidad interna de sus operaciones, de otms objetos y del mundo exterior:

La television oculta sus operaciones de la persona

~ C u hes l la importancia de esto? En el mundo del software, el encapsulamiento permite reducir el potencial de errores que pudieran ocurrir. En un sistema que consta de objetos, Cstos dependen unos de otros en diversas formas. Si uno de ellos falla y 10s especialistas de software tienen que modificarlo de alguna forma, el ocultar sus operaciones de otros objetos significarh que tal vez no sera necesario modificar 10s demis objetos.

En el mundo real, tambiCn verh la importancia del encapsulamiento en 10s objetos con 10s que trabaje. Por ejemplo, el monitor de su computadora, en cierto sentido, oculta sus operaciones de la CPU, es decir, si algo falla en su monitor, 10 reparari o 10 reemplazari; pero es muy probable que no tenga que reparar o reemplazar la CPU a1 mismo tiempo que el monitor. Ya que estamos en el tema, existe un concept0 relacionado. Un objeto oculta 10 que hace a otros objetos y a1 mundo exterior, por 10 cual a1 encapsulamiento tambiCn se le conoce como ocultamiento de la informacidn. Pero un objeto tiene que presentar un "rostro" a1 mundo exterior para poder iniciar sus operaciones. Por ejemplo, la televisi6n tiene diversos botones y perillas en si misma o en el control remoto. Una lavadora tiene diversas perillas que le perrniten establecer 10s niveles de temperatura y agua. Los botones y perillas de la televisi6n y de la lavadora se conocen como interfaces.

Envio de mensajes MencionC que en un sistema 10s objetos trabajan en conjunto. Esto se logra mediante el envio de mensajes entre ellos. Un objeto envia a otro un mensaje para realizar una operacibn, y el objeto receptor ejecutari la operaci6n. Una televisi6n y su control remoto pueden ser un ejemplo muy intuitivo del mundo que nos rodea. Cuando desea ver un programa de televisibn, busca el control remoto, se sienta en su silla favorita y presiona el bot6n de encendido. ~ Q u Cocurre? El control remoto le envia, literalmente, un mensaje a1 televisor para que se encienda. El televisor recibe el mensaje, 10 identifica como una petici6n para encenderse y asi 10 hace. Cuando desea ver otro canal, presiona el bot6n correspondiente del control remoto, mismo que envia otro mensaje a la televisi6n (cambiar de canal). El control remoto tambiCn puede comunicar otros mensajes como ajustar el volumen, silenciar y activar 10s subtitulos. Volvamos a las interfaces. Muchas de las cosas que hace mediante el control remoto, tambiCn las podrh hacer si se levanta de la silla, va a la televisidn y presiona 10s botones correspondientes (jalguna vez 10 habri hecho ya!). La interfaz que la televisi6n le presenta (el conjunto de botones y perillas) no es, obviamente, la misma que le muestra al control remoto (un receptor de rayos infrarrojos). La figura 2.7 le muestra esto.

Asociaciones Otro acontecimiento comdn es que 10s objetos se relacionan entre si de alguna forma. Por ejemplo, cuando enciende su televisor, en tkrminos de orientacidn a objetos, usted se asocia con su televisor. La asociaci6n "encendido" es en una sola direcci6n (una via), esto es, usted enciende la televisibn, como se ve en la figura 2.8. No obstante, a menos que vea demasiada televisi6n, ella no le devolveri el favor. Hay otras asociaciones que son en dos direcciones, como "casamiento".

Ejemplo de un mensaje enviado de un objeto a otm: el objeto "contm2 remoto" envia un rnensaje a1 objeto "televisidn" para encenderse. El objeto "televisidn" recibe el mensaje mediante su interfaz, un receptor infrarrojo.

Con frecuencia 10s objetos se relacionan entre si de alguna forma. Cuando usted enciende su televisidn, tendrd una asociacidn en una sola direccidn con ella.

Encender

+Q

En ocasiones, un objeto podn'a asociarse con otro en rnis de una forma. Si usted y su colaborador son amigos, ell0 serviri de ejernplo. Usted tendna una asociaci6n "es arnigo de", asi corno "es colaborador dew,corno se aprecia en la figura 2.9. FIGURA2.9 En ocasiones, 10s objetos pueden asociarse en mas de una fonna.

Una clase se puede asociar con mls de una clase distinta. Una persona puede viajar en automcivil, pero tambiCn puede hacerlo en autobh (vea la figura 2.10). FIGURA 2.10 Una clase puede asociarse con mas de una clase disrinta.

La multiplicidad (o diversificacibn) es un importante aspect0 de las asociaciones entre objetos. Indica la cantidad de objetos de una clase que se relacionan con otro objeto en particular de la clase asociada. Por ejemplo, en un curso escolar, el curso se imparte por un solo instructor, en consecuencia, el curso y el instructor estAn en una asociacibn de uno a uno. Sin embargo, en un seminario hay diversos instructores que impartirln el curso a 10 largo del semestre, por 10 tanto, el curso y el instructor tienen una asociacicin de uno a muchos. PodrA encontrar todo tipo de multiplicidades si echa una mirada a su alrededor. Una bicicleta rueda en dos neumlticos (multiplicidad de uno a dos), un triciclo rueda en tres, y un vehiculo de 18 ruedas, en 18.

Agregacion Vea su computadora: cuenta con un gabinete, un teclado, un ratdn, un monitor, una unidad de CD-ROM, uno o varios discos duros, un mbdem, una unidad de disquete, una impresora y, posiblemente, bocinas. Dentro del gabinete, junto con las citadas unidades de disco, tiene una CPU, una tarjeta de video, una de sonido y otros elementos sin 10s que, sin duda, dificilmente podria vivir. Su computadora es una agregacidn o adicibn, otro tip0 de asociaci6n entre objetos. Como muchas otras cosas que valdrian la pena tener, su equipo estl constituido de diversos tipos de componentes (vea la figura 2.11). Tal vez conozca varios ejemplos de agregaciones.

FIGURA2.1 1 Una computadora es un ejemplo de agregacicin: un objeto que se conforma de una combinacidn de diversos tipos de objeros.

Un tipo de agregacidn trae consigo una estrecha relacidn entre un objeto agregado y sus objetos componentes. A esto se le conoce como composicidn. El punto central de la composicidn es que el componente se considera como tal s610 como parte del objeto compuesto. Por ejemplo: una camisa e s d compuesta de cuerpo, cuello, mangas, botones, ojales y puiios. Suprima la camisa y el cuello sera inlitil. En ocasiones, un objeto compuesto no tiene el mismo tiempo de vida que sus propios componentes. Las hojas de un kbol pueden morir antes que el 6rbol. Si destruye a1 kbol, tambitn las hojas morirfin (vea la figura 2.12). La agregacidn y la composicidn son importantes dad0 que reflejan casos extremadamente comunes, y ell0 ayuda a que cree modelos que se asemejen considerablemente a la realidad.

En una composicidn, un componente puede morir antes que el objeto compuesto. Si destruye a1 objeto compuesto, destruird tambiin a 10s componentes.

La recompensa Los objetos y sus asociaciones conforman la columna vertebral de la funcionalidad de 10s sistemas. Para modelarlos, necesitarh comprender 10 que son las asociaciones. Si esth consciente de 10s posibles tipos de asociaciones, tendri una amplia gama de posibilidades cuando hable con 10s clientes respecto a sus necesidades, obtendrh sus requerimientos y crearh 10s modelos de 10s sistemas que 10s ayudarhn a cumplir con sus retos de negocios.

Lo importante es utilizar 10s conceptos de la orientaci6n a objetos para ayudarle a comprender el Area de conocimiento de su cliente (su dominio),y esclarecer sus puntos de vista al cliente en tCrminos que C1 o ella puedan comprender. Es alli donde se aplica el UML. En las siguientes tres horas, aprenderi a aplicar el UML para visualizar 10s conceptos que ha aprendido durante esta hora.

Resumen La orientaci6n a objetos es un paradigma que depende de algunos principios fundamentales. Un objeto es una instancia de una clase. Una clase es una categoria genCrica de objetos que tienen 10s mismos atributos y acciones. Cuando crea un objeto, el Area del problema en que trabaje determinarh cuhntos de 10s atributos y acciones debe tomar en cuenta. La herencia es un aspect0 importante de la orientaci6n a objetos, un objeto hereda 10s atributos y operaciones de su clase. Una clase tambitn puede heredar atributos y acciones de otra.

El polimorfismo es otro aspect0 importante, ya que especifica que una accidn puede tener el mismo nombre en diferentes clases y cada clase ejecutara tal operacion de forma distinta. Los objetos ocultan su funcionalidad de otros objetos y del mundo exterior. Cada objeto presenta una interfaz para que otros objetos (y personas) puedan aprovechar su funcionalidad. Los objetos funcionan en conjunto mediante el envio de mensajes entre ellos. Los mensajes son peticiones para realizar operaciones. Por 10 general, 10s objetos se asocian entre si y esta asociaci6n puede ser de diversos tipos. Un objeto en una clase puede asociarse con cualquier cantidad de objetos distintos en otra clase. La agregacion es un tip0 de asociaci6n. Un objeto agregado consta de un conjunto de objetos que 10 componen y una composici6n es un tip0 especial de agregacion. En un objeto compuesto, 10s componentes s610 existen como parte del objeto compliesto.

Preguntas y respuestas P Usted dijo que la orientaci6n a objetos ha tomado por asalto a1 mundo del software. ~QuCno hay algunas aplicaciones importantes que no estan orientadas a objetos? R Si, y se conocen como sistemas "heredados" (programas que en muchos casos son ejecutados para mostrar su Cpoca). La orientaci6n a objetos ofrece diversas ventajas, como la reusabilidad y un ripido period0 de desarrollo. Por tales razones, muy probablemente veri las nuevas aplicaciones (y las versiones rediseiiadas de varias aplicaciones antiguas) escritas bajo el esquema de la orientaci6n a objetos.

Para repasar 10 que ha aprendido de la orientaci6n a objetos, intente responder a algunas preguntas y realizar 10s siguientes ejercicios. Las respuestas las encontrari en el ApCndice A, "Respuestas a 10s cuestionarios".

Cuestionario 1. ~ Q u C es un objeto? 2. iC6m0 trabajan 10s objetos en conjunto?

3. ~ Q u Cestablece la multiplicidad? 4. ~Puedenasociarse dos objetos entre si en mis de una manera?

Ejercicios Esta es una hora tebrica, asi que no inclui ejercicios. Verh algunos en las siguientes horas.

Uso de la orientacion a objetos A continuaci6n conjugaremos las caracteristicas del UML con 10s conceptos de la orientaci6n a objetos. Aqui reafirmarh su conocimiento de la orientacion a objetos a1 tiempo que aprenderi otras cosas del UML.

En esta hora se tratarfin 10s siguientes temas: Concepci6n de una clase Atributos Operaciones Responsabilidades y restricciones QuC es 10 que hacen las clases y como encontrarlas

Concepcion de una clase Como 10 indiquC en la primera hora, en el UML un recthgulo es el simbolo que representa una clase. El nombre de la clase es, por convencibn, una palabra con la primera letra en mayliscula y normalmente se coloca en la parte superior del rectfingulo. Si el nombre de su clase consta de dos palabras, linalas e inicie cada una con mayliscula (como en LavadoraIndustrial en la figura 3.1).

La representacidn UML de una clase.

Lavadoralndustrial

I

Otra estructura del UML, el paquete, puede jugar un papel en el nombre de la clase. Como indiqut en la hora 1, "Introduccibn al UML", un paquete es la manera en que el UML organiza un diagrama de elementos. Tal vez recuerde que el UML representa un paquete corno una carpeta tabular cuyo nombre es una cadena de texto (vea la figura 3.2). FIGURA3.2 Un paquete del UML. Electrodomesticos

Si la clase "Lavadora" es parte de un paquete llamado "Electrodomesticos", podri dale el nombre "E1ectrodomesticos::Lavadora". El par de dos puntos separa a1 nombre del paquete, que estli a la izquierda, del nombre de la clase, que va a la derecha. A este tip0 de nombre de clase se le conoce corno nombre de ruta (vea la figura 3.3).

Posiblernente haya notado que en 10s nombres se han evitado 10s caracteres acentuados (corno en Electrodornesticos)y la letra eiie. Esto se debe a que en el alfabeto ingles, tales caracteres no estan conternplados y no podernos asegurar que el utilizarlos en sus identificadores no le traiga problemas, tanto en el UML corno en el lenguaje de prograrnacion que piense utilizar para traducir 10s modelos. Por ello, evitarernos 10s acentos en todos 10s diagramas que se presentan a lo largo de este libro, de igual rnanera, evitarernos el uso de la letra eiie, rnisrna que sustituirernos --en su caso- por "ni" (corno en Anio, en lugar de Aiio).

Una clase con un nornbre de ruta.

Atri butos Un atributo es una propiedad o caracteristica de una clase y describe un rango de valores que la propiedad podra contener en 10s objetos (esto es, instancias) de la clase. Una clase podra contener varios o ningun atributo. Por convencibn, si el atributo consta de una sola palabra se escribe en minusculas; por otro lado, si el nombre contiene mas de una palabra, cada palabra sera unida a la anterior y comenzara con una letra mayuscula, a excepcibn de la primer palabra que comenzara en minliscula. La lista

de nombres de atributos iniciari luego de una linea que la separe del nombre de la clase, como se aprecia en la figura 3.4. FIGURA3.4 Una clase y sus atributos.

Lavadora rnarca rnodelo nurneroserie capacidad

Todo objeto de la clase tiene un valor especifico en cada atributo. La figura 3.5 le muestra un ejemplo. Observe que el nombre de un objeto inicia con una letra minuscula, y esti precedido de dos puntos que a su vez estin precedidos del nombre de la clase, y todo el nombre esti subrayado.

El nombre miLavadora:Lavadora es una instancia con nombre; pero tambien es posible tener una instancia anonirna, como :Lavadora.

rniLavadora:Lavadora

Un objetb cuenta con un valor especijico en cada uno de 10s atributos que lo componen.

rnarca = "Laundatoriurn" rnodelo = "Washrneister" nurneroserie = "GL57774" capacidad = 16

El UML le da la opci6n de indicar informacidn adicional de 10s atributos. En el simbolo de la clase, podri especificar un tip0 para cada valor del atributo. Entre 10s posibles tipos se encuentran cadena (string), numero de punto flotante (float), entero (integer) y booleano (boolean), asi como otros tipos enumerados. Para indicar un tipo, utilice dos puntos (:) para separar el nombre del atributo de su tipo. TambiCn podra indicar un valor predeterminado para un atributo. La figura 3.6 le muestra las formas de establecer atributos.

Aunque no parece haber restriccion en la designacion de tipos a las variables, utilizaremos 10s nombres en ingles para ceiiirnos a 10s tipos que aparecen en 10s lenguajes de programacion.

Lavadora

Un atributo puede mostrar su tipo asi como su valor predeterminado.

marca: string = "Laundatorium" modelo: string numeroserie: string capacidad: integer

Operaciones Una operacicin es algo que la clase puede realizar, o que usted ( U otra clase) pueden hacer a una clase. De la misma manera que el nombre de un atributo, el nombre de una operaci6n se escribe en minusculas si consta de una sola palabra. Si el nombre constara de mis de una palabra, linalas e inicie todas con maydscula exceptuando la primera. La lista de operaciones se inicia debajo de una linea que separa a las operaciones de 10s atributos, como se muestra en la figura 3.7. Lavadora

La lista de operaciones de una clase aparece debajo de una linea que las separa de 10s atributos de la clase.

marca modelo numeroserie capacidad agregarRopa0 sacarRopa() agregarDetergente0 activar()

Asi como es posible establecer informacidn adicional de 10s atributos, tambiCn 10 es en 10 concerniente a las operaciones. En 10s parkntesis que preceden a1 nombre de la operaci6n podri mostrar el parimetro con el que funcionari la operaci6n junto con su tipo de dato. Lafuncicin, que es un tipo de operacibn, devuelve un valor luego que finaliza su trabajo. En una funci6n podri mostrar el tipo de valor que regresari. Estas secciones de informaci6n acerca de una operaci6n se conocen como la $rma de la operaci6n. La figura 3.8 le muestra c6mo representar la firma.

FIGURA3.8 La $rma de una operacidn.

Lavadora marca modelo numeroserie capacidad

Atributos, operaciones y concepcion Hasta ahora, hemos tratado a las clases como entidades aisladas, y hemos visto todos 10s atributos y operaciones de una clase. No obstante, en la prhctica mostrarh mhs de una clase a la vez; cuando 10 haga, no sera muy util que siempre aparezcan todos 10s atributos y operaciones, ya que el hacerlo le crearia un diagrama muy saturado. En lugar de ello podrh tan solo mostrar el nombre de la clase y dejar ya sea el hrea de atributos o el de operaciones (o ambas) vacia, como se muestra en la figura 3.9. FIGURA3.9 En la practica, no siempre mostrara rodos l o s utriburos operaciones de una clase.

C Lavadora

En ocasiones sera bueno mostrar algunos (pero no todos) de 10s atributos U operaciones. Para indicar que s610 enseiiarh algunos de ellos, seguirh la lista de aquellos que mostrarh con tres puntos (...), mismos que se conocen como puntos suspensivos. A la omisi6n de ciertos o todos 10s atributos y operaciones se le conoce como abreviar una clase. La figura 3.10 le muestra el uso de 10s puntos suspensivos. FIGURA3.10 Los puntos suspensivos indican atributos u operaciones que no se encuentran en todo el conjunto.

Lavadora

...

marca

...

agregarRopa()

Si usted tiene una larga lista de atributos U operaciones podrh utilizar un estereotipo para organizarla de forma que sea mhs comprensible. Un estereotipo es el mod0 en que el UML le permite extenderlo, es decir, crear nuevos elementos que son especificos de un problema en particular que intente resolver. Como 10 mencionC en la hora 1, usted muestra un estereotipo como un nombre bordeado por dos pares de parkntesis angulares. Para una lista de atributos, podrh utilizar un estereotipo como encabezado de un subconjunto de atributos, como en la figura 3.1 1. Lavadora

Podra usar un estereotipo para organizar una lista de atributos U operaciones.

Actualizar despliegue

\

1

1 movimi Teclaz del ra'

I

En el diagrama de estados no he tratado con las ventanas que estin abiertas por otras ventanas (es decir, con subestados anidados en otros). Cuando un estado histdrico recuerda 10s subestados en todos 10s niveles de anidaci6n (como el estado Operacidn de Windows 10 hace), el estado histdrico es profundo. Si s610 recuerda el subestado principal, el estado hist6rico seri supetj+icial. Un estado hist6rico profundo se representa agregando un asterisco (*) a la " H en el circulo (H*).

El estado historic0 y el estado inicial (representados por el circulo relleno) son conocidos como pseudoestados. No tienen variables de estados n i actividades, por l o que n o son estados

Mensajes y sefiales En el ejemplo, el suceso desencadenado que provoc6 la transicidn de Protector de pantalla a Operacidn es la opresidn de una tecla, un movirniento del rat6n o una opresi6n de uno de sus botones. Cualquiera de estos sucesos es, en efecto, un mensaje del usuario a la GUI. Esto es un concept0 importante dad0 que 10s objetos se comunican mediante el envio de mensajes entre si. En este caso, el suceso desencadenado es un mensaje de un objeto (el usuario) a otro (la GUI).

Un mensaje que desencadena una transicidn en el diagrama de estados del objeto receptor se conoce como serial. En el mundo de la orientacidn a objetos, el envio de una seiial es 10 mismo que crear un objeto Seiial y transmitirlo a1 objeto receptor. El objeto Seiial cuenta con propiedades que se representan como atributos. Dado que una seiial es un objeto, es posible crear jerarquias de herencia de seiiales.

Por que son importantes 10s diagramas de estados El diagrama de estados del UML proporciona una gran variedad de simbolos y abarca varias ideas (todas para modelar 10s cambios por 10s que pasa un objeto). Este tipo de diagrama tiene el potencial de convertirse en algo complejo con pasmosa rapidez. iEn verdad es necesario? De hecho, asi es. Es necesario contar con diagramas de estados dad0 que permiten a 10s analistas, diseiiadores y desarrolladores comprender el comportamiento de 10s objetos de un sistema. Un diagrama de clases y el diagrama de objetos correspondiente s610 muestra 10s aspectos estiticos de un sistema. Muestran las jerarquias y asociaciones, y le indican quC son las operaciones. Pero no le muestran 10s detalles dinimicos de las operaciones. Los desarrolladores, en particular, deben saber la forma en que 10s objetos se supone que se comportarin, ya que son ellos quienes tendran que establecer tales comportamientos en el software. No es suficiente con implementar un objeto: 10s desarrolladores deben hacer que tal objeto haga algo. Los diagramas de estados se aseguran que no tendran que adivinar 10 que se supone que haran 10s objetos. Con una clara representacidn del comportamiento del objeto, aumenta la probabilidad de que el equipo de desarrollo produzca un sistema que cumpla con 10s requerimientos.

Adiciones al panorama Ahora puede agregar 10s "Elementos de comportamiento" a1 panorama del UML. La figura 8.9 le muestra la imagen con el diagrama de estados incluido.

FIGURA8.9

Elementos estructurales

El panorama del UML ahora incluye un elemento de comportamiento: el diagrams de estados. La organizacidn del UML, en te'minos de 10s elementos que ha utilizado hasta ahora.

0 Clase

0

lnterfaz

0

Elementos de comportamiento

U Estado

Caso de uso

Relaciones Asociaci6n

--3>

Generalizaci6n

>

Dependencia

I>

Realizaci6n

Agrupaci6n

Extens~on

€3

c~Estereotipo~~ (Restriccion) (valor etiquetado)

Paquete

Resumen Los objetos en 10s sistemas modifican sus estados como respuestas a sucesos y a1 tiempo. El diagrama de estados de UML captura estos cambios de estado. Un diagrama de estados se enfoca en 10s cambios de estado en un solo objeto. Un rectingulo de vertices redondeados representa a un estado, y una linea continua con una punta de flecha representa una transici6n de un estado a otro. El simbolo del estado contiene el nombre del mismo y puede tener variables y actividades del estado. Una transicidn puede suceder como respuesta a un suceso desencadenado, e implicar una respuesta o accidn. Una transicidn tambiCn puede ocurrir por la actividad en un estado: una transici6n que ocurre de esta forma se conoce como transicidn no desencadenada. Finalmente, una transicidn puede ocumr cuando se cumple una condicidn particular, o condicidn de seguridad. En ocasiones, un estado consta de subestados. Los subestados pueden ser secuenciales (ocurrir uno despues del otro) o concurrentes (ocurrir a1 mismo tiempo). Un estado que consta de subestados se conoce como estado compuesto. Un estado hist6rico indica que un estado compuesto recordarA su subestado cuando el objeto trascienda de este estado compuesto. Un estado histdrico puede ser superficial o profundo. Tales tCrminos son propios de 10s subestados anidados. Un estado hist6rico supe@cial recuerda s610 el subestado principal. Un estado hist6rico profundo recuerda todos 10s niveles de 10s subestados.

Cuando un objeto envia un mensaje que desencadena una transici6n en el diagrama de estados de otro objeto, tal mensaje es una sefial. Una seiial es, por si misma, un objeto, y podri crear una jerarquia de herencia de las sefiales.

Es necesario contar con 10s diagramas de estados porque facilitan la comprensi6n de 10s objetos de un sistema a 10s analistas, diseiiadores y desarrolladores. Los desarrolladores, en particular, deben saber como se supone que se comportaran 10s objetos, dad0 que seran quienes tengan que establecer estos comportamientos en el software. No es suficiente implementar un objeto: 10s desarrolladores tienen que hacer que tal objeto haga algo.

Preguntas y respuestas P LCual es la mejor manera de empezar a crear un diagrama de estados? R Es muy parecido a crear un diagrama de clases o un mode10 de caso de uso. En el diagrama de clases, listara todas las clases y luego realizara las asociaciones entre ellas. En el diagrama de estados, primer0 listari 10s estados del objeto, y luego se enfocari en las transiciones. Conforme avance en cada transicion, debera prever si un suceso desencadenado 10 activari y si se realizari alguna acci6n. P iCada diagrama de estados debe tener un estado final (el que se representa por la diana)? R No. Un objeto que nunca queda inactivo jamas tendra un estado final. P ;Alguna sugerencia para diseiiar un diagrama de estados? R Intente arreglar 10s estados y transiciones para minimizar el cruzamiento de lineas. Uno de 10s objetivos de este diagrama (y de cualquier otro) se centra en la claridad. Si las personas no pueden comprender 10s modelos que cree, nadie 10s usara y sus esfuerzos (no importa quC tan minuciosos hayan sido) habran sido infmctuosos.

Taller El cuestionario y 10s ejercicios le haran trascender a1 estado "Aprendizaje de diagramas de estados". Como siempre, encontrara las respuestas en el ApCndice A, "Respuestas a 10s cuestionarios".

Cuestionarios 1. iDe quC forma difiere un diagrama de estados de uno de clases, de objetos o de caso de uso? 2. Defina 10s siguientes tCrminos: transicidn, suceso y accidn.

3. ~ Q u Ces una transicidn no desencadenada? 4. ~ C u aes l la diferencia entre 10s subestados secuenciales y 10s concurrentes?

Ejercicios 1. Suponga que diseiiara un tostador. Cree el diagrama de estados que controle 10s estados del pan en el tostador. Incluya 10s sucesos desencadenados, acciones y condiciones de seguridad necesarios. 2. Cada vez que un objeto envie una seiial, se creari un objeto Seiial y sera transmitido. En Windows, hay varias seiiales posibles a partir de la GUI. Suponga que la seiial (el tipo de seiial que envie a Windows) sea una clase. (~QuCtipo de clase es?) Cree un diagrama de clases de las posibles seiiales y muestre toda la herencia inherente. 3, La figura 8.7 le muestra 10s subestados concurrentes dentro del estado Operaci6n de la GUI. Dibuje un diagrama del estado Protector de pantalla que incluya 10s subestados concurrentes.

Diagramas de secuencias Los diagramas de estados se enfocan a 10s diferentes estados de un objeto. Esto es s610 una pequefia parte del cuadro. El diagrama de secuencias del UML establece el siguiente paso y le muestra la forma en que 10s objetos se comunican entre si a1 transcurrir el tiempo. En esta hora se tratarin 10s siguientes temas: QuC es un diagrama de secuencias La GUI Diagramas de instancias y diagramas genkricos Uso de "si" y "mientras" Creacidn de un objeto en la secuencia Representacidn de la recursividad Diagramas de secuencias en el panorama del UML Los diagramas de estados que vio en la hora anterior se centran en un objeto y muestran 10s cambios por 10s que pasa dicho objeto.

El UML le permite expandir su campo de vision y le muestra la forma en que un objeto interacciona con otros. En este campo de vision expandido, incluira una importante dimension: el tiempo. La idea primordial es que las interacciones entre 10s objetos se realizan en una secuencia establecida y que la secuencia se toma su tiempo en ir del principio a1 fin. A1 moment0 de crear un sistema tendrti que especificar la secuencia, y para ello, utilizari a1 diagrama correspondiente.

Que es un diagrama de secuencias El diagrama de secuencias consta de objetos que se representan del mod0 usual: rectingulos con nombre (subrayado), mensajes representados por lineas continuas con una punta de flecha y el tiempo representado como una progresidn vertical.

Objetos Los objetos se colocan cerca de la parte superior del diagrama de izquierda a derecha y se acomodan de manera que simplifiquen a1 diagrama. La extensidn que esta debajo (y en forma descendente) de cada objeto sera una linea discontinua conocida como la linea de vida de un objeto. Junto con la linea de vida de un objeto se encuentra un pequefio rectingulo conocido como activacidn, el cual representa la ejecucion de una operacidn que realiza el objeto. La longitud del rectingulo se interprets como la duracidn de la activation. La figura 9.1 muestra un objeto, su linea de vida y su activacidn.

Representacidn de un objeto en un diagrarna de secuencias.

Mensaje Un mensaje que va de un objeto a otro pasa de la linea de vida de un objeto a la de otro. Un objeto puede enviarse un mensaje a si mismo (es decir, desde su linea de vida hacia su propia linea de vida). Un mensaje puede ser simple, sincrdnico, o asincrdnico. Un mensaje simple es la transferencia del control de un objeto a otro. Si un objeto envia un mensaje sincronico, esperari la respuesta a tal mensaje antes de continuar con su trabajo. Si un objeto envia un mensaje asincronico, no esperari una respuesta antes de continuar. En el diagrama de secuencias, 10s simbolos del mensaje vm'an, por ejemplo, la punta de la flecha de un mensaje simple esti formada por dos lineas, la punta de la flecha de un mensaje sincrdnico esti rellena y la de un asincr6nico tiene una sola linea, como se aprecia en la figura 9.2.

FIGURA9.2 Simbolos para 10s mensajes en un diagrama de secuencias.

>-b

Simple Sincronico ~

~

i

~

~

~

o

~

i

~

~

Tiempo El diagrama representa a1 tiempo en direcci6n vertical. El tiempo se inicia en la parte superior y avanza hacia la parte inferior. Un mensaje que estC mis cerca de la parte superior ocurrira antes que uno que estC cerca de la parte inferior. Con ello, el diagrama de secuencias tiene dos dimensiones. La dimensidn horizontal es la disposici6n de 10s objetos, y la dimensi6n vertical muestra el paso del tiempo. La figura 9.3 muestra a1 conjunto basico de simbolos del diagrama de secuencias, con 10s simbolos en funcionamiento conjunto. La figura muestra a un actor que inicia la secuencia, aunque, en sentido estricto, la figura adjunta no es parte del conjunto de simbolos del diagrama de secuencias. FIGURA 9.3 En un diagrama de secuencias 10s objetos se colocan de izquierda a derecha en /a parte superior: Cada linea de vida de un objeto es una linea discontinua que se desplaza hacia abajo del objeto. Una linea continua con una punta de flecha conecta a una linea de vida con otra, y representa un mensaje de un objeto a otro. El tiempo se inicia en la parte superior y continua hacia abajo. Aunque un actor es el que nonnalmente inicia la secuencia, su simbolo no es parte del conjunto de simbolos del diagrama de secuencias.

Para ver en acci6n a esta importante herramienta del UML, apliquCmosla en 10s ejemplos que hemos visto en las horas anteriores. Cada aplicaci6n le mostrara algunos conceptos importantes que se relacionan con 10s diagramas de secuencias.

La GUI En la hora anterior desarroll6 10s diagramas de estados que muestran 10s cambios por 10s que pasa una GUI. Ahora dibujara un diagrama de secuencias que represente las interactividades de la GUI con otros objetos.

La secuencia Suponga que el usuario de una GUI presiona una tecla alfanumCrica; si asumimos que utiliza una aplicaci6n como un procesador de textos, el caracter correspondiente debera aparecer de inmediato en la pantalla. LQUCocurre tras bambalinas para que esto suceda? 1. La GUI notifica a1 sistema operativo que se oprimi6 una tecla. 2. El sistema operativo le notifica a la CPU.

3. El sistema operativo actualiza la GUI. 4. La CPU notifica a la tarjeta de video.

5. La tarjeta de video envia un mensaje a1 monitor. 6. El monitor presenta el caracter alfanumkrico en la pantalla, con 10 que se hara evidente a1 usuario. Todo esto ocurre con tanta rapidez que olvidamos que todo ell0 se realiza. (iSi acaso pensabamos que ocurria!)

El diagrama de secuencias La figura 9.4 representa el diagrama de secuencias de la GUI. Como ve, 10s mensajes son asincr6nicos: ninguno de 10s componentes aguarda nada antes de continuar. AI trabajar con algunas aplicaciones de Windows, tal vez haya sentido algunos de 10s efectos de la comunicaci6n asincrbnica, particularmente en una maquina lenta. Cuando teclea en un procesador de textos, en ocasiones no ve aparecer en la pantalla el caracter correspondiente a la tecla que haya oprimido sino hasta despuks de haber oprimido algunas m&.

FIGURA 9.4 Un diagrama de secuencias que rnuestra la forma en que la GUI interacciona con otros objetos.

En ocasiones, es muy instructive mostrar 10s estados de uno o varios de 10s objetos en el diagrama de secuencias. Dado que ya ha analizado 10s estados de la GUI (en la hora anterior), esto es f k i l de hacer. La figura 9.5 le muestra un hibrido: el diagrama de secuencias de la GUI con 10s estados de la GUI. Observe que la secuencia se origina y finaliza en el estado Operativo de la GUI, como podn'a esperarlo.

Un diagrama de secuencias puede mostrar 10s estados de un objeto.

1

Q

1 I :Si.sterna;perafivo I I

I1:~arjetade video] I:Monitor l

0i lnicializacion

. :retroalirnentacior; L

0i Apagar

.I

II

En un diagrama de secuencias, otra forma de mostrar el cambio de estado de un objeto es incluir al objeto mas de una vez en el diagrama.

El caso de uso ~ Q u Ces exactamente lo que representa un diagrama de secuencias? En este ejemplo, muestra las interacciones de objetos que se realizan durante un escenario sencillo: la opresidn de una tecla. Este escenario podria ser parte de un caso de uso llamado "Ejecutar la opresidn de una tecla" (vea la figura 9.6). A1 representar grhficamente las interacciones del sistema en el caso de uso, el diagrama de secuencias habrh, en efecto, "delineado" el caso de uso dentro del sistema.

El caso de uso representado grcificamente por el diagrama de secuencias de la,figura 9.4.

K-

Ejecutar la opresion de una tecla

Usuario

En el siguiente ejemplo, examinarc! detalladamente la relaci6n entre 10s casos de uso y 10s diagramas de secuencias.

lnstancias y genericos El ejemplo anterior comenzd con un diagrama de estados. Este otro ejemplo empieza con un caso de uso. "Comprar gaseosa" fue uno de 10s casos de uso del ejemplo de la mhquina de gaseosas en las horas 6, "Introduccidn a 10s casos de uso", y 7, "Diagramas de casos de uso".

Un diagrama de secuencias de instancias En el mejor escenario del caso de uso "Comprar gaseosa", recuerde que el actor es un cliente que desea adquirir una lata de gaseosa. El cliente inicia el escenario mediante la insercidn de dinero en la maquina. Luego hace una selecci6n. Dado que hablamos del mejor escenario, la mhquina tiene a1 menos una lata de la gaseosa elegida y por 10 tanto presenta una lata fria a1 cliente. Asumamos que en la mhquina de gaseosas hay tres objetos que realizan la tarea que nos ocupa: la fachada (la interfaz que la maquina de gaseosas presenta a1 usuario), el registrador de dinero (que 10 recolecta), y el dispensador (que entrega la gaseosa). TambiCn daremos por hecho que el registrador de dinero controlara a1 dispensador. La secuencia serh como sigue:

1. El cliente inserta el dinero en la alcancia que se encuentra en la fachada de la mfiquina.

2. 3. 4. 5.

El cliente hace su elecci6n. El dinero viaja hacia el registrador. El registrador verifica si la gaseosa elegida esti en el dispensador.

Dado que es el mejor escenario, asumimos que si hay gaseosas, y el registrador actualiza su reserva de efectivo. 6. El registrador hace que el dispensador entregue la gaseosa en la fachada de la mfiquina.

Dado que el diagrama de secuencias s610 se centra en un escenario (una instancia) en el caso de uso "Comprar gaseosa", se conoce como diagrarna de secuencias de instancias. La figura 9.7 le muestra este diagrama. Vea que el diagrama muestra mensajes sencillos. Cada mensaje mueve el flujo de control de un objeto a otro. FIGURA 9.7 Este diagramu de secuencias modela tan scjlo el mejor escenario del caso de uso "Comprar gaseosa". Por lo tanto, es un diagrama de secuencias de instancias.

n ' lnsercion (Alimentacion)

Eleccion (Seleccion)

'

~nviar alimentacion

I1

,

=,

Despachar (Seleccion)

Un diagrama de secuencias generico Como recordarti, el caso de uso "Comprar gaseosa" tenia dos escenarios alternos. Uno de ellos se referia a1 hecho de que la mBquina no tuviera la gaseosa seleccionada y el otro cuando el cliente no contaba con el dinero exacto. Si tomara en cuenta todos 10s escenarios de un caso de uso a1 moment0 de crear un diagrama de secuencias, se trataria de un diagrarna de secuencias genkico. En este caso podri generar el diagrama de secuencias genkrico a partir del diagrama de secuencias de instancias. Para ello tendrti que justificar el control del flujo. Esto es, tendri que representar las condiciones y consecuencias de "Monto incorrecto" y "Sin gaseosa". Para el escenario relacionado con "Monto incorrecto". 1. El registrador verifica si la alimentaci6n del usuario concuerda con el precio de la gaseosa.

2. Si el monto es mayor que el precio, el registrador calcula la diferencia y verifica si cuenta con cambio.

3. Si se puede devolver la diferencia, el registrador devuelve el cambio a1 cliente y todo transcurre como antes. 4. Si la diferencia no se encuentra en la reserva del cambio, el registrador regresarS el monto alimentado y mostrari un mensaje que indique a1 cliente que inserte el monto exacto. 5. Si la cantidad insertada es menor al precio, el registrador no hace nada y la miquina esperari mis dinero.

Si diseria una maquina de gaseosas para u n cliente, tal vez tenga que tomar una decision d e diserio respecto al paso 5. Podra hacer que la maquina aguarde cierto tiempo, calcule la diferencia entre el precio y el monto insertado, y que muestre u n mensaje que solicite al cliente que inserte la diferencia. Como parte de la decision, tendra que responder a estas preguntas: L Q U ~ tanto le importara esta facultad al cliente? ~ C u a n t ocostaria implementar la tecnologia que lograra l o anterior? ~ste es u n buen ejemplo de la forma en que u n diagrama de secuencias puede influir en el proceso d e analisis.

Para representar cada condicidn en la secuencia, tal condici6n la colocarri en un "si" (un si condicional) entre corchetes. Arriba de las flechas de mensaje apropiadas, agregue [alimentacibn > precio], [alimentacidn - precio no presente] y [alimentacion - precio presente]. Cada condici6n causarri una bifurcacidn del control en el mensaje, que separari a1 mensaje en rutas distintas. Como cada ruta irri a1 mismo objeto, la bifurcacidn causara una "ramificaci6n" del control en la linea de vida del objeto receptor, y separari las lineas de vida en rutas distintas. En a l g h lugar de la secuencia, las ramas del mensaje confluirin, como las bifurcaciones en las lineas de vida. La figura 9.8 muestra un diagrama luego de agregar el escenario de "Monto incorrecto".

El diagrarna de secuencias luego de agregar el escenario de "Monro incorrecto" a1 caso de uso "Comprar guseosa ".

Ahora agregaremos el escenario "Sin gaseosa". 1. Una vez que el cliente elige una marca agotada, la maquina mostrari un mensaje de "Agotado".

2. La miquina mostrari un mensaje que solicitara a1 cliente que haga otra elecci6n. 3. El cliente tendra la opci6n de oprimir un b o t h para que se le regrese su dinero. 4. Si el cliente elige una marca en existencia, todo procedera como en el mejor escenario si el monto insertado es correcto. Si no 10 es, la maquina seguira por el escenario del "Monto incorrecto". 5. Si el cliente elige otra marca agotada, el proceso se repetiri hasta que el cliente elija una marca en existencia o presione un b o t h que le regrese su dinero. La figura 9.9 le muestra el diagrama de secuencias genCrico de la miquina de gaseosas con 10s escenarios "Monto incorrecto" y "Sin marca".

El diagrama de secuencias gene'rico de la mkquina de gaseosas luego de agregarle el escenario "Sin rnarca " a la jigura 9.8.

X

. '.-

lnsrclm (Allmentac~on)

r

_

P

-

'

.

.

: A

-

I

'

I

:

'

I

8

[Allmentacton= Preclol VeMfcar (Seleocmn)

,

.

.

8

,

a

[Allmentaoon > Precno] Verlflcar camblo:

[SI hay camblo]

hay camblol Vertflcar (Selecc~on)

Devolver Carnblo [NOhay camblo] Devolver (cargar) -Transacclon I~nabzadas.

.

a

(Salsalon agotadal Mostrar (mensale)

: :.

.

.. S

;

/

jSelecclon en exstencla] bspachar ~Selecclon) (Selecclon Mmtrar (mensate) agotaaa]

I

Q

.

.. .

I

8

I1 I

S

\

[Salecc~onen ex~stenc~a] bspachar ISeleccaon)

4 :

S

,

;

, a

,

C'

Si empieza a pensar que un diagrama de secuencias esti implicit0 en cada caso de uso, ya tiene la idea.

Creacion de un objeto en la secuencia En 10s ejemplos que hemos visto ha analizado distintos tipos de mensajes, diagramas de secuencias gentrico y de instancias, asi como estructuras de control. Otro concept0 importante relacionado con 10s diagramas de secuencias, particularmente cuando diseiie software, es la creacidn de objetos. Con frecuencia se da el caso de que un programa orientado a objetos debe crear un objeto. Recuerde que en tCrminos del software, una clase es una plantilla para crear un objeto (como un molde de galletas para crear una galleta). iC6mo representaria la creaci6n de un objeto cuando represente una secuencia de interacciones entre objetos? El caso de uso "Crear una propuesta" del ejemplo de la LAN en una firma de consultoria nos muestra una instancia de la creacidn de objetos. En este ejemplo concebiri la LAN en el entendido de que todo se realiza mediante la red. Si damos por hecho que el consultor ya ha iniciado una sesi6n en la LAN, la secuencia que modelari quedari como sigue:

1. El consultor querra volver a utilizar partes de una propuesta existente y busca en un irea centralizada de la red una propuesta adecuada. 2. Si el consultor encuentra una propuesta adecuada, abriri el archivo y, en el proceso, abriri el software integrado para la oficina relacionada. El consultor guardari el archivo con un nuevo nombre, con lo que creara un archivo nuevo para la nueva propuesta.

3. Si el consultor no encuentra una propuesta, abriri la aplicacidn de oficina y crearti un archivo para la propuesta. 4. A1 trabajar en la propuesta, el consultor utilizara las aplicaciones del software integrado para oficina. 5. Cuando el consultor finalice la propuesta, la guardarti en el irea de almacenamiento centralizada. Ademis de la creacion de objetos (en este caso, de archivos), esta secuencia trae consigo el uso de "sin asi corno de un ciclo "mientras". Primero veamos lo relacionado con la creacion de objetos. Cuando una secuencia da por resultado la creacion de un objeto, tal objeto se representara de la forma usual: corno un rectangulo con nombre. La diferencia es que no lo colocarh en la parte superior del diagrama de secuencias, sino que 10 colocarfi junto con la dimension vertical, de mod0 que su ubicacion corresponda a1 moment0 en que se cree. El mensaje que creara al objeto se nombrarfi "Crear()". Los parCntesis implican una operaci6n: en un lenguaje orientado a objetos, una operaci6n constructor genera un objeto.

En lugar de usar "CrearO" o "Create()" para etiquetar la flecha de un rnensaje de creacion de u n objeto, podria valerse de un estereotipo llarnado ((Crear,.

En el caso de "mientras", a este control de flujo 10 representara colocando la condition mientras ("mientras se trabaja en una propuesta") entre corchetes, con un asterisco (*) antes del primer corchete. La figura 9.10 le muestra el diagrama de secuencias del caso de uso "Crear una propuesta".

Este ejernplo representa una abstraccion en la que he ornitido detalles que no nos cornpeten en lo particular. Esto lo he hecho de dos forrnas. Prirnero, obvie 10s detalles de la LAN, corno lo rnencione. Tarnbien vea que la GUI es un objeto en el diagrarna de secuencias, y que n o he incluido toda la complejidad del caso de uso "Teclazo" del ejernplo anterior. Los detalles de la interaccion de la GUI con el sisterna operativo, la CPU y el monitor n o son irnportantes en este caso.

FIGURA9.10 El diagrarna de secuencias del caso de uso "Crear una propuesta ".

Como representar la recursividad En ocasiones un objeto cuenta con una operacidn que se invoca a si misma. A esto se le conoce como recursividad, y es una caracteristica fundamental de varios lenguajes de programacion. He aqui un ejemplo. Suponga que uno de 10s objetos en su sistema sea una calculadora, y que una de sus operaciones sea el cilculo de intereses. Para calcular el inter& compuesto para un period0 que incluya a varios periodos, la operacidn del calculo de intereses del obieto tendra que invocarse a si misma varias veces. Para representw esto en el UML, dibujara una flecha de mensaje fuera de la activacion que signifique la operacidn, y un pequeiio rectangulo sobrepuesto en la activacion. Dibuje una flecha de mod0 que apunte a1 pequeiio rectangulo, y una que regresa a1 objeto que inicio la recursividad. La figura 9.11 muestra 10 anterior.

Crimo representar la recursividad en un diagrama de secuencias.

Intereso

Adiciones al panorama Ahora podra agregar otro diagrama a su panorama del UML. Dado que se refiere a1 comportarniento de 10s objetos, el diagrama de secuencias iria bajo la categoria "Elementos de comportamiento". La figura 9.12 actualiza su creciente panorama. FIGURA9.12

Elementos estructurales

Elementos de compoftamiento

El panorama del UML con la adicio'n del diagrama de secuencias.

I n

(-1

U

0 Caso de uso

Relaciones Asociacidn

v Generalizacion - - - - - - - - * Dependencia - - - - - - - -D Realization

Extension

Agrupacion

R Paquete

Secuencia

'

Estereotipo" (Restriccion) (valor etiquetado)

Anotacion

Resumen El diagrama de secuencias UML agrega la dimensi6n del tiempo a las interactividades de 10s objetos. En el diagrama, 10s objetos se colocan en la parte superior y el tiempo avanza de arriba hacia abajo. La linea de vida de un objeto desciende de cada uno de ellos. Un pequeiio rectingulo de la linea de vida de un objeto representa una activacidn (la ejecucion de una de las operaciones del objeto). Puede incorporar 10s estados de un objeto coloc~ndolosjunto a su linea de vida. Los mensajes (simples, sincr6nicos y asincr6nicos) son flechas que conectan a una linea de vida con otra. La ubicaci6n del mensaje en la dimensi6n vertical representari el momento en que sucede dentro de la secuencia. Los mensajes que ocurren primer0 estin mis cerca de la parte superior del diagrama, y 10s que ocurren despuCs cerca de la parte inferior.

Un diagrama de secuencias puede mostrar ya sea una instancia (un escenario) de un caso de uso, o puede ser genCrico e incorporar todos 10s escenarios de un caso de uso. Los diagramas de secuencias genCricos con frecuencia dan la oportunidad de representar instrucciones condicionales y ciclos "mientras". Bordee a cada condicidn con corchetes, y haga 10 mismo en un ciclo "mientras" pero anteceda a1 corchete izquierdo con un asterisco. Cuando una secuencia incluya la creaci6n de un objeto, 10 representari como un rectingulo de la forma acostumbrada. Su posici6n en la dimensidn vertical representadn el moment0 en que se cre6. En ciertos sistemas, una operacidn puede invocarse a si misma. A esto se le conoce como recursividad. Se representa con una flecha que sale de la activacidn hacia si misma, y un pequeiio rectingulo sobrepuesto a la activaci6n.

Preguntas y respuestas P El diagrama de secuencias parece que podria ser util para mas que tan s61o el analisis de sistemas. ;Puedo usarlo para mostrar la interactividad en una empresa? R Asi es. Los objetos pueden ser 10s actores principales, y 10s mensajes pueden ser simples transferencias de control. P Usted indicd la forma de representar la creacidn de objetos en un diagrama de secuencias. ;Los objetos tambikn se destruyen, y si es asi, cdmo 10 represento? R Los objetos, en efecto, se destruyen. Podri representar la destruccidn de un objeto con una "X" a1 final de la linea de vida correspondiente a tal objeto.

Taller Ahora que ha vuelto hacia 10s objetos y ha visto sus interactividades, venga y responda algunas preguntas y realice algunos ejercicios para reafirrnar su conocimiento de 10s diagramas de secuencias. Encontrari las respuestas en el ApCndice A, "Respuestas a 10s cuestionarios".

Cuestionario 1. Defina mensaje sincr6nico y mensaje asincrdnico. 2. En un diagrama de secuencias genCrico jcdmo representm'a el control de flujo implicito en una instruccidn condicional?

3. ~ C d m orepresentm'a el control de flujo implicito en una instruccidn de ciclo "mientras"? 4. En un diagrama de secuencias jc6m0 representaria a un objeto reciCn creado?

Ejercicios 1. Cree un diagrama de secuencias de instancias que muestre 10 que ocurre cuando envia con Cxito un fax. Esto es, modele las interactividades entre objetos en el mejor escenario del caso de uso "enviar fax" de una maquina de fax. Incluya 10s objetos de la maquina que envia, la que recibe, el fax y un "intercambio" central que encause a 10s faxes y a las llamadas telefbnicas.

2. Cree un diagrama de secuencias genCrico que incluya escenarios infructuosos (linea ocupada, error de la maquina que envia), asi como del mejor escenario indicado en el ejercicio 1.

Diagramas de colaboraciones Ahora veremos lo correspondiente a un diagrama que es similar a1 que vimos en la hora anterior. Este tambiCn muestra la colaboraci6n entre 10s objetos, pero de una forma significativamente diferente del diagrama de secuencias. En esta hora se tratarhn 10s siguientes temas: QuC es un diagrama de colaboraciones C6mo aplicar un diagrama de colaboraciones Uso de "si" y "mientras" Anidamiento Objetos activos y concurrencia Sincronizaci6n Donde encajan 10s diagramas de colaboraciones en el UML

Los diagramas de colaboraciones muestran la forma en que 10s objetos colaboran entre si, tal como sucede con un diagrama de secuencias. Muestran 10s objetos junto con 10s mensajes que se envian entre ellos. Si el diagrama de secuencias hace eso, ipor qut el UML requerin'a otro diagrama?, iqut no son 10 mismo?, jno es una ptrdida de tiempo? Ambos tipos de diagrama son similares. De hecho, son sema'nticamente equivalentes. Esto significa que representan la misma informacion, y podra convertir un diagrama de secuencias en un diagrama de colaboraciones equivalente y viceversa. Como se infiere, es 6til contar con ambas formas. Los diagramas de secuencias destacan la sucesidn de las interacciones. Los diagramas de colaboraciones destacan el context0 y organization general de 10s objetos que interactuan. He aqui otra forma de encontrar la diferencia: el diagrama de secuencias se organiza de acuerdo a1 tiempo, y el de colaboraci6n de acuerdo a1 espacio.

Que es un diagrama de colaboraciones Un diagrama de objetos muestra a 10s objetos como tales y sus relaciones entre si. Un diagrama de colaboraciones es una extension de uno de objetos. Ademas de las relaciones entre objetos, el diagrama de colaboraciones muestra 10s mensajes que se envian 10s objetos entre si. Por 10 general, evitara la multiplicidad dad0 que podria ser fuente de confusion. Para representar un mensaje, dibujara una flecha cerca de la linea de asociacidn entre dos objetos, esta flecha apunta a1 objeto receptor. El tip0 de mensaje se mostrarh en una etiqueta cerca de la flecha; por 10 general, el mensaje le indicara a1 objeto receptor que ejecute una de sus operaciones. El mensaje finalizara con un par de parkntesis, dentro de 10s cuales colocara 10s parametros (en caso de haber alguno) con 10s que funcionarh la operation. MencionC que podra convertir cualquier diagrama de secuencias en diagrama de colaboraciones y viceversa. Por medio de esto podd representar la informacion de secuencia en un diagrama de colaboraciones. Para ello, agregari una cifra a la etiqueta de un mensaje, misma que corresponderfi a la secuencia propia del mensaje. La cifra y el mensaje se separan mediante dos puntos (:). La figura 10.1 le muestra la simbologia del diagrama de colaboraciones. Aprovechemos la equivalencia de ambos tipos de diagramas. Para desarrollar 10s conceptos de 10s diagramas de colaboraciones volveremos a ver 10s ejemplos que revisamos la hora anterior. Conforme 10 haga, verh mas conceptos.

FIGURA 10.1 Simbologia del diagrama de colaboraciones.

La GUI Este ejemplo es el caso mis directo. Un actor inicia la secuencia de interaccion al oprimir una tecla, con lo que 10s mensajes ocurriran de manera secuencial. Tal secuencia (a partir de la hora anterior) es: 1. La GUI notifica al sistema operativo que se oprimio una tecla. 2. El sistema operativo le notifica a la CPU.

3. 4. 5. 6.

El sistema operativo actualiza la GUI. La CPU notifica a la tarjeta de video. La tarjeta de video envia un mensaje al monitor. El monitor presenta el caricter alfanumCrico en la pantalla, con lo que se hari evidente al usuario.

La figura 10.2 muestra la forma de representar esta secuencia de interacciones en un diagrama de colaboraciones. El diagrama muestra la figura agregada que representa al usuario que inicia la secuencia, aunque esta figura no es parte de la simbologia de este diagrama. FIGURA 10.2 Un diagrama de colaboraciones para el ejemplo de la GUI.

Cambios de estado Puede mostrar 10s cambios de estado en un objeto en un diagrama de colaboraciones. En el recthngulo del objeto indique su estado. Agregue otro rectingulo al diagrama que haga las veces del objeto e indique el estado modificado. Conecte a 10s dos con una linea discontinua y etiquete la linea con un estereotipo {Restricci6n) (valor etiquetado)

Paquete

Resumen Un diagrama de colaboraciones es otra forma de presentar la informacidn en un diagrama de secuencias. Ambos tipos de diagramas son semhnticamente equivalentes y se recomienda usar ambos cuando construya el mode10 de un sistema. El diagrama de secuencias se organiza de acuerdo a1 tiempo, y el de colaboracidn de acuerdo a1 espacio. El diagrama de colaboraciones muestra las asociaciones entre objetos, asi como 10s mensajes que pasan de un objeto a otro. El mensaje se representa con una flecha junto a la linea de asociacidn, y una etiqueta numerada que muestra el contenido del mensaje. El nlimero representa el turno del mensaje en la secuencia. Las condicionales se representan como antes, mediante la colocacidn de la instruccidn condicional entre corchetes. Para representar un ciclo "mientras", anteceda a1 corchete izquierdo con un asterisco. Algunos mensajes provienen de otros. El esquema de numeracidn de las etiquetas representa esto de forma muy similar a 10s manuales tCcnicos que muestran sus encabezados y subtitulos: con un sistema de numeracidn que utiliza puntos decimales para representar 10s niveles del anidamiento.

Los diagramas de colaboraciones le permiten modelar varios objetos receptores en una clase, ya sea que 10s objetos reciban o no 10s mensajes en un orden especifico. TambiCn podri representar objetos activos que controlen el flujo de 10s mensajes, asi como 10s mensajes que se sincronizan con otros.

Preguntas y respuestas P ~Realmentetengo que incluir a ambos diagramas (el de colaboraciones y el de secuencias) en la mayoria de 10s modelos UML que genere? R Se recomienda hacerlo. Ambos tipos de diagramas podrin estimular diversas ideas de 10s procesos durante el segment0 de anilisis en el proceso de desarrollo. El diagrama de colaboraciones clarifica las relaciones entre 10s objetos debido a que incluye 10s vinculos entre ellos. El de secuencia se enfoca en la secuencia de las interacciones. A su vez, la organizacidn de su cliente podria incluir personas cuya idea de 10s procesos podria diferir entre ellos. Cuando tenga que presentar su modelo, un tip0 de diagrama podria comprenderse mejor para ciertas personas.

Taller Ahora que ha comprendido 10s diagramas de secuencias y a sus hermanos, 10s de colaboracidn, pruebe y fortalezca su conocimiento con el cuestionario y 10s ejercicios. Como siempre, veri las respuestas en el ApCndice A, "Respuestas a 10s cuestionarios".

Cuestionario 1. iCdmo representa a un mensaje en un diagrama de colaboraciones? 2. iC6m0 mostrm'a informacidn secuencial en un diagrama de colaboraciones?

3. iCdmo mostrm'a 10s cambios de estado? 4. iQuC se entiende por la "equivalencia semhtica" de dos tipos de diagramas?

Ejercicios 1. En el ejemplo de la maquina de gaseosas, s610 mostrC un diagrama de colaboraciones equivalente a1 diagrama de secuencias de instancia de la situacidn "importe incorrecto". Cree un diagrama de colaboraciones que corresponda a1 diagrama de secuencias genCrico de la hora 9 para el caso de uso "Comprar gaseosa". Esto es, agregue la situacidn "Gaseosa agotada" a1 diagrama de colaboraciones de la figura 10.5.

2. En el diagrama de colaboraciones del caso de uso "Crear propuesta", el consultor busca en el k e a central de almacenamiento una propuesta adecuada para volverla a utilizar. Imagine a "buscar" como un mensaje enviado para buscar en una secuencia de archives, y utilice las tCcnicas de modelado de la secci6n "Algunos conceptos mas" para cambiar el diagrama de colaboraciones en la figura 10.6.

Diagramas de actividades Ahora veremos un tip0 de diagrama que podria parecerle familiar, este diagrama le muestra 10s pasos en una operaci6n o proceso. En esta hora se tratarin 10s siguientes temas: QuC es un diagrama de actividades Aplicaci6n de 10s diagramas de actividades Marcos de responsabilidad Adiciones a1 panorama Si alguna vez ha tomado algun curso bisico de programaci6n, ya conoceri 10s diagramas de flujo. Siendo uno de 10s primeros modelos visuales que se aplicaron a la computaci6n, el diagrama de flujo muestra una secuencia de pasos, procesos, puntos de decisi6n y bifurcaciones. A 10s programadores novatos se les invita a que utilicen este diagrama para conceptualizar problemas y derivar sus soluciones. La idea es convertir a1 diagrama de flujo

en la base del c6digo. Con sus diversas caracteristicas y tipos de diagramas, el UML es en cierta medida un diagrama de flujo con esteroides. El diagrama de actividades del UML, tema de esta hora, es muy parecido a 10s viejos diagramas de flujo. Le muestra 10s pasos (conocidos como actividades) asi como puntos de decisi6n y bifurcaciones. Es litil para mostrar lo que ocurre en un proceso de negocios U operacibn. Los encontrarh como parte integral del anhlisis de un sistema.

Que es un diagrama de actividades Para empezar, un diagrama de actividades ha sido diseiiado para mostrar una visidn simplificada de lo que ocurre durante una operaci6n o proceso. Es una extensibn de un diagrama de estados, mismo que ya conoci6. El diagrama de estados muestra 10s estados de un objeto y representa las actividades como flechas que conectan a 10s estados. El diagrama de actividades resalta, precisamente, a las actividades. A cada actividad se le representa por un recthngulo con las esquinas redondeadas (mhs angosto y ovalado que la representacibn del estado). El procesamiento dentro de una actividad se lleva a cabo y, a1 realizarse, se continlia con la siguiente actividad. Una flecha representa la transicibn de una a otra actividad. A1 igual que el diagrama de estados, el de actividad cuenta con un punto inicial (representado por un circulo relleno) y uno final (representado por una diana). La figura 1 1.1 le muestra el punto inicial y final, asi como dos actividades y una transicibn. FIGURA11.l Transicidn de una actividad a otra.

Q Actividad 1

9 Actividad 2

Decisiones, decisiones, decisiones Casi siempre una secuencia de actividades llegari a un punto donde se realizari alguna decisi6n. Ciertas condiciones le llevarin por un camino y otras por otro (pero ambas son mutuamente exclusivas). Podri representar un punto de decisi6n de una de dos formas: la primera es mostrar las rutas posibles que parten directamente de una actividad y la segunda es llevar la transici6n hacia un rombo -reminiscencias del simbolo de decision en un diagrama de flujw- y que de alli salgan las rutas de decisidn (como usuario de 10s antiguos diagramas de flujo, prefiero la segunda opci6n). De cualquier forma, indicara la condici6n con una instrucci6n entre corchetes junto a la ruta correspondiente. La figura 1 1.2 le muestra las posibilidades. FIGURA11.2 Dos firmas de mostrar una decisio'n.

I

I

I

Rutas concurrentes Conforme modele actividades tendri la oportunidad de separar una transici6n en dos rutas que se ejecuten a1 mismo tiempo (es decir, de forma concurrente) y luego se relinan. Para representar esta divisibn, utilizari una linea gruesa perpendicular a la transici6n y las rutas partirin de ella. Para representar la reincorporacibn, ambas rutas apuntarin a otra linea gruesa (vea la figura 1 1.3).

Representacidn de una rransicidn que se bifurca en dos rutas que se ejecutan de forma concurrente y, luego, se reincorporan.

lndicaciones Durante una secuencia de actividades, es posible enviar una indicaci6n. Cuando se reciba, la indicaci6n provocara que se ejecute una actividad. El simbolo para enviar una indicacidn es un pentagono convexo, y el que la recjbe es un pentagono c6ncavo. La figura 11.4 le ayudara a clarificar la idea.

En terminos del UML el pentagono convexo sirnboliza al envio de un evento; el concavo simboliza la recepcion del evento.

FIGURA 11.4 Envio y recepcidn de una indicacidn.

Ell T' ' Television

Mostrar nuevo canal

Oprimir numero de canal

Aplicacion de 10s diagramas de actividades Veamos algunos ejemplos. Para empezar, diagramarh una operacidn y posteriomente un proceso.

Una operacion: Fibs ~ H a b i avisto la siguiente serie de numeros? 1, 1, 2, 3, 5, 8, 13,. ... se conoce como la "serie de Fibonacci", pues este matemitico medieval la escribid hace unos 800 aiios. Cada numero es un "fib", asi que el primer fib [o fib(l)] es 1, fib(2) es 1, fib(3) es 2, y asi sucesivamente. La regla de cada fib, except0 en 10s dos primeros, es la suma del anterior par de fibs, por ejemplo, fib(8) tendria un valor de 21. Suponga que una de sus clases es una calculadora, y que una de sus operaciones fuese la de calcular el enCsimo fib y mostrarlo. A esta operacidn podria llamarla calcularFib(n). Creemos un diagrama de actividades que modele a esta operacidn. Requerirh algunas variables como son: un contador para llevar un control para verificar si se ha llegado a1 enCsimo fib, una variable para conglomerar 10s resultados, y dos mhs para alrnacenar dos fibs que tendri que sumar entre si. La figura 11.5 le muestra el diagrama de actividades que realizm'a la tarea.

Un diagrarna de actividades para calcularFib(n), una operacidn que calcula el enksirno nu'mero de Fibonacci.

Proceso de creacion de un documento Ahora volvamos nuestra atencidn de una operaci6n a un proceso. Imagine las actividades necesarias para utilizar una aplicaci6n de oficina para crear un documento. Una posible secuencia podria ser: 1. Abrir la aplicaci6n para procesamiento de textos.

2. 3. 4. 5.

Crear un archivo. Guardar el archivo con un nombre dnico en una carpeta. Teclear el documento. Si se necesitan ilustraciones, se abre la aplicaci6n relacionada, se generan 10s graficos y se colocan en el documento.

6. Si se necesita una hoja de c8lcul0, se abre la aplicaci6n relacionada, se crea la hoja correspondiente y se coloca en el documento.

7. Se guarda el archivo. 8. Se imprime el documento.

9. Se sale de la aplicaci6n de oficina. El diagrama de actividades de esta secuencia aparece en la figura 1 1.6.

Un diagrama de actividades paru el proceso de creacio'n de un documento.

Abrir aplicacion para procesamiento de textos

(5 (3 =P Crear archivo

Guardar archivo

Teclear el docurnento

[graficos requeridosl

rir y utilizar el paquete de grafic

I

[no se requieren tablas]

Marcos de responsabilidad Uno de 10s aspectos mis litiles del diagrama de actividades es su facultad para expandirse y mostrar quiCn tiene las responsabilidad en un proceso. Veamos el caso de una firma de consultoria y el proceso de negociaci6n involucrado en una junta con un cliente. Las actividades podrian ocurrir como sigue: 1. Un vendedor hace una llamada a1 cliente y concierta una cita. 2. Si la cita es en la oficina del consultor, 10s tCcnicos corporativos prepararin una sala de conferencias para hacer una presentaci6n.

3. Si es en la oficina del cliente, un consultor prepararh una presentaci6n en una laptop. 4. El consultor y el vendedor se reunirin con el cliente en el sitio y a la hora convenidos. 5. El vendedor crea una minuta. 6. Si la reuni6n ha planteado la soluci6n de un problema, el consultor crearh una propuesta y la enviarh a1 cliente. Un diagrama de actividades estindar podria lucir como en la figura 1 1.7. El diagrama de actividades agrega la dimensi6n de visualizar responsabilidades. Para ello, separari el diagrama en segmentos paralelos conocidos como marcos de responsabilidad. Cada marco de responsabilidad muestra el nombre de un responsable en la parte superior, y presenta las actividades de cada uno. Las transiciones pueden Ilevase a cab0 de un marco a otro. La figura 11.8 muestra la versidn con marcos de responsabilidad del diagrama de actividades de la figura 11.7.

l Ambos diagramas de actividades de "Reunion con un cliente nuevo" rnuestran la creacion de una propuesta como actividad. En cada caso, tal actividad podria tener una nota adjunta que cite al diagrama de actividades para la creacion del documento.

Un diagrama de actividudes para el proceso de negociacicin en una junta con un cliente.

de conferencias

W Junta con el cliente

[planteamiento diagrama de actividades para

,

--

Crear propuesta [no se plantea un problema] al cliente

La versidn con marcos de trahajo de diagrams de actividades de lajgura 11.7 que muestra quie'n es el responsuble de cadu uctividud.

C Ver el diagrarna de activ~dades para crear un documento

Diagramas hibridos Recordemos el diagrama de actividades para la creaci6n de un documento. Podra depur, la actividad de la impresi6n de un documento. En lugar de s61o mostrar una actividad "Imprimir documento", podria ser un poco m& especifico. La impresi6n se realiza dad( que una sefial dentro del archivo de documento se transmite desde la aplicaci6n para el procesamiento de textos a la impresora, misma que la recibe y la imprime. La figura 1 1.9 le muestra que podra representar esto con 10s simbolos para la transmisic y recepci6n de sefiales, junto con un objeto Impresora que reciba a1 simbolo y realice SI tarea de impresibn. ~ s t es e un ejemplo de diagrama hibrido, dad0 que contiene simbolo que normalmente asociatfa con diferentes tipos de diagramas.

La depuracidn de la actividad "lrnprirnir docurnento" nos otorga un diagrarna hibrido.

0 0 9 Y Crear archivo

Guardar archivo

Teclear el documento

[graficos requeridos]

Abrir y utilizar el paquete de graficos

[no se requieren graficos]

[no se requieren tablas]

0 lmprimir

He aqui otra posibilidad de diagrama hibrido: podrh mostrar un diagrama de actividades para realizar una operacidn dentro de un simbolo de objeto, y mostrar a1 objeto que recibe una peticidn para ejecutar la operacidn. Suponga que model6 al objeto Calculadora, el cual calcula 10s numeros de Fibonacci. Los desarrolladores podrian encontrar util que usted lo representara con un diagrama hibrido como el de la figura 11.10. FIGURA11.10 Un diagrarna hibrido puede rnostrar un diagrarna de actividades dentro de un objeto.

Adiciones al panorama La figura 1 1.1 1 muestra el panorama del UML, donde se incluye el diagrama de actividades. Este diagrama es un element0 de comportamiento.

Elernentos estructurales

El panorama del UML ahora incluye a1 diagrama de actividades.

Elernentos de corn~ortarniento

0 Estado

0 Caso de uso

Relaciones Asociacion

-0 - - - - m - - -

Generalizacion

•

Dependencia Secuencia

Agrupacion

Extension ~~Estereotipo~~

Paquete

(Restriccion) (valor etiquetado)

Actividad

Resumen El diagrama de actividades del UML es muy parecido a un diagrama de flujo. Muestra 10s pasos, puntos de decisidn y bifurcaciones. Este tipo de diagrama es litil para representar las operaciones de un objeto y 10s procesos de negocios. El diagrama de actividades es una extensidn del diagrama de estados. Los diagramas de estados destacan 10s estados y representan actividades como flechas entre 10s estados. Los de actividad se enfocan en las actividades. Cada actividad se representa como un recthngulo con esquinas redondeadas, mhs ovalados en apariencia que la representacidn de un estado. El diagrama de actividades utiliza 10s mismos simbolos que el de estados para 10s puntos de inicio y final.

Cuando una ruta se divide en dos o mas, tal dispersidn se representa con una linea gruesa perpendicular a las rutas, mismas que se reunen en una linea similar. Dentro de un diagrama de secuencias puede mostrar una seiial, cuya transmisidn se representa con un pentagono convexo, y la recepcidn con uno c6ncavo. En un diagrama de actividades, puede representar las actividades de acuerdo con la responsabilidad asignada. Esto 10 hm'a con marcos de responsabilidad, mismos que son segmentos paralelos que corresponden a 10s responsables de realizar cada tarea. Es posible combinar a1 diagrama de actividades con simbolos de otros diagramas con lo que se producirin diagramas hibridos.

Preguntas y respuestas

P hsta es otra de esas preguntas de "~Realmentelo necesito?". Con todo lo que nos muestra un diagrama de estados, irealmente necesito 10s de actividad? R Yo le recomiendo que incluya 10s diagramas de actividades en su analisis. Pueden poner en claro algunos procesos y operaciones para usted y sus clientes. TambiCn son muy utiles para 10s desmolladores. Es muy probable que un buen diagrama de actividades sea de gran utilidad para que un desarrollador codifique una operacibn. P Ha mostrado dos tipos de diagramas hibridos. ;El UML establece limitacione; en 10s tipos de hibridos que puede crear? R No, en absoluto. El UML no intenta ser restrictive. Aunque tiene algunas reglas sintacticas, la idea es que 10s analistas generen un mode10 que transmita una idea consistente a 10s clientes, diseiiadores y desarrolladores; no la de satisfacer cefiida! reglas lingiiisticas. Si puede generar un diagrama hibrido que ayude a que todos lo involucrados comprendan un sistema, higalo.

Taller El cuestionario y 10s ejercicios le haran razonar 10s diagramas de actividades y su utilidac Las respuestas se encuentran en el ApCndice A, "Respuestas a 10s cuestionarios".

Cuestionario 1. iCuales son las dos formas de representar a un punto de decisidn? 2. iQuC es un marco de responsabilidad?

3. iC6m0 representaria la transmisidn y recepci6n de una indicacidn?

Ejercicios 1. Cree un diagrama de actividades que muestre el proceso que realizaria a1 encender su automovil. Empiece a1 colocar la llave en el switch, finalice con el motor en funcionamiento y tome en cuenta todo 10 que haria si el motor no arrancara de inmediato. 2. iQuC podria agregar a1 diagrama de actividades en el proceso de negociaci6n de la junta con un cliente nuevo? 3. Si distribuye tres piedras de mod0 que una de ellas se ubique en una fila y las otras dos en otra, formarian un triangulo. Si hace 10 mismo con seis piedras, de manera que se ubiquen: una en una fila, dos en la siguiente, y tres en la ultima, tambikn formarian un triangulo. Por ello, a 10s numero 3 y 6 se les conoce como numeros triangulares. El siguiente numero triangular es 10, el que le sigue es 15, y asi por el estilo. El primer numero triangular es 1. Cree dos diferentes diagramas de actividades para un proceso que calcule el enksimo numero triangular. Para uno, inicie con n y continue en orden regresivo. Para el otro, inicie con 1 y continue en orden progresivo. 4. He aqui un ejercicio para quienes les gustan las matematicas. Si se sinti6 a gusto con el ejercicio 3, tal vez le guste este otro. Si no, tan s610 continue con la siguiente hora (ipodria intentar diagramar 10 que dije en las dos ultimas oraciones!). En la geometria coordinada, se representa un punto en el espacio a1 mostrar su posici6n X y y. Por ello, puede decir que la ubicacion del punto 1 es X l , Y l. La del punto 2 es X2, Y2. Para encontrar la distancia entre estos puntos, eleve a1 cuadrado X2-X1 y luego Y2-Y 1. Sume ambos cuadrados y calcule la raiz cuadrada de la suma. Cree un diagrama de actividades para una operacidn distuncia (XI, Y I , X2, Y2) que localice la distancia entre dos puntos.

Diagramas de componentes En las horas anteriores ha visto diagramas que tratan temas conceptuales. Un diagrama de clases representa un concepto, es decir, la abstracci6n de elementos que confluyen en una categon'a; un diagrama de estados tambiCn representa un concepto, como son 10s cambios en el estado de un objeto. Ahora veri el uso de un diagrama que es algo distinto a 10s que ha visto, y aprenderi lo correspondiente a un diagrama UML que representa a una entidad real: un componente de software. En esta hora se trataran 10s siguientes temas: QuC es un componente Componentes e interfaces QuC es un diagrama de componentes Aplicaci6n de 10s diagramas de componentes Diagramas de componentes en el panorama del UML

Que es un componente Un componente de software es una parte fisica de un sistema, y se encuentra en la computadora, no en la mente del analista. ~ Q u Cpuede tomarse como componente? Una tabla, archivo de datos, ejecutable, biblioteca de vinculos dinimicos, documentos y cosas por el estilo. /,Cuil es la relacidn entre un componente y una clase? Imagine a un componente como la personificacidn en software de una clase. La clase representa una abstraccidn de un conjunto de atributos y operaciones. Un importante punto por recordar de 10s componentes y clases es que un componente puede ser la implementacidn de m& de una clase. Si el componente se encuentra en una computadora y es la parte funcional del sistema, ipara quC preocuparse por Cl? Tendri que modelar componentes y sus relaciones para que: l. Los clientes puedan ver la estructura del sistema finalizado. 2. Los desarrolladores cuenten con una estructura con la cual trabajar en adelante. 3. Quienes escriban las notas tkcnicas y la documentacidn puedan entender de quC escribiran. 4. Usted se aliste para volver a utilizar 10s componentes. Exploremos el liltimo punto. Uno de 10s aspectos mis importantes de 10s componentes es el potencial que tienen de volver a ser utilizados. Con las necesidades actuales de 10s negocios de soluciones ripidas, entre m& rapid0 presente un sistema para producci6n, mayor sera su competitividad. Si puede crear un componente para un sistema y puede volver a utilizarlo en otro, usted habri contribuido a esa competitividad. Tdmese el tiempo y esfuerzo para modelar un componente que 10 ayude a que esta reutilizacidn pueda llevarse a cabo. Recordaremos la reutilizacidn a1 final de la siguiente seccidn

Componentes e interfaces Cuando trate con 10s componentes, tendri que tratar con sus interfaces; a1 tratar el tema de las clases y 10s objetos, hablC de las interfaces. Como recordari en la hora 2, "Orientacidn a objetos", un objeto oculta a1 mundo exterior 10 que hace (10 que se conoce como encapsulacidn, encapsulamiento U ocultamiento de informacidn). El objeto tiene que presentar un "rostro" a1 mundo exterior, para que 10s demhs objetos (incluso, potencialmente, 10s humanos) puedan pedirle que ejecute sus operaciones. A este "rostro" se le conoce como interfaz del objeto. Di mayores detalles de esta idea en la hora 5, "Agregaci6n, composicidn, interfaces y relaci6nW.Como 10 mencionC en su momento, diversas clases podrian no estar relacionadas con una clase principal (como en la herencia), per0 sus acciones podrian incluir algunas de las mismas operaciones con las mismas firmas. Podri reutilizar

este conjunto de operaciones de clase en clase. La interjiuz es la construcci6n UML que le permite hacer esto. Una interfaz es un conjunto de operaciones que especifica algo respecto a1 comportamiento de una clase. Imagine a una interfaz como una clase que s610 contiene operaciones (no atributos). Para resumir: la interfaz es un conjunto de operaciones que presenta una clase a otras. AI tratar las interfaces en la hora 5, tambitn mencionC que la relaci6n entre una clase y su interfaz se conoce como realizacidn. iUn momento! Parecen'a que modelar una interfaz es la practica de modelar un concepto. AI principio de esta hora, le dije que cuando modele un componente no sera algo conceptual, dad0 que se encontrara en una computadora. ~ D o n d eesta la conexibn? En si, una interfaz puede ser fisica o conceptual. La interfaz que utiliza una clase es la misma que la que utiliza su implementaci6n de software (un componente). Como modelador, esto significa que la de la misma forma en que represente una interfaz para una clase representara una interfaz para un componente. Aunque la simbologia del UML distingue entre una clase y un componente, no hace distinci6n entre una interfaz conceptual y una fisica. Hay un punto importante a este respecto: solo podra ejecutar las operaciones de un componente a travts de su interfaz. De la misma manera que en el caso de una clase y su interfaz, la relaci6n entre un componente y su interfaz se conoce como realizacidn. Hay otro punto por destacar: un componente puede hacer disponible su interfaz para que otros componentes puedan utilizar las operaciones que contiene. Es decir, un componente puede acceder a 10s servicios de otro componente. El componente que proporciona 10s servicios se dice que provee una interjiaz de exportacidn. A1 que accede a 10s servicios se dice que utiliza una interjiuz de importucidn.

Sustitucion y reutilizacion Las interfaces se destacan de forma importante en 10s conceptos primordiales de sustitucidn y reutilizacion de componentes. Puede sustituir un componente con otro si el nuevo contiene las mismas interfaces que el anterior. Podra reutilizar un componente en otro sistema si Cste puede acceder a1 componente reutilizado mediante sus interfaces. Puede diseiiar un componente para ser reutilizado en proyectos de desarrollo a 10 largo de su empresa si quiere depurar sus interfaces para que un amplio rango de componentes puedan acceder a ellos. Es aqui donde son utiles las interfaces en el modelado. Puede simplificarse la vida de un desarrollador que intente sustituir o reutilizar un componente si la informaci6n de su interfaz se encuentra disponible como un modelo. Si no, el desarrollador tendra que pasar por el largo proceso de hacer un seguimiento del c6digo.

Tipos de componentes Conforme avance en su carrera como modelador, se encontrara con tres tipos de componentes:

1 . Componentes de distribucidn, que conforman el fundamento de 10s sistemas ejecutables (por ejemplo, DLL, ejecutables, controles ActiveX y Java Beans). 2 . Componentes para trabajar en el producto, a partir de 10s cuales se han creado 10s componentes de distribucion (como archivos de base de datos y de c6digo). 3. Componentes de ejecucidn, creados como resultado de un sistema en ejecucion. Si es usted un usuario de Windows, encontrara ejemplos de 10s tres tipos de componentes cuando utilice la ayuda, aunque tal vez no 10 sepa. El componente de distribucion es el archivo .HLP (Archivo de Ayuda): Cuando haga clic en uno, se abriri el cuadro de di8logo de 10s temas de la ayuda y empezara a buscar el tema que elija. La primera vez que haga clic en la ficha Buscar, veri una pequefia animacidn que le indicarh que se est6 creando un indice. Un archivo .CNT (tema de contenido) describe el esquema del contenido. Dado que este archivo le ayuda a crear un componente de distribucion (puede utilizar la pagina de indice por siempre), es un componente para trabajar en el producto. A su vez, el indice creado se encuentra en un archivo .FTS (busqueda de texto cornpleto). Finalmente, la primera vez que abra la ayuda, se creara un archivo .GID (indice general), que es resultado de un analisis del sistema de ayuda de Windows que agiliza el acceso a 10s temas del archivo de ayuda. Con ello, 10s archivos .FTS y .GID son componentes de ejecuci6n.

Que es un diagrama de componentes Un diagrama de componentes contiene, obviamente, componentes, interfaces y relaciones. Tambitn pueden aparecer otros tipos de simbolos que ya haya visto.

Representacion de un componente El simbolo principal de un diagrama de componentes es un rectangulo que tiene otros dos sobrepuestos en su lad0 izquierdo. La figura 12.1 le muestra este simbolo. Debe colocar el nombre del componente dentro del simbolo. El nombre es una cadena. FIGURA12.1 El simbolo que representa a un

La figura 12.2 le muestra que si el componente es miembro de un paquete, puede utilizar el nombre del paquete corno prefijo para el nombre del componente. Tambitn puede agregar informaci6n que muestre algdn detalle del componente. FIGURA12.2 Adicidn de inforrnacicin a1 sirnbolo del cornponente.

herrarnientas:: calculadora.java

ProcesadorTextos VerificadorOrtografico ContadorPalabras

El simbolo a la derecha de la figura 12.2 le muestra las clases que implementa un componente en particular. La figura 12.3 le muestra otra forma de hacer esto, aunque esta tCcnica por 10 general desordena el diagrama. Vea las relaciones de dependencia entre el componente y las clases. FIGURA12.3 Sirnbolos de las relaciones entre un cornponente J las cluses que irnplernenra. ProcesadorTextos

ContadorPalabras

Como representar las interfaces Existen dos formas para representar a un componente y sus interfaces: la primera muestra la interfaz corno un rectangulo que contiene la informacion que se le relaciona, se conecta al componente por la linea discontinua y una punta de flecha representada por un trihngulo sin rellenar que visualiza la realization (vea la figura 12.4).

Puede representar a una interjaz corno un recta'ngulo con inforrnacidn, conectado a1 cornponente por una jlecha de realizacidn.

ElernentoDeEscucha

------

AWTEventMulticaster

La figura 12.5 le muestra la segunda forma de representar a un componente y sus interfaces; esta forma es representativa, ya que representara la interfaz como un pequeiio circulo que se conecta a1 componente por una linea continua. En este contexto, la Iinea representa la relacibn de realizacibn (compare a las figuras 12.4 y 12.5 con las figuras 5.6 y 5.7). FIGURA12.5 Puede representar a una inte&z como un pequeAo circulo, conectado a1 componente por una linea continua yue, en este contexto, se interprets como realizacidn.

AWTEventMulticaster

ElementoDeEscucha

Ademis de la realizacibn, puede representar a la dependencia, que es la relacion entre un componente y una interfaz de importation. Como recordara, la dependencia se vislumbra como una linea discontinua con una punta de flecha. Puede mostrar la realizaci6n y la dependencia en el mismo diagrama, como se ve en la figura 12.6. FIGURA12.6 Una interfaz rea- que l i ~ aun componente y otra de la que depende.

AWTEventMulticaster

AWTEventMulticaster

I ElernentoDeEscucha

---

Casillaverificacion

ElernentoDeEscucha Casillaverificac~on carnbioAIEstadoDelElemento()

Aplicacion de 10s diagramas de componentes Algunos ejemplos le ayudariin a empezar a usar 10s diagramas de componentes. El primero es un modelo de una pagina Web que representa a un componente Java. El siguiente tambiCn es un modelo de una pagina Web pero Cste utiliza controles ActiveX. Finalizara con un modelo de un paquete de Microsoft conocido como PowerToys. Este paquete, que puede obtener del sitio de Microsoft, le permite modificar aspectos de Win32.

Una pagina Web con un subprograma Java Este ejemplo modela un programa tomado del excelente y entretenido libro de Rogers Cadenhead llamado Aprendiendo programacidn con Java l .l en 24 horas (Prentice Hall

Hispanoamericana, 1997). El ejemplo aparece en la hora 22, "Escriba un juego para Web". Rogers muestra cdmo generar un applet (o subprograma) que ejecuta el juego de dados "Craps" en una pagina Web, y utiliza una clase llamada "Die" (para crear 10s dados) de la hora 2 1, "A jugar con Java". Para ver 10s detalles del c6dig0, tendrh que leer el libro. Aqui s610 nos concentraremos en 10s componentes.

Un applet es un pequeiio prograrna hecho en Java que funciona en una pagina Web.

La pagina Web se llama Craps.htm1. El cddigo fuente del applet se encuentra en el archivo Craps.java, y el cddigo objeto es el archivo Craps.class. El cddigo fuente de la clase Die se encuentra en Die.java y el cddigo objeto en Die.class. Los cinco archivos se encuentran en el mismo directorio - - y e llamaremos Tirodedados (que no es el nombre que Roger le dio)-. Craps.html depende, obviamente, de Craps.class y Die.class. Cada archivo .class es un componente y cada uno es la implementacidn de una clase. Lo que no es muy obvio (tendria que ver el cddigo fuente para descubrirlo) es que tanto Craps.java como Die.java importan (utilizan las clases de) java.awt, un gmpo de clases que muestran y controlan la GUI (el "awt" significa: "Conjunto de herramientas abstractas para manejar ventanas").

En el context0 de Java, la irnportacion perrnite al desarrollador utilizar solo el nornbre de una operacion cuando la escribe en un prograrna, en lugar de utilizar toda la ruta de la operacion (que podria ser rnuy larga). La irnportacion no "incrusta" una clase en otra. Tan solo perrnite escribir algo rnas corto.

Craps.java es un applet, y por ell0 se hereda desde la clase java.applet.Applet. Finalmente, Craps.java importa a java.awt.event e implementa una interfaz ActionListener (para responder a 10s eventos generados por el usuario, como hacer clic con el ratdn). Dentro del cddigo, la interfaz ActionListener proporciona un botdn para que el usuario haga clic para que se "tiren 10s dados". A1 ver la referencia de Java, notara que la clase java.awt.AWTEventMu1ticasterimplementa esta interfaz. ~ S a b quC? e ~ E s seria ~ o m8s fhcil de comprender si viera el mode10 UML! La figura 12.7 le muestra el diagrama de componentes. Un paquete corresponde a1 directorio en donde se encuentran 10s archivos, el otro a1 JDK (Conjunto de herramientas para desarrollo en Java).

FIGURA 12.7 El diagrarna para el juego de dados basado en la Web de Rogers Cadenhead.

Crapshoot

Este ejercicio --generar un modelo a partir de un codigo existente- se conoce como ingenieria inversa.

Una pagina Web con controles ActiveX ActiveX es el medio de Microsoft para agregar componentes a las aplicaciones. Con tantos tipos de componentes ActiveX (controles) disponibles, podra encontrar alguno que haga casi todo lo que requiera una aplicaci6n. Una propiedad de un componente ActiveX es su nlimero de identificaci6n hexadecimal linico de 32 bits, conocido como CLSID (identificador de la clase). Si sus requerimientos son especiales, podra generar su propio componente ActiveX en Visual Basic o Visual C++. Luego podra reutilizarlo de aplicacidn en aplicaci6n. En las paginas Web, los componentes ActiveX se encuentran y trabajan con el c6digo escrito en alglin lenguaje para secuencias de comandos como VBScript. En este ejemplo, la phgina Web cuenta con un control Timer ActiveX, dos cuadros combinados ActiveX y tres botones ActiveX. La pigina Web permite a un usuario establecer 10s parkmetros para

animar el movimiento de una esfera (una imagen .gif) por la pantalla. De un cuadro combinado, el usuario selecciona la cantidad de pixeles por movirniento. Del otro se selecciona la cantidad de milisegundos entre movimientos. Un bot6n iniciara el movimiento, el otro 10 detendra y el tercero restaurari la esfera a su posici6n inicial. El cron6metro mover5 la esfera cuando pase la cantidad de milisegundos elegida por el usuario. Los controles ActiveX se encuentran en un componente separado conocido como Disposicirin (Layout). La pagina HTML y la disposici6n se encuentran en el mismo directorio. L,a figura 12.8 le muestra el diagrama de componentes para esta pagina. Observe el uso del simbolo de anotaci6n para representar a1 VBScript. Aunque esto no es absolutamente necesario, destaca una diferencia entre el lenguaje de secuencias de comandos y 10s componentes compilados ActiveX.

FIGURA 12.8 El diagrama de cornponentes para una pdgina Web con componentrs ActivrX,

PowerToys Si utiliza cualquier versidn de Win32, ya conoceri las horribles flechas pequeiias que se encuentran en la esquina inferior izquierda de cada icono de acceso directo. Microsoft tiene un paquete llamado PowerToys que le permite eliminarlas y hacer varias otras cosas con la GUI, mediante una aplicaci6n llamada TweakUI que es parte del paquete. Puede obtener a PowerToys del sitio Web de Microsoft. Es gratis. Cuando 10 obtenga y descomprima, vera varios archivos con extensiones .dll. TambiCn vera un archivo de

ayuda y otro .CNT. Haga clic en el archivo de ayuda y generari un archivo .GID. Utilice la caracteristica Buscar y crearh un archivo .ITS. La figura 12.9 le muestra un diagrama de componentes que modela a TweakUI en el paquete PowerToys, mismo que muestra las dependencias entre 10s diversos tipos de componentes. FIGURA12.9 Modelado de TweakUl en el paquete PowerToys.

l

Powertoys

D Setup lnfo I

I

FFt ]FJ--

F-]

-

\

l I

TweakUl.fts

8

. TweakULcnt

Diagramas de componentes en el panorama Ya casi tiene todo su panorama. La figura 12.10 incluye el diagrama de componentes, que se enfoca en una arquitectura de software del sistema. En la siguiente hora, veri c6mo modelar la arquitectura de hardware.

FIGURA 12.10

Elementos estructurales

Su panorama del U M L ahora incluye a1 diagruma de componentes.

Elementos de comportamiento

n

V lnterfaz

Caso de uso

U Estado

Componente

Relaciones Asociacion

D -. Generalizacion - - - - - - - - + Dependencia - - - - - - - -pRealization Agrupacion

Paquete

I

I

Secuencia

Extension -Estereotipo)) (Restriccion) (valor etiquetado) Colaboracion

Anotacion

Actividad

Resumen El diagrama de componentes UML es un conglomerado de figuras de 10s diagramas que ya ha visto. En lugar de representar una entidad conceptual como una clase o estado, un diagrama de componentes representa a un element0 real: un componente de software. Estos componentes se encuentran en las computadoras, no en la mente del analista. Un componente puede accederse a travCs de su interfaz, una coleccidn de operaciones. La relacidn entre un componente y su interfaz se llama realizacidn. Un componente puede acceder 10s servicios de otro. Cuando se hace, utiliza una interfaz de importacidn . El componente que realiza la interfaz con tales servicios proporciona una integaz de exportacio'n. La representacidn de un componente es un rectingulo con otros dos rectangulos pequeRos sobrepuestos en su lado izquierdo. Puede representar una interfaz de dos formas: la primera es un rectingulo que contiene informacibn de la interfaz y se conecta con el componente mediante una linea discontinua con una punta de flecha representada por triingulo sin relleno. La otra es un pequeiio circulo conectado a1 componente con una linea continua. Ambos tipos de conexidn pretenden mostrar una relacibn de realizacibn.

Preguntas y respuestas

P En un diagrama de componentes, jcual sera la regla de oro para usar simbolos que no representen a componentes? R Esto 10 hara cuando desee indicar algo que sea ciertamente distinto de un componente compilado. No es necesario, pero podria ayudar a tener otro punto de vista. Podria utilizar el simbolo de la anotaci6n para representar archivos de encabezado, dll, o archivos de secuencias de comandos. Otra posibilidad es la de utilizar el simbolo regular del componente con un estereotipo que indique el tip0 de archivo. P Ha utilizado a VBScript como un componente de la pagina Web. El c6digo de VBScript consta de varios procedimientos. ;No podria modelar cada uno como componente? R Si, podria. No obstante, podria desordenar su modelo si depurara a1 VBScript (o JavaScript) hasta tal nivel, asi que podria, mejor, agregar una nota que abunde at respecto.

Taller

En este taller reforzara su conocimiento respecto a 10s componentes y c6mo modelarlos. Uno de 10s ejercicios trata de 10s conceptos de una pagina Web, el otro de DLL. El ApCndice A, "Respuestas a 10s cuestionarios", sera el componente del libro que contenga las respuestas.

Cuestionario 1. 2. 3. 4.

iCuales son 10s tres tipos de componentes? ~ C Ollamaria ~ O a la relaci6n entre un componente y su interfaz? iCu6les son las dos formas de representar a esta relacion? iQut es una interfaz de exportaci6n? iQue es interfaz de importaci6n?

Ejercicios 1. AdentrCmonos en la ingenieria inversa para modelar una pagina Web. Visite h t t p : I /W. p e a r s o n . com. mx, la pagina Web de Pearson Educaci6n (la empresa que amablemente public6 el libro que ahora lee). Utilice el menli Ver de su explorador para seleccionar la opci6n que le deje a la vista el c6digo fuente. No encontrarh ninglin componente ActiveX o applet de Java, pero vera diversos archivos .gif y cierto c6digo en JavaScript. No incluya todos 10s archivos .gif en su modelo, s610 algunos para reafirmar su comprensibn. Vaya a1 principio del c6digo y vera una referencia a una hoja de estilo. La referencia se encuentra en un element0 LINK de HTML. Este es un archivo por separado que contiene la informaci6n de estilo para la piigina Web. Aseglirese de incluirla en su modelo.

2. En el diagrama de colaboraciones del caso de uso "Crear propuesta", el consultor busca en el 5rea central de almacenamiento una propuesta adecuada para volverla a utilizar. Imagine a "buscar" como un mensaje enviado para buscar en una secuencia de archivos, y utilice las tCcnicas de modelado de la seccidn "Algunos conceptos mis" para cambiar el diagrama de colaboraciones en la figura 10.6.

Diagramas de distribucion Hasta ahora nos hemos concentrado en el entorno conceptual, aunque en la hora anterior vimos 10s modelos de la arquitectura de software. Es moment0 de concentrarnos en el hardware. Como podri ver, hemos trascendido desde 10s elementos (como las clases) que se encuentran en 10s analisis, hasta 10s componentes en 10s equipos de c6mputo y a1 hardware existente. Claro esta que el hardware es un tema primordial en un sistema de varios componentes. En el mundo actual de la computacibn, un sistema podria abarcar diversos tipos de plataformas en ubicaciones dispersas. Un diseiio sdlido de distribucidn de hardware es basico para el disefio del sistema. El UML le da 10s simbolos para crear una imagen clara de la forma en que deberi lucir el hardware final. En esta hora se trataran 10s siguientes temas: QuC es un diagrama de distribucidn Aplicaci6n de 10s diagramas de distribuci6n Los diagramas de distribuci6n en el panorama del UML

Que es un diagrama de distribucion El element0 primordial del hardware es un nodo, que es un nombre genCrico para todo tip0 de recurso de c6mputo. Es posible usar dos tipos de nodos: un procesador, el cual puede ejecutar un componente, y un dispositivo que no 10 ejecuta. Normalmente, un dispositivo (como impresora o monitor) tiene contact0 de alguna forma con el mundo exterior. En el UML, un cubo representa a un nodo. Debera asignar un nombre para el nodo, y podra utilizar un estereotipo para indicar el tipo de recurso que sea. La figura 13.1 le muestra un nodo. FIGURA13.1 Representacirin de un nodo en el UML.

El nombre es una cadena de texto. Si el nodo es parte de un paquete, su nombre puede contener tambiCn el del paquete. Puede dividir a1 cubo en compartimientos que agreguen informaci6n (como componentes colocados en el nodo), como en la figura 13.2.

Crime agregar informacirin

m Servidor

t Destaca: Directorio telefonico corporativo Programa de busqueda

Otra forma de indicar 10s componentes distribuidos es la de mostrarlos en relaciones de dependencia con un nodo (vea la figura 13.3).

Puede mostrar 10s componentes en relaciones de dependencia con un nodo.

Directorio telefonico corporativo

Programa debusqueda

~esultadode la busqueda

Una linea que asocie a dos cubos representarh una conexi611entre ellos. PodrA utilizar un estereotipo para dar informaci6n respecto a la conexibn. La figura 13.4 proporciona ejemplos de conexiones entre nodos.

Tenga en cuenta que una conexion no es necesariamente u n cable o alambre. Tambien puede visualizar conexiones inalambricas como las infrarrojas o satelitales.

FIGURA13.4 Representacicin de conexiones entre nodos.

Servidor

X

Directorio telefonico corporative

I

Resultado de la busqueda

I I

Cliente

I I

I

Programa de presentacion

Aunque la conexi6n es el tip0 c o m ~ nde asociaci6n entre dos nodos, es posible utilizar otros (como la agregaci6n o la dependencia). PodrA representarlas de las formas ya conocidas.

Aplicacion de 10s diagramas de distribucion Un buen lugar para empezar es con un equipo de c6mputo domkstico, por 10 que el primer ejemplo es un diagrama de distribucidn del sistema que utilick para escribir este libro.

No obstante, como lo dije, 10s sistemas actuales de varios procesadores conectan nodos que podrian encontrarse lejanos entre si. Para visualizar completamente este problema, necesitar6 tambiCn ver 10s ejemplos de 10s diagramas de distribution aplicados a las redes. IncluirC ejernplos que podran servirle para adaptarlos a su propio entorno. Cada ejemplo incluye restricciones que reflejan las reglas de la red particular.

Un equipo domestic0 Para modelar mi equipo de compute, he incluido al procesador y 10s dispositivos, a la vez de que he modelado mi conexion telefonica con rni proveedor de servicios de Internet y su conexion. La nube que representa la Internet no es parte de la simbologia del UML, pero es util para clarificar el rnodelo. La figura 13.5 presenta el diagrama de distribucion.

FIGURA13.5 lnternet

El diagrama de distribucio'n de mi equipo de ccimputo.

Monltor Leading Net

radlus D~splaylzo

Conexlon telelon~ca

/

//

/

"Procesador..

PC ~-D~sp~sltlvox Modem Z w m 56K

p

Computer Renalssance F'entwm 11 400 MHz

a X

"D~spos~t~volmpresora NEC SuperScnpt 860

Windows 95

Onlce 97

a, '3311

lmernet Explorer

Una red token-ring En una red token-ring, las computadoras equipadas con una NIC (tarjeta de interfaz de red) se conectan a una MSAU (unidad central de acceso a rnultiestaciones). Se conectan varias MSAU en una serie que podria parecer un anillo (por ello la parte "ring" del nombre). El anillo de MSAU se cornbina para fungir como un policia de trhnsito, mediante una seiial

conocida como token que permite a cada equipo de c6mputo saber cuhndo puede transmitir informaci6n. Asi es, el token va de equipo en equipo hasta que uno de ellos contenga informacion por enviar. En realidad, el token se mueve por el anillo de MSAU. Cuando se obtiene el token, so10 esa informaci6n del equipo puede ir por la red. Una vez que se envia, la informaci6n viaja hasta su destino. Cuando llega, se devuelve un acuse de recibo al equipo que la envib. En este ejemplo, que se aprecia en la figura 13.6, he modelado una red que consta de tres MSAU y sus respectivos equipos.

El diagrama de disrrihucicin de una red token-ring que consta de tres MSAU.

ARCnet Como en una red token-ring, una red ARCnet (Red de C6mputo de Recursos Adjuntos) implica pasar un token o seiial de un equipo a otro. La diferencia es que en ARCnet cada equipo tiene asignado un numero. El orden numCrico determina cu6l equipo obtendr6 a1 token. Cada equipo se conecta a un concentrador o hub que podri ser activo (amplificar6 la informaci6n que llega antes de transmitirla) o pasivo (transmitirh la informaci6n sin amplificarla).

A diferencia de 10s MSAU en una red token-ring, 10s concentradores ARCnet no mueven el token en un anillo. Los equipos se 10 pasan entre si. La figura 13.7 modela una red ARCnet con un concentrador pasivo, uno activo y varios equipos. FIGURA13.7 Un diagrama de distribucidn de una red ARCnet. {Distancia maxima = 30 M)

I

{Distancia maxima = 30 M)

I

Concentrador {Distancia maxima = 610 M) PC No 3

RG-62U PC No 2

PC No 1

/

Thin ethernet La red thin ethernet es un tipo muy popular. Los equipos se conectan a un cable de red mediante dispositivos conocidos como conectores T. Un segment0 de red puede unirse a otro mediante un repetidor, un dispositivo que amplifica una sefial antes de transmitirla. Tambitn pueden hacerse conexiones de tipo RJ-45, aunque, en este caso, nos concentraremos tan s610 en la conexi6n T. La figura 13.8 modela una red thin ethernet.

Diagrarna de distribucidn de una red thin ethernet.

Red inalambrica Ricochet de Metricom Metricom, Inc, empresa localizada en Los Gatos, CA, cuenta con una soluci6n inalimbrica por m6dem para obtener acceso m6vil a Internet. Su m6dem inalimbrico se conecta a1 Puerto serial de un equipo de c6mputo y se comunica con su red Ricochet. La red Ricochet consta de transmisores y receptores de radio, cuyo tamaiio es de una caja de zapatos. Tales radios de microceldilla se montan en la parte superior de 10s postes de luz a distancias de 400 a 800 metros, en un patrdn de tablero de ajedrez. Cada radio de microceldilla obtiene una pequeiia cantidad de energia de su poste de luz si se equipa con un adaptador especial.

Los radios de microceldillas difunden seiiales a Puntos de acceso cableados que llevan la infomacidn a un NIF (dispositivo de interconexidn a la red). El NIF consta de un servidor de nombres (una base de datos que valida las conexiones), un enrutador (dispositivo que enlaza a las redes entre si), y una puerta de enlace (un dispositivo que traduce la informacidn de un protocolo de comunicaciones a otro). La informaci6n se lleva del NIF a la Internet. La figura 13.9 muestra un diagrama de distribucidn para esta red. FIGURA13.9 Red inalambrica Ricochet de Metricorn.

1

Dlsposlttw de 8nterconexlona la red

Los diagramas de distribucion en el panorama Ha llegado a1 final del conjunto de diagramas. El panorama incluye al diagrama de distribucidn, y ha quedado finalizado.

I

Elementos estructurales comportamientos

Su panorama del UML incluye a1 diagrams de distribucidn y esta complero.

0 Clase

lnteriaz

Distribuclbn

Componente

Relaciones

-0

Generallzaclbn

- - - - - - - - S Dependencla Agrupac16n

Extenslbn

B

"Estereotipo..

Paquete

(Restrlcci6n) {valor et~quetado) Colaboracibn

Resumen El diagrama de distribuci6n del UML ilustra la forma en que luce un sistema fisicamente cuando sea conjugado. Un sistema consta de nodos, donde cada nodo se representa por un cubo. Una linea asocia a dos cubos y simboliza una conexi6n entre ellos. Los tipos de nodos son procesador (que puede ejecutar un componente) y dispositivo (que no 10 puede hacer). Los dispositivos por 10 general interactuan con el mundo. Como puede imaginar, 10s diagramas de distribuci6n son utiles para modelar redes. Los modelos presentados en esta hora incluyeron a redes token-ring, ARCnet, thin ethernet y la red inaliimbrica Ricochet.

Preguntas y respuestas P Usted utilizd una nube para representar a la Internet, y dijo que no era parte de la simbologia del UML. iUn modelador puede utilizar simbolos que no estAn en la simbologia? R Asi es. De hacerlo, no habri policia UML que 10 lleve a prision. La idea es utilizar el UML para expresar una vision. En ninguna parte esto es tan util como en 10s diagramas de distribuci6n. Si tiene una imagen que pueda mostrar claramente 10s equipos de escritorio, porthtiles, servidores y otros procesadores (o dispositivos), podrh utilizarlos en sus diagramas. Claro que estarh creando un estereotipo grhfico. (Por cierto que el simbolo de la nube es una interesante nota al margen por aprender en el UML. Uno de 10s creadores del UML, Grady Booch, solia representar objetos como nubes en la simbologia de su esquema de modelado antes de que se convirtiera en parte del equipo del UML.) P Suponga que cuenta con una gran cantidad de figuras para representar a ciertos objetos y no a otros. iSe pueden mezclar con 10s simbolos del UML? R Claro que puede. El objeto es dibujar diagramas para clarificar una visibn, no para (perd6n por el juego de palabras) nublarla.

Taller Ahora que ha finalizado con todo el conjunto de diagramas del UML, pruebe su conocimiento respecto a la forma de representar hardware. Las respuestas se destacan en el apCndice A, "Respuestas a 10s cuestionarios".

Cuestionario 1. iC6mo representa a un nodo en un diagrama de distribucibn? 2. ~ Q u Ctip0 de informaci6n puede aparecer en un nodo?

3. iCuhles son 10s dos tipos de nodos? 4. iDe quC forma funciona una red token-ring?

Ejercicios l. Imagine a su equipo de c6mputo domkstico como un conjunto de nodos. Dibuje un diagrama de distribucibn que incluya a su gabinete, monitor, impresora y cualquier otro periferico. Incluya cualquier estereotipo necesario y compartimientos para clarificar la informacidn (posiblemente resultarh en un mode10 algo diferente a1 de mi equipo).

2. Es posible conectar una red a otra. Una forma de hacerlo es conectar a cada red con un enrutador y a cada uno de ellos con un (posiblemente muy grande) circuit0 de LAN a LAN. Dibuje un diagrama de distribucibn de una pequeiia red token-ring que se conecte a una pequeiia red thin ethernet.

Nociones de 10s fundamentos del UML Ahora que ha visto 10s diagramas en el UML, ya esti listo para ciertos conceptos fundamentales. En esta hora se tratarin 10s siguientes temas: Estructura del UML Capa del metamodelado Extensibn del UML Estereotipos, restricciones y valores etiquetados Si Cste fuera un texto acadCmico en lugar de uno de autoaprendizaje, esta hora hubiese aparecido a1 principio de la parte I, en lugar de estar casi a1 final. Hice esto para darle la oportunidad de conocer las trincheras del UML (quC es y 10 que hace). Asi, ya estari listo para conocer 10s fundamentos y trabajar con ellos. Ahora que ha visto 10s diagramas y sabe cbmo utilizarlos, ipara quC podria servirle esta hora? Si ya comprendi6 en quC se basa el UML, podra extenderlo y adaptarlo cuando empiece a utilizarlo en el mundo real. Como cualquier analista de sistemas le diria: cada proyecto es diferente. No existe ninglin texto de referencia, libro o manual que 10 pueda preparar para todas las situaciones con las que se encontrari. No obstante, el tener una buena base de 10s conceptos fundamentales 10 preparari para la mayoria de 10s sistemas que tenga que modelar.

Es como aprender un idioma extranjero. La mejor forma de hacerlo es sumergirse en Cl, como 10 hizo en las horas I a la 13 (y como 10 hara en la parte 11, "Estudio de un caso"). Luego podra empezar a captar las reglas gramaticales y sintacticas dad0 que estari preparado para comprenderlas (ipor desgracia, muchos cursos acadCmicos de idiomas proceden en orden opuesto!).

Estructura del UML Su panorama del UML le muestra las categorias de 10s diagramas y a Cstos en cada categoria. Como 10 dije en la hora 1, "Introducci6n a1 UML", necesitara todos 10s diagramas, ya que le permitirin ver su sistema desde diversos puntos. Debido a que hay varias personas a las que les interesa el sistema por distintas razones, debera tener la capacidad de comunicar una vision consistente del sistema de diversas formas. Aunque su panorama es util como una forma de tener a la man0 10s elementos del UML, no funciona como una definici6n de Cste. Los tres amigos estructuraron a1 UML de una manera formal para asegurarse que 10s elementos que habian creado pudieran mostrar una idea clara de un sistema propuesto, o completamente reestmcturado. El UML cuenta con una arquitectura de cuatro capas. Tales capas se distinguen por la generalidad de 10s elementos que en ellas residen.

En la actualidad, la palabra arquitectura nos brinca en el rnundo del desarrollo de sisternas. Imagine una arquitectura corno una forrna de resurnir un conjunto de decisiones respecto a la forrna en que se organiza un sisterna. Tales decisiones se enfocan rnuy especificarnente en 10s elernentos del sisterna: que son, que hacen, corno se cornportan, como se relacionan y se cornbinan.

En las horas anteriores estuvo operand0 en las dos capas mas especificas. Cuando sigui6 un ejemplo o realiz6 un ejercicio que involucraba instancias especificas de un dominio en particular (corno el diagrama de componentes de mi sistema de c6mputo personal), se encontraba en la capa mas especifica. Esta capa se llama capa de objetos del usuario, donde "usuario" se refiere a quien utiliza el UML (no a1 que utiliza el sistema en si). Estuvo en la siguiente capa cuando vio las clases, como en el ejemplo donde el analista habl6 con el entrenador de baloncesto para distinguir las clases en el dominio baloncesto. Los primeros estados del analisis tienen que ver con esta capa: trabajari con un experto o un cliente para obtener la informacion de un dominio, y con 10s usuarios potenciales para comprender 10s casos de uso que tendran que tomarse en cuenta a1 generar el sistema. A esta capa se le denomina capa de modelado.

1

iEn quC moment0 estuvo en una capa menor? A1 principio de cada hora cuando aprendi6 un concept0 como el de una clase o un nodo, estaba en la tercera de cuatro capas. ~ s t define a a1 lenguaje para un modelo especifico. Luego de que obtenga algo de experiencia, se familiarizara tanto con el UML que esta tercera capa le sera algo muy natural. Dado que esta capa define 10 que va en un modelo, se conoce como capa de rnetamodelado.

Puesto que en su panorama se muestran 10s simbolos de las clases, nodos, componentes, casos de uso y cosas asi, tal panorama pertenece a la capa de metamodelado.

i Y la cuarta capa? Durante su carrera como analista, posiblemente nunca tend r i que tratar con ella. Imaginela como una forma de definir un lenguaje que especifique clases, casos de uso, componentes y todos 10s demas elementos del UML con 10s que trabajara. Esto es mis de la incumbencia de 10s te6ricos que disefian y comparan lenguajes que de 10s analistas que 10 usan. Dado que esta capa define 10 que va en el metamodelo, se conoce como capa de metametamodelado. La figura 14.1 le muestra las cuatro capas. FIGURA14.1 L.us cuatro capas del UML.

Capa del metamodelado: cercano y personal

Puesto que la capa de metamodelado es la base de su panorama, examinCmosla mhs detalladamente.

Imagine a esta capa como una formaci6n de tres paquetes: Fundamentos, Elementos de comportamiento y Administracidn de modelos. La figura 14.2 le muestra 10 que quiero decir.

FIGURA 14.2 Los paquetes en La capa de metamodeludo del UML.

Adrninistracion de modelos

Elernentos de comportamiento

I

Fundamentos

Como en el caso de cualquier paquete, cada uno de estos grupos relacionan elementos entre si. (iUtilizamos al UML para modelar al UML? iPor supuesto!) iCu5les son estos elementos? El paquete Fundamentos contiene: Elementos auxiliares Tipos de datos Mecanismos de extension El paquete de Elementos de comportamiento contiene: Comportamiento en comun Colaboraciones Casos de uso Mhquinas de estado El paquete de Administraci6n de modelos es, en si, un modelo. Es un diagrama de clases que muestra c6mo se relacionan 10s elementos del UML entre si, como son 10s paquetes o subsistemas.

El paquete de Fundamentos Hagamos una retrospectiva y entremos a otro nivel. EmpezarC con el paquete de fundamentos, cuyos componentes aparecen en la figura 14.3.

FIGURA 14.3 Los paquetes del propio paquete de Fundamentos.

r 1 f8 =~pfti Elementos auxiliares

---

8

8 \

\

de extension

.

I I

I I

,, , I

h' Tipos de datos

El n6cleo define lo que necesita para crear un modelo UML. Cada uno de 10s elementos definidos es abstracto (10 que significa que no puede crear instancias de Cl) o concreto (con el que si podra). Entre 10s elementos abstractos se encuentran ElernentoDeModelo, ElernentoGeneralizable y Clasi$cador. Entre 10s concretos se encuentran Clase, Interfaz, Asociacidn y Tipo de datos.

Vera e n esta seccion q u e dire q u e u n paquete "define", "establece" o "da 10s detalles formales de" u n elemento ( o concepto). Ello significa tres cosas: (1) el paquete muestra al elemento d e n t r o d e u n diagrama d e clases ( o t r o ejemplo d e usar al U M L para modelar al UML), (2) el paquete contiene reglas para u t i lizar el elemento, y (3) el paquete proporciona informacion respecto al significad0 del elemento. El diagrarna d e clases se conoce c o m o sintaxis abstracts, las reglas se conocen como reglas b i e n formadas, y al significado se le conoce como semdntica.

He aqui otra forma de ver la distinci6n entre abstracto y concreto. Nunca tendr5 nada en su modelo a 10 que usted llame explicitamente ElernentoDeModelo o Clasificador (aunque claro, utilizara tipos ElementosDeModelo y Clasificadores todo el tiempo). Un clasificador, por ejemplo, es cualquier elemento que describe estructura y comportamiento. Imagine a un clasificador como una forma resumida de referirse a una clase, cornponente, nodo, actor, interfaz, indicacidn, subsisterna, caso de uso o tip0 de datos. Decir que algo se le aplica a un clasificador es equivalente a decir que se aplica a cualquiera de estos otros denominadores. En tal caso, ilos elementos concretos se derivan de 10s abstractos? Asi es. ~ E l l osignificar6 que hablamos de clases y herencia? Por supuesto, per0 dad0 que estamos en la capa de metamodelado, en realidad hablamos de rnetaclases. Por ello, un "clasificador" es una "metaclase". ( ~ Q u Ctanto sentido podria haber tenido esta frase en la hora l?)

Continuemos con 10s otros paquetes dentro de 10s fundamentos. Elementos Auxiliares, un paquete que redeondea a1 Nlicleo, define la Dependencia, Componentes y Nodos, entre otros. El paquete Tipo de Datos, especifica 10s tipos de datos que el UML utiliza, incluyendo 10s tipos primitivos (enteros, cadena y tiempo) y enumeraciones. Una enumeracidn como por ejemplo el Booleano lista 10s valores posible. El paquete de Mecanismos de Extensidn le especifica c6mo puede extender el UML e incluye algunas extensiones ya hechas. Analizaremos de manera mis detallada este paquete mis adelante, en la seccion llamada Extensi6n del UML.

El paquete de 10s elementos de comportamiento Este paquete es la parte del UML que se encarga de modelarel procedimiento de un sistema. Los paquetes de que consta aparecen en la figura 14.4. FIGURA14.4 Los paquetes que conforman a1 propio paquete de Elementos de comportamiento.

Colaboraciones

I Casos de uso

Maquinas de estado

I

El paquete de comportamiento comtin proporciona 10s conceptos de 10s elementos dinimicos, y soporta otros paquetes como son: casos de uso, miquinas de estado y colaboraciones. Estos "conceptos" incluyen SeEal, Enlace y Punto final de asociacidn. El paquete de colaboraciones abarca un b b i t o mis amplio que tan s610 10s diagramas de colaboraciones que utiliz6 en la hora 10, "Diagramas de colaboraciones". En este cont e x t ~una , "colaboracibn" describe la forma en que 10s clasificadores y sus asociaciones trabajan en conjunto para realizar una tarea en particular. Los diagramas de colaboraciones y 10s de caso de uso son parte de la perspectiva. La idea es que 10s clasificadores conformen a1 context0 de la colaboraci6n; las asociaciones conforman a la interaccidn. No es de extrafiar que el paquete de casos de uso detalle 10s conceptos (corno a un Actor y un CasoDeUso) que en C1 se encuentran. (Ambos conceptos son clasificadores, como lo indiquC en la secci6n anterior.) El objetivo general es tener la posibilidad de describir el comportamiento de un sistema sin entrar en detalles.

Tampoco debe sorprender que el paquete de Mhquinas de estado dC 10s detalles formales de 10s conceptos que hay detras de 10s diagramas de estados y de actividad que ya ha utilizado.

Administracion de modelos Este paquete define a1 Modelo, Subsistema y Paquete. La meta de estos elementos es agrupar 10s ElementosDeModelo de todo tipo.

Extension del UML Como ya 10 ha visto en las horas anteriores, podri pulir sus diagramas UML mediante la adicion de detalles que expliquen mejor su significado. Los estereotipos, restricciones y valores etiquetados son herramientas utiles dentro del UML. Puede crear una extension sobre la marcha para agregar a su mode10 cuestiones e ideas importantes de su dominio. Esto fue evidente la hora anterior: las restricciones en algunas de las comunicaciones entre nodos revelan las reglas de 10s diversos tipos de redes. El UML incluye varios estereotipos, restricciones y valores etiquetados. Como ya 10 mencione, son parte del paquete Extensiones el cual, a su vez, se encuentra en el paquete Fundamentos de la capa de metarnodelado. Cada una de estas extensiones incluidas es adecuada para uno (a veces dos) de 10s elernentos del UML. Las siguientes secciones trataran a tales extensiones.

Estereotipos El prop6sito de un estereotipo es extender a un elemento del UML para que sea una instancia de una nueva metaclase, y se escribe entre dos pares de parintesis angulares. Esto agrega una gran flexibilidad. Lo que significa que usted podrh utilizar un elemento existente del UML como base para crear sus propios elementos: elementos que capturen algun aspect0 de su propio sistema o dominio de una forma en que no podrian hacerlo 10s elementos del UML. La intention del estereotipo es permitir a la entidad reciCn creada que embone con 10s demas dentro de una herramienta de modelado. Las herramientas de modelado (como Rational Rose, SELECT Enterprise o Visual UML) tienen que almacenar y manejar las clases para la generacidn de c6digo y la de informes. El mecanismo del estereotipo les permite hacerlo con sus creaciones. El UML incluye un extenso conjunto de estereotipos generados. Podra agregar de uno en uno o dos elementos. Las siguientes subsecciones organizan a 10s estereotipos en tirminos de 10s elementos con que confluyen.

Dependencia La relaci6n de dependencia puede tomar la mayor cantidad de estereotipos ya creados. Cada uno extiende una relaci6n de dependencia entre un origen (el elemento del cual parte la flecha punteada) y un destino (el elemento a1 que apunta la flecha). Veamos ripidamente a cada dependencia estereotipada. Una dependencia de tipo ccse convierte enn muestra que el origen y el destino son el mismo objeto en distintos momentos. El origen se convierte en el destino con (posiblemente) diferentes roles y valores. ccllamar>~ tiene una operaci6n como origen y otra como su destino. En esta dependencia estereotipada, la operacidn de origen invoca a la de destino. Una dependencia cccopiar>>indica que el destino es una copia exacta del origen. En una dependencia ccderivar,,, el origen se deriva del destino. ~Recuerdael concept0 de visibilidad de la hora 5, "Agregacibn, composicibn, interfaces y realizaci6nm?Si tiene una operacion que sea privada dentro de una clase en particular, aun podri hacerla accesible a otra clase. Coloque la otra clase (origen) y la operaci6n (destino) en una dependencia ccreunir,, o . El origen tendra acceso al destino sin importar la visibilidad.

Una dependencia entre dos casos de uso tambiCn puede tener un estereotipo. Ya ha utilizado dos de ellos, y ccusar>>, aunque sustituy6 c> por ccusarn. le indica que 10s comportamientos del caso de uso de destino se agregan al caso de uso de origen. ccusarn indica que algunos casos de uso tienen cierto comportamiento en comun, y este estereotipo le permite utilizar dicho comportamiento sin tener que repetirlo una y otra vez. Una dependencia ccimportar>>se establece entre dos paquetes. Este estereotipo agrega el contenido del destino al espacio de nombres del origen (el aspecto del paquete que agrupa 10s nombres que 10 constituyen). El estereotipo ccinstancia>> indica que el origen es una instancia de su destino, que siempre sera un clasificador. En una dependencia de ccmetadestino>>, tanto el destino como el origen son clasificadores, y el destino es la metaclase del origen. En un ccenviar,,, el origen es una operacion y el destino es una seiial. El estereotipo muestra que el origen envia la seiial.

Clasificador Los estereotipos extienden a 10s clasificadores de diversas formas. El estereotipo ccmetaclase>>muestra que el clasificador al que esti adjunto es una metaclase de otra clase. El cctipodeautoridad>> indica que un clasificador tiene objetos que provienen de un antecesor en particular. TambiCn puede usar cctipodeautoridad>> en una dependencia para mostrar que el destino es un tip0 de potestad del origen. (Normalmente utilizari Cste cuando modele bases de datos.)

Los estereotipos ccproceso>>y ccsubproceso>> tienen que ver con el flujo de control. Ambos indican que su clasificador es una clase activa; es decir, sus objetos pueden iniciar la actividad de control. Un proceso puede consistir de varios subprocesos (flujos de control), y puede ejecutarse a1 rnismo tiempo que otros procesos. Un subproceso puede ejecutarse junto con otros subprocesos en el misrno proceso. Un clasificador con el estereotipo ccutileria,, es una coleccidn titulada de atributos y operaciones que no son miembros de tal clasificador: un clasificador que no tiene instancias. Finalmente, un clasificador puede tener a1 abuelo (jcasi literal!) de todos 10s estereotipos: ccestereotipo>,.Este indica que el clasificador funciona como un estereotipo, y le permite modelar jerarquias de estereotipos.

Clase Puede obtener algo mis especifico que con 10s clasificadores: tambiCn es posible extender a una clase. Un crtipo, es una clase que establece un dorninio de objetos junto con atributos, operaciones y asociaciones. El cctipo>>no contiene mCtodos (algoritmos ejecutables para sus operaciones). Una ccclaseDeImplementacion~~ es 10 contrario de un cctipo,,. Representa la implementaci6n de una clase en un lenguaje de prograrnaci6n.

Generalizacion Es una relacion entre clasificadores, con su propio pequeiio conjunto de estereotipos. ccheredar,, significa que las instancias del subtipo no pueden substituirse por instancias del supertipo. ccsubclase>>hace 10 mismo que en las clases: significa que las instancias de la subclase no son sustituibles por instancias de la superclase. ccprivado* denota una herencia exclusiva: oculta 10s atributos heredados y operaciones de una clase a sus ancestros.

Paquete Los estereotipos de 10s paquetes son directos. Una afachada,, es un paquete que contiene referencias a elementos de otro paquete, y que no contiene elernentos propios. Un ccsisterna,, es una colecci6n de rnodelos de un sistema. Un cccabo,, es un paquete que proporciona s610 las partes publicas de otro paquete. Ademas de 10s elernentos que he dicho, un paquete puede incluir patrones. Un patr6n es un tipo de colaboracidn entre 10s elementos que ha probado su efectividad en diversas situaciones. Un ccmarcoDeTrabajo>>es un paquete estereotipado que s610 contiene patrones.

Dado que 10s paquetes pueden encontrarse dentro de paquetes, sirve de mucho tener un estereotipo que indique cud de 10s paquetes esta en el nivel superior. Tal estereotipo es el ccpaqueteDeNivelSuperior>~. (iLe dije que 10s estereotipos de 10s paquetes son directos!)

Componente Los estereotipos para 10s componentes son aun mas directos. Puede mostrar que un componente es un documento, un ejecutable, un archivo, una tabla de datos o una biblioteca. Los estereotipos respectivos son ecdocumento>>, ccejecutablen, ccarchivo,,, cctabla,, y ccbiblioteca,,.

Alg unos otros estereotipos En esta subsecci6n, he conjugado algunos estereotipos utilizados con otros elementos del UML. Un comentario que aparece en una nota adjunta puede tener un estereotipo ccrequerimienton, que denota que el comentario establece un requisito para el element0 adjunto a la nota. Dentro de una clase, una operaci6n o un mCtodo pueden crear una instancia o destruirla. (Quiz8 haya visto metodos como constructor y destructor en Java.) Tales caracteristicas se indican mediante cccrear,, y ccdestruirn respectivamente. Las restricciones, que son el mecanismo de extensi6n que ahora tratarC, pueden tambiCn funcionar con 10s estereotipos. En ocasiones usari una restricci6n para mostrar las condiciones previas a una operaci6n; aunque algunas veces mostrara sus condiciones posteriores. Tales restricciones las estereotipara con cccondicionPrevia>> o cccondicionPosterior~. En ocasiones adjuntara una restricci6n a un conjunto de clasificadores o relaciones, y necesitara indicar que las condiciones de la restriccidn deberan tener todos 10s clasificadores, relaciones e instancias. Para ello, debera estereotipar la restricci6n como ccinvariable,,.

Estereotipos graf icos Algunas veces en su dominio, tal vez tendri que obtener un nuevo simbolo o dos para transmitir algo a un cliente. Como 10 mencionC en la hora anterior, 10s diagramas de distribucion pueden encajar de forma importante en esto. Por 10 general, hay disponibles figuras de procesadores y dispositivos, y pueden remplazar a 10s cubos que vio en la hora 13, "Diagramas de distribuci6n". La figura 14.5 le muestra un ejemplo. Es una versi6n estilizada de la figura 13.7, un mode10 de una ARCNet.

FIGURA 14.5

PC NO 4

PC NO 5

Un mode10 estilizado de una ARCNet.

(Distancia maxima = 3

ancia maxima = 30 M) ~~Dispositivo~~ Concentrador activo PC No 3 (Distancia maxima =

Restricciones Las restricciones se encuentran entre Ilaves. Proporcionan las condiciones para las asociaciones, extremos de vinculos, generalizaciones y peticiones (transmisiones de sefiales o llamadas a operaciones). La restriccidn ( 0 ) se aplica a un conjunto de asociaciones, y muestra que s610 una asociaci6n podri utilizarse para tal conjunto. Otra restriccidn basada en asociaciones, {implicito], indica que una asociaci6n es conceptual. Los extremos de vinculos, que son puntos finales de vinculos entre objetos, pueden contener cualquier cantidad de restricciones. Cada restriccidn indica el porqu6 el objeto en el extremo del vinculo es visible. (parimetro) muestra que el objeto es un valor necesario relativo a1 vinculo. (propio) le indica que el objeto es el despachador de una petici6n. {global) y {local) indican el imbito del objeto respecto a1 vinculo. (asociacidn) denota que el objeto es visible por su coalici6n.

Un conjunto de generalizaciones pueden ser (completo) (todos sus subtipos han sido especificados) o {incompleto}(alin pueden agregarse subtipos). Otro conjunto de generalizaciones pueden ser {traslapado}(mhs de un subtipo puede funcionar como un tip0 de instancia) o {desarticulado) (sblo un subtipo puede ser un tipo de una instancia, 10 que es predeterminado en la generalizacibn). Si una peticibn se envia a diversas instancias de destino en un orden no especificado, es una {difusibn}.Si varias instancias devuelven valores, y la mayoria de tales valores determinan un solo valor, la restriccibn sera un {voto).

Valores etiquetados Un valor etiquetado se escribe entre Ilaves. Consiste en una etiquetu, un signo = y un valor. Los valores etiquetados ya elaborados son adecuados para 10s clasificadores, componentes, atributos, instancias y operaciones. Una etiqueta {documentacibn = ), se aplica a cualquier elemento. A la derecha del =, debe colocar una descripcibn, explicacibn o comentario respecto al elemento a1 que adjuntb este valor etiquetado. Puede adjuntar una {ubicacidn = ) a un clasificador o componente. Cuando lo adjunta a un clasificador, debe proporcionar al componente del cual es parte. Cuando lo hace a un componente, debe indicar el nodo donde se encuentra. El valor etiquetado (persistencia = ) puede ir en un atributo, clasificador o instancia. Denota la permanencia del eztado del elemento al que lo ha adjuntado. Los valores posibles son permanente (el estado persiste cuando la instancia se destruye) y trunsitorio (cuando la instancia se destruye, tambiCn 10 hace el estado). (semhntica = } especifica el significado de un clasificador o una operacibn. {responsabilidad} es una obligacidn de un clasificador.

Resumen Esta hora tratb 10s conceptos bisicos del UML. El objetivo fue el de darle un conocimiento profundo que le permitirin aplicar a1 UML en situaciones reales que no siempre puedan reflejarse en 10s ejercicios de un libro de texto. Hemos tratado estos conceptos luego de todos 10s diagramas porque tenia que comprender 10s elementos del lenguaje antes de profundizar en sus fundamentos. El UML consta de cuatro capas: objetos del usuario, modelado, metamodelado y metametamodelado (que van desde especificos hasta generales). Cuando analice un sistema, tipicamente trabajara en las primeras dos capas. Cuando aprenda 10s conceptos del UML, por 10 general se encontrarh en la tercera. La cuarta capa esta orientada a 10s tebricos y diseiiadores del lenguaje, en lugar de 10s usuarios del lenguaje y analistas de sistemas.

El UML incluye varias extensiones propias. Cada uno de estos estereotipos, restricciones y valores etiquetados se orientan a ser usados por uno o dos de 10s simbolos del UML. s Si le hubiera dado todos estos conceptos fundamentales al iniciar en la hora 1 ~ 1 0 habria entendido?

Preguntas y respuestas P Veo que el UML tiene varias reglas. iQuikn las implementa? R Como ya dije, la policia UML no le acecha para verificar que su modelo sea preciso. No obstante, una herramienta de modelado le podra ayudar a cefiirse a las reglas. Por ejemplo: Visual UML tiene un archivo de estereotipos que usara de un mod0 sensible al contexto. Cuando intente colocar un estereotipo en un elemento en particular, solo le permitira seleccionar de 10s estereotipos adecuados para tal elemento, todos ellos en inglCs. Ademas, le permitira agregar estereotipos a su archivo de estereotipos. P Los valores etiquetados parecen ser esotkricos. iDebo utilizarlos? R Si, y con frecuencia. Los valores etiquetados integrados, aunque son utiles, palidecen en comparacion con 10s que usted definira para si. Puede utilizar un valor etiquetado para mantener informacion relacionada con la administraci6n de un importante proyecto en su modelo: como 10s numeros de version y 10s autores de las clases. Es decir, "estado", "versi6nWo "autor" podrian ser sus etiquetas, y usted establecera 10s valores adecuados.

Taller Este taller reafirmara su conocimiento de 10s fundarnentos del UML. Utilice sus procesos de reflexi6n en el cuestionario y localice las respuestas en el ApCndice A, "Cuestionario". ~ s t es a una hora tebrica, por 10 que no he incluido ninglin ejercicio.

Cuestionario 1. iCuales son las cuatro capas del UML?

2. ~ Q u Ces un clasificador? 3. iPorquC es importante el poder extender a1 UML? 4. LCuales son 10s mecanismos de extensi6n del UML?

Adaptacion del UML en un proceso de desarrollo Ahora que ha comprendido 10s diagramas del UML y su estructura, ya casi es hora de ponerlo a funcionar. El UML es una herramienta maravillosa, pero no la utilizari de manera aislada. El UML tiene la intenci6n de impulsar el desarrollo de software, por ello, es necesario aprender 10s procesos y metodologias de desarrollo como un vehiculo para comprender el uso del UML en un contexto. En esta hora se trataran 10s siguientes temas: Por quC es importante un proceso de desarrollo Por quC no son adecuadas las antiguas metodologias para 10s sistemas de hoy El Proceso de desarrollo GRAPPLE C6mo incorporar a1 UML en el proceso Su empresa requiere un nuevo sistema de computo. Los nuevos componentes de hardware y software darin por resultado una ventaja competitiva, misma que usted necesitara. Debe empezar el desarrollo, iy pronto!

Es usted quien ha tomado la decisidn de generar a1 nuevo sistema, ha establecido un equipo de desarrollo completo, con un gerente de proyectos, modeladores, analistas, programadores e ingenieros de sistemas. Ya todos se truenan 10s dedos, ansiosos por empezar. Usted es, en otras palabras, un cliente. ~ C u i l e sproductos de trabajo esperari obtener del equipo de desarrollo? iC6m0 querri que el gerente de proyectos le reporte? AI final, claro, querri un sistema en funcionamiento; pero antes de ello, necesitarh ver indicios de que el equipo ha comprendido el problema que usted intenta resolver y su visidn para hacerlo. Necesitarh ver el avance de su solucidn, y necesitari saber cuil ha sido su avance en diferentes puntos. Tales inquietudes son comunes con cualquier cliente y en cualquier proyecto de desarroIlo que requiera una considerable cantidad de tiempo, dinero y recursos humanos.

Metodologias: antiguas y recientes A usted no le gustaria que el equipo de desarrollo comenzara a codificar sin mhs. DespuCs de todo, LquC sen'a 10 que codificarian? El equipo de desarrollo tiene que proceder de manera mis estructurada y metddica. La estructura y naturaleza de 10s pasos en un esfuerzo de desarrollo es 10 que yo entiendo como metodologia. Antes de comenzar a programar, 10s desarrolladores tienen que comprender con claridad el problema. Esto requiere que alguien analice sus requerimientos. Una vez hecho ese anhlisis, jse podri iniciar la codificacibn? No. Alguien tiene que convertir tal anhlisis a diseiio. De esta manera, 10s codificadores comenzarin a producir el cddigo a partir del diseiio, despuCs de probar y distribuir el cddigo se convertiri en un sistema.

El metodo antiguo Esta idea demasiado simplificada del proceso de desarrollo podra darle una idea de que las etapas deberin sucederse en lapsos claramente definidos, una despuCs de otra. De hecho, las metodologias de desarrollo iniciales se estructuraban de esa manera. La figura 15.1 le muestra una forma de pensar cuya influencia trascendid por varios aiios. ~ s t es e el mCtodo "en cascada", y establece que el anilisis, diseiio, codificacidn y distribuci6n van uno despuCs de otro como las actividades en un diagrama de actividades: solamente cuando se haya completado uno se podri iniciar el otro. Esta forma de hacer las cosas tiene algunos puntos inquietantes. Por un lado, tiende a la realizacidn de tareas individuales. Si un analista no tiene contacto con un diseiiador, y Cste a su vez no tiene contacto con un desarrollador, existe la posibilidad de que 10s tres miembros rara vez trabajen juntos para compartir puntos de vista importantes.

El mCtodo antiguo fomenta otro problema: es comun el caso de que 10s partidarios al mCtodo "en cascada" reparten el tiempo del proyecto en la codificaci6n. El verdadero efecto de esto es que se quita un tiempo valioso al anilisis y diseiio.

Lo que debe hacer un proceso de desarrollo En 10s primeros aiios de la programacidn de computadoras, una persona podia analizar un problema, otorgar una solucidn y escribir un programa. En 10s primeros aiios de la construccidn de viviendas (cuando la tierra era plana), una persona podia construir una casa, tambiCn. En la actualidad la historia ha cambiado. Para desarrollar las diferentes naturalezas de sistemas complejos que demandan 10s negocios de hoy, es mis necesario el uso de un equipo. ~ P o quC? r El conocimiento se ha especializado tanto que una persona no puede conocer todas las facetas de un negocio, comprender un problema, diseiiar una solucidn, traducirla a un programa, distribuir el programa en el hardware y asegurarse que 10s componentes del hardware funcionen de forma conjunta. El equipo tiene que formarse de analistas para comunicarse con el cliente y comprender el problema, diseiiadores para generar una solucidn, programadores para codificarla e ingenieros de sistemas para distribuirla. Un proceso de desarrollo tiene que tomar en cuenta todos 10s procesos anteriores, utilizarlos adecuadamente y asignar la cantidad de tiempo necesaria para cada fase. El proceso tambiCn debe dar por resultado diversos productos del trabajo que den indicios de progreso y conformar una estela de responsabilidad. Finalmente, el proceso deberi asegurar que sus fases no sean discontinuas. En lugar de ello, debe obtenerse informaci6n entre las fases para fomentar la creatividad y aumentar la facilidad de innovar. La base seria: es mis sencillo hacer una modificacidn a un proyecto y luego hacerla en la casa, en lugar de modificar la casa mientras construye la estructura.

AI llegar a un proceso, existe la tentaci6n de generar una serie de fases que podrian traer una gran cantidad de papeleo. Algunas metodologias que estin disponibles de forma comercial lo hacen, con lo que hacen que 10s gerentes de proyectos llenen interminables formularios. El papeleo se complica por si mismo. Una razdn de esto es la idea err6nea de que la metodologia de la "unitalla" es posible; cada empresa es linica. Una empresa tiene su propia cultura, normatividad, historia y personal. La metodologia del desarrollo que pueda aplicarse a un consorcio international posiblemente fallari en una pequeiia empresa y viceversa. AI intentar meter con calzador una metodologia en una empresa, se tendri la mala impresi6n de que un papeleo extremo podri ayudar.

Asi que aqui esti el reto. Un equipo de desarrollo deberi: Asegurar que el equipo de desarrollo cuenta con una firme comprension del problema que se intenta resolver Dar pie a un equipo que conste de una coleccidn de responsabilidades Fomentar la comunicacidn entre 10s miembros del equipo que ostentan tales responsabilidades Dar pie a la intercomunicacion entre las fases del proceso de desarrollo Desarrollar productos de trabajo que comuniquen el progreso a1 cliente, y eliminar el papeleo superfluo iAh! Por cierto, seria una buena idea si el proceso origina un product0 terminado en un lapso corto.

Se habra dad0 cuenta que utilizo las palabras proceso y metodologia de forrna indistinta. Aunque es posible encontrar algunas diferencias entre ellas, prefiero no discutir 10s detalles. En mi experiencia, la palabra metodologia se ha tergiversado de forma paulatina. Creo que si se rnezcla la palabra proceso en el tema, se puede elirninar tal tergiversacion.

GRAPPLE

l

Para enfrentar este reto de varias facetas, le presento GRAPPLE (Guias para la Ingenieria de Aplicaciones Ripidas)). Las ideas dentro de GRAPPLE no son originales. Son una condensacidn de las ideas de varias otras personas. Los Tres Amigos han creado el Proceso Racional Unificado, y antes de ello, cada Amigo tenia su propio proceso; las ideas en tales procesos son similares a GRAPPLE. El libro de Steve McCornell, Rapid Development (Microsoft Press, 1996), contiene varias de las mejores pricticas que se aplican a1... bueno... desarrollo ripido de aplicaciones. La primera palabra en las siglas de GRAPPLE, Directivas, es importante: Csta no es una fdrrea metodologia. En vez de ello, es un conjunto de ideas adaptables y flexibles. Imaginelas como un patrdn simplificado de un proceso de desarrollo. Lo presento como un vehiculo para mostrar a1 UML dentro de un contexto. Con algunos ajustes, GRAPPLE puede aplicarse en diversas organizaciones (aunque, tal vez, no a todas). Da la oportunidad a un gerente de proyectos, con creatividad, de agregar sus propias ideas respecto a 10 que funcionari en una organization en particular, y puede sustraer 10s pasos incluidos que no funcionen.

Antes de adentrarnos en el terna de GRAPPLE, he aqui una pregunta que tal vez se formule: " ~ P o que r me esta hablando de esto un libro que, se supone, trata del UML?" La respuesta es que si no le dig0 a usted algo respecto al proceso de desarrollo y le doy un context0 para utilizar al UML, t o d o lo que habre hecho es mostrarle corno dibujar diagramas. Lo importante de esto es rnostrarle corno y cuando utilizar cada uno de ellos. En la parte II, "Estudio de un caso", vera un caso de prueba que aplicara a GRAPPLE en el UML.

RAD3: la estructura de GRAPPLE GRAPPLE consta de cinco segmentos. He utilizado "segmentos" en lugar de "fases" para eliminar la idea de que una "fase" debe completarse antes de iniciar la otra. (Resisti la tentacion de llamarlos "piezas". "Cinco piezas fhciles era demasiado hermoso.) Cada segmento, en turno, consta de diversas acciones. Cada acci6n trae consigo un producto del trubujo, y cada acci6n es responsabilidad de un jugador. "

En muchos casos, el gerente de proyectos puede combinar 10s productos de trabajo en un informe que presente al cliente. Los productos de trabajo, de hecho, tienen el mismo proposito que un avance en papel, sin sumergirse en el papeleo.

Para adaptar a GRAPPLE, un gerente de proyectos podria agregar acciones a cada segmento. Hay otra posibilidad, que es profundizar a un nivel inferior, y subdividir a cada accion en subacciones. Aun hay otra posibilidad de reordenar las acciones dentro de cada segmento. Las necesidades de organizacion estableceran el carnino a seguir.

GRAPPLE se encausa a 10s sistemas orientados a objetos. Por ello, las acciones dentro de cada segmento se orientan a crear productos de trabajo de una naturaleza orientada a objetos. Los segmentos son: 1. 2. 3. 4. 5.

Recopilacidn de necesidades Analisis DiseAo Desarrollo Distribution

Esto nos otorga un acrdnimo RADDD o RAD'. Luego del tercer segmento, el gerente de proyectos combina 10s productos de trabajo en un documento de diseiio para dirselo a1 cliente y los desarrolladores. Cuando se han completado todos 10s segmentos RAD3, todos 10s productos de trabajo se combinan para conformar un documento que define a1 sistema. Antes de iniciar tales segmentos, debe asumir que el cliente ha generado un caso de negocios para el nuevo sistema. TambiCn debe asumir que 10s miembros del equipo de desarrollo, particularmente 10s analistas, han leido tanta documentacidn relevante como sea posible. Examinemos cada segmento con mayor atencibn, sin perder de vista las partes del UML que se ajusten a cada uno.

Recopilacion de necesidades Si intenta asignar una importancia relativa a cada segmento, Cste es un buen candidato para ser el nlimero uno. Si no comprende lo que desea el cliente, nunca podri generar el sistema adecuado. Todos 10s anilisis de casos de uso en el mundo no le ayudarin si no comprende las bases del dominio del cliente y el problema que quiera que usted resuelva.

Descubra 10s procesos de negocios Es una buena idea empezar el proceso de desarrollo mediante la comprensidn de 10s procesos de negocios del cliente, en especial aquellos que tratara de mejorar con el sistema propuesto. Para comprenderlo, un analista entrevistari a1 cliente o a una persona con el conocimiento necesario que sea designada por el cliente, a quien le preguntari 10s pasos relevantes del proceso uno por uno. Una consecuencia importante sera que el analista obtendri un vocabulario de trabajo en un subconjunto de la terminologia del cliente. El analista usari este vocabulario cuando entreviste a1 cliente en la siguiente accidn. El product0 del trabajo es un diagrama de actividades o conjunto de ellos que captan 10s pasos y puntos decisivos en el proceso (o procesos) del negocio.

Realice un analisis del dominio Esta accidn es como el ejemplo de la plitica con el entrenador de baloncesto. Puede realizarse durante la misma sesidn en la accidn anterior. El objetivo es comprender de la mejor manera posible el dominio del cliente. Observe que esta accidn y la anterior tratan de conceptos, no del sistema que va a generar. El analista tiene que acomodarse en el mundo del cliente, pues, a fin de cuentas, es el interlocutor entre el cliente y el equipo de desarrollo.

El analista entrevista a1 cliente con la finalidad de cornprender las principales entidades en el dorninio del cliente. Durante la plitica entre el cliente y el analista, otro rniernbro del equipo tomari las notas (de forma dptima) en un equipo de cdrnputo portatil equipad0 con un procesador de textos, y un modelador de objetos generari un diagrama de clases de alto nivel. Si puede contar con rnas de un rniernbro del equipo que tome notas, por su bien higalo. El modelador de objetos prestari atencidn a 10s sustantivos y ernpezari a convertir a cada uno en una clase. Finalrnente, algunos de esos sustantivos se convertirin en atributos. El modelador tarnbiCn prestari atenci6n a 10s verbos, que se convertirin en operaciones de las clases. En este punto, una herrarnienta de modelado computarizada seria muy util. El producto del trabajo es un diagrama de clases de alto nivel y un conjunto de rninutas.

~GRABAR o NO GRABAR? ~Deberiagrabar en cinta de sonido tales entrevistas o tan solo basarse en las minutas? 6sta es una pregunta comun. Cuando se graba una entrevista, se tiende a no prestar tanta atencion, o a s61o tomar algunas notas muy obligatorias. (Despues de todo, siempre podrB recurrir a la cinta). Si decide grabar, le sugiero que ignore a la grabadora y tome todas las notas corno si la grabadora no existiera. La grabacion en cinta de sonido puede ser muy util cuando se encuentra en proceso de entrenamiento de un nuevo modelador de objetos. Un modelador experimentado podri comparar 10s diagramas del nuevo mediante la grabacion del debate y verificar su minuciosidad.

ldentificacion de 10s sistemas cooperativos El poeta del S. XVII John Donne, escribio: "Nadie es una isla, cornpleto en si misrno" Si C1 hubiera escrito en la Cpoca actual, tal texto debid decir "Ninguna personu es una masa de tierra rodeada de agua, completa en si misma". TambiCn pudo haber escrito "Ningun sistema es una isla ...", y asi por el estilo. En cualquier caso Donne estaria en lo correcto. Normalmente, 10s sistemas de negocios actuales no ernergen de la nada, tienen que colaborar con otros. En las primeras instancias del proceso, el equipo de desarrollo veri exactarnente de quC sistemas dependeri el nuevo sistema, y cuiles dependerin de Cl. Un disefiador de sisternas se encargari de esto, y produciri un diagrama de distribuci6n corno su producto del trabajo. El diagrama muestra a 10s sistemas corno nodos, con lineas de comunicaci6n entre ellos, componentes residentes y dependencias entre componentes.

Descubra las necesidades del sistema Descubrir las necesidades es muy importante, ya que en esta accibn, el equipo realiza su primera sesion de JAD (Desarrollo conjunto de aplicaciones). Habra otras mas en el curso del GRAPPLE. Una sesibn JAD redne a quienes toman las decisiones en la empresa del cliente, a 10s usuarios potenciales y a 10s miembros del equipo de desarrollo. Debe haber alguien que modere la sesi6n; el trabajo del moderador es obtener una respuesta de quienes toman las decisiones y de 10s usuarios acerca de 10 que esperan que haga el sistema. AI menos debera haber dos miembros del equipo que tomen notas, y el modelador de objetos debera refinar el diagrama de clases que se obtuvo previamente. El producto del trabajo es un diagrama de paquetes. Cada paquete representa a un hrea de alto nivel de la funcionalidad del sistema (por ejemplo: "ayuda con el servicio a clientes"). Cada paquete agrupa un conjunto de casos de uso (por ejemplo: "obtener el historial del cliente" o "tratar con el cliente"). La complejidad del sistema sera lo que determine la duracibn de la sesibn. Casi nunca sera menor a medio dia laboral, y podn'a durar hasta toda una semana laboral. La empresa del cliente debe hacer el comprorniso de invertir el tiempo que sea necesario. ~ P a r aquC acceder a una sesibn JAD para desarrollar 10s requerimientos del sistema? i,Por quC no so10 entrevistar a cada individuo? Como podrh recordar, dije que la ultima parte del reto de un proceso de desarrollo es generar un sistema en un corto lapso. Las entrevistas individuales pueden tardar semanas, mucho mhs si existen conflictos en 10s itinerarios de las personas. La espera de entrevistas individuales puede ocupar mucho tiempo y, con Cl, puede irse por tierra la supuesta ventaja competitiva de completar rhpidamente el sistema. Las entrevistas individuales posiblemente contendrian puntos de vista contlictivos, y se perderia tiempo en intentar resolverlos. Agruparlos a todos crea una expectativa general, en la que 10s participantes podrian hacer una simbiosis de sus puntos de vista en beneficio de todos.

Presentar 10s resultados al cliente Cuando el equipo finaliza todas las acciones de Necesidades, el administrador de proyectos presentarh 10s resultados a1 cliente. Algunas empresas podn'an requerir la aprobaci6n del cliente en este punto, para que pueda proceder el desarrollo. Otras podrian necesitar una estimacibn de 10s costos de acuerdo con 10s resultados. De esta manera, el producto del trabajo podria variar de acuerdo con la empresa.

Analisis En este segmento, el equipo profundiza en 10s resultados del segmento Necesidades y aumentara su comprension del problema. De hecho, partes de este segmento empezarhn durante el segmento de Necesidades, conforme el modelador de objetos empieza a depurar el diagrama de clases durante la sesion JAD de Necesidades.

Comprension del uso del sistema Esta acci6n es un analisis de casos de uso de alto nivel. En una sesidn JAD con usuarios potenciales, el equipo de desarrollo trabaja con 10s usuarios para descubrir a 10s actores que iniciarin cada caso de uso, y 10s actores que serfin beneficiados. (Recuerde que un actor puede ser un sistema o una persona.) Un moderador interviene en la sesibn, y dos miembros del equipo toman notas. Luego de algunos proyectos, el moderador de esta sesi6n podria convertirse en el analista de casos de uso. El equipo tambiCn intentari desarrollar nuevos casos de uso y casos de uso abstractos. El producto del trabajo sera un conjunto de diagramas de casos de uso que muestren a 10s actores y las dependencias estereotipadas ("extender" e "incluir") entre 10s casos de uso.

Hacer realidad 10s casos de uso En esta accibn, el equipo de desarrollo contin6a su trabajo con 10s usuarios. El objetivo es analizar la secuencia de pasos en cada caso de uso. Esta sesi6n JAD puede ser la continuaci6n de la sesion previa. Cuidado: Csta es, por lo general, la sesi6n JAD mis compleja para 10s usuarios. Tal vez no estCn acostumbrados a dividir una operaci6n en 10s pasos que la conforman y, a su vez, tampoco puedan enumerarlos. El producto del trabajo es una descripci6n textual de 10s pasos en cada caso de uso.

Depurar 10s diagramas de clases Durante las sesiones JAD, el modelador de objeto escuchari todos 10s debates y continuari con su depuraci6n del diagrama de clases. En este punto, el modelador de objetos deberi rellenar 10s nombres de las asociaciones, clases abstractas, multiplicidades, generalizaciones y agregaciones. El producto del trabajo es un diagrama de clases depurado.

Analizar cambios de estado en 10s objetos El modelador de objetos depurari el mode10 mediante la presentacidn de cambios de estado conforme sea necesario. El producto del trabajo es un diagrama de estados.

Definir la comunicacion entre objetos Ahora que el equipo cuenta con un conjunto de diagramas de casos de uso y un diagrama depurado de clases, se definiri la forma en que 10s objetos se comunican. El modelador de objetos desarrollari un conjunto de diagramas de secuencias y de colaboraciones para delinear la comunicacibn. Deberin incluirse 10s cambios de estado. Estos diagramas conforman el producto del trabajo de esta acci6n.

Analizar la integracion con diagramas de colaboraciones A1 tiempo de realizar 10s pasos anteriores, el diseiiador del sistema descubre 10s detalles especificos de la integracidn con 10s sistemas cooperativos. ~ Q u Ctip0 de comunicaci6n esta envuelto? i C d l es la arquitectura de red? Si el sistema tendra que utilizar bases de datos, un analista de bases de datos determinara la arquitectura (fisica o Ibgica) de ellas. Los productos del trabajo son diagramas de distribucidn detallados y (de ser necesario) modelos de datos.

En este segmento, el equipo trabajara con 10s resultados del segmento de Analisis para diseiiar la soluci6n. En el diseiio y en el analisis se haran las revisiones pertinentes hasta que el diseiio se haya completado. De hecho, algunas de las metodologias combinan a1 Analisis y a1 DiseRo en una sola fase.

Desarrollo y depuracion de 10s diagramas de objetos Los programadores tomaran el diagrama de clases y generaran cualesquier diagramas de objetos que sea necesario. Darfin vida a 10s diagramas de objetos mediante el analisis de cada operaci6n y el desarrollo de un diagrama de actividades correspondiente. Los diagramas de actividades fungitan como la base de gran parte del c6digo en el segmento de desarrollo. Los productos del trabajo serln 10s diagramas de objetos y 10s de actividades.

Desarrollo de diagramas de componentes Los programadores seran quienes jueguen un importante papel en esta acci6n. La tarea sera visualizar 10s componentes que resultarhn del siguiente segmento y mostrar las dependencias entre ellos. Los diagramas de componentes serfin el producto del trabajo.

Planeacion para la distribucion Cuando se haya completado el diagrama de componentes, el diseiiador del sistema empezara a planear la distribuci6n e integraci6n con sistemas cooperativos. Creara un diagrama de distribucibn que muestre el lugar donde se encontraran 10s componentes. El producto del trabajo serit un diagrama que sea parte del de distribucidn generado con anterioridad.

Diseiio y prototipos de la interfaz del usuario Esto trae consigo otra sesidn JAD con 10s usuarios. Aunque esto es parte del Diseiio, esta sesidn puede ser la continuacidn de anteriores sesiones JAD con 10s usuarios -un indicio de la interaccidn entre el Analisis y el Diseiio-.

La interfaz del usuario deberia perrnitir la consumacidn de todos 10s casos de uso. Para ello, un analista de GUI debera trabajar con 10s usuarios para desarrollar prototipos, en papel, de las pantallas que corresponderhn a grupos de casos de uso. Los usuarios pegarin papeletas removibles que representen 10s componentes de la pantalla (botones, casillas de verificaci6n, listas desplegables, menus y cosas asi). Cuando los usuarios queden satisfechos de la posici6n de 10s componentes, 10s desarrolladores generarhn prototipos de las pantallas para que sean aprobados por 10s usuarios. Los productos del trabajo serhn capturas de pantalla de los prototipos resultantes.

Pruebas de disefio Los casos de uso permiten el diseiio de pruebas del software. El objetivo es evaluar si el software hace 10 que se supone que deberia (esto es, que hace 10 que se especifica en 10s casos de uso). Preferentemente, un desarrollador o especialista de pruebas externo al equipo de desarrollo deberi utilizar 10s diagramas de casos de uso para crear secuencias de comandos en herramientas automatizadas de pruebas. Tales secuencias de comandos conformarhn el producto del trabajo.

lniciar la documentacion Nunca es demasiado pronto para empezar a documentar el sistema para 10s usuarios finales y gerentes de sistemas. Los especialistas en la documentacion trabajarhn en conjunto con los diseiiadores para empezar a generar un panfleto de la documentacion y llegar a una estructura de alto nivel para cada documento. Tal estructura es el producto del trabajo.

Desarrollo De este segmento se encargan los programadores. Con suficiente anlilisis y diseiio, este segmento deberia realizarse con rapidez y sin problemas.

Generacion del codigo Con 10s diagramas de clases, de objetos, de actividades y de componentes a la mano, los programadores generaran el cddigo del sistema. Tal cddigo es el producto del trabajo de esta acci6n.

Verificacion del codigo Los especialistas en pruebas (no 10s desarrolladores) ejecutarhn secuencias de comandos de prueba para evaluar si el cddigo hace 10 que se pretende. Los resultados de las pruebas son 10s productos del trabajo. Esta accidn alimenta a la anterior y viceversa, hasta que el cddigo pase todos 10s niveles de prueba.

Generacion de interfaces del usuario, conexion con el codigo y prueba Esta accidn crea las interfaces de usuario ya aprobadas. El especialista en GUI las genera y conecta con el c6digo. Las pruebas ulteriores aseguran que las interfaces funcionen adecuadamente. El sistema en funcionamiento junto con las interfaces de usuario, son el producto del trabajo.

Consumacion de la documentacion Durante el segmento de desarrollo, 10s especialistas en documentaci6n trabajan en paralelo con 10s desarrolladores para asegurar la entrega oportuna de toda la documentaci6n, la cual es el producto del trabajo de esta accibn.

Distribucion Cuando un sistema se ha finalizado, se distribuye en el hardware adecuado y se integra con 10s sistemas cooperativos. No obstante, la primera accion en este segmento puede iniciar antes de que el segmento de Desarrollo comience.

Planeacion para copias de seguridad y recuperacion El diseiiador del sistema creara un plan que incluya 10s pasos a seguir en caso de que el sistema falle. El plan, producto del trabajo de esta accibn, establece 10 que se debera hacer para crear una copia de seguridad del sistema y para recuperarse del error.

Instalacion del sistema terminado en el hardware adecuado El diseiiador del sistema, con toda la ayuda necesaria de 10s programadores, distribuye el sistema terminado en 10s equipos de cdmputo adecuados. El producto del trabajo es el sistema completamente distribuido.

Verificacion del sistema instalado Finalmente, el equipo de desarrollo verifica el sistema instalado. i S e ejecuta como se esperaba? iEl plan de copias de seguridad y recuperaci6n funciona? Los resultados de estas pruebas determinarin si se necesita hacer una depuracion ulterior. Tales resultados conforman el producto del trabajo de esta acci6n.

Celebracion Sin mayor explicaci6n, el equipo de desarrollo podri inventar 10s productos del trabajo de esta acci6n.

Resumen de GRAPPLE Si revisa 10s segmentos y acciones en GRAPPLE, veri que 10s movimientos van de 10 general a 10 especifico: de lo rustico a 10 refinado. Empieza con una asimilacidn conceptual del dominio, trasciende a la funcionalidad de alto nivel, profundiza en 10s casos de uso, depura 10s modelos y diseiia, desarrolla y distribuye el sistema. TambiCn not6 que hay m i s acciones en 10s segmentos de Analisis y Diseiio que en el de Desarrollo. Esto es por diseiio, valga la redundancia. La idea es utilizar tanto tiempo como sea necesario en el anilisis y diseiio, para que la codificacidn se realice sin problemas. Podria parecer una herejia, per0 en el mundo ideal la codificacidn es s610 una pequeiia parte del desarrollo de sistemas. Entre m8s analice, m i s cerca estari del ideal.

GRAPPLE, como lo dije, es un patrdn simplificado de un proceso de desarrollo. No me centrC en 10s detalles en ciertos puntos importantes, como 10s niveles de prueba. TambiCn pas6 por alto algunas cuestiones b8sicas: iD6nde y c6mo el equipo alberga 10s producto del trabajo en ejecucibn? iC6m0 trata el equipo el importante punto de la administracidn de la configuraci6n? No aludi a estos puntos porque se salen del tema del UML. Una respuesta corta para estos puntos importantes es cobijarse en la tecnologia. Los productos del trabajo (finalizados o en ejecucibn) pueden encontrarse en un k e a de almacenamiento que se encuentre en la red de la empresa. Una opci6n es contar con una jerarquia de directorios a la que puedan acceder 10s miembros del equipo. Una opci6n mis segura es instalar un paquete de almacenamiento central que lleve un control del cumplimiento e inicio de 10s productos del trabajo, y que s610 permita que una persona a la vez verifique una copia modificable de un elemento. ~ s t es e el fundamento de una solucion para la administraci6n de la configuracibn. La tecnologia de almacenamiento avanza con regularidad, y hay varias opciones. La hora siguiente dari inicio a la parte 11, el estudio de un caso que aplica tanto al UML como a GRAPPLE.

Resumen Una metodologia de desarrollo estructura 10s segmentos y actividades en un proyecto de desarrollo de sistemas. Sin una metodologia habria un caos y 10s desarrolladores no comprenderian el problema que se supone deberian resolver, asi como 10s sistemas no cumplirian con las necesidades de 10s usuarios. Las metodologias de antaiio forzaban a una secuencia "en cascada" de anilisis, diseiio, codificaci6n y distribuci6n. Este tipo de metodologia secuencial podia fragmentar el desarrollo, de mod0 que un equipo de desarrollo podria no aprovechar la mejor asimilaci6n que se obtiene durante la vida de un proyecto. Por 10 general, tambiCn distribuye la mayor parte del tiempo en la codificaci6n, y esto resta una enorme cantidad de tiempo al anilisis y diseiio. Esta hora present6 a1 GRAPPLE (Directivas para el Rapido Diseiio de Aplicaciones), un patron para el proceso de desarrollo. GRAPPLE consta de cinco segmentos: Recopilaci6n de necesidades, Anilisis, Diseiio, Desarrollo y Distribuci6n. Cada segment0 consta de diversas acciones, y cada una de ellas da por resultado un producto del trabajo. Los diagramas UML constituyen productos del trabajo para varias de las acciones. La parte I1 aplica a GRAPPLE y el UML a1 estudio de un caso.

Preguntas y respuestas P ;En algun moment0 se podria aplicar el mCtodo "en cascada"? R Si el Bmbito del sistema propuesto es muy pequeiio (claro que es algo subjetivo), podria aplicarlo sin problemas. No obstante, en el moderno desarrollo de sistemas orientados a objetos, una metodologia que propenda a la interaction entre 10s segmentos de desarrollo podri otorgar un mejor resultado.

P En la respuesta anterior, menciond el desarrollo de sistemas orientados a objetos. Suponga que el sistema propuesto no est6 orientado a objetos. ;Aun asi se aplica? R Incluso en 10s sistemas que no esten orientados a objetos (como en muchos proyectos basados en grandes computadoras centralizadas) se aplican las ideas que ha visto en esta hora. Las sesiones JAD, un analisis y diseiio de avanzada y la interacci6n entre 10s segmentos de desarrollo inclusive seran muy utiles. Podria adaptar a GRAPPLE (por ejemplo: mediante la eliminaci6n del modelado de clases), pero esa es la idea: es un conjunto de directivas flexibles en lugar de ser una metodologia que tenga que seguirse a pie juntillas.

Taller Ahora que ya comprendi6 las metodologias, verifique, con las siguientes preguntas, que tanto ha asimilado. El apendice A, "Respuestas a 10s cuestionarios", le dara las respuestas.

Cuestionario 1. ~ C u a l e sson algunas de las inquietudes de un cliente? 2. iQuC se debe comprender como metodologia de desarrollo?

3. iCual es el metodo "en cascada"? iCuBles son sus debilidades? 4. iCuBles son 10s segmentos de GRAPPLE? 5. ~ Q u Ces una sesi6n JAD?

Estudio de un caso Hora 16 Presentacion del caso por estudiar 17 Elaboracion de un analisis de dominio

18 Recopilacion de las necesidades del sistema 19 Desarrollo de 10s casos de uso 20 Orientation a las interacciones y cambios de estado

21 DiseAo del aspecto, sensacion y distribucion

22 Nocion de 10s patrones de diseAo

Presentacion del caso por estudiar Ahora que ya cuenta con cierta experiencia del UML y se le ha presentado el patr6n de una metodologia de desarrollo, veri c6mo aplicar el UML en un proceso de desarrollo. A partir de aqui daremos inicio a la parte 11, el estudio de un caso que aplica a1 UML bajo el context0 del proceso GRAPPLE. En esta hora se tratarin 10s siguientes temas: El panorama del caso por estudiar C6mo descubrir y modelar 10s procesos del negocio Sugerencias a1 hacer entrevistas La empresa multinacional (y ficticia) LaHudra, Nar y Goniff, S.A., ha hecho una encuesta sobre el mundo de 10s restaurantes y ha llegado a sorprendentes conclusiones: a la gente le gusta comer fuera, pero no disfrutan algunos momentos de esa experiencia. "Bueno", dijo LaHudra, "pude haber predicho 10s resultados de nuestra encuesta. Cuando salgo a comer, me disgusta cuando el mesero toma mi orden y se desaparece por una hora. A1 ir uno a un restaurante con clase se espera un trato diferente".

"Cierto", respondid Nar, "En ocasiones cambio de parecer luego de hacer mi orden y quiero decirle al mesero que aguarde. 0 tengo una pregunta... o algo... y no puedo encontrarlo." Goniff asiente: "Estoy de acuerdo. Pero, con todo, el comer fuera es divertido; me agrada cuando alguien me sirve y ademas, me gusta la idea de que el personal de cocina me prepare la comida. Los resultados de nuestra encuesta muestran que la mayoria de las personas tambiCn opinan de esa forma."

NO habria alguna manera en que podamos mantener la experiencia b6sica y mejorarla de alguna forma?" "iC6m0?', preguntd Nar, "~YosC cdmo!", dijo LaHudra. "Con tecnologia." Y asi fue que decidieron que uno de sus equipos de desarrollo de software corporative construyera el restaurante del futuro.

Aplicacion de GRAPPLE al problema Los miembros del equipo de desarrollo se ciiien a1 esquema de GRAPPLE. Saben que la mayor parte del tiempo en el proyecto deber6n orientarlo a1 analisis y diseiio. De esa forma, la codificacidn se generarh con rapidez y eficiencia, con 10 que aumentara la posibilidad de una instalacidn y distribucidn sin problemas. El proyecto debe iniciar con la recopilacidn de necesidades, y con la asimilaci6n del dominio del restaurante. Como podri recordar de la hora anterior, la recopilacidn de necesidades consta de las siguientes acciones: Descubrir 10s procesos del negocio Realizar un analisis del dominio Identificar 10s sistemas cooperativos Descubrir 10s requerimientos del sistema Presentar 10s resultados al cliente En esta hora trataremos la primera accidn.

Descubrir 10s procesos del negocio LaHudra, Nar y Goniff 10 hacen todo a 10 grande. E s a listos para entrar en el mundo de 10s restaurantes y han conformado una Divisidn de Restaurantes LNG. Han contratado a varios restauranteros, meseros (camareros), chefs y personal de mantenimiento experimentados. Todo 10 que esperan es el apoyo tecnoldgico para el restaurante del futuro. Luego, establecerh su primer restaurante, integro, con todo y la tecnologia para mejorar el placer de comer en un restaurante.

Los rniembros del equipo de desarrollo esdn de suerte. Iniciardn con un papel en blanco. Todo 10 que deberdn hacer sera comprender 10s procesos del negocio y el dominio para continuar en esa linea. El andlisis del proceso del negocio empieza con la entrevista de un analista a un restaurantero. Durante la entrevista, alguien tomard nota en una computadora portAtil. A1 mismo tiempo, un modelador plasmarti en una pizarra blanca un diagrama de actividades que el analista, quien estd tomando nota y el restaurantero podrtin ver. En las siguientes subsecciones, seguiremos la entrevista en cada proceso del negocio en un restaurante. La meta es producir 10s diagramas de actividades que modelen 10s procesos.

Servir a un cliente "Gracias por atendernos", dice el analista. "Es un placer", dice el restaurantero. ' ' ~ Q u tes exactamente 10 que desean saber?" "Empecemos con una sencilla transacci6n de negocios. ~ Q u Csucede cuando un cliente entra a1 restaurante?" "Bueno, si el cliente tiene un abrigo o chaqueta, le ayudamos a quitfirselo, 10 almacenamos en un guardarropa y le damos un boleto para solicitarlo posteriormente. Eso mismo hacemos con un sombrero. Luego, nosotros ..." "Un momento. Suponga que hay una linea de espera. ~Primerose forma, o da su nombre a1 capitdn, o...?" "No. Intentamos que se sienta tan c6modo como sea posible a1 llegar. Luego nos preocupamos por la linea de espera, en caso de haber alguna" "De hecho, si hay una lista de espera, le preguntamos a1 cliente si hizo alguna reservaci6n. Si la hizo, intentamos honrarlos de forma oportuna y darles asiento tan pronto como sea posible. Si no hay una reservacibn, deja su nombre y puede ir a nuestro bar para tomar algo antes de comer. Claro que no es obligatorio que 10 hagan. Pueden tan s610 sentarse en un irea de espera claramente indicada." "Interesante. A6n no se han sentado a comer y ya se han logrado algunos puntos decisivos." Hagarnos una pausa para determinar a d6nde llegamos. El diagrama del proceso del negocio ahora luce como en la figura 16.1. De vuelta a la entrevista. El trabajo del analista es continuar por el proceso del negocio.

FIGURA16.1 Las fuses iniciales del diagrama de actividudes del proceso del negocio del restaurante, "Servir a un cliente ".

Guardarlo

C>\

[[Lista de espera]]

Espera en el bar

el area de espera

"Bien. Cuando le llegue el turno a1 cliente, o que haya llegado un cliente qpe hizo reservaci6n, sera hora de sentarlo, jno?"

"Si, per0 ahora que lo pienso no es tan sencillo. La mesa deberi estar lista; para ello, deberi ser limpiada. Un mozo de piso debe cambiar el mantel usado por el cliente anterior, y acomodar la mesa. Cuando esti lista, el capitan de meseros lleva a1 cliente a su mesa y luego llama a un mesero." "jlo llama?"

Observe lo que hace el analista. El restaurantero ha utilizado un nuevo termino (nuevo dentro del context0 de la entrevista), y el analista desea que se lo defina. El saber cuando y como hacer esto es parte del arte de entrevistar, donde la experiencia sera el mejor maestro.

"Si. No es muy complicado dad0 que 10s meseros tienen sus Areas asignadas de servicio y, por lo general, saben c u h d o esti lista una mesa. Nonnalmente circundan su Area y estin atentos a las expresiones del capitin."

"jLueg0 quC ocurre?" "Bueno, el mesero llega a la mesa, entrega un menu a cada comensal y les pregunta si desean alguna bebida mientras se deciden. Luego llamari a un 'asistente', quien colocari una charola con pan y mantequilla, y llenari un vaso con agua para cada persona en la mesa. Si alguien ha pedido una bebida, el mesero la traeri."

"Un momento. Dijo 'el mesero'. iLa persona que siwe siempre es un hombre?" "No. Hablo de 'el mesero' por habito. Lo siento." hay si utilizamos el tCrrnino neutral 'sirviente'? TambiCn vi que el cliente "Bien. ~ Q u C tiene un par de oportunidades para pedir una bebida." "Siwiente no es una palabra que usemos en el iunbito restaurantero. Sugiero que sigamos con 'mesero' y que se aplique indistintamente a hombres y mujeres. En cuanto a 10 de las bebidas, es cierto. Si un cliente est6 a la espera de una mesa y pas6 a1 bar, puede llevarse su bebida a la mesa si no se la ha terminado cuando se le haya asignado una mesa. A prop6sit0, siempre nos reservamos el derecho de negar el sewicio a quien ha consumido demasiado alcohol."

El entrevistador no es solo un oyente pasivo luego de hacer una pregunta. En este caso, et analista ha conjugado un tema en comun a partir de algunas respuestas previas, y ha hecho una pregunta basada en algo que ha salido a colacion en algunas ocasiones (la oportunidad de pedir algo de tornar). La respuesta contiene un extract0 de la 16gica de negocios, una regla que sigue el negocio en una situation en particular. En este caso. la 16gica de negocios se aplica a negar el s e ~ i c i oa un cliente alcoholizado.

"Es bueno saberlo. Regresemos a la mesa donde 10s comensales deciden quC van a consumir." "Si. Siempre tenemos algunas sugerencias del dia que no estan en el menli, y el mesero se las propone a 10s clientes." "iSabe quC es 10 que he visto que pasa? La gente le pide a1 mesero las recomendaciones, y 10s meseros por 10 general parecen ser sinceros: le dicen si un platillo es mejor que otro. iEs algo que usted alienta a hacer?' "Asi es. Ciertamente nuestros meseros comen en el restaurante y tienen sus propias opiniones de 10 que les gusta y 10 que no. Si a ellos realmente no les gusta un platillo en particular, queremos que 10 digan a1 chef antes que a 10s clientes, aunque no tengo inconveniente que expresen una preferencia. Claro que no queremos que 10s meseros le digan a 10s comensales que la comida es temble, pero el expresar una preferencia por un platillo no est6 mal." "Bien. Vamos a resumir. El cliente o comensal deja sus abrigos, entra a1 bar, aguarda una mesa, se sienta ante ella, posiblemente ordena una bebida, se le sine pan y agua y mira el menli."

Se sugiere detenerse y resurnir de vez en cuando. Le ayudarh a verificar qu6 tanto ha asirnilado y le da la oportunidad de utilizar la terrninologia del dorninio, adernhs de que reconforta al entrevistado saber que usted le ha puesto atencion.

"Asi es. El mesero regresa con una bebida y 10s clientes la beben mientras ven el menli. El mesero les da de cinco a diez minutos para hacer su elecci6n y, luego, regresa. El mesero regresa antes si, claro, 10s comensales hacen su eleccidn antes." ''iC6m0 saben que deben regresar antes?' "Bien, 10s clientes llaman la atenci6n del mesero. Por 10 general e s d cerca del Area de la mesa, a menos que haya tenido que ir a la cocina a traer un pedido o necesitara hablar con 10s chefs por alguna raz6n."

"ihea?' "Si, a cada mesero se le asigna un Area que consta de varias mesas. Hay una secci6n asignada como Area de fumadores, y el resto es para quienes no fuman." "iC6mo determina quiin atiende un Area?" "Alternamos a 10s meseros en las diferentes Areas." "Bueno, volvamos al proceso de servir. Los comensales hacen su eleccidn, el mesero toma la orden en su comanda y luego..."

"Y luego notifica a1 chef. Esto 10 hace mediante la trascripci6n de la elecci6n en un formulario, llamado comanda, que le da a1 chef." "iQuC hay en la comanda?" "La mesa, la eleccidn y, muy importante, la hora." "iPor quC es tan importante?" "Debido a que generalmente la cocina e s d (espero) muy ocupada, y el chef tiene que dar prioridad a las cornandas en el orden en que hayan llegado." "LESOes complicado?" "En realidad, se complica m6s de acuerdo con su naturaleza." "iC6m0 esd eso?" "La mayoria de las comidas incluyen un entremks antes del plato principal. A la mayoria de la gente le gusta comer el plato fuerte caliente, asi que el chef prepara el entremis, muchos de ellos ya estiin preparados, como algunas ensaladas, y el mesero se 10s lleva a1 cliente. El reto e s d en llevar el plato fuerte, caliente, a todos 10s comensales en la mesa a1 mismo tiempo. Digo 'reto' porque las personas de la mesa por 10 general se terminan el entremCs en diferentes momentos. Todo el asunto debe estar coordinado." "Hum. Esto suena a proceso separado. Tomaremos esto en una reuni6n por separado desde el punto de vista del chef."

El analista ha tomado una importante decision: sacar del context0 una secuencia que posiblernente sea parte de u n proceso separado. El reconocer en que mornento hacerlo se obtiene rnediante la experiencia. Un buen principio es que, si el entrevistado utiliza palabras como "complejo" o "cornplicado", o responde que "sin cuando le pregunta si algo es complicado, t a l vez estara ante u n conjunto de pasos que necesitarhn su propio modelo. Deje que el entrevistado hable u n poco antes d e tomar una decision como esta.

"De acuerdo, es una buena idea." "Estarnos en el punto donde el chef preparari el plato fuerte. A prop6sit0, este diagrama?'(Vea la figura 16.2.)

le parece

FIGURA16.2 Las fases intermedias del diagrarna de actividades para el proceso del negocio "Servir a un cliente". [Nohzo mserveaonl

SBntar d diente

4 Sugerir *lib

Leer menu

Elegir

Notdkar 4 chef

I

"Creo que ha comprendido. De cualquier forma, el chef prepararh el plato fuerte y el mesero 10 recogerh cuando se de cuenta de que 10s comensales han terminado con el entrem6s; posteriormente, el mesero llevarh el plato fuerte a la mesa. Los comensdes ingerirhn sus alimentos, y el mesero regresarh a1 menos una vez para verificar si todo esta bien." "Suponga que a un cliente no le ha satisfecho algo de la comida. iQu6 ocurre?" "Bueno, hacemos nuestro mejor esfuerzo para que le satisfaga, aun cuando nos cueste algo de dinero. Es mejor perder algo de dinero que a un cliente." "Buen concepto." "Gracias. Cuando 10s comensales terminan con sus alimentos, el mesero regresa y pregunta si desean un postre. En tal caso, el mesero darh el menti de postres y tomar6 las brdenes. En caso de que no deseen postre, preguntarh si desean un caf6. Si es el caso, traerh caf6 y tazas y les servirii. Si no desean nada, traerh la cuenta. Luego de unos instantes, regresarh y obtendrh el pago en efectivo o en tarjeta de crCdito. Luego traerh el cambio o 10s vouchers, 10s clientes dejarhn una propina, recogerhn sus abrigos y se irhn."

"No necesariamente. El mesero llamarh a1 mozo de piso para limpiar la mesa, la preparar6 y estarh lista para 10s siguientes comensales." "Dado que ell0 no tiene que ver con el cliente, voy a considerarlo dentro de un proceso por separado, aunque sea breve. Quiero hacerle un par de preguntas. La primera iC6m0 sabe el mesero que la gente ha terminado?" " ~ pennanece 1 en su kea, y echa una mirada a cada mesa. La experiencia le dicta cuhnto le toma a 10s comensales ingerir sus alimentos, de forma que se puede anticipar a ell0 cuando est6 cerca de una mesa. iOtra pregunta?' "Si. Dijo que el mesero podria estar en la cocina para hablar con el chef por alguna raz6n. iCuhl seria tal razbn?" "En ocasiones un cliente necesita saber c u h t o tardarh la preparaci6n de un alimento. En tales casos, el cliente llama a1 mesero, quien le pregunta a1 chef. Una vez que se informa, regresa y le responde a1 cliente."

Los entrevistadores se aseguran de agregar cualquier pregunta restante al final.

"iSabe? Nunca me habia dad0 cuenta de todo 10 que ocurre para servir a un cliente en un restaurante."

"Es curios0 que 10 diga. Hasta que me pidi6 que le describiera 10s pasos, yo tampoco 10 habia analizado mucho. Pienso que su diagrama esquematiza todo 10 que he dicho, y es una imagen que aclara mis propias ideas." (Vea la figura 16.3.) FIGURA16.3 El diagrama de actividades completo para el proceso del negocio del restaurante, "Servira un cliente".

Como 10 vio en la hora 11, "Diagramas de actividades", puede convertu un diagrama de Cstos en uno con marcos de responsabilidad. Cuando modele un proceso del negocio, serA algo muy util dad0 que el diagrama con marcos de responsabilidad le muestra la forma en que cada uno de 10s responsables figuran en el proceso. La figura 16.4 es un diagrama con marcos de responsabilidad para el proceso del negocio "Servu a un cliente".

FIGURA16.4 Un diagram con marcos de responsabilidad para "Servira un cliente ".

Preparacion de platillos ~Recuerdaque separ6 10s procesos del negocio que aparecieron en la entrevista? Volvamos a reunir al analista con el restaurantero y explorernos el proceso de la "Preparacibn de platillos". "En la plhtica anterior", decia el analista, "mencionb que muchos platillos incluyen un entremCs antes del plato fuerte, y que la mayoria de las personas preferian el plato fuerte caliente. Indic6 el reto de traer el plato fuerte a todos a1 mismo tiempo y tenerlo caliente; y mencion6 la importancia de la coordinacibn. ~Podriaahondar?"

"Claro." dice el restaurantero. "La gente en una mesa casi siempre finaliza sus entremeses, ensaladas o sopas en momentos distintos. Tenemos que coordinarnos para traerles a todos 10s platos fuertes. La coordinacidn se realiza entre el mesero y el chef. El chef recibe la comanda del mesero y empieza a preparar 10s entremeses y el plato fuerte. Cuando se han preparado 10s entremeses, el mesero va a la cocina, 10s toma y 10s lleva a la mesa." "iY el mesero sabe que ya se han preparado 10s entremeses porque ...?" "Porque va a la cocina de vez en cuando. Es aqui donde se inicia la coordinaci6n: el chef, luego de dar el entremCs a1 mesero, espera a que Cste le avise cuando la mayoria de 10s comensales ya casi ha terminado con sus entremeses para poderle dar el toque final a cada plato fuerte. El mesero permanece en su k e a designada, y no pierde de vista a la mesa. En el moment0 adecuado, el mesero va a la cocina, le indica a1 chef que 10s comensales casi esdn listos para el plato fuerte, y el chef termina su preparaci6n. Un chef experto, que cuente con un grupo de asistentes, equilibrarh la preparaci6n de platillos para varios comensales a la vez. La meta es tener listo el platillo principal tan pronto como todos 10s comensales estCn listos para Cl." " ~ E s ~siempre o ocurre a tiempo?" "No, no siempre. Pero con un poco de experiencia y sentido comdn esto podria ser frecuente. Lo que a veces ocurre es que un comensal lento en un gmpo no esth del todo listo cuando llevamos el platillo fuerte, pero es un problema menor." "Ya entiendo. ~ Q u C opina de nuestro diagrarna para este proceso?'(Vea la figura 16.5.)

Un diagrama de actividades para "Preparacidn de platillos ".

* Recibir comanda

nalizar la preparacion del plato fue

I

Q Tomar el plato fuerte

C Llevar plato fuerte

Como en el caso del proceso del negocio anterior, es adecuado generar un marco de responsabilidades,como el de la figura 16.6.

Un diagrama con marcos de responsabilidades para "Preparacidn de alimentos ".

Limpieza de la mesa "Ahora vayamos a otro proceso por separado, aquCl en el que el mozo de piso limpia la mesa", dice el analista. " ~ s t etambiCn requiere cierta coordinaci6n. El mesero se asegura de que todos se hayan ido y, luego, llamarh a1 mozo de piso para que se encargue de la mesa. En una noche ajetreada, esto tendrh que hacerse con rapidez. No tenemos tantos mozos de piso como meseros, dad0 que esto es un proceso casual. Los mozos de piso no siempre esGn cerca, por 10 que tal vez el mesero se veria en la necesidad de buscar uno." "Creo comprenderlo con 'encargarse de la mesa', per0 ipodria ser un poco mhs especifico?'

"Claro. En 10s restaurantes que yo manejo, tenemos un mantel para cada servicio. Asi que el mozo de piso tiene que quitar el mantel usado, amarrarlo, colocar uno nuevo y un nuevo juego de cubiertos en la mesa. Dobla las servilletas y acomoda 10s cubiertos y un plato para cada asiento de la mesa. Luego se lleva el mantel doblado a una habitacibn detrhs de la cocina. Lo empacamos y 10 enviamos a1 cuarto de lavado a1 dia siguiente." La figura 16.7 muestra el diagrama de actividades para este proceso. FIGURA16.7 Un diagrama de actividades para "Limpieza de la mesa ".

e=) 0 Llamada de un mesero

Quitar mantel

( Colocar un nuevo mantel )

0 Acomodar la mesa

C Empacar el otro mantel para el cuarto de lavado

Lecciones aprendidas Si usted es aspirante a analista, recuerde las lecciones aprendidas en esta entrevista: Se recomienda detenerse y resumir de vez en cuando para verificar su asimilacibn, practicar con la terminologia y hacer que el entrevistado se sienta c6modo. Siempre pida que el entrevistado le explique cualquier terrninologia que no le sea familiar. No se preocupe si ell0 aparenta falta de conocimiento. La raz6n por la que esta aqui es para adquirirlo y aprender la tenninologia. DespuCs de todo, va a tener que utilizar el nuevo vocabulario cuando penetre en el analisis del dominio. A veces, podrh hacer una pregunta basada en un tema que perciba como respuesta a preguntas anteriores. Mantenga su mente y oidos abiertos para hacer preguntas como Cstas. La 16gica de negocios con frecuencia emerge de las respuestas.

Tome nota cuando aparezcan las reglas de la 16gica de negocios. Lleve un registro de estas reglas. Podrian ser 6tiles posteriormente (usted nunca sabe: alg6n dia podria generar una herramienta para la automatizaci6n de decisiones que dependa de tales reglas). Claro que debe generarse una registro de esto en la minuta. Si siente que cierta parte del proceso se torna complejo, puede optar por sacar tal complicacidn del context0 hacia un proceso del negocio por separado. Podria facilitar el modelado y el modelo resultante serh mhs claro que si intenta aglomerarlo todo en un solo proceso. Obtenga el punto de vista del entrevistado respecto a1 diagrama de actividades. Haga cualquier modificaci6n que sugiera. Ha aprendido mucho esta hora y ahora ya cuenta con algunas valiosas tCcnicas. Conforme obtenga experiencia, generarh sus propias tCcnicas. En la siguiente hora, comprenderh el anhlisis de dominios.

Resumen Esta hora le present6 el escenario para el estudio de un caso que aplicarh a1 UML en un proceso de desarrollo. En el escenario, el consorcio ficticio LaHudra, Nar y Goniff, S. A. decide incorporar la tecnologia del c6mputo en el restaurante del futuro. Como analista, su trabajo es comprender el proceso del negocio involucrado, comprender el dominio y recopilar las necesidades (acciones presentes en el primer segment0 de GRAPPLE). La reciCn creada Divisi6n de restaurantes LNG le da acceso a 10s expertos del dominio que necesita para comprender 10s procesos del negocio. El contenido de esta hora se ha orientado a1 dihlogo en una entrevista y la forma en que podria fluir. Se han intercalado notas que le servirhn de guia para saber c6mo realizar la entrevista. El objetivo fue el de mostrarle c6mo convertir 10s resultados de la entrevista en un modelo UML. En la siguiente hora, comprenderh 10 relacionado a1 analisis de un dominio.

Preguntas y respuestas P ;Siempre se da el caso en que las acciones de un segment0 se realicen en el orden en que las listb? R No. En ocasiones podria ser sensato realizarlas en otro orden. Por ejemplo: tal vez quiera descubrir 10s requerimientos de un sistema antes de identificar a 10s elementos cooperativos. A su vez, tenga en cuenta que algunas de las acciones no siempre seran necesarias para ciertos proyectos y que algunas de ellas pueden realizarse a1 mismo tiempo que otras. La "G" en GRAPPLE significa "Guidelines" o "Lineamientos". El10 no se puede interpretar como "iGulp! Es una obligaci6n seguirlo as?' o "Debo hacerlo exactamente as?'. P ;Es necesario contar con un solo entrevistador para enterarse de 10s procesos de negocios de un cliente o un experto? ;Dos funcionarian mejor que uno? R Por 10 general se recomienda que sea una sola persona la que hable con el experto, para que el entrevistado no se sienta como que encara a la inquisicibn. Podria optar por rotar a 10s entrevistadores en algun moment0 de una sesi6n. El segundo entrevistador podria haber sido el que tomaba las notas, mismo que alternaria su papel con el primer t ntrevistador. P ;Hay alguna consideracibn especial para las notas de la entrevista? R Asegurese que haya indicado la fecha, hora, lugar y participantes a1 principio. Nunca sabri cufindo necesitarh tal informacidn y no necesitarfi tenerla de memoria. A su vez, dentro de las notas intente capturar tanto como le sea posible. Es como un esten6grafo en una corte. Si intenta hacer un boceto conforme avanza, podria estar pasando por alto algo. P ;NO podria omitir algo a1 intentar tomar nota de todo? R iPor supuesto -raz6n por la cual es mejor contar con dos personas que tomen notas-! Seguramente uno de ellos podria haber anotado algo que el otro no. Recuerde que las notas que tome serfin parte del document0 que le darl a1 cliente. Entre mfis completas estCn las notas, sera m8s ficil rastrear la evoluci6n de una idea.

Taller Para realmente captar todo esto, responda a1 cuestionario y haga 10s ejercicios. Las respuestas estan en el ApCndice A, "Respuestas a 10s cuestionarios".

Cuestionario I. iCuil diagrama del UML es adecuado para modelar un proceso del negocio? 2. iC6m0 podria modificar a este diagrama para mostrar quC hace cada quitn? 3. iQuC debe entenderse por "16gica de negocios"?

Ejercicios 1. Intente aplicar 10s principios de esta hora a otro dominio. Suponga que LaHudra, Nar y Goniff le han contratado para encabezar un equipo de desarrollo que genere un sistema para su biblioteca corporativa. Inicie el segment0 Recopilaci6n de necesidades mediante la asimilaci6n y modelado de 10s procesos del negocio involucrado. Para ello, tendra que confiar en su propio conocimiento de las bibliotecas. Haga anotaciones de su solucidn dad0 que utilizara este ejemplo en 10s ejercicios de las siguientes horas. 2. Revise las entrevistas de esta hora. ~ Q u Cpartes de la 16gica de negocios se hicieron evidentes?

analisis de dominio Ahora continuaremos con el anilisis conceptual en el segment0 de recopilacidn de necesidades de GRAPPLE. En esta hora se trataran 10s siguientes temas: Anilisis de la entrevista del proceso del negocio Desarrollo del diagrama de clases inicial Agrupacidn de las clases Conformacidn de asociaciones Agregados y objetos compuestos Llenado de clases las clases El primer par de acciones en GRAPPLE se orientan a1 dominio y no a1 sistema. Ni la hora anterior ni Csta se orientartin al sistema propuesto. Ciertamente, en 10 que hemos visto hasta ahora no se ha propuesto sistema alguno. S610 tenemos una asignacidn vaga de LaHudra, Nar y Goniff para valernos de la tecnologia y mejorar el act0 de comer en restaurantes.

El objetivo de las horas 16 y 17 es comprender el dominio. Lo que significa que tenemos que conocer 10s procesos especificos que intentamos mejorar y el mod0 en el que operan tales procesos. A1 intentar descubrir 10s procesos del negocio, hemos empezado a alimentar el conocimiento del equipo de desarrollo en nuestro escenario. Como resultado, 10s miembros del equipo cuentan con un vocabulario que pueden utilizar para comunicarse posteriormente con la Divisi6n de Restaurantes de LNG. Esto es de gran importancia dad0 que el equipo cuenta con un fundamento para aumentar y cultivar su conocimiento en el transcurso del proyecto.

Analisis de la entrevista del proceso del negocio El equipo de desarrollo tendri otras entrevistas con 10s expertos restauranteros, per0 antes de ello trabajarin con el context0 de la entrevista del proceso del negocio. El objetivo es producir un diagrama de clases inicial. Un modelador de objetos harB este trabajo con el equipo durante la entrevista o mediante 10s resultados de ella. En este punto, el modelador buscari sustantivos, verbos y construcciones verbales. Algunos de 10s sustantivos se convertirin en clases dentro del modelo, y algunos otros en atributos. Los verbos y construcciones verbales podrin convertirse en operaciones o las etiquetas de asociaciones. Examinemos 10s resultados de la entrevista de la hora anterior. ~ Q u Csustantivos y verbos utiliz6 el restaurantero? He aqui 10s sustantivos: cliente, abrigo, guardarropa, vale de guardarropa, sombrero, linea de espera, lista de espera, reservaci61-1,nombre, bar, bebida, comida, Brea de espera, mesa, mozo de piso, mantel, capitin de meseros, mesero, servidor, Brea de servicio, comensal, mend, asistente, charola, pan, mantequilla, vaso, agua, persona, eleccidn de menli, sugerencia del dia, restaurante, chef, platillo, cocina, comanda, Area de fumadores, formulario, hora, entremCs, plato fuerte, postre, mend de postres, cafC, taza, cuenta, efectivo, tarjeta de credito, cambio, voucher, propina, cubierto, servilleta, habitacibn, cuarto de lavado. Observe que hemos utilizado cada sustantivo en su forma singular. Los verbos y construcciones verbales son: tener, ayudar, almacenar, dar, formarse, honrar, sentar, salir, aguardar, surgir, deshacerse, establecer, carninar, llamar, rondar, ver, gesticular, mostrar, preguntar, ordenar, decidir, traer, ir, obtener, finalizar, reservar, rehusar, relatar, pedir, recomendar, alentar, gustar, decir, expresar, mirar, regresar, beber, leer, permitir, seleccionar, atender, obtener un

pedido, servir, recolectar, dejar, limpiar, alistar, anticipar, hablar, venir, convocar, localizar, proveer, preferir, coordinar, recibir, verificar, depender, cuidar, limpiar, asegurarse, encargarse, buscar, quitar, atar, doblar, arreglar, empacar, enviar. Cuando busquemos 10s sustantivos y verbos, deberemos procurar incluirlos todos. iEl modelador 10s incluid a todos en el modelo? No. El sentido corn611 indicard a cudles incluir y a cudles no. Serd de mucha ayuda tener mayor contact0 con el restaurantero.

Desarrollo del diagrama de clases inicial Ahora ponghmonos en 10s zapatos del modelador y empecemos a desarrollar el diagrama de clases. Es aqui donde el sentido comun entra en juego. Primero eliminaremos algunos de 10s sustantivos. Recordemos en la entrevista que se intent6 cambiar "mesero" por "servidor", pero que no dio resultado. Asi que podriamos eliminar uno de estos ttrminos. Tanto el entrevistado como el entrevistador decidieron usar "mesero", asi que eliminaremos a "servidor". "Cliente" y "comensal" son sinbnimos, por 10 que podremos eliminar otro sustantivo: nos quedaremos con "cliente". "Persona" parece ser demasiado gentrico, asi que tambitn 10 eliminaremos. iPodriamos eliminar a otros? Algunos sustantivos son mds adecuados para usarse como atributos y no como clases. En nuestra lista, "nombre", "hora" y "reservaci6nWcaen en tal categoria. Otro de ellos, "cuarto de lavado", no es parte fisica del restaurante, por 10 que podriamos eliminarlo. He aqui el otro lad0 de la moneda: tambitn es posible agregar una o dos clases. Si analizamos la entrevista, veremos que el restaurantero hizo referencia a "Areas asignadas" y "rotaci6n de meseros". ~ Q u i t nhace la "asignaci6n" y la "rotaci6n"? Pues un "gerente", que agregaremos a la lista. Tal clase podria no haber surgido de la entrevista original, dad0 que el analista se enfoc6 a1 cliente, el mesero, el chef y el mozo de piso.

La adicion de una clase (corno l o vera en la adicion de clases abstractas) refleja la evolucion del entendirniento conforme avanza el proyecto.

Luego de filtrar 10s sin6nimos y atributos, asi como agregar una clase, ahora Csta sera nuestra lista de sustantivos que se convertiran en clases: cliente, abrigo, guardarropa, vale de guardmopa, sombrero, linea de espera, lista de espera, bar, bebida, comida, k e a de espera, mesa, mozo de piso, mantel, capitin de meseros, k e a de servicio, men6 asistente, charola, pan, mantequilla, vaso, agua, servicio, mesero, eleccibn, sugerencia del dia, restaurante, chef, platillo, cocina, comanda, k e a de fumadores, formulario, entremCs, plato fuerte, postre, menli de postres, cafC, taza, cuenta, efectivo, tarjeta de crCdito, cambio, voucher, propina, cubierto, servilleta, habitacibn, reservaci611, gerente. Nos serviremos de estos sustantivos para generar el diagrama de clases de la figura 17.1, donde pondremos en mayliscula la primera letra de cada nombre de clase. Si tal nombre tiene m b de una palabra, las uniremos y pondremos con mayliscula la primera letra de cada palabra. TambiCn eliminaremos 10s acentos.

FIGURA17.1

Cliente

El diagrama de clases inicial para el dominio del restaurante. Linea DeEspera

El Abrigo

Lista DeEspera

AreaDe Espera

Bebida

Comida

Mantel

Capitan DeMeseros

DePiso

AreaDe Sewicio

Asistente

Mantequilla

Charola

Sewicio

Sugerencia DelDia

Cocina

Sombrero

Guardarropa

Mesero

Platillo

Restaurante

UI Formulario

Comanda

Entremes

DeFumadores

Postre

0 DePostres

Cuenta

Efectivo

Propina

Cubierto

Tajeta DeCredito

CI Cambio

Vaucher

Gerente

Agrupacion de las clases Ahora intentaremos conformar algunos grupos significativos. Uno de 10s grupos consta de personas: cliente, servicio, mozo de piso, capitan de meseros, asistente, chef, mesero y gerente. Este grupo podria tener alguna divisi6n pues todos, except0 el cliente y el servicio, son empleados. Asi que nos quedaremos con 10s grupos cliente, servicio y empleado. Otro grupo consta de elementos relacionados con alimentos: bebida, comida, pan, mantequilla, agua, sugerencia del dia, platillo, entremks, plato fuerte, postre y cafk. Hay un tercer grupo que consta de utensilios: vaso, cubierto, charola, servilleta y mantel. El cuarto grupo contiene elementos de transacci6n: vale de guardarropa, cuenta, efectivo, cambio, tarjeta de crkdito, pagarC y propina. Existe otro grupo que consta de Qreasdel restaurante: 5rea de espera, Area de fumadores, bar, guardmopa, cocina, Area de sewicio, mesa y habitaci6n. "Habitaci6nmse refiere a aquella que almacena 10s manteles (y asumimos que otros elementos) que el restaurante enviara a la lavanderia. Para hacerlo mis descriptive, llamCmoslo "cuarto de lavado". Finalmente, podemos agrupar 10s formularios del restaurante: menu, menu de postres, vale de guardmopa, cuenta y formulario. El ultimo se refiere a1 que se entrega a1 chef con la orden, por 10 que 10 llamaremos "comanda". Observe que un par de estos elementos pueden encontrarse en dos grupos (formularios y elementos de transacci6n). Esto, como veremos, es admisible. ~ A h o r aquC haremos con tales grupos? Cada nombre de grupo puede convertirse en una clase abstracta: una que no genera instancias por si misma, pero que funciona como una clase principal de clases secundarias. Asi, la clase abstracta AreaDeRestaurante tiene las siguientes clases secundarias: Bar, AreaDeServicio, Mesa, AreaDeEspera, Guardmopa y Cocina. Podemos modificar el diagrama de clases de la figura 17.1 y producir el de la figura 17.2.

Conformacion de asociaciones Ahora, crearemos y etiquetaremos asociaciones entre algunas de las clases. Los verbos y las construcciones verbales podrln ayudarnos con las etiquetas, y no debemos lirnitarnos so10 a las de la entrevista. Las etiquetas que sean mls descriptivas podrian sobreentenderse. Una estrategia es la de enfocarnos en algunas de las clases, ver como se asocian entre si, e ir a otro grupo hasta que hayamos desmadejado a1 conjunto de clases. Posteriormente, generaremos las agregaciones y objetos compuestos. A continuation, incorporaremos 10s verbos y construcciones verbales como operaciones de las clases.

Asociaciones con el cliente Empecemos con la clase Cliente. iCulles clases se asocian con ella? La Reservacion seria una de ellas, y Mesero otra. Algunas otras serian Menu, Alimento, MenuDePostre, Postre, Orden, Cuenta, Propina, Abrigo y Sombrero. La figura 17.3 muestra las asociaciones. En este punto podemos tomar algunas decisiones. iEs necesario incluir Sombrero y Abrigo? DespuCs de todo, nos enfocamos en servir un alimento. Luego de debatir, probablemente concluiriamos que tales clases podrian quedarse en el modelo, porque nuestro inter& se centra en todo el proceso de salir a corner. Esto nos har5 generar otra clase, EncargadoDelGuardarropa, dad0 que alguien deber5 guardar el abrigo y el sombrero del cliente. Vamos a etiquetar las asociaciones con algunas frases que las distingan. He aqui algunas de ellas: El Cliente hace una Reservation El Cliente es atendido por un Mesero El Cliente ingiere un Alimento El Cliente ingiere un Postre El Cliente hace una Orden El Cliente elige de un Menu El Cliente elige de un MenuDePostre El Cliente liquida la Cuenta El Cliente deja una Propina El Cliente da a guardar un Abrigo a un EncargadoDelGuardarropa El Cliente da a guardar un Sombrero a un EncargadoDelGuardarropa La figura 17.4 le muestra las asociaciones etiquetadas.

FIGURA17.2 Las clases abstractas dividen a1 diagrama de clases en grupos signijicativos.

n Empleado

0 Alimento

Q Utensilios

00n Sewicio

Restaurante

Abrigo

07 Orden

Sombrero

Cliente

Resewacion

Transaction

Formulano Restaurante

I

I

Menupostre

Menu

Cambio

Mesero

Tarjeta DeCredito

Formulario

ValeDeGuardarropa

I

Restaurante

Area

I

Propina

Voucher

Ahora varnos a enfocarnos en las multiplicidades. Recuerde que una multiplicidad es parte de una asociaci6n: indica cuhtas instancias de la clase B se asocian con una de la clase A. En la mayoria de las frases enumeradas, el Cliente se relaciona con una instancia de otra clase. La segunda frase es distinta de las otras. Tiene una voz pasiva ("es atendido por") en lugar de una voz activa de otras (corno "liquida" o "deja"). Esto sugiere que algo diferente podria ocurrir con tal asociaci6n. Si la invertimos y exarninarnos la asociaci6n desde el punto de vista del mesero ("El Mesero sime a un Cliente"), es evidente que un Mesero puede atender a varios clientes. Las dos frases finales apuntan a un tipo de asociacidn que no habiamos visto antes: El Cliente da a guardar un Abrigo a un EncargadoDelGuardarropa El Cliente da a guardar un Sombrero a un EncargadoDelGuardarropa iC6mo modelan'amos esto? A este tip0 de asociacidn se le conoce como tripartita; esto quiere decir que hay tres clases involucradas. Este tip0 de asociaci6n la modelaria mediante la conexi6n de las clases asociadas con un rombo, y escribiria el nombre de la asociacidn cerca de Cl, como en la figura 17.5. En una asociaci6n tripartita, las multiplicidades indican cuhntas instancias de dos clases esthn involucradas cuando la tercera se mantiene constante. En este ejemplo, un Cliente puede dar a guardar mhs de un Abrigo a un EncargadoDelGuardarropa.

n Abrigo

En la siguiente subsecci6n, verh otra forma de manejar esto.

Es posible contar con rnas de tres clases en una asociacion. En nornbre de la generalizacibn, el UML la trata corno asociaci6n multiple.

La figura 17.6 le muestra todas las asociaciones del Cliente etiquetadas, donde se incluyen las multiplicidades.

Inclusidn de las multiplicidades en las asociaciones de la clase Cliente.

Asociaciones con el Mesero Ahora utilicemos la asociacidn Cliente-Mesero para generar las asociaciones con el Mesero. Una forma de modelar cualquiera de las asociaciones del mesero es tratarlas como tripartitas: El Mesero toma una Orden de un Cliente El Mesero lleva una Orden a un Chef El Mesero siwe un Alimento a un Cliente El Mesero siwe un Postre a un Cliente El Mesero trae un Menu a un Cliente El Mesero trae un MenuDePostre a un Cliente El Mesero trae la Cuenta a un Cliente El Mesero recoge el Efectivo de un Cliente El Mesero recoge la TarjetaDeCreditode un Cliente Esto, sin duda, desordenari a1 mode10 y 10 hari dificil de comprender. Una forma mis eficiente es examinar tales asociaciones, utilizar la menor cantidad de etiquetas y adjuntar las clases de asociacidn adecuadas.

El trabajo de un Mesero es, aparentemente, el de traer y llevar cosas. "Recoger" se sobreentiende como "llevar" y "servir" como "traer". Etiquetaremos esta asociacidn de la clase Mesero como "llevar" y "traer". Adjuntaremos una clase de asociacibn, y en ella indicaremos 10 que se lleva o se trae. Para ello, le daremos un atributo llamado element0 y le asignaremos un tip0 numtrico. Los valores posibles del atributo son 10s diversos elementos que el Mesero podria llevar o traer. La figura 17.7 le muestra 10 anterior una vez puesto en efecto.

L I ~ V ~

1

Mesero

El uso de clases de asociacidn en las asociaciones del Mesero.

I...-

-

Cliente

I I I I

R Elemento

El Mesero tambitn se asocia con un Asistente y un Mozo de piso, como muestra la figura 17.8. FIGURA 17.8 Otras asociaciones con el Mesero.

~sistente.1

Mesero l...'

Llama a

1

l...'

Llama a

1 Mozo DePiso

Asociaciones con el Chef El Chef se asocia con el Asistente, el Mesero y con el Alimento, como en la figura 17.9.

FIGURA17.9

Es notificado por

1

Chef

1 .. .'

I

Asociaciones con el ChQ

Mesero

I I

I

1

R Notificacion

1

Elemento

Asigna

Prepara

l...'

l...'

Alimento

Asistente

Asociaciones con el Mozo de piso El Mozo de piso realiza algunas tareas, como se establece en la figura 17.10. FIGURA 17.10 Asociaciones con el Mozo de piso.

\

Se encarga de

Asociaciones con e B Gerente El Gerente es una clase nueva que hemos derivado a partir del analisis del dominio. Esta clase se asocia con muchas otras hacia las cuales hemos desarrollado las siguientes frases: El Gerente opera el Restaurante El Gerente supervisa a 10s Empleados El Gerente supervisa la Cocina El Gerente se comunica con el Cliente La figura 17.11 modela tales asociaciones.

FIGURA17.11 Asociaciones con el Gerente.

Restaurante Gerente

Opera

1

l...'

Supervisa

1

-

Supervisa

1

l Empleado

Se comunica con

-

Cliente

1

Cocina

Una digresion Algo que podria imaginar es que debiera eliminar 10s sustantivos que son roles en las asociaciones y contar s610 con una clase genCrica, como Empleado. En la asociaci6n, pondria el nombre del rol cerca de la lfnea de vida adecuada de la asociacibn. En algunos contextos (como un sistema de nbminas), ell0 funcionaria bien. En Cste tal vez no. Analice las siguientes asociaciones: El Mesero trae a1 Cliente El Mesero lleva del Cliente El Mesero trae a1 Chef El Mesero lleva del Chef El Mesero llama a1 Mozo de piso El diagrama luciria como en la figura 17.12.

FIGURA17.12 Modelado con la clase Empleado.

Mesero Llama

I

Mesero

l...'

v

I

Lleva del Ernpleado

MozoDePiso 1

:

1.. '

Mesero

lleva de

Trae

v

Como puede advertir, 10s iconos de clase del diagrama se hacen densos y poco claros, y a6n no hemos incluido las clases de asociaci6n. En todo 10 que se relacione con el modelado, deje que le guie la comprensi6n.

Formacion de agregados y objetos compuestos Ya hemos conformado y bautizado clases abstractas y asociaciones, pero hay otra dimensi6n organizacional. El siguiente paso es localizar clases que sean componentes de otras. En este dominio ell0 no deberi ser dificil. Por ejemplo, un Alimento consta de un EntremCs, un PlatoFuerte, una Bebida y un Postre. El EntremCs y el Postre son opcionales. A su vez, 10s componentes se encuentran en un orden especifico que deseamos conservar en nuestro modelo. He aqui algunas otras composiciones: Una Orden consta de una o varias EleccionesDeMenu Un Restaurante consta de una Cocina, una o varias AreasDeServicio, un AreaDeEspera, un Bar y un CuartoDeLavado Un AreaDeServicio consta de una o varias Mesas Un Servicio consta de uno o varios Clientes En cada caso, el componente es miembro exclusivo de un agregado, de mod0 que la figura 17.13 10s modela a todos ellos como objetos compuestos.

I

Objetos compuestos en el dominio Restaurante.

----0..1

Bebida

(precede)

0..1

------

O..l Postre

PlatoFuerte

Entremes

'7

Restaurante

Orden

t 1:.

1

1

Area DeEspera

Area DeSetvicio

Cocina

4 1

1

Bar

-

1:.

1

Cuarto DeLavado

Mesa

rl Cliente

Llenado de las clases Las entrevistas y sesiones consecuentes seran muy fitiles para dar cuerpo a nuestras clases. Tenga en cuenta que a partir de este momento, un modelador de objetos deberti estar en cada sesion y depurara el mode10 a1 mismo tiempo. Podemos comenzar con la depuracion mediante la adicion de algunos atributos y operaciones. Nuestras clases mas importantes parecen ser las de Cliente, Mesero, Chef, Gerente y Asistente. Verifique si hay alguna otra clase importante.

El Cliente LCuiles son 10s atributos obvios para un Cliente? He aqui algunos: nombre horaLlegada orden horaservicio LQut hay con las operaciones? Nuestra lista de verbos nos podria servir de guia (aunque no nos deberi limitar). Algunas operaciones del Cliente son: ingerir() beber() estarFeliz (i bromeaba!) ordenaro pagaro

La figura 17.14 le muestra la clase Cliente. FIGURA 17.14 La clase Cliente.

horaLlegada orden

ordenaro

El Empleado El Mesero, Chef, Gerente y Asistente son todas clases secundarias de la clase abstracta Empleado. Por ello, asignaremos atributos a Empleado y las clases secundarias 10s heredarin. Algunos de ellos son: nombre domicilio numeroSeguroSocia1 aniosExperiencia fechacontratacion salario

Para el asistente, hay cosas que son un poco m6s complejas. Primero, necesitaremos un atsibuto llamado trabajacon dad0 que un Asistente podria ayudar a un Mesero o a un Chef. Este atributo sera de tip0 numkrico. Las operaciones seran especificas para cada clase secundaria. Para el Mesero, tales operaciones parecen ser adecuadas y pueden verse en la figura 17.15: llevar() servir() recoger() llamar() verificarEstadoDeLaOrden() Para el Chef: prepararo cocinar() darPrioridad() crearReceta() Para el Asistente:

Las operaciones del Gerente serian:

a Empleado

FIGURA 17.15

nombre domicilio numeroSeguroSocial aniosExperiencia fechacontratac~on salario

La clase Ernpleado y sus clases secundarias.

Mesero

F&

Gerente

recoger0 verif~carEstado

La Cuenta La Cuenta es, obviamente, una clase importante pues contiene la informaci6n del dinero que cost6 la comida. Sus atributos son: totalAlimentos impuesto total Dado que total es la suma de totalAlimentos e impuesto, es una variable derivada. Nuestro modelo (vea la figura 17.16) 10 refleja. La operacidn de la Cuenta es calcularTotal(totalAlimentos, impuesto). FIGURA 17.16 La clase Cuenta.

impuesto

Detalles generales de 10s modelos Hasta este punto ya ha recopilado bastante informaci6n. He aqui algunas sugerencias para ayudarle a mantenerlo todo organizado.

Diccionario del modelo Cuando conjugue 10s resultados de las entrevistas, procesos del negocio y analisis de dominio, mantenga un diccionario del modelo. ~ s t es e un glosario de terminologia en el modelo. Le ayudari a mantener la consistencia y a evitar la ambigiiedad.

Por ejemplo: en nuestro dominio del restaurante, el tCrmino ''men$' es prominente. Este ttrmino significa una cosa para un restaurantero y otra para un desarrollador de interfaces grificas. "Servidor", el tCrmino propuesto per0 rechazado, podria tener implicaciones similares: mientras el restaurantero podria pensar en un "mesero", un ingeniero de sistemas podria pensar en otra cosa completamente distinta. Si tiene definiciones con las que todos esttn de acuerdo, o si esti al menos consciente de quC palabras podrian causar una gran confusidn, evitari muchos problemas subsecuentes. La mayoria de las herramientas de modelado le permiten generar un diccionario conforme cree el modelo.

Organizacion del diagrama Otra sugerencia tiene que ver con la organizacidn del diagrama. No es recomendable tener todos 10s detalles de su modelo de clases en un enorme diagrama. Necesitari un diagrama principal que muestre todas las conexiones, asociaciones y generalizaciones, per0 seri mejor omitir 10s atrib~itosy operaciones de Cl. Podra enfocarse en determinadas clases si las coloca en diagramas por separado. Normalmente, las herramientas de modelado le permiten organizar sus diagramas mediante una vinculaci6n adecuada entre ellas.

Lecciones aprendidas ~QuC es 10 que hemos aprendido en nuestro anilisis de dominio? La entrevista del proceso del negocio otorga las bases para el anhlisis del dominio Los sustantivos resultantes pueden convertirse en candidatos para clases Hay que eliminar 10s sustantivos que son atributos, y 10s que son sin6nimos de otros sustantivos de la lista, asi como 10s que representen a clases fuera del imbito del dominio No pierda de vista la oportunidad de agregar clases que podrian no haberse mencionado durante la entrevista del proceso del negocio Vilgase de algunos de 10s verbos o construcciones verbales como etiquetas para las asociaciones Agrupe las clases y utilice 10s nombres de 10s agruparnientos como clases abstractas Agrupe clases en agregados u objetos compuestos Cambie el nombre de las clases para mayor legibilidad Algunas asociaciones pueden ser tripartitas (esto es, que involucran a tres clases) Vilgase del sentido comlin para denominar asociaciones y establecer multiplicidades En la siguiente hora nos iremos del entorno conceptual a 10s detalles relacionados con el sistema.

Resumen Esta hora continu6 con el analisis conceptual que inicid en la hora anterior. La entrevista del proceso del negocio da por resultado 10s fundamentos para el anhlisis del dominio. Los sustantivos, verbos y construcciones verbales de la entrevista son 10s candidatos para el diagrama de clases inicial que definen a1 dominio Restaurante. El sentido comdn le indicara cuhles utilizar y cuales eliminar. Es posible que agregue clases conforme haga el anhlisis. El modelador de objetos agregara sustancia a este diagrama mediante la derivacidn de clases abstractas, asociaciones y multiplicidades. La derivacion de agregados U objetos compuestos le ayudarh a organizar a1 modelo. Serfin necesarias otras entrevistas y sesiones para dar cuerpo completamente en el modelo, aunque es posible empezar a agregar atributos y operaciones en este punto.

Preguntas y respuestas P ;C6mo sabrC cu6les clases eliminar de la lista de clases candidatas? R Mediante el sentido comun, elimine 10s nombres de clases redundantes y estC consciente de 10s nombres que sean atributos. Elimine 10s nombres de las clases que estCn fuera del Bmbito del dominio que esth analizando. Recuerde que tambiCn podra agregar clases.

Taller Este taller verifica la muy importante aptitud para el analisis del dominio, requerida para la creacidn y desarrollo de un diagrama de clases. Las respuestas se encuentran en el ApCndice A, "Respuestas a 10s cuestionarios".

Cuestionario 1. iDe quC forma utilizaremos 10s sustantivos obtenidos en la entrevista con un experto? 2. i Y de quC forma utilizaremos 10s verbos y construcciones verbales? 3. ~ Q u Ces una asociaci6n "tripartita"? 4. iC6m0 modelm'a una asociaci6n tripartita?

Ejercicios 1. Revise las asociaciones tripartitas del cliente con el EncargadoDelGuardarropa. Utilice una clase de asociaci6n para modelarlas de forma eficiente.

2. Si ha seguido con atencidn la entrevista y el aniilisis del dominio, tal vez habra pensado en algunas clases que no aparecieron en ninguna de tales instancias. Una de ellas seria el Cajero. Conforme una asociaci6n entre el Mesero y el Cajero. Utilice una clase de asociaci6n en caso de ser necesario. Si puede pensar en otras clases, incorp6relas en el aniilisis del dominio. 3. Nuestro objeto compuesto Restaurante incluye s610 a clases "fisicas": fireas como la Cocina y Bar. Tal vez podria decirme que un restaurante tambiCn incluye a gente. Revise el objeto compuesto Restaurante e incluya a 10s empleados en el diagrama. iAl incluir a 10s empleados se convierte a1 objeto compuesto en un agregado? 4. Ademiis de 10s atributos y operaciones, apuntC en la hora 3, "Uso de la orientaci6n a objetos", que podria representar la responsabilidad de una clase. En la clase Mesero, agregue un panel de responsabilidades y asignele una descripcidn de la responsabilidad propia del mesero. 5. Continlie con el dominio Biblioteca de 10s ejercicios de la hora 16, "Presentaci6n del caso por estudiar", y desarrolle un diagrama de clases.

Recopilacion de las necesidades del sistema Las dos horas anteriores trataron de cuestiones conceptuales respecto a1 dominio. Deriv6 procesos del negocio y gener6 diagramas de clases. Ahora iremos a1 sistema. En esta hora se trataran 10s siguientes temas: C6mo vislumbrar el sistema La sesi6n Desarrollo conjunto de aplicaciones (JAD) C6mo organizar las necesidades del sistema El aprovechamiento de 10s casos de uso Los sefiores LaHudra, Nar y Goniff estan impresionados. Han visto el resultado de su equipo de desarrollo y saben que el proyecto va en la direcci6n corrects. Todos parecen tener una buena comprensi6n del dominio Restaurante, tanto que 10s restauranteros de la Divisi6n de Restaurantes de LNG dicen que 10s diagramas han aclarado su propio concept0 de las operaciones de un restaurante.

Ahora el equipo tendra que trabajar en la parte medular, es decir, en la parte ttcnica para el restaurante del futuro. Ya cuentan con 10s procesos del negocio y 10s diagramas de clases. Ya pueden empezar a codificar jcierto? NO! Ni siquiera est6n cerca de escribir un programa. Antes que nada, tienen que desarrollar una visi6n del sistema. La mayoria de 10s proyectos empiezan con frases como "Generar una base de datos con la informacibn del cliente y hacerla facil de usar para que 10s empleados puedan utilizarla con un minimo de capacitaci6n" o "Crear un entorno de ayuda computarizado que resuelva 10s problemas en menos de un minuto". Aqui, el equipo de desarrollo ha comenzado la misidn de "usar la tecnologia para construir el restaurante del futuro". Tienen que vislumbrar a este restaurante basado en tecnologia para tener una idea de la forma en que el personal del restaurante trabajara en 61. Trabajan en un nivel en el que un equipo l e desarrollo usualmente no llega, y LaHudra, Nar y Goniff confian en ellos. El equipo utilizari el conocimiento del proceso del negocio y el recitn adquirido conocimiento del dominio para ver en qut lugar la tecnologia podria mejorar la experiencia de comer en un restaurante. Escuchemos una reuni6n del equipo. Los integrantes son un analista, un modelador, un restaurantero, un mesero, un chef y un ingeniero de sistemas. Habra un moderador en la reunibn.

Desarrollo de la idea Moderador: "A1 analizar nuestros diagramas de procesos del negocio, pienso que podemos ver varios lugares donde podria ser 6til la tecnologia basada en computadoras. Hart una lista en la pizarra. jQuitn quiere empezar?"

El rnoderador distribuye copias de la figura 18.1, el diagrarna de procesos del negocio para "Servir a un cliente", y la figura 18.2, el de "Preparar un platillo".

Analista: "Si, aparentemente el negocio del restaurante, como casi cualquier otro, depende de la transmisi6n de la informaci6n. Si podemos agilizar tal transmisibn (algo en 10 que la tecnologia se especializa) cumpliremos nuestra meta." Restaurantero: "No me queda muy claro. jQuC quieren decir con 'transmisibn de la informacibn'? Siempre penst que mi negocio se centraba en el movimiento de alimentos."

Ingeniero de sistemas: "Yo le puedo explicar. Cuando el cliente hace una orden, le da informacidn a1 mesero. .. por cierto, recordemos que mesero es alguien que sirve las mesas. Una vez que el mesero tiene la informacibn, se la lleva a1 chef, con ello e s d transmitiendo informacibn." Moderador: "iDbnde m& se transmite informacibn en el diagrama?" Mesero: "Creo que cuando un cliente me pide que le informe cbmo va el avance de su orden y yo le pregunto a1 chef, ello tambiCn puede traducirse como transmisibn de informacidn jno?" Analista: "Asi es." Chef: "Transmisibn, tecnicismos. No se ofendan, per0 yo no me emociono para nada cuando un mesero entra y me pregunta cuanto mis tardark en terminar de preparar un platillo. Tardara 10 que tenga que tardarse y no puedo ser molestado." Moderador: "Bueno, tal vez podriamos hacer algo por reducir su molestia. iVen algunos otros puntos de transmisibn de informacibn?"

En este caso el moderador intenta suavizar las cosas con el chef para que este contin~jeinvolucrado.

Restaurantero: "~QuCtal cuando el mesero hace la sugerencia del dia? i O cuando responde a una pregunta acerca del mend?" Moderador: ''iPor supuesto!" Chef: "En ocasiones yo tambiCn tengo que dar respuestas. Las personas me envian a1 mesero para pedirme alguna receta en particular. A veces se las envio mediante el mesero y, si no hay mucho trabajo, yo mismo voy y hablo con el cliente. A ellos les gush eso." Mesero: "Pues hay cierta informacidn que no me gusta transmitir. Un cliente hace una orden, voy y se la paso a1 chef, y luego de quince minutos, cuando regreso a la cocina por cualquier otra cosa, oigo que ya se acabaron 10s ingredientes para tal orden. Yo tengo que ir con el cliente y sugerirle que ordene alguna otra cosa. Generalmente eso molesta mucho a1 cliente y a m' tambiCn, debido a que reduce mi propina." Analista: "Tal vez podriamos agregar esto a1 proceso del negocio..." Moderador: "Tal vez. Pienso que, si esdn de acuerdo, podriamos tratarlo en otra reunibn."

FIGURA18.1 Un diagrama de procesos del negocio para "Servir a un cliente".

Clients

Leer m""

spltan de mnsn

_I:

Un diagrarna de procesos del negocio para "Preparacidnde platillos ".

El moderador intenta mantener bien enfocada la reuni6n. Observe que el moderador evita utilizar la enojosa construccion "Si, per0...".

Analista: "Si, claro. No seria bueno desviarnos del tema." Moderador: "Vearnos d6nde hemos llegado. De acuerdo con la lista que he hecho, la transmisi6n de la informaci6n se realiza cuando El cliente hace una orden El mesero lleva la comanda a1 chef El cliente pide a1 mesero el grado de avance de su orden El mesero da la sugerencia del dia

El mesero responde a una pregunta de algo en el mend El chef responde a inquietudes respecto a alguna receta."

Es rnuy adecuado que, en la entrevista del proceso del negocio, el rnoderador haga una pausa para resurnir.

Analista: "S6 que no esti en ninguno de nuestros diagramas de negocios, per0 iquC acaso el cliente no tiene preguntas sobre algo en la cuenta? Cuando el mesero le da la respuesta, tambidn se tiene transrnisi6n de informaci6n." Moderador: "Correcto. iA1g0 mis de 10s procesos del negocio?" Ingeniero de sistemas: "Creo que si. jQuC hay de la farnosa coordinacidn entre el mesero y el chef? Es decir, jen quC moment0 saben que debe servirse el plato fuerte una vez que 10s clientes han terminado sus entremeses? TarnbiCn, esto es informaci6n que se transrnite." Analista: "De acuerdo. La informaci6n se transmite de distintas formas en este caso." Restaurantero: "S610 nos dio dos diagramas de procesos del negocio y recuerdo que creamos otro." Moderador: "Asi es. Aqui est6 el de 'Limpieza de una mesa"' (vea la figura 18.3). FIGURA18.3 Un diagrama de procesos del negocio para "Limpieza de una mesa".

Llamada de un mesero

e=) 6 Colocar un nuevo mantel

Poner la mesa

Analista: "Parece que aqui so10 hay un caso de transmision de informaci6n , pero apuesto que es muy importante: El mesero llama a1 mozo de piso para hacerle saber que es hora de limpiar la mesa." Restaurantero: "Esto es muy importante. No puede sentar a un nuevo grupo de personas en la mesa si no esta lista. Si la limpieza no se realiza tan rfipido como sea posible, tendremos muchos clientes hambrientos, y molestos, amontonados en el bar y en el k e a de espera." Modelador: "He ido modificando mis diagramas de clases mientras transcurre la reuni6n. ~ P u e d ohacer una pregunta? ~ S e r i abueno que nuestro sistema (como sea que luzca) nos permitiera evaluar nuestra eficiencia en conjunto para atender a nuestra clientela?" Restaurantero: "iClaro! De esa forma sabriamos donde y c6mo mejorar. LEn quC est6 pensando?" Modelador: "En nuestra clase Cliente hay un atributo horaLlegada y otro horaservicio. Quisiera agregar un atributo derivado que se llame tiempoEspera, que podria ser la diferencia entre horaLlegada y horaservicio. ~ Q u C opinan?" Restaurantero: "Me parece bien. Asi sabremos quC tal estamos en cuestiones de eficiencia." Analista: "Asi es. Tendran muchos datos con 10s que podran jugar, por ejemplo, tiempoEspera como una funcidn de la hora del dia, o como una funci6n de cuhntos meseros estaban laborando en ese moment0 o cosas como esas..." Modelador: "Hay otra posibilidad. i Y si agregamos otro atributo llamado horasalida, y un atributo derivado llamado duracioncomida que seria la diferencia entre horaservicio y horasalida?" Moderador: "Parece ser una buena sugerencia. La agregark. iAlguna otra?" Modelador: "Ya que estamos con 10s atributos de tiempo, iquC tal si agregamos algunos atributos de tiempo a las clases Mesero y Chef que indiquen a1 gerente el tiempo que se tardan en realizar el trabajo?" Restaurantero: "Huy, no.. . La idea de supervisar el rendimiento de 10s empleados no es muy agradable para ellos y para mi tampoco. No porque sean perezosos (no 10 son), sin0 porque no es agradable sentirse acosado por una especie de capataz. Es mejor que todos se sientan a gusto en el trabajo; de esta manera, el restaurante sera mejor y 10s clientes tambiCn se sentiran m b a gusto."

Chef: "Si, estoy de acuerdo. Como 10 dije, cuando se prepara un platillo se tardara 10 que tenga que tardarse. No quiero tener un manojo de comandas y tener un capataz que me diga que tengo que tardarme cuatro minutos y medio menos en preparar una trucha a la almandina." Mesero: "Y yo no quiero oir que me he tardado mucho en llevar el menci de postres cuando 10s clientes hayan terminado con sus alimentos. Hay muchas cosas involucradas." Modelador: "Bien, bien, idea descartada. De hecho, ya que 10 mencionan, creo que debo quitar 'supervisar' corno operaci6n de la clase Gerente. Entretanto, he aqui la forma en que luce la clase Cliente ahora." (Vea la figura 18.4.) FIGURA18.4 La clase Cliente horaLlegada orden horase~icio ItiernpoEspera horasalida IduracionComida

actualizada.

ordenar()

Las ideas del rnodelador rnuestran que se encuentra rnodificando constanternente 10s diagramas de clases. El debate entre el rnodelador, el restaurantero y el rnesero dejan entrever un punto crucial: es necesario que las personas del negocio participen en el desarrollo del sisterna. Sin las opiniones tanto del restaurantero corno del rnesero, el proyecto de desarrollo podria haber gastado tiernpo y dinero en instaurar algunas caracteristicas para la supervision del rendirniento que no s e ~ i r i a na posteriori. Los ernpleados podrian haber reaccionado de rnanera negativa, lo que causaria repercusiones en el sisterna y, eventualrnente, en el restaurante.

Moderador: "Por 10 que he escuchado, parece que podemos distinguir dos tipos de agilidad. Uno de ellos involucra la velocidad con que se transmite la informaci6n, y la otra a la rapidez con que cada empleado realiza una tarea. El sentir del grupo deja entrever que la segunda es una molestia, pero la primera no. iEstoy en 10 correcto?" (Todos asienten). Analista: "Bien, ya que estamos de acuerdo en ello, ipodriamos ver algunas otras ideas respecto a 10 que el sistema hm'a especificamente?" Moderador: "Claro. ~Algunaidea?"

Mesero: "Cuando transmit0 toda esta informacion, camino mucho en el transcurso de una tarde. En ocasiones tengo que trabajar en un 6rea que esti lejos de la cocina. El caminar tanto se lleva tiempo -sin contar las suelas de mis zapatos-." Analista: "Bien, pues parece que tendremos que hacer algo para eliminar, o a1 menos reducir, el tiempo muerto. Con ello podriamos agilizar la transmisi6n de la informacion." Moderador: "iTiempo muerto?" Analista: "Si. Nuestro sistema debe evitar que 10s meseros caminen de m&. Es obvio que tendran que ir a la cocina para llevar la orden a 10s clientes, per0 i y quC tal si logramos que sea a 10 linico que vayan a la cocina? i Y suponga que pudieran ir a ella justo a tiempo para traer la orden?" Ingeniero de sistemas: "Pues creo que ya nos estamos concentrando en algo importante. Se me ocurre que podriamos establecer una pequeiia red que conecte a 10s meseros con la cocina, incluso con 10s mozos de piso. Asi la informacidn se transmitiria con mucha rapidez." Analista: "No quisiera sonar demasiado analitico aqui pero.. . iUna pequeiia red? Tendran que brincar cables para llegar a las terminales. En lugar de canlinar a la cocina, tendrh que buscar una computadora. A mi me parece que es como matar moscas a cMonazos. ~QuCnos ahorran'a?" Ingeniero de sistemas: "Tal vez nada, como 10 has descrito. Incluso hasta el servicio podria empeorar. Pero asi no era 10 que yo pensaba." Analista: "iEntonces?" Ingeniero de sistemas: "Bueno. Suponga que cada mesero y mozo de piso llevan consigo una terminal. Una pequeiia, del tamaiio de la palma de su mano. Y tambiCn supon que no usamos cables. Tendriamos una terminal de escritorio en la cocina y otra en la oficina del gerente." Analista: "Ah, ya veo.. . El sistema del que hablas podria resolver muchas cosas. Por ejemplo, si el cliente hace sus Qdenes, el mesero podria marcarlas en su computadora de man0 y se irian a una terminal en la cocina. El10 eliminm'a el paso, y 10s pasos, de caminar del 5rea de servicio a la cocina."

tal si el cliente casi ha acabado sus entremeses y se 10 indico a Mesero: "Me gusta. ~ Q u C la cocina apretando algo en la computadora que dicen? El10 me evitari el tener que ir y decirle a1 chef que termine de preparar el plato principal." Chef: "Y asi verC el mensaje en la cocina. De hecho, todos mis asistentes podrian ver el mensaje a1 mismo tiempo, y podriamos tener 10s mensajes en una, dos o tres pantallas grandes. No tendrC que ver cud asistente estaba cocinando quC platillo ni decirles quC tanto deberian de haber avanzado. Ellos podrian tomar tal responsabilidad por si mismos."

Ingeniero de sistemas: "Y cuando terminen la orden, podrian enviar un mensaje a1 mesero para hacCrselo saber. No tendri que estar regresando a la cocina para verificar." Mesero: "Huy, pues suena muy bien. Incluso podria enviarle una seiial a un mozo de piso para que limpie una mesa. No tendr6 que buscar a uno. El10 podria agilizar mucho las cosas." Restaurantero: "iC6m0 podrian ustedes hacer esto?" Ingeniero de sistemas: "No se preocupe de ell0 por el momento." Moderador: "Bueno, entonces nuestro sistema sera una red de Area local inalimbrica con computadoras palmtop para 10s meseros y 10s mozos de piso, y con computadoras de escritorio en la cocina y en la oficina del gerente. Pero nos estamos olvidando de algo." Analista: "iDe quC?" Moderador: "De un nombre para el sistema." Chef: "~QuCtal 'EL EXPERT0 CHEF'?" Moderador: "iY tiene alglin significado en particular? iForman alguna sigla?" Chef: "No. S610 me gust6." Analista: "~QuCtal Red Interactiva Inalimbrica para Restaurantes? Podriamos llamarla RIIR." Moderador: "Bueno.. . No 10 sC." Ingeniero de sistemas: "Bueno, tal vez podria ser Red Inalimbrica para la Comunicaci6n Organizada. iMiren! Y ell0 deja las siglas RICO, que seria muy adecuado para el servicio en un restaurante." Chef: "Me gusta." Analista: "A mi tambiCn. El nombre deja entrever que el sistema nos enriqueceria a nosotros, y tiene un significado muy directo." Moderador: "Entonces, ~Estamosde acuerdo con RICO? Bien, pienso que hemos terminado por el momento."

Preparacion para la recopilacion de las necesidades El equipo pasa 10s resultados de su reunidn a 10s funcionarios corporativos. LaHudra no puede creer en su buena fortuna a1 explorar una nueva firea. Nar esti completamente abmmado. Goniff ve visiones de signos monetarios que bailan ante sus ojos. Los tres le dicen a1 equipo que prosiga.

Ahora que el equipo tiene una idea del sistema, ipodran iniciar su trabajo 10s programadores y 10s ingenieros de sistemas? Por supuesto que no. El equipo deberi adaptar el sistema RICO a las necesidades de 10s usuarios, no a la tecnologia. Aunque ya cuentan con algunas ideas de la reuni6n del equipo, aiin no han expuesto el concepto de RICO a un grupo de empleados y gerentes para obtener informaci6n e ideas desde su punto de vista como usuarios. La siguiente accidn GRAPPLE hace exactamente eso. En una sesi6n de Desarrollo conjunto de aplicaciones (JAD), el equipo obtendra y documentari las necesidades del sistema. Con esto, podrdn hacer algunas estimaciones de tiempo y dinero. La sesidn JAD se realiza en una sala de conferencias. Encabezada por un moderador, se denomina sesi6n "conjunta" dad0 que incluira a miembros del equipo de desarrollo y a usuarios potenciales del sistema, asi como a expertos del dominio. Los miembros del equipo de desarrollo en esta reuni6n son dos analistas que toman notas, un modelador, dos programadores y un ingeniero de sistemas. Los usuarios potenciales son tres meseros, dos chefs, dos restauranteros y dos mozos de piso. El objetivo de esta reunion es producir un diagrama de paquetes que muestre 10s principales segmentos de funcionalidad del sistema. Cada paquete representara un segmento y contendra casos de uso que detallarin de quC se trata cada segmento de funcionalidad. Vamos a la sesi6n.

La sesion JAD de necesidades Moderador: "Para empezar, quiero agradecerles a todos haber venido a nuestra sesi6n. Estas sesiones nos pueden llevar algo de tiempo, pero tambiCn pueden ser muy divertidas. Lo que intentamos hacer es conocer las necesidades para un sistema llamado RICO: Red Inalambrica para la Comunicaci6n Organizada." "El concepto de RICO es muy directo. La forma en que 10 imaginamos es que 10s meseros tendrdn en su poder una computadora palmtop y la utilizaran para comunicarse con la cocina y sus mozos de piso. Estos tiltimos tambiCn tendran computadoras de este tip0 y las utilizaran para comunicarse. La cocina tendri una terminal de escritorio y una o varias pantallas. El gerente tambitn tendra una en su oficina. He aqui una figura de 10 que estoy hablando." (Vea la figura 18.5.) "Esperamos instalar a RICO en todos 10s restaurantes LNG, y queremos ayudarles a hacer su trabajo. Para lograrlo, necesitamos que nos digan quC es 10 que desean que haga el sistema. Es decir, si el sistema ya estuviera en funcionamiento iquC quem'an que hiciera?"

FIGURA18.5 El sistema RICO.

Cornputadora palrntop

\ 'Dispositivo" Red

l3 PC del Gerente

"Haremos esta pregunta una y otra vez. A1 final de la sesion, tendremos un conjunto organizado de necesidades con las que todos estaremos de acuerdo. Piensen que es su carta a Santa Claus. Nos basaremos en esa carta para crear un proyecto que 10s programadores utilizaran para generar el sistema. Hay algo que quisiera que tuvieran en cuenta: necesitamos la comprensi6n e ideas de cada uno de ustedes, no importa cual sea el nombre de su puesto." Analistal: "iPodriamos empezar por imaginarnos cuiles serian 10s principales segmentos de funcionalidad?" Moderador: "Si. iEstan de acuerdo 10s miembros del grupo?" Restaurantero2: "Si, mire.. . Yo no estuve en 10s debates anteriores, pero creo que esto es una buena idea. iPodriamos organizarlo de acuerdo a, por decir, las heas del restaurante? Es decir, las keas de servicio tienen ciertas necesidades, la cocina otras, el h e a de espera otras..." Moderador: "Es una posibilidad." Analista2: "Hum.. . A1 ver 10s diagramas de procesos del negocio yo ya veo una organizacibn." Programador l : "iPerd6n?" Analista2: "Por tarea. El chef tiene que realizar ciertas cosas, el mesero otras, y asi." Moderador: "Suena bien. iEstmiamos de acuerdo en organizarlo por tarea?" (Todos asienten).

Moderador: "iBien! En 10s diagramas de procesos del negocio y de clases, las tareas que tenemos son Mesero, Chef, Mozo de piso, Asistente y Gerente." Restaurantero2: cantinero."

NO olvidaron algunas? No e s t h el encargado del guardanopa y el

Restauranterol: "iVaya! iC6m0 se me pudieron olvidar?" Moderador: "Los agregark a nuestra lista, y utilizark 10s simbolos de paquetes del UML para estar a1 tanto." (Vea la figura 18.6.)

I Los paquetes de fun-

Funcionalidadde RICO

cionalidad de RICO.

F 1 Encargado del guardarropa

Modelador: "Ya estoy en ello. AgreguC informaci6n a nuestros diagramas de clases. Ya estaba la clase EncargadoDelGuardarropa. Lo que agreguC fue la clase Cantinero." Restaurantero2: "Me pregunto quC hace en su computadora laptop. iMe podria mostrar sus, hum, 'clases'?" Modelador: "Si, claro. Aqui esth." (Vea la figura 18.7.)

FIGURA18.7 Las clases EncargadoDelGuardar ropa y Cantinero.

a EncargadoDel Guardarro a

guardarAbrigo0 guardarSombrero() imprimirvale

Restaurantero2: "Muy interesante. Espero que en alghn descanso se dC tiempo de explicarme lo que significa." Moderador: "Ahora que contamos con las piezas principales, jalguien prefiere empezar con alguna tarea en particular?" Mesero l : "jQuC tal con la del Mesero?" Moderador: "Me parece adecuado. Bien, iquC tip0 de funcionalidad quisiera ver en este paquete? Recuerden, miembros del grupo, que aunque tratemos una tarea que no sea la de ustedes, pueden participar. Todas las opiniones son bienvenidas." Mesero2: "Quisiera poder tomar una orden en mi pequefia computadora y enviarla a la cocina." Moderador: "Muy bien. jQuC m6s?" Meserol: "Quisiera saber el grado de avance de una orden." Chef2 ''iPued0 indicarle a un mesero cuando ya estC lista su orden?" Moderador: "Si y si. Estos conceptos, como ven, 10s estoy escribiendo dentro de elipses rotuladas. Las IlamarC 'casos de uso'. Les pediremos a algunos de ustedes que regresen y que nos ayuden a analizar tales casos de uso, pero ell0 sera en otra reuni6n."

El resultado La sesidn JAD continud por el resto del dia. Cuando 10s participantes terrninaron, ya contaban con un conjunto de necesidades que aparecieron como casos de uso organizados en 10s paquetes. Para el paquete mesero, 10s casos fueron: Tomar una orden Transmitir la orden a la cocina Cambiar una orden Recibir una notificacidn de la cocina

Llevar un control del progreso de la orden Notificar a1 chef el progreso de 10s clientes en sus alimentos Totalizar una cuenta Imprimir una cuenta Llamar a un asistente Llamar a un mozo de piso Tomar una orden de bebida Transmitir una orden de bebida a1 bar Obtener un acuse de recibo Recibir una notificaci6n del bar Para el paquete chef, 10s casos de uso fueron: Almacenar una receta Recuperar una receta Notificar a1 mesero Recibir una peticidn del mesero Dar acuse de recibo a una peticidn del mesero Indicar el period0 de preparaci6n Asignar una orden Los casos de uso del mozo de piso fueron: Recibir una peticidn del mesero Dar acuse de recibo a una peticidn Indicar que una mesa ha sido limpiada Los casos de uso para el asistente fueron: Recibir una peticidn del mesero Recibir una peticidn del chef Dar acuse de recibo de una peticidn Notificar que la peticidn se ha completado Para el cantinero: Capturar una receta de bebida Obtener la receta de una bebida Recibir una notificacidn del mesero

Recibir una peticion del mesero Dar acuse de recibo de una petici6n Notificar que la peticion se ha completado Y para el encargado del guardarropa:

Imprimir un vale de abrigo Imprimir un vale de sombrero La figura 18.8 muestra la forma en que todo 10 anterior luce en el UML. FIGURA18.8 El diagrama de paquetes de funcionalidad.

El modelador hari el desarrollo ulterior de 10s diagramas de clases mediante la adici6n de dos clases y asociaciones como en la figura 18.9.

FIGURA18.9 La infomacidn de las clases reciin agregada.

El document0 de diseiio que entregari el equipo a su cliente crece a pasos agigantados. Ahora incluye procesos del negocio, diagramas de clases y un conjunto de paquetes de funcionalidad. ~ A h o r aempezari a codificar el equipo? En absoluto. En la siguiente hora empezarin a analizar el contenido de 10s paquetes.

Resumen En el context0 de la reunidn, el equipo de desarrollo ha generado una visidn del sistema de cdmputo para el restaurante del futuro. Los miembros del equipo decidieron que la agilizacidn en la transmisidn de la informacidn es la clave para el Cxito del sistema, y traen a colacidn tipos de tecnologia para lograrlo. En una sesi6n JAD, el equipo de desanollo se reline con usuarios potenciales y expertos de dominio para obtener 10s requerimientos del sistema. El resultado es un diagrama de paquetes en donde cada paquete representa una seccidn principal de funcionalidad. Los casos de uso dentro de un paquete se basan en tal funcionalidad.

Preguntas y respuestas P ;Podria ser que algunos de 10s participantes de la sesi6n JAD sean 10s mismos que participaron en la reuni6n anterior en equipo? R Si, y, de hecho, es recomendable. Tales personas podrian recordar detalles vitales que podrian no ser muy claros en las minutas. P Vi que 10s seiiores LaHudra, Nar y Goniff no participan en tales reuniones. ~Podriaalguien de tal nivel tomar parte en las reuniones y las sesiones JAD? R Estos en particular no. Sin embargo, en algunas empresas, 10s altos directivos podrian participar de manera activa a1 menos en parte de una sesidn. Es dificil que un alto directivo tome parte en toda una sesidn JAD. P iSiempre se dar6 el caso de que se tenga que organizar a1 sistema por tareas, como 10 hicimos en este dominio? R No, no siempre. Aqui se hizo asi porque fue conveniente para este dominio. De hecho, podriamos buscar una forma alternativa de hacerlo si nos concentramos en ello. Otros tipos de sistemas podrian requerir un trato distinto. Por ejemplo: un Area de asistencia podria tener Recepcidn de llamadas, Resolucidn de problemas y Regreso de llamadas como paquetes. Nuevamente, dentro de cada paquete, tendra un conjunto de casos de uso.

Verifique su conocimiento en la recopilacidn de necesidades y localice las respuestas en el ApCndice A, "Respuestas a 10s cuestionarios".

Cuestionario 1. iC6mo hemos representado las necesidades del sistema? 2. iUna vez que se hace el analisis del dominio ya finaliza el modelado de clases?

3. ~ Q u Ces el "tiempo muerto"?

Ejercicio Continde con el dominio de la Biblioteca. iCuiles son 10s principales paquetes de funcionalidad? iCuhles son 10s casos de uso que 10s componen?

Desarrollo de 10s casos de uso Ahora que ha visto 10 que esta involucrado en la recopilaci6n de necesidades, veremos el analisis de tales necesidades y las llevaremos a cab0 en un sistema. En esta hora se trataran 10s siguientes temas: Cuidado y provisi6n de casos de uso La especificacidn de descripciones, condiciones previas y resultantes. La especificaci6n de pasos La diagramaci6n de 10s casos de uso Los casos de uso del diagrama de paquetes de la hora 18, "Recopilaci6n de las necesidades del sistema", nos dio una buena idea de 10 que el sistema tendra que hacer. El equipo tendri que llevar a cab0 cada uno de ellos. Poco a poco han pasado de comprender el dominio a comprender el sistema. Los casos de uso establecieron el puente. Si cree que el proyecto del desarrollo del sistema se orienta a 10s casos de uso, ya habra comprendido todo el proceso.

Observe que en ninglin moment0 de la sesidn JAD el equipo de desarrollo habl6 de la forma en que el sistema realizaria todas las actividades indicadas en 10s diversos casos de uso. La idea fue la de enumerar todos 10s casos de uso posibles. Conforme se realicen 10s casos de uso en esta hora, verh la forma en que 10s componentes del sistema RICO empezariin a materializarse. En este punto del desarrollo, el sistema empieza a ser el centro de atencibn. Varnos a ponernos en 10s zapatos del equipo de desarrollo y verernos algunos de 10s casos de uso obtenidos.

Cuidado y provision de 10s casos de uso Para analizar a 10s casos de uso, tendremos que realizar otra sesidn JAD. El debate en esta sesi6n se orienta a derivar un anhlisis para cada caso de uso. A mod0 de advertencia: la sesi6n JAD de 10s casos de uso es, por 10 general, la mhs compleja, dad0 que pide a 10s participantes (usuarios potenciales del sistema terminado) que se conviertan en analistas. En su propio nicho, cada uno es un experto del dorninio, y tendrh que profundizar en su experiencia. Por lo general, no esthn acostumbrados a expresar o analizar su conocimiento. De hecho, tambiCn es probable que tampoco hayan formado parte de algun proyecto de diseiio, y que no se sientan muy a gusto a1 intentar especificar lo que un sistema deberia hacer para ayudarles en su trabajo. Para reducir estas presiones, es mejor organizar la sesi6n JAD para que el equipo trate con un grupo a la vez; por ejemplo: s610 10s rneseros. De esa forma, 10s dernhs no estarfin ociosos mientras 10s meseros analizan sus casos de uso. Quienes conocen las generalidades del dominio, 10s restauranteros, podrian dar una man0 en todos 10s grupos. Una selecci6n de usuarios sen'a adecuada cuando se trate el terna del paquete del Cliente. Son rnuchos 10s casos de uso, y para no extendernos mucho en esta hora, nos enfocarernos en 10s primeros nueve de ellos, propios del paquete Mesero. Luego de que vea c6mo se harhn tales anhlisis, podrh hacer el resto de 10s casos de uso de 10s Meseros, asi como 10s de 10s demhs paquetes.

El analisis de 10s casos de uso Por 10 que se mencion6 anteriormente (hora 7, "Diagramas de casos de uso"), recuerde que, cada caso de uso es una colecci6n de situaciones, y cada una de Cstas es una secuencia de pasos. Para cada escenario en cada caso de uso, queremos mostrar: Una breve descripcidn del escenario Conjeturas del escenario

El actor que inicia el caso de uso Condiciones previas para el caso de uso Pasos relacionados con el sistema en el escenario Condiciones resultantes una vez terminado el escenario El actor beneficiado del caso de uso

En su analisis tarnbien podra incluir cualquier condicion excepcional o alternativas. No obstante, 10s presentes escenarios se han rnantenido sirnples.

Ninguna forma especifica es "correctan para establecer un analisis de casos de uso. Los elementos que he listado establecen, por 10 general, un panorama del caso de uso.

En su document0 de diseiio (el que le da a su cliente y prograrnadores), cada uno de estos analisis de casos de uso deberan estar en paginas por separado. Posiblernente quiera incluir un diagrarna del caso de uso, con todo y actores, en esta pagina.

Los pasos, en el escenario, que estan relacionados con el sistema son muy importantes. Mostraran la forma en que se supone que funcionara el sistema. Cuando 10s participantes de la sesi6n JAD nos digan 10s pasos, de hecho nos estaran diciendo c6mo va a lucir el sistema. DespuCs de esta sesi6n JAD, deberiamos tener una firme idea de 10s componentes del sistema. TambiCn es importante hacer conjeturas. En la lista de conjeturas, podrh indicar algunas consideraciones de diseiio, como 10 vera posteriormente. Esto era 10 que quise decir cuando dije que el proyecto seria "orientado a casos de uso". Los casos de uso crearan, a fin de cuentas, la ruta de acceso a1 sistema.

El paquete Mesero La clase Mesero se distingue por ser la de mayor actividad, 10 cual no deberia sorprendemos, dad0 que el mesero interactda prhcticamente con las demhs clases.

Los casos de uso. del Mesero son: Tomar una orden Transrnitir la orden a la cocina m

m

Cambiar una orden Recibir una notificaci6n de la cocina Sondear el progreso de la orden Notificar a1 chef del progreso de 10s clientes en sus alimentos Totalizar una cuenta Imprimir una cuenta Llamar a un asistente Llamar a un mozo de piso Tomar una orden de bebida Transmitir una orden de bebida a1 bar Obtener un acuse de recibo Recibir una notificacidn del k e a del bar

Tomar una orden Empecemos con "Tomar una orden". Vamos a preguntarle a 10s meseros experimentados, para que nos den una descripci6n, conjeturas, condiciones previas, pasos y condiciones resultantes. El paquete y subpaquete ya indica a1 actor que inicia (Mesero) y a1 beneficiado (Cliente). Una buena descripci6n en una sola frase podria ser: "El mesero captura la orden del cliente en la palmtop y la transmite a la cocina." Se asume que un cliente desea un platillo, que ha leido el menu y que ya hizo su eleccibn. TambiCn se puede asumir que la palmtop del mesero cuenta con una interfaz para capturar drdenes. Las condiciones previas son que un cliente se haya sentado y haya leido el menli. La condici6n resultante es que tal pedido se haya capturado en RICO. Los pasos en el caso de uso son:

1. 2. 3. 4.

En la palmtop, el Mesero activa la interfaz para capturar una orden. Aparece la interfaz para capturar Qdenes. El Mesero registra la seleccidn del Cliente hecha del menli en RICO. El sistema transmite la orden a la PC de la cocina.

Aunque hemos asurnido que ya hay una interfaz para registrar drdenes, aiin no hemos especificado cdrno luciria o cdmo sena el proceso fisico de registrar la orden. Todavia no sabemos cdmo luciri la interfaz de la PC de la cocina, ni hernos dicho nada de 10s detalles ttcnicos de transrnitir una orden. El punto es que, conforme ponemos de manifiesto nuestras conjeturas en cuanto a1 diseiio, empezamos a tener una idea de 10 que se supone que debe hacer el sistema y empezamos a dar forma a nuestras ideas para ponerlo en prictica. Los pasos en 10s casos de uso nos fuerzan a asumir la idea acerca de 10s componentes del sistema. Recuerde que 10s casos de uso pretenden rnostrar como se ve el sistema para un usuario.

Transmitir la orden a la cocina iListo para otro? ~ s t sera e incluido en (esto es, "usado por") a1 rnenos dos casos de uso: la anterior y "Cambiar una orden". La descripcidn es: "Tomar una orden que ha sido registrada en la palrntop, colocarla en la red inalimbrica y enviarla a la PC de la cocina". Se asurne que ya tenemos medios para cornunicar la orden (mediante una red inalirnbrica) y, nuevamente, que contamos con una interfaz para registrar una orden. iTenemos que repetir esta conjetura? Si. Cada caso de uso aparecera eventualmente en una phgina por separado en el document0 de diseiio, 10 que serviri como una referencia del sistema. Para mayor claridad, las conjeturas deberian aparecer en cada caso de uso, aun si tenemos que repetirlas en cada uno de ellos. La condicidn previa es una orden registrada en una palrntop. La condicidn resultante es que la orden llegue a la cocina. El actor beneficiado es el Cliente. Los pasos son:

1. Hacer clic en un bot6n en la interfaz para el registro de drdenes indica "Enviar a la cocina". 2. RICO transrnitiri la orden mediante la red inalimbrica. 3. La orden llega a la cocina. 4. La interfaz del usuario para registrar las 6rdenes en la palmtop indica que la orden ha llegado a la cocina. Claro esti que tendremos que modificar nuestro diagrama de casos de uso para el subpaquete Cliente. Tiene que mostrar la dependencia aincluir,, entre este caso de uso y "Tomar una orden", y entre este caso de uso y "Cambiar una orden". La figura 19.1 muestra 10s diagramas actualizados del caso de uso para el paquete Mesero.

I Los diagramas actualizados de casos de uso para el paquete Mesero.

Mesero

a 1a coclna

Cambiar una orden Dentro de este contexto, vayamos a "Cambiar una orden". La descripci6n es "Modificar una orden ya registrada en R I C O . Se asume que ya se ha registrado y enviado a la cocina una orden y que, subsecuentemente, el cliente desea cambiarla. TambiCn asumiremos que RICO cuenta con una base de datos de 6rdenes que muestra a1 mesero quiCn ha capturado cada orden y la mesa de donde provino, que el mesero podr6 acceder a tal base de datos en la palmtop, que RICO puede transmitir y recibir de la palmtop a la PC de la cocina, y que la palmtop tiene una interfaz de usuario capaz de cambiar una orden. La condici6n previa es la orden registrada con anterioridad. La condici6n resultante es que la orden modificada haya llegado a la cocina. El actor beneficiado es el Cliente. Los pasos en este caso de uso son: 1. En la palmtop, el mesero activa la interfaz del usuario para cambiar una orden. 2. La interfaz del usuario trae una lista de drdenes realizadas y enviadas a la cocina por el mesero. 3. El mesero selecciona la orden por cambiar.

4. El mesero registra la modificaci6n a la orden. 5. El sistema transmite la orden a la PC de la cocina. El paso 5 incluye a1 caso de uso anterior "Transmitir la orden a la cocina".

Sondeo del progreso de la orden Corno podrh recordar, 10s debates anteriores respecto a1 restaurante del futuro incluyeron la posibilidad de descubrir en quC rnomento la orden de un cliente saldria de la cocina. Este caso de uso hace exactarnente eso. Si se instaura en el sistema se facilitarh enormernente el trabajo del rnesero. La descripci6n es: "Sondear el progreso (el tiernpo para cornpletar) de una orden que ya se haya registrado en RICO". Se asume que ya se ha realizado, registrado y enviado una orden a la cocina, y que el cliente desea saber c u h t o rn6s esperarh para que llegue su platillo. Repetirnos dos conjeturas de diseiio anteriores: una base de datos de pedidos y la facultad de transmitir mensajes entre la palrntop y la PC de la cocina. Tarnbikn asurnimos una interfaz del usuario en la palmtop para el sondeo de las drdenes y otra en la PC de la cocina con el rnisrno prop6sito. La condici6n previa es la orden registrada con anterioridad. La condici6n resultante es que el estado de la orden ha llegado a la palrntop del rnesero. El actor beneficiado es el Cliente. Los pasos son: 1. El rnesero activa la interfaz en la palmtop para sondear una orden registrada. 2. La interfaz le rnuestra a1 mesero una lista de las 6rdenes que tiene registradas en la cocina. 3. El rnesero elige la orden que desea sondear.

4. 5. 6. 7. 8.

El sistema transrnite el rnensaje de sondeo a la PC de la cocina. La PC de la cocina recibe el rnensaje. El chef selecciona la orden de la cual se quiere conocer su avance. El chef teclea un tiernpo estirnado para cornpletar la orden. El sistema transmite el tiernpo estirnado a la palrntop del mesero.

Notificar al chef del progreso de 10s clientes en sus alimentos A partir de este caso de uso, utilizark subtitulos para indicar 10s aspectos del anhlisis del caso de uso y viiietas para establecer frases para cada subtitulo con dos excepciones: Seguirk numerando 10s pasos y no utilizark viiietas para la descripcibn.

Description Mediante la red, el mesero le indica a1 chef que un cliente ya casi ha finalizado con su entremks.

Conjeturas El mesero se encuentra en el Area de semicio del cliente El mesero puede medir el progreso del cliente El sistema cuenta con una interfaz para el estado del cliente El sistema transmite mensajes de la palmtop a la PC de la cocina y viceversa.

Condiciones previas El cliente ha finalizado de manera parcial el entremts

Condiciones resultantes El chef ha iniciado 10s pasos finales para completar el plato principal

Pasos 1. 2. 3. 4.

En la palmtop, el mesero activa la interfaz para el estado del cliente. La interfaz de usuario trae una lista de las mesas en el hea de semicio del mesero. El mesero elige la mesa indicada. El mesero envia un mensaje de "ya casi termin6 con el entremts" a la PC de la cocina. 5. La PC de la cocina recibe el mensaje. 6. El mesero obtiene un acuse de recibo de la PC de la cocina.

Este liltimo pas0 utiliza el caso de uso "Acuse de recibo", que se encuentra en el paquete Mesero. La figura 19.2 le muestra un diagrama de este caso de uso. FIGURA19.2 Diagrama de caso de uso para "Notificar a1 chef del progreso de 10s clientes en sus alimentos ".

K-

Mesero

'Incluir'

Actor benef iciado Cliente

Totalizar una cuenta Descripcion Sumar 10s elementos en la orden.

Conjeturas Existe una base de datos de pedidos accesibles mediante la palmtop Cada element0 de la orden se relaciona con su precio

Condiciones previas El servicio ya ha terminado con sus alimentos

Condiciones resultantes Se totaliza la cuenta

Pasos 1. El mesero trae una lista de 6rdenes activas en la palmtop. 2. El mesero elige la orden adecuada. 3. El mesero presiona un bot6n en la palmtop para totalizar la cuenta. 4. El sistema calcula el total de 10s precios en la cuenta.

Actor benef iciado Cliente

lmprimir una Cuenta Aunque podria parecer trivial, es una parte importante de la transacci6n.

Descripcion Imprimir la cuenta totalizada.

Conjeturas Una impresora conectada a la red inalhmbrica en el k e a de servicio

Condiciones previas Una cuenta totalizada

Condiciones resultantes Una cuenta impresa

Pasos 1. El mesero presiona un bot6n para imprirnir la cuenta. 2. La impresora conectada a la red en el Area de semicio imprime la cuenta.

3. El mesero presiona un bot6n en la palmtop para quitar esta orden de la lista de 6rdenes activas.

Actor beneficiado Cliente

Llamar a un Asistente Description Solicitar a un asistente que limpie la mesa para el siguiente cliente.

Conjeturas El sistema permite una comunicaci6n inalhmbrica entre dos empleados en movimiento El sistema cuenta con una interfaz para enviar un mensaje a un asistente

Condiciones previas Una mesa vacia tendrh que ser limpiada y preparada

Condiciones resultantes El asistente llega a la mesa para limpiarla y prepararla

Pasos 1. El mesero activa la interfaz para enviar un mensaje a un asistente.

2. El mesero obtiene un acuse de recibo del asistente. Como en el caso de uso "Notificar a1 chef del progreso de 10s clientes en sus alimentos", el dltimo pas0 utiliza el caso de uso "Acuse de recibo".

Actor beneficiado Asistente

En el lad0 del software, es obvio que son necesarias varias interfaces de usuario. RICO necesitarh interfaces del usuario basadas en palmtops para registrar brdenes, cambiarlas, sondearlas, dar el estado del cliente y enviar mensajes para un asistente. Como buena medida, algo como una interfaz tipo "phgina principal" serh necesario para tener organizadas las demhs interfaces. RICO tambiCn necesitarh una interfaz del usuario en la PC de la cocina para permitir a1 chef verificar el avance de una orden. TambiCn parece que necesitaremos una base de datos que contenga a todos 10s pedidos. Cada registro contendrh la mesa, el pedido, la hora en que se realizb, el mesero, si el pedido esth activo, y cosas asi. Del lad0 del hardware, necesitaremos una red inalhmbrica, palmtops para 10s empleados en movimiento (meseros, asistentes y mozos de piso) y una PC de escritorio en la cocina, asi como otra en la recepci6n. Necesitaremos una impresora conectada a la red en cada Area de servicio. Probablemente, tambiCn necesitaremos una palmtop y una impresora para el encargado del guardarropa. Ya esta tomando forma un mejor document0 de diseiio. En la hora siguiente, profundizarh alin mhs en 10s casos de uso.

Resumen No basta con listar todos 10s casos de uso. Un equipo de desarrollo deberh comprender cada uno detalladamente para empezar a comprender el sistema. En esta hora vimos detalladamente el anhlisis de cada parte de un caso de uso. Un anhlisis de casos de uso involucra la especificacibn de una descripcibn del propio caso de uso, derivar las condiciones previa y resultante, y especificar 10s pasos. Un aspect0 importante del anhlisis de 10s casos de uso es que 10s componentes del sistema empiezan a ser evidentes.

Preguntas y respuestas P En el segment0 inicial de GRAPPLE, not6 que pas6 por alto la acci6n "Identificaci6n de 10s sistemas cooperativos". i A quC se debe? R Como recuerda, este equipo de desarrollo inicid un proyecto sin precedentes. No hay sistemas cooperativos. No obstante, el siguiente sistema que alguien diseiie para Restaurantes LNG tal vez tendria que acceder a RICO de alguna forma. P En esta hora modific6 10s diagramas de casos de uso y el de clases. iEsto sucede con frecuencia? R Asi es. No deberh ser reacio a hacer modificaciones conforme evolucione su conocirniento. La lista original de casos de uso captur6 todo el conocimiento en cierto punto del proyecto, y captura una imagen de tal momento. Los diagramas modificados representarhn las ideas subsecuentes del equipo de desarrollo.

Taller El taller para esta hora verificari su conocimiento para realizar casos de uso. Para ver las respuestas reales, vea el apCndice A, "Respuestas a 10s cuestionarios".

Cuestionario 1. iCuiles son las partes de un diagrama de casos de uso tipico? 2. LA quC se refiere que un caso de uso "incluya" (o "utilice") a otro?

Ejercicios 1. Genere el diagrama de casos de uso para "Llamar a un mozo de piso". 2. Analice 10s restantes casos de uso del paquete Mesero, y dibuje sus diagramas.

3. Analice 10s casos de uso del paquete Chef, y dibuje 10s casos de uso. 4. Haga 10 mismo para 10s paquetes Cantinero, Asistente y Mozo de piso. Analice 10s casos de uso que haya obtenido de su proyecto Biblioteca.

Orientacion a las interacciones y cambios de estado A continuacidn profundizara en 10s casos de uso analizados en la hora anterior. Los utilizara como fundamento para comprender las partes del sistema y la forma en que se comunican entre si. En esta hora se trataran 10s siguientes temas: Las partes funcionales del sistema Modificacidn de 10s casos de uso Analisis de la colaboracidn entre las partes funcionales El analisis de 10s casos de uso de la hora anterior es un gran avance para hacer realidad el sistema RICO. No obstante, el analisis aun esta muy lejos de permitir que se empiece con la codificacidn. Analizar 10s casos de uso ha ayudado a visualizar las partes funcionales del sistema. Aunque ahora sabemos mucho de ellos, aun tenemos que modelar la forma en que las partes funcionales se comunicarhn entre si y la forma (y momento) en que cambiaran de estado. Dar esta informacidn a 10s programadores facilitari su trabajo. Tendran una visidn de la forma de codificar las clases y hacer que trabajen en conjunto.

Las partes funcionales del sistema Una forma de empezar es enumerar 10s componentes sugeridos del sistema en cada paquete de casos de uso. Aunque no hemos analizado de manera explicita todos 10s casos de uso en todos 10s paquetes en la hora anterior, aun podriamos obtener 10s componentes que se asumen en ellos. Claro que en un verdadero proyecto de desarrollo, un equipo de desarrollo deben'a analizar todos 10s casos de uso antes de continuar.

El paquete Mesero A1 finalizar la hora anterior, enumeramos las partes de software del sistema de acuerdo con nuestro analisis de 10s primeros nueve casos de uso del paquete Mesero: en las palmtops, RICO necesitari interfaces para el registro de brdenes, su modificacibn, su control, el estado de 10s clientes y el envio de mensajes. TambiCn sera necesaria una pantalla principal en la interfaz. Nuestro analisis trajo a la luz la necesidad de una interfaz para ver el avance de 10s pedidos en la PC de la cocina. RICO necesitari una base de datos para contener a todas las brdenes. Los casos de uso que no analizamos tambiCn sugieren componentes del sistema. Para refrescar su memoria, esos casos eran: Llamar a un mozo de piso Tomar una orden de bebida Transmitir una orden de bebida a1 bar Obtener un acuse de recibo Recibir una notificacibn del bar Los casos de uso sugieren algunos componentes evidentes. El primer0 nos indica que algo en la interfaz del Mesero (como una pantalla dedicada) tiene que permitir la llamada a un mozo de piso. El segundo, que se necesita una pantalla para obtener una orden de bebidas (similar a la que se usa para tomar una orden de alimentos). La interfaz debe poder obtener un acuse de recibo (para mostrar, por decir, que el mozo de piso ha recibido la petici6n) y recibir un mensaje del bar que indique que esti lista la bebida. Debido a1 trabajo de un mesero, no debe sorprendernos que 10s componentes primordiales en este paquete son interfaces relacionadas con el registro de brdenes, asi como la recepcibn y envio de mensajes.

El paquete Chef Los casos de uso del paquete Chef son: Almacenar una receta Obtener una receta Notificar a1 mesero Recibir una peticidn del mesero Dar acuse de recibo a una peticidn del mesero Indicar el period0 de preparaci6n Asignar una orden iQuC componentes sugieren estos casos de uso? Nuevamente, algunos vienen a la mente de manera evidente.

El paquete Mozo De Piso Los casos de uso para el mozo de piso son: Recibir una petici6n del mesero Dar acuse de recibo a una peticidn Indicar que una mesa ha sido limpiada

El paquete Asistente Mesero Como recordxi, decidimos dividir el paquete Asistente en Asistente Mesero y Asistente Chef. Los casos de uso del Asistente Mesero serian: Obtener una peticidn del mesero Dar acuse de recibo a la peticidn Notificar que se ha completado la petici6n

El paquete Asistente Chef Los casos de uso del Asistente Chef serian: Obtener una petici6n del chef Dar acuse de recibo a la petici6n Notificar que se ha completado la petici6n

Tal vez podria pensarse que no es necesaria una computadora para un asistente de chef dad0 que trabaja de forma muy cercana a1 chef en la cocina. No obstante, si la cocina es muy grande, la comunicaci6n electr6nica podria ser una buena idea.

El paquete Cantinero Los casos de uso del Cantinero son: Capturar la receta de una bebida Obtener la receta de una bebida Recibir una notificacion del mesero Recibir una peticidn del mesero Dar acuse de recibo de una petici6n Notificar que la petici6n se ha completado Estos casos de uso son similares a 10s del paquete del Chef, y 10s componentes de software que sugieren tambiCn 10 son. El hardware es similar, a su vez: detrfis de una barra, una PC de escritorio podria tener mfis sentido que una palmtop. Necesitamos una base de datos de recetas para bebidas y una interfaz que permitan un ficil acceso a ella (tanto para capturar como para obtener recetas). La interfaz para el cantinero tiene que mostrar una notificaci6n proveniente del mesero (de que la mesa de un cliente esti lista) y una peticidn de una bebida tambiCn proveniente del mesero. El cantinero tendrfi que enviar un acuse de recibo de que la petici6n se ha recibido y, tambiCn, notificar a1 mesero que la bebida esti lista.

El paquete Encargado Del Guardarropa Los casos de uso del Encargado Del Guardarropa son: Imprimir un vale de abrigo Imprimir un vale de sombrero Los componentes de software en la palmtop del encargado del guardarropa deberian incluir una interfaz que permita la impresi6n del vale adecuado. El vale deberi incluir la hora y una descripci6n del articulo. Posiblemente tambiCn queramos tener una base de datos de elementos almacenados.

Colaboracion en el sistema En este punto del proyecto, la tarea sera mostrar la forma en que 10s componentes inieractlian para completar cada caso de uso. Modelaremos tales interacciones para un par de casos de uso en el paquete del Mesero. El conjunto de casos de uso es demasiado grande para que 10s veamos todos; per0 en un proyecto real, un equipo de desarrollo harfi justamente eso.

Recuerde que, corno dije antes: Detras de cada caso de uso se esconde u n diagrarna de interacciones.

Tomar una orden Empecemos con el caso de uso "Tomar una orden". De 10 desprendido en la hora 19,los pasos son: 1. 2. 3. 4.

En la palmtop, el Mesero activa la interfaz para capturar una orden. Aparece la interfaz para capturar ordenes. El Mesero registra la selecci6n del Cliente hecha del mend en RICO. El sistema transmite la orden a la PC de la cocina.

En el mode10 que desarrollamos en la hora anterior, este caso de uso incluye a "Transmitir la orden a la cocina", cuyos pasos son: 1. Hacer clic en un boton en la interfaz para el registro de drdenes indica "Enviar a la cocina". 2. RICO transmitirh la orden mediante la red inalhmbrica.

3. La orden llega a la cocina. 4. La interfaz del usuario para registrar las ordenes en la palmtop indica que la orden ha llegado a la cocina. Un diagrama de secuencias podria mostrar bastante bien esta colaboracidn (igual 10 haria un diagrama de colaboraciones, mismo que le pedirC que genere en el ejercicio 1). La preparacidn del diagrama nos fuerza a enfocar nuestra imagination de varias formas. Para empezar, cuando el mesero toma la orden de un cliente, crearh algo: iuna orden! Tal orden es un objeto en el sistema RICO (a su vez, es una instancia de una clase, Orden, proveniente de nuestro anhlisis del dominio en la hora 17, "Elaboraci6n de un anhlisis del dominio"). El chef la usarh corno orientation para iniciar y realizar un conjunto de acciones. El mesero totalizarh una cuenta de acuerdo con ella. El cliente pagarh la cuenta. Asi, esta orden generada es un element0 importante. A su vez, si examina 10s casos de uso "Cambiar una orden" y "Sondear el progreso de la orden" (corno 10 haremos en un momento), verfi que se hace referencia a una lista de 6rdenes. Esta lista se habra obtenido de una base de datos de ordenes, misma que mencionC a1 finalizar la hora 19. iC6m0 se captura la orden en la base de datos? Bien, pues ell0 deberfi ocurrir en este caso de uso.

Podemos enfocar nuestra imaginaci6n de otra forma. En el caso de uso incluido, el tCrmino "cocina" es un poco vago. Dado que estamos modelando componentes de software, tendremos que pulir 10 que queremos decir aqui. Imaginar c6mo podria funcionar todo nos llevari a una forma donde el sentido comun estableceri que la orden deberi mostrarse de algun mod0 en la interfaz del chef en la PC de la cocina. El c6mo ocurra no es algo que en este moment0 deberi ocuparnos. Luego de que hemos pensado en 10 anterior, el caso de uso "Tomar una orden" luciria asi: 1. 2. 3. 4. 5. 6.

En la palmtop, el Mesero activa la interfaz para capturar una orden. Aparece la interfaz para capturar 6rdenes. El Mesero registra en RICO la selecci6n del Cliente hecha del menu. RICO genera una orden. Incluir(Transmitir una orden a la cocina). El sistema guarda la orden en la base de datos de 6rdenes.

"RICO" y "el sistema" son sinonirnos.

Observe el recurso utilizado en el pas0 5 que indica la inclusi6n del caso de uso "Transmitir una orden a la cocina". La "base de datos de pedidos" emplaza nuestra imaginaci6n hacia el lado del hardware. Esta base de datos debe encontrarse en una computadora, pero no hemos establecido una. Una posibilidad seria contar con un equipo de c6mputo central que tuviera esta base de datos y la hiciera accesible a las demas maquinas de la red. Mientras estamos en esto, debemos expandir el caso de uso "Transmitir la orden a la cocina" e incluir la modificacidn respecto a la interfaz del chef. Dado que tiene un paso que establece un mensaje en la palmtop del mesero que indica la recepci6n de la orden en la cocina, debemos agregar un paso que haga que el sistema envie un mensaje de la PC de la cocina a la palmtop. Asi, 10s pasos serian: 1. Hacer clic en un bot6n en la interfaz para el registro de drdenes indica "Enviar a la cocina".

2. RICO transmitiri la orden mediante la red inalimbrica. 3. La orden llegari a la interfaz del chef en la PC de la cocina. 4. RICO enviari un mensaje de la cocina a la interfaz de la palmtop que acuse el recibo de la orden. 5. La interfaz del usuario, para registrar las 6rdenes en la palmtop, indicari que la orden ha llegado a la cocina.

Estas modificaciones a 10s casos de uso son s610 dos ejemplos mis de la forma en que una fase de un proyecto puede influenciar a otra. En este contexto, la preparaci6n de nuestros diagramas de secuencias nos ayudaron a pulir nuestra idea de 10s casos de uso con la base de esos diagramas. La figura 20.1 le muestra el diagrama de secuencias que captura nuestra idea de este caso de uso. Para recordar 10 que vio de 10s diagramas de secuencias, 10s objetos que estfin colocados en la parte superior de C1 representan a 10s componentes en este caso de uso. El objeto Orden se genera durante el caso de uso, y por ell0 esta bajo 10s otros dos. El mensaje que apunta hacia C1 tiene un estereotipo cccrear,,. La linea punteada que parte de cada objeto representa la "linea de vida de un objeto", misma que avanza hacia abajo verticalmente. Los pequeiios rectangulos en 10s tiempos de actividad se llaman "activaciones". Cada activaci6n representa a1 period0 en el que un objeto realiza una accion. FIGUM 20.1 El diagrama de secuencius de "E~rnar una orden".

, SB c0nvleRe en de orden

,

, I

I I

Registrar(Sel8cclon)

I

I

I crear. I

'

j

'

EnnarCoclna(0rden)

F , ' I I

\

Rec~b~do(Orden)

,

,

I

8 > . - - - - - - - - - - - - ' - - - - - - - - L I I I

',I I

I I

,

\

,

Reglstrar(0rden)

'

\

I

Parte del caso de uso

I 0

, I

I I

' Recibido(0rden)

., . !,, \

I

'inalambrico-,

I

I

I

I 1 I

I I I

I

Vea el cambio de estado en el primer tiempo de actividad. Intenta aclarar la forma en que una interfaz maneja un tip0 especial de actividad. Podriamos incluir todos 10s cambios de estado posibles como diagramas de estados por separado, per0 seria excesivo. El colocarlos en diagramas de secuencias (a1 menos en este dominio) aparentemente es mis sencillo.

En un diagrama de secuencias, una flecha de mensaje con una linea punteada representa a un mensaje devuelto.

Cambiar una orden Intentemos con otra. En la hora anterior, 10s pasos de caso de uso "Cambiar una orden" fueron: 1. En la palmtop, el mesero activa la interfaz del usuario para carnbiar una orden.

2. La interfaz del usuario trae una lista de ordenes realizadas y enviadas a la cocina por el mesero. 3. El mesero selecciona la orden por cambiar. 4. El mesero registra la modificaci6n a la orden.

5. El sistema transmite la orden a la PC de la cocina. Nuevamente, la preparaci6n del diagrama nos ayuda a pulir nuestra imaginaci6n y modificar de cierto mod0 a1 caso de uso. Luego del paso 4, sin duda queremos que el sistema cree una orden modificada. Luego del paso 5, el sistema deberia registrar la orden modificada en la base de datos de 6rdenes. Con ello, el nuevo caso de uso deberia ser: 1. En la palmtop, el mesero activa la interfaz del usuario para cambiar una orden. 2. La interfaz del usuario trae una lista de drdenes realizadas y enviadas a la cocina por el mesero. 3. El mesero selecciona la orden por cambiar. 4. El mesero registra la modificaci6n a la orden. 5. RICO crea una orden de acuerdo con la modificaci6n a la anterior. 6. Incluir(Transmitir una orden a la PC de la cocina). 7. El sistema guarda la orden modificada en la base de datos de brdenes. Nuevamente, utilizamos el recurso para indicar la inclusi6n de un caso de uso. La figura 20.2 le muestra el diagrama de secuencias que corresponde a este caso de uso. A1 igual que en la figura 20.1, ahora mostramos un cambio de estado.

secuencias para "Cambiar una orden ".

O-.! Camblar Orden

Obtener(h41sOrdenes):

naambn

FIecuperar(M1~0rde~es)

Sondeo del progreso de la orden Veamos otro caso de uso antes de tenninar. El caso de uso "Sondear el progreso de la orden" consta de 10s siguientes pasos: 1. El mesero activa la interfaz en la palmtop para sondear una orden registrada. 2. La interfaz le muestra a1 mesero una lista de las 6rdenes que tiene registradas en la cocina. 3. El mesero elige la orden que desea sondear. 4. El sistema transmite un mensaje de sondeo a la PC de la cocina. 5. La PC de la cocina recibe el mensaje. 6. El chef selecciona la orden de la cual se quiere conocer su avance. 7. El chef teclea un tiempo estimado para completar la orden. 8. El sistema transmite el tiempo estimado a la palmtop del mesero. Para continua con las modificaciones que hemos hecho, posiblemente queramos cambiar el paso 5 a "El mensaje llega a la interfaz del cocinero en la PC de la cocina". TambiCn podriamos hacer una entrevista a un chef o dos para preguntarles c6mo calculan el tiempo estimado del paso 7. Quiz5 pudieramos desarrollar un paquete de software que ayudara con ello. La figura 20.3 hace 10s honores a este caso de uso.

FIGURA20.3 El diagrarna de secuencias de "Sondear el progreso de una orden".

6 I

n :

Capturar(S0ndearOrden)

I 0 I

I I 4

~nalambnco

I I

Recuperar (M~sOrdenes)

Requenr (SondeoOrden)

i

: I

1

Capturar (TiempoEst~mado)

lmplicaciones A1 ver todos 10s resultados obtenidos hasta ahora, 10s seAores LaHudra, Nar y Goniff estan euf6ricos. "Esto cambiari todo el entorno del negocio de 10s restaurantes", dijo Nar. "S6 que hemos logrado algo", dijo LaHudra, "pero, iquC quieres decir con 'cambiar todo el entorno del negocio de 10s restaurantes'?" "Si, iqu6 quisiste decir?', preguntd Goniff. "Bueno, si lo analizan", respondi6 Nar, "todo el trabajo de un mesero cambiari, igual que el del chef. Los meseros no tendran que correr de aqui para alla como ahora 10 hacen. Siempre estarin a1 alcance de 10s clientes dad0 que siempre se encontrarin en sus areas de servicio designadas. Irin a la cocina y a1 bar s610 cuando tengan que hacerlo. Mediante sus palmtops, se convertiran en supervisores del proceso de preparacidn de las 6rdenes y administradores de sus keas. Serin mis parecidos a salvavidas que a meseros tradicionales. De hecho, podran sentarse ocasionalmente mientras se encuentren en sus keas, dad0 que el 'trabajo' ya no involucrari andar a las carreras de forma despiadada."

"iY qut con 10s chefs?"

"TambiCn seran mAs administrativos. Utilizaran sus equipos de cdmputo para asignar drdenes a sus asistentes, y coordinaran 10 que proceda en una cocina. Esto sera estupendo para grandes cocinas y restaurantes, ahora que 10 que hacemos es mover informaci6n y no a la gente." "Hum.. . Suena bien", dijo LaHudra. "Aparentemente, cuanta mis informacion muevas, moveris menos a la gente y lograras mas. No esta mal." "No del todo", dijo Goniff, ya maquinando la siguiente expansidn del negocio.

Resumen Luego del analisis del caso de uso, un equipo de desarrollo volvi6 su atenci6n a 10s componentes del sistema que sugirieron 10s casos de uso. ~ Q u Cson? iC6m0 interactuan? Esta hora mostr6 c6mo responder a estas preguntas dentro del context0 del desarrollo del sistema RICO. El objetivo de esto es dar informacidn a 10s programadores que les facilite su trabajo. Los resultados de este analisis deberjn facilitar a 10s programadores la codificacion de 10s objetos del sistema y la forma en que se comunican entre si. Luego de modelar la cooperacidn entre componentes, el sistema ya esta mas cercano a convertirse en realidad. Conforme modele la cooperaci6n entre 10s componentes, podria encontrarse con que sera adecuado modificar 10s casos de uso.

Preguntas y respuestas P Ha mostrado diversas modificaciones a 10s casos de uso. iEn realidad asi ocurre en un proyecto? R Indudablemente que si. Ciertamente, 10s ejemplos podrian parecer algo amaiiados; por ejemplo: en realidad posiblemente podriamos haber sabido de la base de datos en el primer caso de uso antes de llegar hasta este punto. Sin embargo, la meta es mostrarle que conforme se desarrolle nuestra nocibn, el mode10 tambiCn se desarrollara. P iPor qu6 podria ser que 10s casos de uso originales no capturaran todos 10s aspectos en primera instancia? R Porque reflejan 10s resultados de las sesiones JAD con 10s usuarios del sistema, no con 10s desarrolladores de sistemas. VerA que todas las adiciones y cambios estaban relacionados con el sistema, no con el negocio. Una vez que acabe las sesiones con 10s usuarios potenciales y que tenga la oportunidad de analizar 10s casos de uso, sera corntin que salgan a la luz modificaciones como esas.

Aqui sera donde tendrfi la oportunidad de practicar con el modelado de la cooperaci6n entre 10s componentes de un sistema. Interactlie con el ApCndice A, "Respuestas a 10s cuestionarios", para encontrar las respuestas. Tal vez necesite utilizar 10s componentes listados en esta hora para que le ayuden a continua por encima y mBs all6 de 10s ejercicios listados y hacer otros diagramas de secuencias y colaboraciones.

Cuestionario 1. iC6m0 representaria a un objeto que se genera durante el curso de un diagrama de secuencias? 2. iC6mo se representa el tiempo en un diagrama de secuencias?

3. ~ Q u Ces la "linea de vida"? 4. En un diagrama de secuencias, ~ representa?

C O muestra ~ O

una "activaci6nWy quC es 10 que

Ejercicios 1. Desarrolle un diagrama de colaboraciones equivalente a1 de secuencias para el caso de uso del Mesero "Tomar una orden". 2. Cree un diagrama de secuencias para el caso de uso "Tomar una orden de bebida". 3. Seleccione a1 menos un caso de uso del paquete Chef y desarrolle un diagrama de secuencias. Utilice la lista de componentes mencionados en esta hora. iSe necesitan algunos otros? 4. VBlgase de su imaginaci6n con Csta: Los casos de uso del paquete Encargado Del Guardmopa parecen ser muy sencillos. LPodria adornar a cada uno mediante la adici6n de uno o dos pasos? ~Podrianayudar algunos otros componentes adicionales? Dibuje un diagrama de secuencias para uno de estos casos de uso.

5. Continlie con su proyecto Biblioteca para listar las partes funcionales de su sistema y agregar la colaboraci6n entre objetos. Genere 10s diagramas de secuencias para 10s casos de uso resultantes, una vez que haya hecho las modificaciones pertinentes a cada caso de uso.

Diseiio del aspecto, sensacion y distribucion Ahora nos centraremos en dos importantes aspectos del diseiio de sistemas: la interfaz del usuario y la distribuci6n del sistema. En esta hora se tratarin 10s siguientes temas: Algunos principios generales del diseiio de interfaces grificas La sesi6n JAD de la GUI De 10s casos de uso a las interfaces de usuario Diagramas UML para el diseiio de la GUI Esbozos de la distribuci6n del sistema Ya ha cumplido con Cxito gran parte del anilisis conducido por casos de uso. En esta hora, veri dos importantes aspectos del diseiio de sistemas. Ambos pueden, a final de cuentas, orientarse a casos de uso, y son muy importantes para el product0 final. Las GUI (interfaces grgicas de usuario) detenninan quC tan prictico es un sistema. La distribuci6n convierte a la arquitectura fisica planeada del sistema en una realidad.

Algunos principios generales en el diseiio de las GUI El diseiio de las GUI, que conjuga a1 arte y la ciencia, dibuja, bajo la vision del artista grifico, las conclusiones del investigador de factores humanos y las intuiciones del usuario potencial. Luego de mucha experiencia con interfaces WIMP (Ventanas, Iconos, Menus y Dispositivos apuntadores), han salido a la luz diversos principios generales. He aqui 10s principales: 1. Entienda lo que el usuario tiene que hacer. Por lo general, 10s diseiiadores de interfaces realizan un andlisis de tareas para comprender la naturaleza del trabajo del usuario. Nuestro analisis de casos de uso corresponde m5s o menos a esto. 2. Haga que el usuario sienta que tiene el control de la interaccion. Siempre incluya la posibilidad de que el usuario cancele una accion luego que la haya iniciado. 3. DC al usuario diversas formas de realizar cada accidn relacionada con la interfaz (corno el cierre de una ventana o archivo) y disculpe con elegancia los errores del usuario. 4. Dadas nuestras influencias culturales, nuestros ojos se dirigen a la esquina superior izquierda de la pantalla. Coloque la informacidn de mayor prioridad alli. 5. Aproveche las relaciones de espacio. Los componentes de la pantalla que estkn relacionados deberhn aparecer uno junto de otro, quiz5 con un marco que 10s bordee. 6. Destaque la legibilidad y la comprensi6n (ipalabras con las que tenemos que vivir!). Utilice la voz activa para comunicar ideas y conceptos. 7. Aunque tal vez tenga la capacidad de incluir miles de colores en la pantalla, restrinja 10s que vaya a utilizar. De hecho, haga una fuerte limitacidn de ellos. Demasiados colores distraeran al usuario de la tarea por realizar. Por cierto, se recomienda dar a1 usuario la opci6n de modificar 10s colores. 8. Si piensa en utilizar colores para indicar algo, recuerde que no siempre sera ficil para el usuario asociar un color con un significado. A su vez, tenga en cuenta que ciertos usuarios (cerca del 10%de 10s adultos masculinos) sufren de daltonismo, y se les podria dificultar distinguir a un color de otro. 9. Como con el color, restrinja el uso de fuentes. Evite las fuentes cursivas y ornamentales. "Haettenschweiler" es un nombre de fuente que puede ser divertido pronunciar, pero que no fomenta una facilidad de uso. 10. Intente mantener, tanto como sea posible, 10s componentes (corno 10s botones y cuadros de lista) del mismo tamaiio. Si utiliza componentes de tamaiios dispares, mliltiples colores y fuentes, crearh una terrible interfaz que 10s especialistas en el area conocen como un diseiio de "pantalon de payaso". 1 1. Alinee 10s componentes y campos de datos a la izquierda: alineelos de acuerdo con sus bordes izquierdos. Esto reduce 10s movirnientos oculares cuando el usuario tiene que revisar la pantalla.

12. Cuando el usuario tiene que leer y procesar informacidn y luego hacer clic en un botdn, coloque 10s botones en una columna a la derecha de la informacidn, o en una fila debajo y a la derecha de la misma. Esto es conveniente debido a la tendencia natural (o cultural) de leer de izquierda a derecha. Si uno de 10s botones es el predeterminado, destiquelo y col6quelo como el primer0 en el conjunto. Esta docena de principios no son 10s unicos, pero nos dan una idea de lo que esti involucrado en el disefio de una GUI. El reto es comunicar la informacidn adecuada en un contexto visual elemental, direct0 e intuitivo.

Para ver mayor informacion respecto al disefio de interfaces, en especial las que estan relacionadas con Windows, visite h t t p : Ilrnsdn . m i c r o s o f t .corn/UI. En esa misma pagina encontrara informacion para el disefio de paginas Web o puede visitar W. u s e i t . corn. En ambos casos, la informacion se encuentra en ingles.

La figura 2 1.1 le muestra lo que ocurre cuando pone en accidn algunos de estos principios y la figura 2 1.2 le muestra 10 que sucede cuando no lo hace.

Aplicacio'n de 10s prin cipios para el disetio de GUI.

FIGURA 21.2 El resultado dt. no aplicar 10s principios para el disetio de GUI.

La sesion JAD para la GUI Aunque la sesidn JAD no tendri una conexidn directa con el UML, es buena idea hablar de la forma en que 10s usuarios potenciales determinan a la GUI. Nuevamente, se realizari una sesidn para el Desarrollo conjunto de aplicaciones (JAD). Para esta sesidn reuniri a 10s usuarios potenciales del sistema. En el caso de RICO, reuniremos a 10s meseros, chefs, asistentes de 10s meseros, asistentes de 10s chefs, mozos de piso y a 10s encargados del guardarropa. Los integrantes del equipo de desarrollo que estarhn presentes serhn 10s programadores, analistas, modeladores y un moderador. El objetivo seri comprender las necesidades de 10s usuarios e implementar una interfaz de acuerdo con sus ideas (una interfaz que integre sutilmente a1 sistema con 10s procesos del negocio). La antigua manera de desarrollar un sistema (por ejemplo, escribir un programa desde sus inicios, moldear el comportarniento del usuario para que puedan interactuar con Cl y modificar 10s procesos del negocio para que se adapten a Cl) ya es obsoleta. Para mantener la eficiencia de la sesidn, programari a 10s usuarios en grupos de acuerdo con el rol que desempeiien. Planeari la cantidad de tiempo que se llevari cada sesi6n de acuerdo con la cantidad de casos de usos en el paquete de cada rol. Esto es s610 un vago lineamiento, claro, ya que algunos casos de uso son m h complejos que otros. Recuerde, a su vez, que podrian aparecer nuevos casos de uso a1 diseiiar la GUI. La participacidn de 10s usuarios en la sesidn es un asunto que envuelve a dos partes. En la primera se obtendrin las pantallas de la interfaz del usuario. En la segunda se aprobarin 10s prototipos generados por el equipo de desarrollo. iDe quC forma 10s usuarios obtendran las pantallas? El moderador sugiere un caso de uso con el cual empezar, y 10s usuarios debatirin las formas de implementarlo mediante el sistema. Cuando estCn listos para empezar a hablar al nivel de una pantalla especifica, 10s usuarios trabajarin con prototipos en papel. El moderador proporciona una gran hoja de papel para rotafolios de manera horizontal para representar la pantalla. Las notas autoadheribles representarin a 10s componentes de la GUI (por ejemplo: men6s contextuales, botones, cuadros combinados, cuadros de lista). La tarea de 10s usuarios sera trabajar en conjunto para colocar 10s componentes de manera adecuada. Cuando lleguen a un acuerdo en 10s componentes que deban estar en una pantalla y su disposici6n, 10s rniembros del equipo de desarrollo generarh pantallas de prototipo. Conforme hagan su trabajo, i r h utilizando 10s principios adecuados del diseiio de GUIs que se indicaron en la seccidn anterior. Luego, presentarin tales pantallas en computadoras y 10s usuarios les h a r h las modificaciones necesarias. La meta de todo esto, claro esd, es que 10s usuarios (y no 10s desarrolladores) conduzcan el proceso tanto como se pueda. Asi, el sistema funcionari de manera dptima en las actividades reales y diarias del negocio.

De 10s casos de uso a las interfaces de usuario Los casos de uso describen la forma en que se utiliza el sistema. Por ello, la interfaz del usuario tiene que servir como medio para implementar 10s casos de uso. Imagine un diagrama de secuencias de un caso de uso como una visi6n de un caso de uso. Si pudikramos "girar" tal visi6n en tres dimensiones, para que la parte del extremo izquierdo del diagrama de secuencias se desprendiera de la p6gina y quedara frente a nosotros, veriamos la interfaz que llevaria a1 usuario a la secuencia (vea la figura 21.3). FIGURA21.3 El supuesto "giro" del diagrarna de secuencias nos pone de rnanifiesto la interfaz del usuario.

I Q Q 7

usuario I I

I I I

I I

Examinemos 10s casos de uso del paquete Mesero y veamos c6mo encajan en la interfaz de RICO. Nuevamente, aqui e s t h tales casos de uso: Tomar una orden Transmitir la orden a la cocina Cambiar una orden Recibir una notificaci6n de la cocina Sondear el progreso de la orden Notificar a1 chef del progreso de 10s clientes en sus alimentos Totalizar una cuenta Imprimir una cuenta Llamar a un asistente

Panralla para 10s casos de uso relacionados con las o'rdenes.

Cuando se haga clic en 10s botones de la fila inferior se obtendri otro grupo de capacidades. Por ejemplo, el boton Mensaje traeri la pantalla de la figura 21.6. Por cierto la interfaz de usuario no debe ser solo visual. Esta interfaz tiene que incorporar algun elemento audible para notificar a un mesero que le ha llegado un mensaje. Asi, har5 clic en el bot6n Leer para que se le presente una lista desplegable de mensajes.

Pantulla para los casos de uso relacionados con 10s mensajes.

Diagramas UML para el disefio de la GUI El UML no hace recomendaciones especificas respecto a 10s diagramas para diseiios GUI. No obstante, en una hora anterior indicarnos una posibilidad: recuerde que en la hora 8, "Diagramas de estados", present6 un ejemplo que trataba de 10s cambios de estado en una GUI. Aunque tal ejemplo profundizd en la funcionalidad de una GUI mas de 10 que deberiamos en este punto, sugiere que 10s diagramas de estados son utiles cuando se trata de interfaces de usuario.

En la hora 24, "El futuro del UML", presentaremos algunas ideas de corno extender el UML para rnodelar las GUls.

Deberia usar un diagrama de estados para mostrar el flujo de una interfaz de usuario. La figura 2 1.7 le muestra c6mo las pantallas de alto nivel en la interfaz del Mesero se conectan entre si.

Un diagrama de estados para el flujo de pantalla de alto nivel en la interjiiz del Mesero.

Pantalla principal del Mesero

Como una pantalla en particular consta de varios componentes, un diagrama de clases para un objeto compuesto es adecuado para modelar una pantalla. La figura 21.8 muestra un diagrama para un objeto compuesto que corresponde con la pantalla de la figura 21.5.

Un diagrama compuesto que corresponde con la pantalla de la jigura 21.5.

Esbozos de la distribucion del sistema Luego de que el segmento de analisis GRAPPLE ha producido el concept0 general del sistema RICO, un ingeniero de sistemas empezari a pensar c6mo debera lucir la arquitectura fisica. Empezara a considerar las alternativas en topologias de red y la forma de implementarlas de manera inalimbrica, y comenzari a resolver qut componentes de software pertenecerhn a determinados nodos en la red. Este segmento de diseiio no tiene que esperar a que el analisis se haya completado. Sus acciones pueden proceder de forma paralela con las de 10s segmentos GRAPPLE, como con el diseiio de la GUI. La meta se centra en que el administrador del proyecto sondee todas las acciones en todos 10s segmentos.

La red A1 recordar 10s distintos tipos de LAN disponibles (vea la hora 13, "Diagramas de distribucibn"), el ingeniero del sistema cuenta con diversas opciones. El objetivo es elegir aquCl que se integre mejor con la conectividad inalimbrica en las palmtops. Para comprender algunas de las decisiones que el ingeniero del sistema tiene que tomar, vamos a profundizar un poco en las redes LAN inalimbricas (WLANs). Es frecuente el caso de que un transceptor de radio conocido como punto de acceso se coloque en un lugar fijo y se conecte a una LAN (por algun medio alimbrico estindar). El punto de acceso recibe 10s mensajes de, y transmite 10s mensajes a, 10s dispositivos inalimbricos, y cambia 10s mensajes recibidos a una forma que la red alimbrica entienda. Varios puntos de acceso aumentarin el rango de la WLAN y la cantidad de usuarios que podrin acceder a ella. iDe quC manera 10s usuarios accederian a la WLAN? En RICO, harin la conexion mediante adaptadores LAN inalimbricos integrados con sus palmtops. No importa cuantos puntos de acceso se incorporen en la red, cada palmtop se asocia con solo un punto de acceso y su area de cobertura, lo que se conoce como microcelda (que es similar a una celda que funciona en 10s telifonos celulares). El ingeniero del sistema tendri que decidir cuintos puntos de acceso deberi tener el restaurante, quC tip0 de adaptador inalimbrico LAN integrari a las palmtops, y el tipo y disposicion de la red alimbrica.

Si algo de esto le ha interesado para su WLAN, visite www.wlana.com. el sitio Web de la Alianza inalambrica LAN (WLANA). WLANA es un consorcio de corporativos que comercializan componentes para redes WLAN.

Vamos a suponer que el ingeniero del sistema decide utilizar una red thin ethernet para la LAN (vea la hora 13).

Los nodos y el diagrama de distribucion Ya enumeramos 10s nodos en nuestro sistema. Los meseros, asistentes de meseros y mozos de piso tendrin palmtops. La cocina, guardarropa y bar tendrin computadoras de escritorio. Cada computadora se conectari a una impresora. Ademis, cada 6rea de servicio tendri una computadora de escritorio conectada a una impresora para que pueda imprimir cuentas y obtenerlas sin caminar demasiado (un servidor de impresion, si se puede llamar asi).

No obstante, en este punto veremos un ejemplo primordial del porquC es mejor empezar a pensar en las caracteristicas de distribucion desde el principio. Conforme se avanza, el ingeniero del sistema y el equipo de desarrollo tendran que tomar una decisi6n de negocios: las palmtops requieren adaptadores LAN inalimbricos, que podrian ser muy costosos, y el software asociado podna estar fuera de las necesidades iniciales. Una posibilidad potencialmente menos costosa es la de cambiar 10s dispositivos m6viles de palmtops a otras conocidas como Handheld que ejecuten Windows CE y utilicen una tarjeta PC para conectarse de manera inalambrica a la LAN. Una caracteristica importante de esta alternativa es que 10s programadores pueden utilizar herramientas de desarrollo ya conocidas para crear el software y llevarlo a las computadoras m6viles. iPor quC no utilizar una palmtop con Windows CE? Cuando escribi estas lineas, 10s dispositivos Palmtop con Windows CE no tenian ranuras para tarjetas PC, y la unica tarjeta PC WLAN para Windows CE era la Proxim RANGELAN2. Conclusi6n: resuelva estos detalles en 10s procesos iniciales del proyecto. En cualquier caso, asumamos que el equipo de desarrollo y 10s usuarios deciden utilizar la soluci6n Windows CEProxim, con la idea de que el desarrollo sera m8s eficiente y econ6mico si 10s desarrolladores pueden aprovechar sus herramientas de desarrollo para crear el c6digo necesario. Como comentario al margen, de acuerdo con la velocidad a la que avanzan las cosas, podna aparecer en cualquier moment0 un nuevo dispositivo Palmtop con Windows CE y una ranura para tarjetas PC. Esta linea de razonamiento orienta al ingeniero del sistema hacia una soluci6n Proxim para un punto de acceso a la LAN; a1 igual que la tarjeta PC, tambiCn se llama RANGELAN2. Para ilustrar la distribucion, el ingeniero del sistema genera el diagrama de distribuci6n que se muestra en la figura 21.9.

FIGURA 21.9 Diagrama de distribucio'n para RICO.

Siguientes pasos El equipo de desarrollo ha ido de 10s casos de usos a las interfaces y a las WLANs. ~ Q u C sigue? Para empezar, 10s analistas pondran en orden a1 modelo. Veran el diccionario de modelos y pondran en orden cualquier ambigiiedad. Se aseguraran de que toda la terminologia sea utilizada de manera consistente en todos 10s diagramas y que 10s problemas con terminos

como "men$' no propendan a confusiones. Cuando se completen todas las partes del analisis y diseiio de GRAPPLE, el equipo compilara 10s resultados en un documento de diseiio y enviara copias a1 cliente y a 10s programadores. A 10s programadores o desarrolladores es a quienes corresponde convertir el diseiio en c6digo (la parte de la codificaci6n va mis all6 de 10s alcances de este libro). El cddigo sera probado, vuelto a escribir de acuerdo con 10s resultados de las pruebas, y vuelto a probar (proceso que continuara una y otra vez hasta que el cddigo pase todas las pruebas). El analisis de 10s casos de uso conforma 10s fundamentos de las pruebas. Los especialistas en la documentaci6n empezarin a crear la informacidn del sistema, y crearan tambiCn 10s materiales de entrenamiento. Un buen proyecto para la creacidn de la documentacidn deberia proceder como uno para el desarrollo de un sistema, con una cuidadosa planeaci611, analisis y pruebas, y debera comenzar en las primeras instancias del proceso de desarrollo. Con un documento de diseiio bien organizado e informativo y con un analisis y diseiio sdlidos, 10s siguientes pasos deberian proceder sin problemas durante todo el proceso de desarrollo. La idea principal es enfocar 10s esfuerzos primordialmente en el analisis y diseiio para que la implementacidn tenga muy pocos traspiCs y que el proyecto dC por resultado un sistema que cumpla por completo con las necesidades del cliente.

...Y ahora, unas palabras de nuestros patrocinadores Los seiiores LaHudra, Nar y Goniff no podrian estar mis emocionados por la forma en que ha transcurrido el proyecto de desarrollo. El equipo de desarrollo 10s ha mantenido informados del proceso y les ha dad0 diseiios basados en UML que les muestran el punto en que se encuentra el proyecto. Incluso estan satisfechos por la forma en que el equipo soluciond el gran problema de distribuci6n respecto a 10s dispositivos mbviles. Todo el esfuerzo ha despertado sus imaginaciones y 10s ha impulsado a buscar nuevas formas de utilizar la tecnologia (tanto dentro como fuera del mundo restaurantero). Han caido en la cuenta que la mayoria de 10s procesos de negocios involucran la transmisidn de la informaci6n. El grado en que la tecnologia acelera tal transmisidn, representa una enorme ventaja competitiva.

Mejorar el trabajo de la fuerza de ventas Fuera del mundo restaurantero, 10s tres empresarios ven el potencial de volver a utilizar las ideas de la LAN inalambrica para una fuerza de ventas mdvil dentro de un enorme area de trabajo. El volverlas a emplear no deberia ser dificil, ya que toda la informaci6n de 10s modelos esta intacta.

Una aplicacidn de esta idea podria ser en las enormes tiendas departamentales o de autoservicio. Los vendedores de piso de dichas tiendas podn'an beneficiarse de un dispositivo de man0 que acceda a la informacidn de 10s productos mediante una LAN inalambrica. Un sistema como Cste podria ayudar a1 vendedor a responder preguntas respecto a1 lugar donde se encuentra el product0 en la tienda, si hay en existencia y cdmo se podria utilizar. Esto tiene algunas implicaciones intrigantes tanto para el vendedor como para el cliente. Los clientes estarian seguros que siempre obtendrin la informacidn mis reciente y concisa del vendedor. Un nuevo vendedor entrenado sobre cdmo utilizar el sistema podria, con rapidez, empezar a trabajar aunque tuviera una minima capacitacidn sobre el almacCn. LaHudra, Nar y Goniff pronto invadirin el mundo de las mejoras a1 hogar.

Expansiones en el mundo restaurantero Esta idea de la fuerza de ventas mdvil no es suficiente para LaHudra, Nar y Goniff. NO quieren hacer nada que no incluya a la tecnologia para revolucionar 10s negocios restauranteros. Creen que nodrian crear restaurantes basados en RICO en las principales ciudades del mundo. Creen que la tecnologia simplificari la sensacidn de comer fuera de casa y 10 hara m6s conveniente para que todos salgan a hacerlo. Goniff, como siempre en busca de nuevas formas de ganar dinero, tiene un buen rato pensado en esto (jal menos desde que finalizd la hora 20!). "Amigos," les dijo a sus socios, "si construimos restaurantes en todas las ciudades principales, podriamos llevar la tecnologia a un siguiente paso y transmitir la informacidn por doquier." "~Cdmo?'preguntd Nar, que siempre ha sido algo torpe. "PiCnsenlo. Si nos internacionalizamos, podriamos entrar en la Web y . . ." LaHudra intermmpe: "Un momento. Ya estamos en la Web. Hay muchos que visitan www.lahudranargoniff.com, i O no?" "DCjame terminar, LaHudra. Podriamos utilizar la Web para que la gente 'vaya' a todos estos restaurantes. Utilizariamos la Web para darles un emparedado gratuito." "iQuC?'preguntaron Nar y LaHudra a1 unison0 y con incredulidad. "Vamos a ver. Orientamos una pagina de nuestro sitio Web a nuestra divisidn de restaurantes. Alguien entra a la pigina, da su nombre y otra informacidn, y se le pide que elija el emparedado que desee. Si nuestra base de datos muestra que el visitante no ha hecho esto con anterioridad, se le presentm'a otra pagina donde podra imprimir un cupdn para un emparedado. Llevara el cupdn a1 restaurante mis cercano. Obtendra el emparedado, 10 comeri, le gustari y regresari como un cliente normal."

"Si, pero la Web puede verse en cualquier parte", dijo Nar. "Supdn que alguien no vive cerca de uno de nuestros restaurantes y, de todas maneras, desea el emparedado." "i Aguarden! iYa sC!", dijo LaHudra. "Pueden utilizar su tarjeta de crCdito para pagar un cargo nominal por envio en el sitio Web, y nuestro restaurante mhs cercano se 10 enviara a su hogar en un frio y economico contenedor. Podran colocar el emparedado en su horno de microondas y calentarlo. Asi, podran comer un product0 de LaHudra, Nar y Goniff donde estCn. Luego, cuando viajen a una ciudad donde haya uno de nuestros restaurantes, querran comer alli."

"Por cierto, ipara quC seria el resto de la informacidn que ellos capturen antes de imprimir el cupdn?', preguntd Nar. "Te 10 dire," dijo Goniff. "Utilizaremos esta indagacidn para enviarles por correo electrdnico informaci6n promocional de nuestros demis negocios, de acuerdo con su demografia (siempre y cuando indiquen que quieren recibirla). "iD6nde esta el equipo de desarrollo? Tenemos mucho trabajo quC hacer."

Resumen Cuando su proyecto se encuentre en el segment0 de disefio, habra dos elementos por enfocar que seran la interfaz del usuario y la distribucidn del sistema. Ambos son finalmente conducidos por 10s casos de uso y de extrema importancia. El disefio de la interfaz del usuario depende de una visidn artistica y de una investigacidn cientifica. Varios de 10s principios del disefio de la interfaz han salido a la luz luego de afios de trabajo con interfaces WIMP. Esta hora le mostrd algunos de ellos. TCngalos en cuenta cuando su equipo de desarrollo disefie GUIs. Los casos de uso conducen el disefio de la interfaz del usuario. El sistema tiene que permitir a1 usuario completar cada caso de uso, y la interfaz es la puerta de acceso hacia cada uno de ellos. De forma simultanea con varios de 10s procesos del proyecto, el ingeniero de sistemas del equipo se orientara a la arquitectura fisica. La arquitectura esta conducida por 10s casos de uso dad0 que el uso del sistema finalmente determina la naturaleza fisica y la disposicidn del mismo. El ingeniero de sistema otorga un diagrama de distribucidn UML que muestra 10s nodos, 10s componentes de software que haya en cada nodo y las conexiones entre nodos. Aunque 10s detalles de la distribucidn aparecen en las etapas avanzadas del proceso GRAPPLE, no hay razdn para no empezar a pensar en ellos en etapas previas. Como se mostrd en esta hora, pueden aparecer detalles fundamentales que necesitaran ser resueltos.

Luego que el sistema ha sido modelado, la informacion del modelado puede volver a utilizarse en diversos contextos. El mode10 puede impulsar miles de ideas nuevas para negocios.

Preguntas y respuestas P Una vez que 10s usuarios hayan generado un prototipo en papel, ;en realidad sera necesario crear la pantalla y mostrarselas? DespuCs de todo, ya generaron la pantalla en el papel y colocaron adecuadamente 10s componentes. ;NO podrian esperar y ver las pantallas en el sistema una vez que est6 finalizado? R Es indudable que tendra que mostrarles a 10s usuarios una pantalla verdadera ("verdadera" en el sentido de la computadora). Para empezar, es muy probable que 10s usuarios vean cosas en la pantalla que no vieron en el papel. Otra razdn (relacionada con la primera) es que las dimensiones de las notas autoadheribles s610 se aproximan a las de 10s componentes en la pantalla. Colocar las notas autoadheribles podria distorsionar la relacidn de espacio entre 10s componentes de la pantalla. La pantalla podria lucir un tanto distinta al prototipo en papel. A su vez, las capturas de la pantalla se convertiran en partes muy valiosas para su document0 de diseiio. P S6 que esto no esti directamente relacionado con el UML, per0 uno de 10s principios de la GUI que mencion6 fue dar a1 usuario diversos medios para realizar las acciones relacionadas con la interfaz. iPor qu6 esto es importante? R Lo es porque no podra predecir todos 10s contextos en donde un usuario realizari una acci6n. En ocasiones el usuario utilizarh una aplicacidn que utiliza mucho el teclado, y una combinacidn de teclazos sera mis adecuada que un clic con el rat6n. En ocasiones el usuario utilizara mucho el ratdn, y un clic sera mas adecuado. Dar ambos medios para realizar 10 mismo hace que la interaccidn sea mas facil para el usuario. P Y hablando de preguntas que no se relacionan con el UML, quisiera saber el porqu6 del principio de la "voz activa" en la GUI. R Los estudios demuestran que las personas comprenden mejor la voz activa que la pasiva. A su vez, la voz activa requiere, por 10 general, menos palabras y, con ello, ocupara menos del precioso espacio de la pantalla que la voz pasiva. Los usuarios (asi como 10s editores y jefes de redacci6n) aprecian si sus instmcciones dicen: "Haga clic en el b o t h Siguiente para continuar" en lugar de "El b o t h Siguiente deben'a ser oprimido por usted para que contin6e el proceso".

Taller Este taller verifica su conocimiento de las cuestiones relacionadas con el diseiio del aspect0 y sensaci6n de un sistema, y para orientarse a la arquitectura fisica correspondiente. Disefie bien sus respuestas y, luego, vaya a1 ApCndice A, "Respuestas a 10s cuestionarios" para verificarlas.

Cuestionario 1. iQuC es un analisis de tareas? 2. iCual analisis de 10s que ya hemos hecho es un vago equivalente de un analisis de tareas?

3. iQuC se entiende por un diseiio de tipo "pantal6n de payaso"? 4. DC tres razones para restringir el uso del color en una GUI.

Ejercicios 1. Utilice un diagrama de estados UML para modelar la interfaz del usuario del chef. 2. Utilice papel y lhpiz para diseiiar a1 menos una de las pantallas de la interfaz del usuario del chef. Empiece por agrupar 10s casos de uso y, luego, ciiiase a las convenciones de la sesi6n JAD. Si puede utilizar Microsoft Visual Basic, o alguna otra herramienta para el diseiio visual de pantallas, intente utilizarla para completar este ejercicio. 3. Nuevamente, continlie con el analisis de las tareas que haya obtenido en su proyecto de la Biblioteca. No olvide hacer un analisis de la distribuci6n.

Nocion de 10s patrones de diseiio Ahora que ha comprendido 10s fundamentos del UML y ha visto cdmo utilizarlo en el context0 de un proyecto de desarrollo, finalizaremos la parte I1 con una semblanza de la aplicacidn del UML a un Area novedosa: 10s patrones de diseiio. En esta hora se tratarin 10s siguientes temas: Parametrizacih Patrones de diseiio Cadena de responsabilidad Uso de nuestros propios patrones de diseiio Ventajas de 10s patrones de diseiio En las 21 horas anteriores ha visto muy diversos temas. Desde 10s diagramas de clases hasta 10s de secuencias, desde 10s diagramas de estados hasta las sesiones JAD, la meta fue prepararlo para aplicar el UML en situaciones que ocurren frecuentemente en el mundo real.

Ahora, cambiaremos nuestro rumbo un poco. En esta hora exploraremos una de las aplicaciones del UML que, posiblemente, se haran mis populares. Esta aplicacion, la representaci6n de patrones de disefio, captura la esencia de las soluciones que han funcionado una y otra vez en proyectos y situaciones reales.

Parametrizacion En la hora 2, "Orientacibn a objetos", menciont que una clase es una plantilla para la generacidn de objetos. Le dije que podia concebir a una clase como un molde de galletas generador de nuevos objetos. Un objeto, recordara, es una instancia de una clase. Para ayudarle a recordar, veamos de nuevo el ejemplo de nuestra lavadora. La especificaci6n de la clase lavadora (0, para utilizar una notaci6n corrects, la clase Lavadora) incluia 10s atributos marca, modelo, numeroDeSerie y capacidad, y las operaciones agregarRopa(), agregarDetergente y quitarRopa0, con 10 que tendriamos una forma de generar nuevos objetos provenientes de nuestra clase Lavadora. Cada vez que queramos crear un objeto, asignaremos valores a 10s atributos. El propio UML le permite ir un paso mis allh. Le da un mecanismo para crear clases de una forma similar a la creaci6n de objetos. Podrii establecer una clase de manera que cuando asigne valores a un subconjunto de sus atributos habrii creado una clase en lugar de un objeto. A este tipo de clase se le conoce como clase parametrizada. Su representaci6n en el UML aparece en la figura 22.1. El cuadro punteado del extremo superior derecho contiene 10s parimetros a 10s que asignari valores para generar la clase. A estos se les llaman para'metros desvinculados. Cuando les asigne valores, 10s vinculari con ellos. La T del cuadro punteado es un clasificador que indica que la clase es una plantilla para crear otras clases.

FIGURA 22.1 El icono UML para una clase parametrizada.

He aqui un ejemplo. Suponga que establece un SerVivo como clase parametrizada. Los parimetros desvinculados podrian ser gtneros y especies, junto con 10s atributos estindar de nombre, estatura y peso, como se muestra en la figura 22.2. Si vincula a gtnero con "homo" y a especie con "sapiens", creara una clase llamada "Humano". El nombre de la clase se vincula con la T. La figura 22.3 le muestra una forma de representar tal vinculaci6n. Este estilo en particular se conoce como vinculacidn explicita porque muestra de manera explicita la clase generada en una relaci6n de dependencia con la clase parametrizada y le da a la clase generada su propio nombre.

FIGURA22.2 SerVivo cumo una clase parametrizada.

SerVivo

FIGURA22.3 Vinculacidn explicita de la clase parametrizada SerVivo. I

A I I

I I

: I

evincular(Humano, homo. sapiens)

0 Humano

Hay otro tipo de vinculaci6n que se conoce como vinculacidn implicita. En ella no se muestra la relacidn de dependencia, y las vinculaciones aparecen en una lista dentro de parkntesis angulares en el nombre de la clase generada. La figura 22.4 le muestra 10 anterior.

------------------T.genero:String, especies:Cadena:

Vinculacidn implicita de la clase parametrizada SerVivu.

Servivo

r'-

En cualquier caso, podri asignar valores a nombre, estatura y peso para generar objetos en la clase Humano.

Patrones de diseiio Es posible expandir la idea de la parametrizacibn. Cualquier clasificador UML puede ser parametrizado. De hecho, un grupo de clasificadoresque colaboren entre si pueden ser parametrizados, 10 que nos evitara entrar en situaciones desconcertantes. DespuCs de varias dCcadas de amplio uso, mismo que se incrernenta, la orientaci6n a objetos ha otorgado varias soluciones firmes a 10s problemas recurrentes. Tales soluciones se conocen comopatrones de diseiio, y han jugado un importante papel hltimamente. Como 10s patrones de diseiio han traspasado el mundo de la orientaci6n a objetos, son Eziles de conceptualizar, diagramar y reutilizar. A1 contar ahora con el UML, tenemos ur, lenguaje de modelado comun para explicarlos y diseminarlos. El primer librq que populariz6 a 10s patrones de diseiio fue "Design Patterns" (AddisonWesley, 1995). "\S autores (Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides) han sido reconocidos como el "Grupo de 10s cuatro". Un patr6n de diseiio es bhsicamente una soluci6n (un diseiio) que surge de la experimentaci6n practica con varios proyectos, y 10s equipos de desarrollo han encontrado que se puede aplicar en diversos contextos. Cada patr6n de disefio describe a un conjunto de objetos y clases comunicadas. El conjunto se ajusta para resolver un problema de disefio en un contexto especifico. En su libro, el grupo de 10s cuatro catalogd y destac6 a 23 patrones de diseiio fundamentales. Dividieron esos patrones en tres categorias de acuerdo con cada uno de sus propdsitos: (1) Patrones de creacidn que atafien a1 proceso de creaci6n de objetos, (2) Patrones de estructura que se orientan a la composici6n de clases y objetos, y (3) Patrones de comportamiento que especifican la forma en que las clases U objetos interactuan y distribuyen la responsabilidad. Posteriormente dividieron sus patrones de diseiio en tCrminos si se aplican a las clases U objetos. A este criterio 10 llarnaron a'mbito, y la mayoria de 10s Bmbitos de 10s patrones se encuentra a1 nivel de 10s objetos. Cada patr6n de disefio tiene cuatro elementos: ( l ) un nombre que nos permite describir un problema de diseiio en una palabra o frase, (2) un problema que define cuando aplicar el patrbn, (3) una solucidn que 2specifica 10s elementos que conforman a1 diseiio y c6mo colaboran, y (4) las consecuencias de aplicar el patr6n. Ahora veremos esas "situaciones desconcertantes" que indiquC con antenoridad: dentro de un modelo, podemos representar un patr6n de diseiio como una colaboracidn parametrizada en el UML. El patrdn de diseiio se expresa de una forma genCrica, con nombres genCricos para 10s colaboradores. El asignar nombres especificos del dominio hace que el patron se aplique a un modelo especifico. La colaboraci6n parametrizada le ayuda a visualizar 10s detalles especificos dentro del contexto del patr6n.

Cadena de responsabilidad Examinemos un patron de diseiio y veri 10 que quiero decir. La Cadena de responsabilidad es un patron de comportamiento que se aplica a cierta cantidad de dominios. Este patron se encarga de la relacion entre un conjunto de objetos y una peticibn. Aplicara este patron cuando mhs de un objeto pueda manejar una peticibn. El primer objeto en la cadena obtiene la peticion y la resolver&o se la enviarh a1 siguiente objeto de la cadena, hasta que uno de ellos pueda manejarla. El objeto que originalmente hizo la peticion no sabe cual de 10s objetos la manejara. El objeto que a1 final maneje la petici6n se conoce como un receptor implicito. Los restaurantes estan establecidos de esta forma, a1 igual que 10s distribuidores de autom6viles cuando financian la adquisici6n de autom6viles. Por 10 general, en un restaurante un cliente no envia una peticidn directamente a un chef ni sabe quC chef preparara su platillo. En vez de ello, el cliente le da una orden a un mesero, el mesero se la lleva a1 chef, quien podri cumplir con ella o dhsela a uno de sus asistentes (de cualquier forma, asi ocurre con 10s supuestos restaurantes de LaHudra, Nar y Goniff). Con un distribuidor de autombviles, el agente de ventas pasa el pedido de prCstamo a diversas instituciones financieras hasta que alguna decide otorgar el prkstamo. Las ligas de deportes profesionales implementan este patron cuando un equipo pone transferible a un jugador. El equipo con la peor marca tendri una oportunidad de solicitar a1 jugador. Si decide no hacerlo, el equipo con la siguiente peor marca tendri la oportunidad, y asi sucesivamente. El equipo que puso transferible a1 jugador no necesariamente sabe quC otro equipo se quedara con C1 (vea el Ejercicio I). Ahora que ha visto el patron de diseiio Cadena de responsabilidad en algunos contextos, ya esta preparado para comprenderlo de manera abstracta. Los participantes en este patron serfin un Cliente, un Controlador abstracto y Controladores concretes que provengan del Controlador abstracto. El Cliente inicia una peticion; si un Controlador (concreto) puede ocuparse de la peticibn, asi 10 hara; si no, pasari la peticidn a1 siguiente Controlador abstracto. La figura 22.5 le muestra la forma en que luce esta estructura. La idea de este patron es liberar a un objeto de que tenga que saber quC otro objeto realizara su peticion. Le da una flexibilidad adicional cuando asigne responsabilidades a 10s objetos. La desventaja es que el patron no garantiza que algiin objeto maneje la petici6n. Por ejemplo: ningiin equipo de fiitbol contrataria a un jugador que haya sido puesto como transferible.

FIGURA22.5 La estructura del patrdn de diseiio Cadena de responsahilidad.

Controlador Cliente

I I I

manejarPeticion( )

Sucesor

ControladorConcretol

1 l ControladorConcreto2

Observe la asociaci6n reflexiva en la clase Controlador abstracto. El grupo de 10s cuatro intent6 mostrar que usted tendra la opcidn de que el Controlador implemente un vinculo sucesor (en algunos contextos, 10s objetos saben c6mo encontrar a sus sucesores). He decidido representar tal implernentacion con una clase asociacion como en la figura 22.5, para permitir que mas adelante se puedan agregar atributos a1 sucesor.

Cadena de responsabilidad: dominio Restaurante En el dominio Restaurante, el Controlador abstracto es la clase Empleado, y 10s Controladores concretos son el mesero, el chef y el asistente. El Cliente es, en si, el propio cliente, quien podria iniciar una petici6n, como hacer una orden, y no saber quiCn la llevari a cabo. A1 sustituir 10s nombres especificos del dominio de la figura 22.5 nos deja la figura 22.6.

El patron de diserio Cadena de responsabilidad en el dominio del restaurante.

Empleado Cliente

I

A

Mesero manejarPeticion()

-

n I

manejarPeticion()

Sucesor

Chef

Asistente Chef

manejarPeticion( )

manejarPeticion( )

La figura 22.6, aunque es un util diagrama, no nos muestra la forma en que 10s nombres especificos del dominio encajan en el patrdn. Para mostrar el contexto, utilizaremos una colaboracidn parametrizada, como en la figura 22.7. FIGURA22.7 Una colaboracidn parumerrizada pura representar la Cadena de responsabilidad en un restaurante.

Empleado

.

'

Controlador

,:>C--------.\

.

'Eontrolador~oncretol

:

~ontrolador~oncreto;*O\"tr0'ad0rC0ncret03

AsistenteChef

En la figura 22.7, el dvalo punteado representa la colaboracidn que hay en el patr6n de disefio, de alli el nombre dentro del dvalo. Los cuadros que 10 rodean representan a 10s colaboradores. Las dependencias muestran que la colaboracidn depende de 10s colaboradores. La etiqueta en una dependencia indica el rol que juega el colaborador dependiente dentro del patrdn. La colaboraci6n se ha parametrizado con la adicidn de 10s nombres de clases especificas del dominio.

Cadena de responsabilidad: Modelos de eventos de 10s exploradores Web Cuando se desarrollan paginas Web interactivas, un disefiador debe tomar en cuenta el mode10 de eventos del explorador que las abrira. En Internet Explorer, puede escribir cddigo de JavaScript o VBScript para reaccionar a un evento, como el clic en un botdn. Este c6dig0, conocido como "controlador de evento", establece 10s cambios (en caso de haberlos) que habra cuando se haga clic en un botdn. En un document0 HTML, podra dividir una pagina en heas conocidas como DIV, y subdividir a un DIV en formularies. Puede colocar un botdn dentro de un formulario. jLe suena a objeto compuesto? iC1ar0, porque eso es! Cada element0 es un componente del documento, y ciertos componentes son parte de otros. La Gamma lista a 10s objetos compuestos como uno de sus patrones de disefio, y se usa con frecuencia junto con el patrdn de Cadena de responsabilidad. La relacidn entre componente y objeto compuesto implementa 10s vinculos de 10s sucesores. Cuando le m o s d el diagrama de clases de la Cadena de responsabilidad, le mencionC a modo de aclaraci6n que en ciertos contextos 10s objetos saben e uno de esos contextos. cdmo localizar a sus propios sucesores. ~ s t es

Cuando se coloca el b o t h en un formulario dentro de un DIV cuyo documento se abre en Internet Explorer, el evento de hacer clic en C1 iniciarh con el bodn en si, pasarh a1 formulario, luego a1 DIV y, finalmente, a1 documento que 10 contiene. Cada uno de estos elementos puede tener su propio controlador del evento hacer clic en el b o t h , el cual reaccionarh ante tal evento. Si una secuencia de comandos que se encuentre en el documento establece de forma dinhmica cuhl de 10s controladores de eventos del element0 se ejecuta, la secuencia de comandos sera una instancia del patr6n de diseiio de la Cadena de responsabilidad. La figura 22.8 le muestra el diagrama de clases, y la 22.9 le muestra la colaboraci6n pararnetrizada para este patr6n de diseiio aplicada a1 mode10 de eventos del Internet Explorer.

Diagrarna de clases de la Cadena de responsabilidad en una pkgina Web que se abre en Internet Explore,:

ElementoDeLaPaginaWeb Usuarlo

I

l I I I

controladorDeEvento( )

n

A

Sucesor

controladorDeEvento( )

Document

Form

Dlv

controladorDeEvento( )

controladorDeEvento( )

Button

controladorDeEvento( )

FIGURA22.9 La Colaboracidn parametrizada para la Cadena de responsabilidad en una pagina Web que se abre en Internet Explore,:

ElementoDeLaPaginaWeb

3 0 0

Controlador

.,.. -------

'

.Cc

I

'

0 0

-.'

Cadena de responsabilidad

0

ControladorConcreto4

Netscape Navigator tambitn cuenta con un modelo de eventos. Su modelo es, exactamente, 10 opuesto a1 de Internet Explorer. En Navigator, el element0 de mayor nivel (el documento) primero obtiene el evento y 10 pasa hasta que 10 lleva a1 que 10 origin6. iC6m0 cambiaria a1 diagrama de clases de la figura 22.8 para modelar a1 modelo de eventos de Navigator? (Vea el Ejercicio 2.)

lnternet Explorer llama a su modelo de eventos burbujeo de eventos. Navigator lo llama captura de eventos.

Nuestros propios patrones de diseAo Aunque el Grupo de 10s cuatro saltaron a la fama por su catiilogo de patrones de disefio, no establecieron que sus patrones fueran 10s unicos posibles. AI contrario, intentaron alentar el descubrimiento y uso general y propio de 10s patrones. Para darle una idea de la forma en que surgen tales patrones, recuerde 10 que hicimos en la hora 1 1, "Diagramas de actividades". Durante esa hora, vio un ejemplo de c6mo tratar con 10s numeros de Fibonacci y un ejercicio referente a 10s numeros triangulares. iCu6les fueron las caracteristicas en comun? Cada uno empezo con un valor o conjunto de valores iniciales, sigui6 con una regla para acumular numeros y finaliz6 con el enCsimo numero de la serie. Llamemos a este patr6n "Calculadora de series". Aunque podriamos implementarlo en un objeto, hagamoslo en un conjunto de objetos colaboradores para ilustrar algunos conceptos de 10s patrones de disefio. La Calculadora de series cuenta con tres participantes: ValorInicial (que puede contener uno o miis valores), ReglaDeAcumulacion y ValorFinal. La figura 22.10 muestra el diagrama de clases de este patr6n. El valor inicial estii en un atributo llamado primero. Si es necesario un segundo valor inicial, como en el caso de 10s numeros de Fibonacci, se especifica en un atributo llamado segundo. En ocasiones, como en el caso de 10s factoriales, el patr6n necesitari un valor para el tCrmino cero. El algoritmo para la ReglaDeAcumulacion se implementa en la operaci6n acumularo. La cantidad de tCrminos por calcular esta en el enisimo atributo en ReglaDeAcumulacion. En la colaboraci6n, ReglaDeAcumulacion obtiene el (10s) valor(es) inicial(es) de ValorInicial, aplica la regla la cantidad de veces indicada y envia el resultado a ValorFinal para que sea mostrado. La figura 22.1 1 muestra la interaction.

ValorFinal

La estructura de clases pura nuestro patron de diseiio Calculadora de series.

1-1 Obtener valores iniciales de

del patron de diseiio Calculadora de series.

Enviar resultado a

enesimo:lnteaer

mI El Valorlnicial

La interaccihn dentro

ReglaDeAcurnulacion

ValorFinal

ReglaDeAcumulacion

I I

I l I

I I

I

I

I

I Establecer

I I

valores iniciales

I I

l

I

acumular(ValoresIniciales,enesimo) Establecer Resultado

m I I I I

I

mostrarResultado(resultado)

I

I

I

I

I I

I I I

I

I

I I

I

I

Para aplicar este patron de diseiio a la serie de nlimeros triangulares, adoptaremos algunos nombres de la numeracidn triangular para las clases y mostraremos la colaboracion parametrizada de la figura 22.12.

La colaboracidn parametrizada para la Calculadora de Numeros triangulares.

I

R 1 \

I

'.... .

Valor inicial >-

.

,----, - S

: Calculadora de series

!

Como buena medida, mostraremos la colaboracidn parametrizada para una calculadora de factorial en la figura 22.13.

FIGURA 22.13 La colaboraci6n paramerrizada para una calculaclora de Factorial.

InicioFactorial

Valor inicial

\,

l.--------, : \

. \

.!

Calculadora de series

\

'

/ 0'

5

, Regla de acumulacion

/

Valor final

',.

Ventajas de 10s patrones de diserio Los patrones de disefio son litiles en diversas maneras. Para empezar, promueven la reutilizacidn. Si ha expresado un diseiio bien fundamentado como patrdn, 10 habra hecho sencillo para usted y otros que con C1 trabajen nuevamente. A su vez, le dan una forma clara y concisa de hablar y pensar respecto a un grupo de clases U objetos que funcionen en conjunto para resolver un problema. Esto aumenta la posibilidad de que utilice a1 patrdn como un componente de un diseiio. Finalmente, si utiliza patrones en su diseiio, posiblemente se le facilitara documentar el sistema que haya generado.

Resumen Una clase parametrizada tiene parimetros desvinculados. El vincular a tales parametros dara como resultado la creacidn de una clase. Cualquier clasificador UML podra estar parametrizado. Una colaboracidn parametrizada sirve como la representacidn de un patrdn de diseiio: una solucidn que es 6til en diversos dominios. Un patrdn de diseiio, la "Cadena de responsabilidad", se ocupa de que 10s objetos pasen una peticidn entre ellos hasta que uno pueda manejarla. Este patrdn proviene del libro mis conocido en patrones de diseiio, escrito por un grupo de autores conocidos como "El grupo de 10s cuatro". Nuestros propios patrones de diseiio surgen del trabajo que hicimos en la hora 1 1 en 10s diagramas de actividades. Podemos crear un patrdn de diseiio para una calculadora que determine el enCsimo valor de una serie aritmCtica. Los participantes en este patron son . Valorlnicial, ReglaDeAcumulacion y ValorFinal.

Los patrones de diseiio ofrecen varias ventajas. Permiten que 10s diseiiadores vuelvan a utilizar con facilidad las soluciones ya probadas, incorporar componentes s6lidos en 10s diseiios y documentar claramente 10s sistemas que generen.

Preguntas y respuestas P ;Qui tan dificil es "descubrir" 10s patrones de diseiio? R No es cuestidn de dificultad, sino de experiencia. Conforme avance en su carrera de analista y diseiiador, verh que hay ciertas cosas que se repiten una y otra vez y desputs de un tiempo tratarit de aprovechar esas circunstancias regulares. Los estudios muestran que 10s expertos en un dominio en particular piensan en ttrminos de patrones y tratan de aplicarlos siempre que pueden. P ;Los patrones ~610son utiles en el diseiio? R No. Los patrones pueden surgir en cualquier moment0 del proceso de desarrollo o en cualquier campo de accibn. El Grupo de 10s cuatro se inspir6 en el trabajo de un arquitecto que pens6 en recurrir a patrones para el diseiio de 10s edificios.

Taller Las preguntas y ejercicios en este taller le llevarhn a pensar respecto a algunas caracteristicas avanzadas del UML. Vaya a1 Aptndice A, "Respuestas a 10s cuestionarios", para encontrar las respuestas.

Cuestionario 1. iC6m0 representaria a una clase parametrizada?

2. iQuC es "vincular" y cuhles son 10s dos tipos de vinculacibn?

3. iQut es un "patr6n de diseiio"? 4. iQuC es el patr6n de diseiio "Cadena de responsabilidad"?

Ejercicios 1. Aplique el diagrama de clases del patr6n diseiio Cadena de responsabilidad a1 proceso de transferencia que se realiza en las ligas deportivas profesionales. 2. Modifique el diagrama de clases de la figura 22.8 de mod0 que deje entrever el mode10 de eventos de Netscape Navigator. Como ya 10 indiqut anteriormente, un evento en Navigator se inicia a1 nivel del documento y pasa por 10s distintos elementos hasta que llega a1 que 10 originb. El element0 originador podria localizarse a varios niveles por debajo del documento HTML.

Vision del futuro Hora 23

Modelado de sistemas incrustados

24 El futuro del UML

Modelado de sistemas incrustados Esta vez vera 10 referente a sistemas de cbmputo que no se basan en sistemas de escritorio, laptops o en palmtops. En vez de ello, estarin incrustsdos dentro de aparatos como aviones, trenes y autombviles. En esta hora se trataran 10s siguientes temas: ~ Q u Cson 10s sistemas incrustados? Conceptos de 10s sistemas incrustados Modelado de un sistema incrustado en el UML LaHudra y sus intripidos socios, Nar y Goniff, han tenido buenas ganancias de su Divisibn de Restaurantes LNG. El servicio es tan bueno y las comidas tan deliciosas que la gente llega por miles para probarlas dentro de una atmbsfera de eficiencia y amistad.

Hay dos problemas que deterioran su otrora buena fortuna. Conforme leen 10s informes mensuales, la terrible tendencia ha continuado. "Miren esto", dijo Nar dindoles 10s escritos a Goniff y LaHudra. "Estamos haciendo mucho dinero, pero deberiamos hacer m&. Parece que 10s meseros estin rompiendo mis losa de la aceptable."

"Si, ya 10 habia advertido", dijo Goniff. "Cada vez que rompen un plato lleno de comida, el cocinero tiene que preparar otra vez el plato. Y tenemos que pagar el nuevo plato." "~Realmenteimporta si algunos de nuestros meseros tienen las manos torpes?", pregunt6 LaHudra. "Claro que S?', respondid Goniff. "Un par de platos aqui, otros alli, pronto las pCrdidas serin considerables. Pero hay algo de 10s meseros que me esti molestando mls." "iY quC es?', pregunt6 Nar. "Los reportes indican que se estan enfermando demasiado. Es bueno eso de que tengamos toda esta tecnologia en 10s restaurantes. Nos ayuda cuando tenemos que trabajar con limitaciones en el personal: por 10 general 10s meseros pueden hacerse cargo de mayores secciones de 10 que podrian normalmente." "Veamos quC ocurre", dijo LaHudra.

La madre de la invencion Los tres socios entrevistaron a varios de 10s meseros que se habian enfermado con frecuencia en 10s dos dltimos meses, e hicieron un asombroso descubrimiento: 10s platos rotos y 10s dias de enfermedad estaban relacionados. Los meseros habian estado manejando y empufiando sus palmtops tanto que sus mufiecas habian comenzado a debilitarse. Tal como una saliente puede hundir embarcaciones, una mufieca dCbil puede dejar caer 10s platos. Lo que es mis, habian tenido tanto dolor en sus mufiecas que no podian ir a trabajar.

NO podriamos ayudar a estas personas de alguna forma?',

pregunt6 desconsolado Nar.

"iY en el proceso ayudarnos a nosotros mismos?', contra argument6 el oportunista Goniff. "Tal vez haya alguna forma de que les ayudemos a mejorar sus fuerzas y sus mufiecas", dijo LaHudra. "Bien, iquC haremos?" pregunt6 Goniff, "jcomprar a cada uno un ejercitador de mufiecas?" "Podria ser peor", dijo LaHudra, "pues no sC quC tan efectivos sean tales ejercitadores. Podria ser eterno el proceso de curacion de nuestro personal".

"Con todo, la idea es buena", dijo Nar, "tal vez s610 necesitemos un ejercitador de mufiecas mejor que el que se pudiera adquirir en algun establecimiento". "iEn verdad? iC6m0 podriamos hacer un mejor ejercitador de mufiecas?', pregunto LaHudra. No tuvo que esperar mucho la respuesta. Nar estaba en uno de sus papeles de querer patentar. "Recuerdo que mucha gente cree que la mejor y mis eficiente forma de ejercitarse es aquella que genera el mayor reto, cuando sus mlisculos estfin trabajando a su maxima potencia. Si podemos crear un ejercitador de mufiecas que aumente su resistencia conforme 10s musculos del antebrazo trabajen mhs, apuesto que mejoraremos la fuerza de las mufiecas de nuestros meseros en la mitad del tiempo que ocuparian con un ejercitador de mufiecas comlin." "Y, jc6m0 hariamos eso?'se preguntaba el siempre pragmatic0 LaHudra. "Tal como revolucionamos a1 negocio de 10s restaurantes", dijo Nar, "con tecnologia". "A ver, espCrame", dijo LaHudra, "10 que hicimos en 10s restaurantes requiri6 el uso de computadoras. ~Realmentequieres decirme que agregaremos una computadora a un ejercitador de mufiecas?"

"iY por quC no?'dijo Nar. ''icierto! iPor quC no?', replic6 Goniff. "Ya te entendi, Nar. Y cuando terminemos de generar este aparato, podriamos comercializarlo. Y ya tengo el nombre perfecto: ~ Q u Ctal 'LNG TecnoApret6n'?" "Creo que me esta gustando", dijo, con cautela, LaHudra. "Ya me gusta", indic6 Nar, con entusiasmo. "~D6ndeest8 ese equipo de desarrollo?"

Creacion de TecnoApreton El equipo de desarrollo de RICO se ha vuelto a reunir. Su nueva misi6n sera la de generar TecnoApreton, una pulsera "inteligente" para la mufieca y el antebrazo que dC una resistencia variable durante 10s movimientos repetitivos de un ejercicio: cuanto m8s trabajen 10s musculos, mayor sera la presion de TecnoApreton. Durante la realization de la idea, el equipo hizo algunas investigaciones para ver c6mo medir quC tanto trabaja un musculo. Aprendieron 10 referente a sefiales elCctricas de las fibras activas de 10s mlisculos. Tales sefiales, llamadas EMG (siglas de sefiales Electromiograficas), son el fundamento de fascinantes dispositivos que permiten a 10s discapacitados manejar equipo electronico.

Esto n o sera u n tratado de ciencia-ficcion. En 10s primeros aiios de la decada de 10s noventa, el neurocientifico David Warner del Centro Medico de la Universidad Lorna Linda coloco electrodos en el rostro de u n muchacho y lo conecto a una cornputadora. El muchacho, completamente paralizado del cuello para abajo en u n accidente automovilistico, pudo mover objetos en la pantalla de la computadora al tensar algunos de sus musculos faciales. Para aprender mas respecto a esta emocionante area, lea el articulo de Hugh S. Lusted y Benjarnin Knapp, "Controlling Computers w i t h Neural Signals", en la revista de octubre de 1996 de Scientific American.

El equipo concluyd que podrian capturar estos EMGs mediante pequeiios y econdmicos "electrodos de superficie" colocados en el antebrazo, pasar 10s EMGs capturados por una computadora y, luego, utilizarlos como base para que la computadora ajuste la resistencia en el ejercitador de muiiecas. Esto trae consigo la captura y analisis de datos en tiempo real, dad0 que 10s ajustes tienen que hacerse tan pronto como el mlisculo se contrae. Una posibilidad del diseiio seria colocar el electrodo de superficie en el antebrazo, conectarlo a una computadora de escritorio para que analice 10s EMGs y haga 10s ajustes necesarios al ejercitador de muiiecas. La ventaja seria que posibilitaria la presentacidn de diversos datos en la pantalla, imprimir informes del progreso, y analizar las tendencias. No obstante, la desventaja seria que la persona quedm'a atada a la computadora. Otra posibilidad es la de incrustar un chip de computadora directamente en el ejercitador de muiiecas para que la persona pueda moverse a donde desee mientras utilice TecnoApretdn. La figura 23.1 muestra cdmo luciria este diseiio. En cada repeticidn del ejercicio, la persona aprieta la barra de constriccidn y la mueve hacia la barra base. La ventaja del diseiio incrustado seria que el usuario podria utilizar un dispositivo como Cste en casi cualquier lugar (si la computadora tiene suficiente energia en las baterias). La desventaja, claro, es la pCrdida de la informaci6n potencial que pudiera almacenar y mostrar una computadora de escritorio. Las sesiones JAD dejaron entrever que todos sen'an mis felices con el segundo diseiio, y ell0 nos lleva hacia el mundo maravilloso de 10s sistemas incrustados.

La versio'n en sistema incrustado de TecnoApretdn.

I.

0

Computadora incrustada, lnterfaz con 10s resortes y Accionador Resortes

I Barra de constriccion

U Barra base

@

Electrode de superficie

L Q Ues ~ un sistema incrustado? A estas alturas, ya sabe que las computadoras estan por doquier. Lo que tal vez no sepa es quC tanto territorio abarca ese "doquier". Las computadoras que ve a su alrededor son s610 la punta del tCmpano. Muchas de ellas se encuentran ocultas en lugares de dificil acceso: dentro de 10s electrodomCsticos, automdviles, aeroplanos, maquinaria de fabrica, dispositivos biomCdicos y otros. Hay procesadores medianamente poderosos dentro de las impresoras. Todas esas computadoras que no se ven a simple vista son ejemplos de sistemas incrustados. Siempre que tenga un dispositivo "inteligente", tendri un sistema incrustado. Los sistemas incrustados no tienen teclados y monitores que interaccionen con nosotros, en vez de ello, cada uno es un chip que se encuentra dentro de un dispositivo (como un aparato electrodomCstico), y ese dispositivo no se parece para nada a una computadora. El sistema incrustado decidira quC debe hacer el dispositivo. Si utiliza un sistema de este tipo, no tendra la sensacidn de trabajar con una computadoEn vez de ello, estara interactuando con un dispositivo. Le apuesto que nunca sabra que hay un chip de computadora dentro. Cuando tuesta una rebanada de pan, no le preocupa que un chip de computadora este distribuyendo el calor -s610 quiere su pan tostado. rd.

Cuando termina de trabajar con su computadora, la apaga. Un sistema incrustado por 10 general no se puede dar esos lujos. Una vez que se le coloca, un sistema tiene que trabajar por dias o aiios (como en un marcapasos). Si un procesador de textos o una hoja de cilculo tienen un error y su sistema se colapsa, simplemente vuelve a arrancarlo. Si el software en un sistema incrustado falla, 10s resultados pueden ser desastrosos. Por lo tanto, un sistema incrustado no realiza el cdmputo de la forma habitual. Se le coloca para ayudar a otro tipo de dispositivo a hacer su trabajo. El otro dispositivo es el que es manejado por el usuario y se integra a1 entomo. Como podri imaginar, programar un sistema incrustado no es para novatos. Requiere mucho conocimiento del dispositivo donde se encontrari el sistema: quC tipo de seRales enviari, quC tipo de parimetros de cronometraje tendri y otras cosas.

Conceptos de 10s sistemas incrustados Veamos de cerca 10s sistemas incrustados y lo que comunmente tienen que hacer. En las siguientes subsecciones examinaremos algunos de 10s conceptos mis importantes de un sistema incrustado.

Tiempo Si revisa el tema hasta donde vamos, veri que el tiempo se destaca en el mundo de 10s sistemas incrustados. De hecho, el tiempo es la base para clasificar a 10s sistemas incrustados como tolerantes o estrictos. Un sistema tolerante hace su trabajo tan pronto como sea posible sin tener que cumplir con plazos especificos. Un sistema estricto tambiCn tiene que hacer su trabajo tan pronto como sea posible, per0 deberi finalizar sus tareas de acuerdo con plazos rigurosos.

Subprocesos En el mundo de 10s sistemas incrustados, un subproceso (que tambiCn se conoce como tarea) es un simple programa. Es una secci6n de una aplicacidn, y realiza cierto trabajo significativo dentro de ella. Intenta obtener toda la atenci6n de la CPU. La mulritareu es el proceso de programar el tiempo de la CPU para que trabaje con varios subprocesos y atienda a uno y otro. Cada subproceso cuenta con un numero que establece su prioridad dentro del programa de aplicacidn, y que se relaciona -por lo general- con uno de seis estados: inactive: esta en la memoria y no se ha hecho disponible a1 sistema operativo

listo: puede ejecutarse, pero el subproceso que esta en ejecucion tiene una prioridad mayor

suspendido: se ha intermmpido a si mismo por cierto tiempo a la espera de un evento: algo debe ocunir para que se ejecute ejecucidn: cuando esti siendo atendido por la CPU interrumpido: poque la CPU se esti ocupando de una iizterrupcidn La figura 23.2 le muestra un diagrama de estados que representa a estos estados y las transiciones entre ellos. Observe la ausencia de un simbolo de inicio y otro de fin. Esto le indica que el subproceso fluye de un estado a otro en un ciclo infinito. FIGURA23.2

Eliminar subproceso

Estudos de un suhproceso en unu aplicucio'n de un sisternu incrustado.

A

Evento

Crear subproceso Eliminar subproceso

Esperar

L

vv

lnterrupcion procesada Ejecuc~on

Listo

v

lnactivo

A Eliminar subproceso Suspender subproceso

Eliminar subproceso

Petition de interrupcion V

lnterrump~do

W

Suspendido

Por cierto, iquC es una "intermpcion"? Continue leyendo.

lnterrupciones Una interrupcidn es un element0 pequeiio de mucha importancia en un sistema incrustado. Es un mecanismo basado en hardware que le indica a la CPU que ha acontecido un evento asincronico. Un evento es asincronico si sucede de forma impredecible (esto es, fuera de sincronia). Por ejemplo: en el TecnoApreton, las seiiales EMG llegan de forma asincr6nica. Cuando la CPU reconoce una interrupcion, guarda 10 que estaba haciendo e invoca a un ISR (Rutina para el servicio de interrupciones) que procesa a1 evento. Cuando el ISR finaliza su trabajo, la CPU continua con 10 que hacia cuando sucedid la interrupcion.

Despues de procesar una interrupcion. el lugar a donde regresara la CPU se determina por el tip0 de sistema operativo que en ella se ejecuta, como l o vera posteriormente.

Las intermpciones son importantes dad0 que permiten que una CPU se libere de lo que estd haciendo y procese 10s eventos conforme suceden. Esto es trernendamente significativo para un sisterna en tiernpo real que tenga que responder a eventos del entorno de manera oportuna. Ya que la puntualidad es tan importante, 10s sisternas incrustados tienen que ocuparse del curso del tiempo en una intermpcidn y su procesamiento, aunque tal lapso pudiera parecer infinitesimal. La CPU tiene que tornar algo de tiempo desde que se le notifica de la intermpcion hasta que guarda lo que estaba haciendo (esto es, su contwto). A ello se le conoce como latenciu de la interrupcidn. La respuesta de la interrupcihn es el tiempo entre la llegada de la peticidn de intermpcion y cuando la CPU inicia el ISR. AI finalizar el ISR, la recuperacidn de lu interrupcicin es el tiempo que le lleva a la CPU regresar a donde estaba -a su contexto- cuando ocunid la intermpcion. Hay un tipo de intermpcidn especial: 10s ciclos del reloj. Como un "latido de corazdn" del sistema, el ciclo del reloj sucede en intervalos regulares especificos de una aplicacicin (por lo general entre 10 y 200 microsegundos). Los ciclos del reloj deterrninan las restricciones de tiernpo de un sistema incrustado. Por ejemplo: un subproceso en estado suspendido permanecera asi durante una cantidad especifica de ciclos.

Sistema operativo Un sistema operativo en tiernpo real (RTOS) funciona como un policia de trhnsito entre 10s subprocesos y las intermpciones; media la comunicacion entre subprocesos y entre una intermpcion y un subproceso. El nucleo o kernel es la parte del RTOS que adrninistra el tiempo que utiliza la CPU en subprocesos individuales. El programador del nucleo determina cud1 subproceso se ejecuta despuCs. Como 10 mencionk, cada subproceso tiene una prioridad asignada. Los nucleos pueden ser preferenciales o cooperatives (no preferenciales), de acuerdo con la forma en que se encarguen de las intermpciones. En un nucleo cooperativo cuando se termina la ejecucidn de un ISR, la CPU regresa a1 subproceso en que se encontraba cuando llegd la peticidn de intermpcion. Un nucleo cooperativo se dice que se involucra en la rnultitarea cooperativa. La figura 23.2 se aplica a1 nlicleo cooperativo, Por otro lado, en un ndcleo preferencial, cuando finaliza un ISR, la CPU verifica la prioridad de 10s subprocesos que se encuentren en el estado de Listo. Si uno de 10s subprocesos tiene una mayor prioridad que la tarea intermmpida, la CPU ejecutara dicho subproceso en lugar de aquCl en el que se encontraba cuando se recibio la peticidn de intermpci6n. Por ello, la tarea de mayor prioridad tiene preferencia sobre la tarea intermrnpida. La figura 23.3 muestra la modificacion a dos de 10s estados en la figura 23.2, para modelar al nlicleo preferencial.

FIGURA 23.3 Modijicacidn de transiciones enrre dos estados en la figura 23.2 para rejlejar lo que ocurre en un nucleo preferencial.

Cambio de context0

La Figura 23.4 modela el nlicleo cooperativo como un diagrama de secuencias, y la figura 23.5 hace 10 propio para el n6cleo preferencial. FIGURA 23.4 Diagrama de secuencias para el nicleo cooperativo.

lnterrupcion I I

I I

I I

Ejecucion

I

I

Cambio de estado

I I

I

I

-se transforma enll

procesar ISR

I I I I I I I I I

Camblo de estado

'

7

-se transforms en,,

I

0 Ejecucion

Microsoft ernpezo a reducir la brecha hacia el dorninio de 10s sisternas incrustados. Esta cornercializando, de Windows CE, el sisterna operativo para dispositivos de rnano, al igual que para sistemas incrustados. Windows CE esta generado de forrna modular. Para ajustarse a una CPU en particular y a una aplicacion incrustada, solo requiere utilizar 10s rnodulos que necesite para que funcione. La ventaja de utilizar Windows CE es que podra utilizar el popular conjunto de herrarnientas de Microsoft junto con Visual C++ para generar un sistema incrustado.

FIGURA 23.5 Diagrama de secuencias para el nucleo preferential.

1_1

I

lnterrupcion I

I

I

I

I I I

Peticion de

SubprocesoBajaPrioridad

I

Ejecucion

I l

i

II

SubprocesoAltaPrioridad

Cambiar estado

I I

I

I

l

I

I

I

i I

I

I

-se transforma enn

1

I Cambio de estado I

I

I I

I

I

I,

use transforma I en*

Aunque hemos visto bastantes fundamentos, tenga en cuenta que s610 hemos visto cuestiones superficiales de 10s sistemas incrustados.

Modelado de TecnoApreton De regreso a la tarea (jsubproceso?) que dejamos suspendido, empezaremos a crear un mode10 para TecnoApretbn. Aunque no es el caso de que todos 10s sistemas incrustados esttn orientados a objetos, aun podemos utilizar tal orientacidn para modelar a1 sistema y su comunicacidn con el mundo exterior. A partir de nuestro tema de 10s sistemas incrustados, es claro que tenemos que tomar en cuenta el cronometraje, 10s eventos, 10s cambios de estado y las secuencias.

Clases Como en el caso de cualquier otro tip0 de sistema, empezaremos con las clases. Para comprender la estructura de clases, empezaremos con una descripcidn resumida de TecnoApretdn y la forma en que funciona. Este resumen pudo haber sido el resultado de un analisis del dominio. He aqui la descripcidn. TecnoApretdn consta de un electrodo de superficie, una CPU, un accionador (para realizar 10s comandos de ajuste provenientes de la CPU), y un conjunto de cinco resortes. El accionador se conecta a 10s resortes mediante una interfaz mechica. TecnoApretbn recibe seiiales EMG asincrdnicas de un electrodo de superficie y las pasa a la CPU. Cada EMG provoca una peticidn de intermpcibn, misma que la CPU tratarh

con un ISR. El software en la CPU analiza las seiiales. Cuando el anhlisis esth completo, la CPU envia una seiial a un accionador para ajustar la tensidn en 10s resortes. El actuador hace el ajuste mediante el manejo de la interfaz mechnica con 10s resortes. La figura 23.6 muestra una estructura de clases que resume a1 p k a f o anterior. Observe que el borde de la CPU esth en negritas, 10 que indica que es una clase activa. La idea es que la CPU siempre tendrfi el control (en la recepcidn, anhlisis de seiiales y la administracidn de 10s ajustes). TambiCn realiza algunas tareas internas del sistema. Observe, a su vez, el uso de una clase de asociacidn para MensajeDeAjuste, que nos permite establecer parhmetros a1 mensaje. FIGURA23.6 Estructura de clases

SenialEMG y MensajeDeAjuste son importantes, asi que nos enfocaremos en ellos. El sistema estarh interesado en el moment0 en que llegue una seiial y su potencia, por 10 que horaDeLlegada y amplitud parecen ser atributos razonables para SenialEMG. A su vez, la SenialEMG tendrh indudablemente caracteristicas complejas que esthn fuera del hmbito de este tema. Para MensajeDeAjuste, tanto horaDeGeneracion y cantidadAjuste parecen ser atributos razonables. La figura 23.7 muestra 10s atributos de estas clases.

FIGURA 23.7 Una mirada ma's cercana a SenialEMG y MensajeDeAjuste.

SerialEMG amplitud

Casos de uso La sesi6n JAD que menciont anteriormente (que dio por resultado la decisidn de diseiiar un sistema incrustado en lugar de una computadora de escritorio), tambiCn dio por resultado varios casos de uso, como se aprecia en la figura 23.8. FIGURA 23.8 Los casos de uso de TecnoApretdn.

Estos casos de us0 determinan las facultades por generar en el sistema. "Encender" incluye a "Realizar una auto-prueba" la cual, a su vez, incluye "Verificar el electrodo" y "Verificar la CPU". "Seleccionar uso" se refiere a diversas formas de ajustar el TecnoApret6n, muchas de las cuales no se le ocunieron a1 Sr. Nar cuando pens6 en este dispositivo. Por ejemplo: 10s participantes de la JAD dijeron que les gustaria establecer repeticiones "negativas": una resistencia limitada cuando aprieten las barras, y una m6xima cuando dejen de apretar. Esto significa que debemos agregar un atributo a MensajeDeAjuste para reflejar el uso del sistema. Podnamos llamarlo algoritmoDeUso y darle 10s valores posibles de aumentarTension y repNegativa. La figura 23.9 muestra la clase MensajeDeAjuste modificada.

FIGURA23.9 La cluse MensajeDeAjuste mod~j?cada.

lnteracciones Ahora prestemos atencidn a "Apretar la barra", y asumamos que la persona ha seleccionado el mod0 originalmente concebido: incrementar la resistencia al incrementarse la actividad muscular. En esta parte del modelo, tenemos que asegurarnos de considerar restricciones de tiempo y cambios de estado. Asumamos que un intervalo de ciclos del reloj es de 20 microsegundos, y que el lapso desde que se recibe una seiial hasta enviar un mensaje de ajuste no debera ser mayor de 10 ciclos del reloj. Una conjetura mis: supongamos que el nucleo RTOS funciona de forma preferencial. Ello requiere de algunas pequeiias decisiones de modelado. Para empezar, y para reflejar la operaci6n del nlicleo, vamos a tratar las operaciones de analizaro, ajustaro y tareasIntemas0 de la CPU como subprocesos, y les asignaremos prioridades. Para mostrarlas en nuestro modelo, tenemos que tratarlas como clases (algo que no solemos hacer con las operaciones). Este es un ejemplo de UML avanzado llamado concrecidn: tratar algo como si fuera una clase (Uobjeto) que no se suele tratar asi. Cuando lo haga, enriqueceri a su modelo porque sus clases concretadas tendrin relaciones con otras clases, tendrin sus propios atributos y se convertirin en estructuras que podri manipular y almacenar. En este caso, la concreci6n nos permite mostrar las prioridades de 10s subprocesos como atributos y utilizar 10s subprocesos en nuestros diagramas de interaccibn. La figura 23.10 muestra la estructura de clases de 10s subprocesos de TecnoApret6n.

FIGURA23.10 Estructura de clases para 10s subprocesos de TecnoApretdn.

Analizar

Ajustar

tareaslnternas

iC6m0 podriamos dar prioridades a nuestros subprocesos? Cuando llegue una peticidn de interrupcidn, la CPU tendrh que detener 10 que hacia, guardar su context0 y atender la intermpcidn con un ISR. Nuestra operacidn procesarISR() toma la amplitud de SenialEMS y las otras caracteristicas de seiial compleja y las inserta en la memoria para analizaro para trabajar en las mismas. Entonces la operacidn analizaro debe tener la mhima prioridad. Seguirh la operacidn ajustaro. La operacidn tareasInternas0 debe tener la menor prioridad. He aqui un ejemplo de cdmo todo esto funcionaria en conjunto de una manera preferencial. Si la CPU esth a la rnitad de la ejecucidn de algunas operaciones internas y llega una seiial, intermmpirh 10 que est6 haciendo. La CPU ejecutarh procesarISR() y obtendrh 10s valores adecuados de la seiial. ~ Q u Cocurre despuks? Regresar a las tareas internas no seria productivo. En vez de ello, la CPU ejecutarh la operacidn de mayor prioridad, analizaro, seguida por ajustaro. La figura 23.11 le muestra el diagrama de secuencias para "Apretar la barra". La figura 23.12 le muestra un diagrama de colaboraciones para este caso de uso. En ambos diagramas utilizarnos llaves para indicar restricciones de tiempo (medidas por ciclos del reloj). (1 clclw del relq = 20 m~crosegundos)

FIGURA23.1 1 Diagrama de secuencias para "Apretar la barra ".

1 I

:, :

I

I

:

l I I

Llsto

I I I

I I

;Camblo de sstado _:

I

0 I I

0

I I I

I l

I

l

I I

1 I

I

I

:

I

l4

I I I

I 0

I

II I I I

I I I I I 8 8 I I

l

, r

I 0 I

o

l 0 I

8 I

,

Cambar estaddlnlcar analets I 0

I I I

I

I

I I l

I I I l I I I l I I I 0

,

I

I I I I

I I I

I I

I I I

I -S$ tanslorma en.

0 I

0

("1 0

(L+]

,

' I

I I I

I

l

Petlciande 1 ~nterrupclor (Tiempc para aiustar