ay if 4 Si sélo tiene tiempo para las respuestas 24 lecciones en las que invertiré una hora por leccién ( rorentiendo i byResumen de contenido Introduccién Parte | Para INICIAR Hora | Aken Cami) 15 Introduccién al UML Orientacién a objetos Uso de la orientacién a objetos Uso de relaciones Agregacién, composicién, interfaces y realizacion Introduccién a los casos de uso Diagramas de casos de uso Diagramas de estados Diagramas de secuencias Diagramas de colaboraciones Diagramas de actividades Diagramas de componentes Diagramas de distribucién Nociones de los fundamentos del UML Adaptacién del UML en un proceso de desarrollo Parte Il Estupio DE UN CASO. Hora 16 7 18 19 20 an 22 Presentacién del caso por estudiar Elaboraci6n de un analisis de dominio: Recopilacién de las necesidades del sistema Desarrollo de los casos de uso Orientacién a las interacciones y cambios de estado Disefio del aspecto, sensacién y distribueién Nocién de los patrones de disefio 37 67 15 o1 103 119 133 149 163 173 187 203 205 223 247 267 281 293 309Parte Ill VisiION DEL FUTURO 321 Hora 23 Modelado de sistemas incrustados 323 24 El futuro del UML 341 Parte IV APENDICES 355 Apéndice A Respuestas a los cuestionarios 357 Apéndice B_ Herramientas de modelado para el UML. 369 Apéndice C Un resumen gréfico a7 Indice 387Contenido Iwrropucaon 1 Parte | PARA INICIAR 3 Hora 1 Hora 2 Irropucaién aL UML Por qué es necesario el UML. La concepeién del UML... Diagramas del UML Diagrama de clases = e Diagrama de objetos ... : eee) Diagrama de casos de uso Diagrama de estados Diagrama de secuencias Diagrama de actividades Diagrama de colaboraciones Diagrama de componentes Diagrama de distribucién Otras caracteristicas Paquetes. Notas Estereotipos Para qué tantos diagramas Resumen Preguntas y respuestas .. Taller ; Cuestionario Ejercicios ORIENTACION A OBJETOS Objetos, objetos por doquier .. Algunos conceptos .. Abstraccién Heren« Polimorfismo Encapsulamiento .. Envio de mensajes Asociaciones Agregacion La recompensa ...Hora 3 Hora 4 Hora 5 Resumen ..... 30 Preguntas y respuestas Taller Cuestionario Ejercicios Uso DE LA ORIENTACION A OBIETOS Concepeién de una clase Atributos Operaciones .. Atributos, operaciones y concepeién Responsabilidades y restricciones Notas adjuntas Qué es lo que hacen las clases y cémo encontrarlas Resumen ... Preguntas y respuestas Taller ecnnnnnnnnee Cuestionario Ejercicios Uso pe RELACIONES 45 Asociaciones ee 46 Restricciones en las asociaciones 47 Clases de asociacién Vinculos .. Multiplicidad Asociaciones calificadas Asociaciones reflexivas .. Herencia y generalizacién . Descubrimiento de la herencia ... Clases abstractas Dependencias Resumen 5 Preguntas y respuestas 55 Taller _ 56 Cuestionarios 56 Ejercicios 56 AAGREGACION, COMPOSICION, INTERFACES Y REALIZACION 37 Agregaciones 58 Restricciones en las agregaciones 59 Composiciones, 59 Contextos 59Hora 6 Hora 7 Interfaces y realizaciones Visibitidad Ambito ... Resumen Preguntas y respuestas Taller z Cuestionario Ejercicios InTRODUCCION A LOS CASOS DE USO Qué son Tos €a505 de USO nn Importancia de los casos de uso Un ejemplo: la maquina de gaseosas.... El caso de uso “Comprar gaseosa” Casos de uso adicionales Inclusién de los casos de uso Extensién de los casos de uso Inicio del andlisis de un caso de uso .. RESUMEN rrr Preguntas y respuestas Taller : Cuestionario .. Ejercicios DIAGRAMAS DE CASOS DE USO Representaci6n de un modelo de caso de uso .. Una nueva visita a la méquina de gascosas Secuencia de pasos en los escenarios ‘Concepcién de las relaciones entre casos de uso Inclusién Extension Generalizacién Agrupamiento sn co Diagramas de casos de uso en el proceso de andlisis Aplicacién de tos modelos de caso de uso Comprensién del dominio. Comprensién de los usuarios ‘Comprensién de los casos de uso ... Profundizacién Donde estamos sonn Elementos estructurales Relaciones. AgrupamientoHora 8 Hora 9 Anotacién Extension y mas El Panorama Resumen Preguntas y respuestas Taller. ‘Cuestionario Ejercicios DIAGRAMAS DE ESTADOS 1 Qué es un diagrama de estados . m2 Simbologia eee 92 ‘Adicidn de detalles al icono de estado senses Sucesos y acciones 94 Condiciones de seguridad 95 Subestad0s nn 96 ee 96 Subestados concurrentes so sens 96 Estados hist6ricos : soon Mensajes y seffales 98 Por qué son importantes los diagramas de estas... 99 ‘Adiciones al panorama 9 Resumen “ 100 Preguntas y respuestas 101 Taller sernonnnnninnnsninninnininnnnnannannnsnnannnnmnnnnnan 101 Cuestionarios 101 Ejercicios 102 DiaGRAMAS DE SECUENCIAS 103 Qué es un diagrama de secuencias = enn OF Objetos Mensaje Tiempo ... La GUI... La secuencia 106 E] diagrama de secuencias El caso de uso Instancias y genéricos Un diagrama de secuencias de instancias Un diagrama de secuencias genérico Creacién de un objeto en la secuencia .... (COmo representar la recursividad 108 108 seve 12 114Adiciones al panorama Resumen .. Preguntas y respuestas Taller Cuestionario Ejercicios HoRA 10 DIAGRAMAS DE COLABORACIONES Qué es un diagrama de colaboraciones La GUI Cambios de estado .. La maquina de gaseosas Creacién de un objeto Algunos conceptos mas Varios objetos receptores en una clase Representacién de los resultados Objetos activos . Sincronizacién Adiciones al panorama Resumen Preguntas y respuestas, Taller Cuestionario Ejercicios Hora 11. DIAGRAMAS DE ACTIVIDADES Objetivos. Que es un diagrama de actividades Decisiones, decisiones, decisiones Rutas concurrentes Indicaciones Aplicacion de los diagramas de actividades Una operacién: Fibs .. Proceso de creacién de un documento Marcos de responsabi Diagramas hibridos Adiciones al panorama Resumen Preguntas y respuestas Taller Cuestionario Ejercicios ...Hora 12 Hora 13 Hora 14 DIAGRAMAS DE COMPONENTES 19 Qué es un componente 150 Componentes e interfaces, 150 SustituciOn y reutilizaciOn on eerste 151 Tipos de componentes ... sol 52 Qué es un diagrama de componentes 152 Representacién de un componente 152 Cémo representar las interfaces... onl 53 Aplicacién de los diagramas de componentes 154 Una pagina Web con un subprograma Java w.cunnnnnnnnnnrnnenneed SA Una pagina Web con controles ActiveX ... 156 PowerToys penne 157 Diagramas de componentes en el panorama 158 Resumen .... Preguntas y respuestas ... Taller... Cuestionario ... Ejercicios 160 DIAGRAMAS DE DISTRIBUCION 163 Qué es un diagrama de distribucién se 4 Aplicacién de los diagramas de disttibUCI6M .....n.mnnnmnnmnnnnnnnnnel 65 Un equipo doméstico 166 Una red token-ring 166 ARCret ... 167 Thin ethernet ssn 168 Red inalambrica Ricochet de Metricom 169 Los diagramas de distribucién en el panorama .... 170 Resumen nnn m1 Preguntas y respuestas 172 Taller so snnnnnnnnnninnnanennnnnnnnnel 2 Cuestionario 172 Ejercicios 172 Nociones DE Los FUNDAMENTOS DEL UML. 173 Estructura del UML 174 Capa del metamodelado: cercano y personal : 175 El paquete de Fundamentos 176 E] paquete de los elementos de comportamiento .. 178 Administracién de modelos 179 Extensién del UML 2179Estereotipos Dependencia Clasificador Clase .. Generalizacién Paquete ... Componente Algunos otros estereotipos .. Estereotipos gréficos Restricciones Valores etiquetados Resumen Preguntas y respuestas Taller Cuestionario Hora 15 ADAPTACION DEL UML EN UN PROCESO DE DESARROLLO 187 Metodologias: antiguas y recientes sl 88 EI método antiguo 188 El método reciente unnnninnnnnnninnnnnnnnnnsnnne 189 Lo que debe hacer un proceso de desarrollo “ 190 GRAPPLE oo ; 191 RAD®: la estructura de GRAPPLE ...nnnsnnssnnnnnnnnnnnn 192 Recopilacién de necesidades en sennneaned 9B Anilisis Diseio ... Desarrollo Distribucién Resumen de GRAPPLE / : 199 Resumen se 200 Preguntas y respuestas 201 Taller 201 Cuestionario 201 Parte Il EsTUDIO DE UN CASO 203 HORA 16 PRESENTACION DEL CASO POR ESTUDIAR 205 Aplicacién de GRAPPLE al problema 206 Descubrir los procesos de! negocio .. 206 Servir a un cliente ... vs 207 Preparacién de platillos, “ - 215 Limpieza de la mesa 218 1219 Lecciones aprendidas ..Hora 17 Hora 18 Resumen .. Preguntas y respuestas .. Taller Cuestionatio Ejercicios ELABORACION DE UN ANALISIS DE DOMINIO Andlisis de la entrevista del proceso del negocio Desarrollo del diagrama de clases inicial Agrupacién de las clases Conformacién de asociaciones Asociaciones con el cliente Asociaciones con el Mesero ‘Asociaciones con et Chef Asociaciones con el Mozo de piso .. Asociaciones con el Gerente Una digresi6n 0. Formacién de agregados y objetos compuestos Llenado de las clases El Cliente El Empleado La Cuenta Detalles generales de los modelos Diccionario de! modelo ‘Organizacién del diagrama Lecciones aprendidas Resumen... Preguntas y respuestas Taller Cuestionario Ejercici0S an 245 RECOPILAGION DE LAS NECESIDADES DEL SISTEMA 247 Desarrollo de la idea .. 248 Preparacién para la recopilacin de las necesidades 257 La sesi6n JAD de necesidades 258 El resultado .261 Ahora qué? Resumen . Preguntas y espuestas Taller Cuestionario .. Ejercicio 265 265 265 265Hora 19 Hora 20 DESARROLLO DE LOS CASOS DE USO 267 Cuidado y provisién de los casos de uso 268 El andlisis de los casos de uso 268 El paquete Meset0 ..nnnsnnnnnnnsnn sn “ 269 ‘Tomar una orden 270 ‘Transmitir la orden a la cocina an ‘Cambiar una orden .. oe am Sondeo del progreso de la orden so oT Notificar al chef del progreso de los clientes en sus alimentos 273 ‘Totalizar una cuenta 275 Imprimir una Cuenta 275 Llamar a un Asistente 216 Casos de uso restantes, 277 Componentes del sistema an Resumen 2718 Preguntas y respuestas 278 Taller 279 Cuestionario 279 Ejercicios 279 ORIENTACION A LAS INTERACCIONES Y CAMBIOS DE ESTADO 281 Las partes funcionales del sistema 282 El paquete Mesero 282 El paquete Chef . 283 El paquete Mozo De Piso ... se sens ; 283 El paquete Asistente Mesero 283 El paquete Asistente Chef sev . 283 El paquete Cantinero . El paquete Encargado Del Guardarropa Colaboracién en el sistema ‘Tomar una orden 285 Cambiar una ofden ncn 288 Sondeo del progreso dela orden 289 Implicaciones 290 Resumen nnn 29 Preguntas y respuestas : 291 Taller 292 Cuestionario ... 292 Ejetcicios anne smn 292HoRA 21 DISENO DEL ASPECTO, SENSACION Y DISTRIBUCION 293 Algunos principios generales en el disefio de las GUI DM La sesi6n JAD para la GUE... 1.296 De los casos de uso a la interfaces de usuario 297 Diagramas UML para el disefio de la GUI . 299 Esbozos de la distribucién del sistema... 300 Lated .. 301 Los nodos y el diagrama de distribucign . 301 Siguientes pasos sve BO3 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 “ Cuestionario ae 308 Ejercicios 308 Hora 22 NOCION DE LOS PATRONES DE DISERIO Parametrizacion Patrones de disefio Cadena de responsabilidad Cadena de responsabilidad: dominio Restaurante Cadena de responsabilidad: Modelos de eventos de los exploradores Web Nuestros propios patrones de disefto ... Ventajas de los patrones de diseio Resumen Preguntas y respuestas Taller Cuestionario Ejercicios Parte Ill VisiON DEL FUTURO 321 Hora 23. MoDELADO DE SISTEMAS INCRUSTADOS 323 La madre de la invencisn ... 324 Creacién de TecnoApretén 325 Qué es un sistema incrustado? 327 Conceptos de los sistemas incrustados nen 328 Tiempo a = 328 Subprocesos. 328 Interrupciones .. 329 Sistema operative sence os 330Modelado de TecnoApret6n. Clases Casos de uso Interacciones so Cambios de estado generates Distribucién Flexiones en sus musculos Resumen Preguntas y respuestas .. Taller Cuestionario : Ejercicios .... 340 Hora 24 EL Futuro oft UML 341 342 Extensiones para los negocios .. Lecciones de las extensiones de negocios se 343 Interfaces gréficas de usuario ‘Conexiones a casos de uso Modelado de la GUI Sistemas expertos ‘Componentes de un sistema experto Un ejemplo . 348 Modelado de ta base de conocimientos seman 349 Eso es todo, amigos eee sonnn3S2 Resumen senna 352 Preguntas y respuestas Seema 399) Taller 353 Cuestionario 353 Parte IV APENDICES 355 ‘APENDICE A RESPUESTAS A LOS CUESTIONARIOS 357 ‘APENDICE B_ HERRAMIENTAS DE MODELADO PARA EL UML 369 Caracteristicas en comin .. Rational Rose SELECT Enterprise .. Visual UML. . — La herramienta ideal para el modelado‘APENDICE C. UN RESUMEN GRAFICO 377 Diagrama de actividades... eee Diagrama de clases sn sna 380 Diagrama de colaboraciones 382 Diagrama de componentes —E 382 Diagrama de distribUci6n ....unnmn : eeetss3 Diagrama de secuencias 383 Diagrama de estados 384 Diagrama de casos de uso 385 inpice 387Acerca del autor Joseph Schmuller es vicepresidente de la divisi6n de Consumer Finance Technologies del Bank of America. De 1991 a 1997 fue editor en jefe de la revista PC Al. Ha escrito diversos articulos y resefias de tecnologias avanzadas de computacién y es autor de ActiveX 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 enseRé a aprender por mi mismo, Reconocimientos Escribir un libro es un proceso arduo; pero por fortuna, el equipo de Macmillan Computer Publishing lo ha hecho mas facil. 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 experien- cia editorial, les agradezco sus alicientes, paciencia y apoyo. Los revisores técnicos, Bill Rowe y Michael Tobler se aseguraron de que el contenido fuera técnicamente correcto y se los agradezco. La editora, Susan Moore, los destacados artistas de Macmillan y el personal de produccién convirtieron el manuscrito y sus diversos diagramas en el libro que ahora esté leyendo. David Fugate de Waterside Productions conjug6 todo el proceso. Le agradezco haberme hecho coincidir con Macmillan y haberme colocado en otro proyecto muy retribuyente. Tengo el privilegio de trabajar todos los dias con un grupo de excelentes profesionales en la divisin 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 cooperacién. En particular, las conversaciones con Keith Barret y Rob Warner me ayudaron a clarificar mis ideas sobre diversos puntos. Por des- gracia Tom Williamson, nuestro Director de divisién, fallecié mientras escribfa este libro. El era el coraz6n y el alma de CFT, y fue un asesor, tutor, colega y amigo. Agradezco a mis queridos amigos, los Spragues de Madison, Wisconsin, en cuyo vecinda- rio estaba de casualidad cuando empecé a escribir este libro y, nuevamente, al 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 mf.Pearson Educacion Latinoamérica EI personal de Pearson Educacién Latinoamérica esté comprometido en presentarle lo mejor en material de consulta sobre computacién. Cada libro de Pearson Educacién Latinoamérica es el resultado de meses de trabajo de nuestro personal, que investiga y tefina la informacién que se ofrece. Como parte de este compromiso con usted, el lector de Pearson Educacién Latinoamérica lo invita a dar su opini6n, Por favor hdganos saber si disfruta este libro, si tiene alguna dificultad con la informacién y los ejemplos que se presentan, o si tiene alguna sugerencia para la préxima edicién, in embargo, recuerde que el personal de Pearson Educacién Latinoamérica no puede actuar como soporte técnico 0 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 Educacién Latinoamérica, existen muchas formas de entrar en contacto con nosotros. Responderemos a todos los lectores que podamos. Su nombre, direccién y némero tele- fonico jamés formarén parte de ninguna lista de correos ni serdn usados para otro fin, ‘més que el de ayudarnos a seguirle llevando los mejores libros posibles. Puede escribimnos a la siguiente direccién: Pearson Educacién Latinoamérica Attn: Editorial Divisién Computaci6n Calle Cuatro No. 25, 2° Piso, Col. Frace. Alce Blanco Naucalpan de Juérez, Edo. de México. CP. 53370 Si lo prefiere, puede mandar un fax a Pearson Educacién Latinoamérica al (525) 5387-0811 También puede ponerse en contacto con Pearson Educacién Latinoamérica a través de nuestra pagina Web: http: / /aww. pearson .com.mxIntroduccién Todo gira en torno de una visi6n. Un sistema complejo toma forma cuando alguien tiene la visi6n 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 dé foma. El éxito de los proyectos de desarrollo de aplicaciones o sistemas se debe a que sirven como enlace entre quien tiene Ia idea y el desarrollador. EI UML (Lenguaje Unificado de Modelado) es una herramienta que cumple con esta funcién, ya que le ayuda a capturar la idea de un sistema para comunicarla posteriormente a quien esté involucrado en su proceso de desarrollo; esto se Hleva a cabo mediante un conjunto de simbolos y diagra- mas. 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 incluird ejercicios que le per- mitirdn practicar sus recién adquiridos conocimientos. Divids este libro en tres partes: la primera parte le da un panorama del UML y le explica la orientacién a objetos, misma que conforma los conceptos fundamentales de la diagra- macién de objetos y clases. Examinaremos los casos de uso (una estructura para mostrar la forma en que un sistema luciré ante el usuario, para luego mostrar emo hacer dia- ‘gramas de esta estructura). Las horas restantes de la primera parte le permitirdn trabajar con el resto de los 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 mostrarén la forma en que el UML se adapta al contexto de un proyecto de desarrollo. Verd la forma en que los elementos del UML funcionan en conjunto para modelar un sistema, Por tiltimo, en la tercera parte aplicaremos el UML para disefiar patrones y sistemas incrustados, y examinaremos su campo de aplicacién en dos reas més. Existen diversos fabricantes que cuentan con paquetes que le permitiran generar diagra- mas UML y coordinarlos en un modelo. Los més notables son Rational Rose y SELECT Enterprise, aunque cabe mencionar que Visual UML es otto digno contendiente. Microsoft esté 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 necesi tard serd un lépiz. y papel para dibujar los diagramas y una sana curiosidad respecto al estado actual del disefio de sistemas. jlniciemos!Convenciones utilizadas en este libro En los diagramas incluidos en este libro no utilizamos vocales con acento, ni la letra eft. Esto debido a que el alfabeto inglés, de donde procede la mayoria de los Ienguajes de programaci6n, no los incluye y el empleo de esos caracteres en sus diagramas podria acarrearle problemas tanto en el UML como en el lenguaje de programacién que piense af | Una Nota presenta interesantes secciones de informacién relacionadas con el tema que se trate, El icono Término Nuevo resalta las definiciones de vocablos nuevos y esen- ciales. El vocablo, en si, aparecerd en cursiva. TenPARTE | Para iniciar Hora ONRDUAWN 10 1 12 13 14 15 Introduccién al UML Orientacion a objetos Uso de la orientacién a objetos Uso de relaciones Agregacién, composicién, interfaces y realizaci Introduccién a los casos de uso Diagramas de casos de uso Diagramas de estados Diagramas de secuencias Diagramas de colaboraciones Diagramas de actividades Diagramas de componentes Diagramas de distribuci6n Nociones de los fundamentos del UML Adaptacién del UML en un proceso de desarro—_ — — = a — = HORA 1 Introduccién al UML El UML (Lenguaje Unificado de Modelado) es una de las herramientas més emocionantes en el mundo actual del desarrollo de sistemas. Esto se debe a que permite a los creadores de sistemas generar diseiios que capturen sus ideas en una forma convencional y facil de comprender para comunicarlas a otras personas. En esta hora se tratardn los siguientes temas: + Por qué es necesario el UML + La concepeién del UML + Diagramas del UML + Para qué tantos diagramas En el contexto de este libro considere a un sistema como una combinacién de software y hardware que da una solucién a un problema de negocios. El desarrollo de sistemas es la creaci6n de un programa para un cliente, este ultimo es quien tiene el problema que debe ser resuelto. Un analista es el que documenta el problema de! cliente y !o comunica a los desarro- adores, que son los programadores que generarén el programa que resolverd el problema y lo distribuirén en equipos de computacién. onLa comunicacién de la idea es de suma importancia. Antes del advenimiento del UML, el desarrollo de sistemas era, con frecuencia, una propuesta al azar. Los analistas de sis- temas intentaban evaluar los requerimientos de sus clientes, generar un andlisis de requerimientos en algain tipo de notacién que ellos mismos comprendieran (aunque el cliente no lo comprendiera), dar tal andlisis a uno o varios programadores y esperar que el producto final cumpliese con lo que el cliente deseaba. Dado que el desarrollo de sistemas es una actividad humana, hay muchas posibilidades de cometer errores en cualquier etapa del proceso, por ejemplo, el analista pudo haber malentendido al cliente, es decir, probablemente produjo un documento que el cliente no pudo comprender. Tal vez ese documento tampoco fue comprendido por los programa- dores quienes, por ende, pudieron generar un programa dificil de utilizar y no generar una solucién al problema original del cliente. {Alguien se preguntard por qué muchos de los sistemas en uso son ineficientes, engorro- sos y dificiles de utilizar? Por qué es necesario el UML En los principios de la computacién, los programadores no realizaban andlisis muy pro- fundos sobre el problema por resolver. Si acaso, garabateaban algo en una servilleta. Con frecuencia comenzaban a escribir el programa desde el principio, y el eédigo nece- sario se escribia conforme se requeria. Aunque anteriormente esto agregaba un aura de aventura y atrevimiento al proceso, en la actualidad es inapropiado en los negocios de alto riesgo. Hoy en dfa, es necesario contar con un plan bien analizado. Un cliente tiene que compren- der qué es Jo que hard un equipo de desarrolladores; ademés tiene que ser capaz de sefalar cambios si no se han captado claramente sus necesidades (0 si cambia de opiniGn durante el proceso). A su vez, el desarrollo es un esfuerzo orientado a equipos, por lo que cada uno de sus miembros tiene que saber qué lugar toma su trabajo en la solucién final (asi como saber cual es la solucién en general). Conforme aumenta la complejidad del mundo, los sistemas informéticos también deberdn crecer en complejidad. En ellos se encuentran diversas piezas de hardware y software que se comunican a grandes distancias mediante una red, misma que esta vinculada a bases de datos que, a su vez, contienen enormes cantidades de informaci6n. Si desea crear sistemas que lo involucren con este nuevo milenio ,cémo manejard tanta complejidad? La clave est en organizar el proceso de disefio de tal forma que los analistas, clientes, desarrolladores y otras personas involucradas en el desarrollo del sistema lo comprendan y convengan con él. El UML proporciona tal organizacién, Un arquitecto no podria crear una compleja estructura como lo es un edificio de oficinas sin crear primero un anteproyecto detallado; asimismo usted tampoco podria generar un complejo sistema en un edificio de oficinas sin crear un plan de disefto detallado. La ideaLa es que asi como un arquitecto le muestra un anteproyecto a la persona que lo contrat6, usted deberd mostrarle su plan de disefio al cliente. Tal plan de disefio debe ser el resul- tado de un cuidadoso andlisis de las necesidades del cliente. Otra caracteristica del desarrollo de sistemas contemporéneo es reducir el periodo de desarrollo. Cuando los plazos se encuentran muy cerca uno del otro es absolutamente necesario contar con un disefio sélido. Hay otto aspecto de la vida moderna que demanda un disefio s6lido: las adquisiciones corporativas. Cuando una empresa adquiere a otra, fa nueva organizacién debe tener la posibilidad de modificar aspectos importantes de un proyecto de desarrollo que esté en progreso (Ja herramienta de desarrollo, el lenguaje de codificacién, y otras cosas). Un anteproyecto bien disefiado facilitara la conversién. Si el disefio es s6lido, un cambio en la implementacién procederd sin problemas. La necesidad de diseitos s6lidos ha trafdo consigo la creacién de una notacién de diseito que los analistas, desarrolladores y clientes acepten como pauta (tal como la notacién en los diagramas esquemiticos sirve como pauta para los trabajadores especializados en clectrénica). El UML es esa misma notacién. concepcién del UML EI 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 década de los afios ochenta y principios de los noventa y cada uno diseiié su propia metodologfa para el andlisis y diseiio orientado a objetos. Sus metodologias pre- dominaron sobre las de sus competidores. A mediados de los afios noventa empezaron a intercambiar ideas entre sf y decidieron desarrollar su trabajo en conjunto. Las horas 2, “Orientacién a objetos”, y 4, "Uso de relaciones", tratan de la orientacién a objetos. Los conceptos de orientacién 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 ingresé a Rational un afio después; el resto, como dicen, es historia. Los anteproyectos del UML empezaron a circular en la industria del software y las reac- ciones resultantes trajeron consigo considerables modificaciones. Conforme diversos cor- porativos vieron que el UML era itil a sus propdsitos, se conformé un consorcio de! UML. Entre los miembros se encuentran DEC, Hewlett-Packard, Intellicorp, Microsoft, Oracle, Texas Instruments y Rational. En 1997 el consorcio produjo la versi6n 1.0 del UML y lo puso a consideracién del OMG (Grupo de administracién de objetos) como respuesta a su propuesta para un lenguaje de modelado estandar.El consorcio aument6 y generé la versién 1.1, misma que se puso nuevamente a consi- deraci6n del OMG. El grupo adopts esta versién a finales de 1997. El OMG se encargé de la conservaci6n del UML y produjo otras dos revisiones en 1998. El UML ha llegado a ser el estindar de facto en la industria del software, y su evolucién continta, Diagramas del UML EI UML esta compuesto por diversos elementos gréficos que se combinan para confor- mar diagramas. Debido a que el UML es un lenguaje, cuenta con reglas para combinar tales elementos. En lugar de indicarle a usted cudles son los elementos y las reglas, veamos directamente los diagramas ya que los utilizar para hacer el andlisis del sistema. Este enfoque es similar a aprender un idioma extranjero mediante el uso del mismo, en luger de aprender sus regs gramaticatesy lo conjugecion de aut = verbos. Después de un tiempo de hablar otro idioma se le facilitara la conju- acon de verbosyla comprension dela regs gramaticles, ee eee eee eee eee ee La finalidad de los 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 interpretaci6n del artista del edi ficio. Es importante destacar que un modelo UML describe lo que supuestamente hard un sistema, pero no dice c6mo implementar dicho sistema. A continuacién se describiran brevemente los diagramas mas comunes del UML y los conceptos que representan. Posteriormente, en la parte I verd cada uno de los diagra- mas con mayor detenimiento. Recuerde que es posible generar hibridos de estos dia- gramas y que el UML otorga formas de organizarlos y extenderlos. Diagrama de clases Piense en las cosas que le rodean (una idea demasiado amplia, pero jinténtelo 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. También se encontrar4 con que las cosas naturalmente se albergan en cate- gorias (automéviles, mobiliario, lavadoras...). A tales categorias las llamare- mos clases. Una clase es una categorfa 0 grupo de cosas que tienen atributos y acciones similares. He aqué un ejemplo: cualquier cosa dentro de Ia clase Lavadoras tiene atribu- tos como son la marca, el modelo, el mimero de serie y la capacidad. Entre las acciones itde las cosas de esta clase se encuentran: “agregar ropa”, “agregar detergente”, “activarse” y “sacar ropa”. La figura 1.1 le muestra un ejemplo de la notacién del UML que captura los atributos y acciones de una lavadora. Un recténgulo es el simbolo que representa a la clase, y se divide en tres dreas. El drea superior contiene el nombre, el drea central contiene los atributos, y el drea inferior las acciones. Un diagrama de clases esté formado por varios rectingulos de este tipo conectados por Iineas que muestran la manera en que las clases se relacionan entre s Figura 1.1 EL simbolo UML marca de una clase. modelo numero de serie capacidad Tavadora agregar ropa) agregar detergented) sacerropa() {Qué objetivo tiene pensar en las clases, asf como sus atributos y acciones? Para interac- tuar con nuestro complejo mundo, la mayorfa del software modemno simula algtin aspecto del mundo. Décadas de experiencia sugieren que es mas sencillo desarrollar aplicaciones que simulen algiin aspecto del mundo cuando el software representa clases de co: reales. Los diagramas de clases facilitan las representaciones a partir de las cuales los desarrolladores podrén trabajar. A su vez, los diagramas de clases colaboran en lo referente al anélisis. Permiten al analista hablarle a los clientes en su propia terminologfa, lo cual hace posible que los clientes indiquen importantes detalles de los problemas que requieren ser resueltos. Diagrama de objetos Un objeto es una instancia de clase (una entidad que tiene valores especifi- cos de los atributos y acciones). Su lavadora, por ejemplo, podria tener la marca Laundatorium, el modelo Washmeister, el nimero de serie GL57774 y una capacidad de 7 Kg. La figura 1.2 le muestra la forma en que el UML representa a un objeto. Vea que el sim- bolo es un rectangulo, como en una clase, pero el nombre esté subrayado. El nombre de la instancia espeeffica se encuentra a la izquierda de los dos puntos (:), y el nombre de la clase a la derecha.Figura 1.2 ‘Wi Lavadora: Lavadora EL simbolo UML del objeto, Diagrama de casos de uso Un caso de uso es una descripcién de las acciones de un sistema desde el punto de vista del usuario. Para los desarrolladores del sistema, ésta es una herramienta valiosa, ya que es una técnica de aciertos y errores para obtener los reque- rimientos del sistema desde el punto de vista del usuario. Esto es importante si la finali- dad es crear un sistema que pueda ser utilizado por la gente en general (no s6lo por expertos en computacién), Posteriormente trataremos este tema con mayor detalle; por ahora, le mostraré un ejem- plo sencillo. Usted utiliza una lavadora, obviamente, para lavar su ropa. La figura 1.3 le muestra cémo representarfa esto en un diagrama de casos de uso UML. Figura 1.3 O Diagruma de casos de uso UML. Lavar ropa Usuario de la avadora A la figura correspondiente al 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. Ter ° Diagrama de estados En cualquier momento, un objeto se encuentra en un estado en particular. Una persona puede ser recién nacida, infante, adolescente, joven o adulta. Un elevador se moverd hacia arriba, estard en estado de reposo 0 se moverd hacia abajo. Una lavadora podré 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 pequeia reali- dad. La figura muestra las transiciones de la lavadora de un estado al otro. EI simbolo que esté en la parte superior de la figura representa el estado inicial y el de la parte inferior el estado final.Figura 1.4 Diagrama de estados UML. Diagrama de secuencias Los diagramas de clases y los de objeto representan informacién estética. No obstante, en un sistema funcional los objetos interactian entre sf, y tales interacciones suceden con el tiempo. El diagrama de secuencias UML muestra la mecdnica de la interaccién con base en tiempos. Continuando con el ejemplo de la lavadora, entre los 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 también son objetos (como verd, un objeto puede estar conformado por otros objetos). {Qué sucederd cuando invoque al caso de uso Lavar ropa? Si damos por hecho que com- pleté las operaciones “agregar ropa”, * “agregar detergente” y “activar”, la secuencia serfa ms o menos asf: El agua empezaré a llenar el tambor mediante una manguera. El tambor permanecerd inactivo durante cinco minutos. La manguera dejard de abastecer agua. El tambor girard de un lado a otro durante quince minutos. El agua jabonosa saldré por el drenaje. ‘Comenzaré nuevamente el abasteci into de agua Aaya enyr El tambor continuaré girando.8. El abastecimiento de agua se detendra. 9. El agua del enjuague saldré por el drenaje. 10. El tambor girard en una sola direcci6n y se incrementard su velocidad por cinco minutos. 11, El tambor dejara de girar y el proceso de lavado habré finalizado. La figura 1.5 presenta un diagrama de secuencias que captura las interacciones que se realizan a través del tiempo entre el abastecimiento de agua, el tambor y el drenaje (re- presentados como rectingulos en la parte superior del diagrama). En este diagrama el tiempo se da de arriba hacia abajo. Ficura 1.5 angers ae gua Tmaor rena Diagrama de 7 secuencias UML, Avastocmente de agua —of Permanecerinmavt Detenerse —— rare un ado 2 oko | — vcare! agua aborass fy — Reabastecer de agua —+ Gtr deuniado acne} cmoune JH sacar apa eae —ef] (at an un sole sentco Por cierto, volviendo a las ideas acerca de los estados, podriamos caracterizar los pasos 1 y 2.como el estado de remojo, 3 y 4 como el estado de lavado, 5 a7 como el estado de enjuague y del 8 al 10 como el estado de centrifugado Diagrama de actividades Las actividades que ocurren dentro de un caso de uso 0 dentro del comportamiento de un objeto se dan, normalmente, en secuencia, como en los once pasos de la seccién anterior. La figura 1.6 muestra la forma en que el diagrama de actividades UML representa los pasos del 4 al 6 de tal secuencia.