/ Datos de catalogacion bibliografica

APRENDIENDO UML EN 24 HORAS Joseph Schmuller

PEARSON EDUCACION, MCxico, 2000 ISBN: 968-444-463-X Area: Computacidn Formato: 18.5 x 23.5 cm Pbginas: 448

EDICIdN EN ESPANOL

EDITOR EJECUTIVO
OSCAR MADRIGAL MUNIZ ANA MARfA MONTANEZ LUZ ANGELICA GUTIERREZ ROJO Bradley L. Jones

EDITOR DE DIVISION COMPUTACION: SUPERVISOR DE TRADUCCION: SUPERVISOR DE PRODUCCION:

APRENDIENDO UML EN 24 HORAS

EDITOR DE ADQUISICIONES
Chris Webb

EDITOR DE DESARROLLO
Matt Purcell

Versidn en espaiiol de la obra titulada SAMS Teach Yourself UML in 24 hours, de Joseph Schmuller, publicada originalmente en inglCs por SAMS Publishing, una divisidn de Macmillan Computer Publishing, 201 W. 103rdStreet, Indianapolis, Indiana, 46290, EUA. Esta edicidn en espaiiol es la hnica autorizada. Authorized translation from the English language edition published by Macmillan Computer Publishing Copyright 0 1999 All rights reserved. No part of this book may be reproduced or transmitted in any form of by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from the Publisher. Primera edici6n D.R. 0 2000 por Pearson Educacih de MCxico, S.A. de C.V. Calle 4 No. 25-2do. Piso Fracc. Industrial Alce Blanco 53370 Naucalpan de Jufirez, Edo. de MCxico C h a r a Nacional de la Industria Editorial Mexicana Registro No. 1031 Reservados todos 10s derechos. Ni la totalidad ni parte de esta publicacion pueden reproducirse, registrarse o transmitirse, por un sistema de recuperacidn de informacidn, en ninguna forma ni por ningun medio, sea electrdnico, mecinico, fotoquimico, magnCtico o electro6ptico, por fotocopia, grabacidn o cualquier otro, sin permiso previo por escrito del editor. El prCstamo, alquiler o cualquier otra forma de cesi6n de us0 de este ejemplar requeriri tambiCn la autorizacidn del editor o de sus representantes. ISBN: 968-444-463-X de la versidn en espaiiol ISBN: 0-672-31636-6 de la version en inglCs Impreso en Mtxico. Printed in Mexico 1 2 3 4 5 6 7 8 9 0 03 02 01 00

EDITORA ADMINISTRATIVA
Jodi Jensen

EDITORA EJECUTIVA
Susan Ross Moore

CORRECTORES DE ESTILO
Mike Henry Mary Lagu Rhoda Tinch-Mize

INDIZADORA
Sandra Henselmeier

CORRECTORES DE PRUEBAS
Ben Berg Mona Brown

REVISORES T~CNICOS
Bill Rowe Michael Tobler

ESPECIALISTA EN DESARROLLO
DEL SOFTWARE

Dan Scherf
DISENO DE

PAGINAS INTERIORES

Gary Adair
DISENADOR DE PORTADA

Aren Howell

REDACTOR
Eric Borgert
DISENADOREST~CNICOS

Brandon Allen Stacey DeRome Tim Osbom Staci Somers

Resumen de contenido
Introduccidn
PARTE

PARA INlClAR

3
5 19 33 45 57 67 75 91 103 119 133 149 163 173 187

Hora 1 2 3 4 5 6 7 8 9 10
11

Introduccidn a1 UML Orientacidn a objetos Us0 de la orientacidn a objetos Us0 de relaciones Agregacidn, composicidn, interfaces y realizacidn Introduccidn a 10s casos de us0 Diagramas de casos de us0 Diagramas de estados Diagramas de secuencias Diagramas de colaboraciones Diagramas de actividades Diagramas de componentes Diagramas de distribucidn Nociones de 10s fundamentos del UML Adaptaci6n del UML en un proceso de desarrollo

12 13 14

15
PARTE

11 ESTUDIO DE UN CASO Hora 16 Presentacidn del caso por estudiar 17 Elaboracidn de un anilisis de dominio 18 Recopilacidn de las necesidades del sistema 19 Desarrollo de 10s casos de us0 20 Orientacidn a las interacciones y cambios de estado 21 Diseiio del aspecto, sensacidn y distribucidn
22 Nocidn de 10s patrones de diseiio

203
205 223 247 267 28 1 293 309

PARTE 111 VISION

Hora 23

DEL FUTURO

321
323 341

Modelado de sistemas incrustados El futuro del UML

24

PARTE IV APENDICES
ApCndice A ApCndice B ApCndice C Respuestas a 10s cuestionarios Herramientas de modelado para el UML Un resumen grlfico hdice

355
357 369 377 387

Contenido
INTRODUCCI~N 1

PARTE I PARA INICIAR

HORA 1
INTRODUCC16N A1

3
UML

Por qu6 es necesario el UML ................................................................................ 6 La concepci6n del UML ........... ............................................ 7 Diagramas del UML ............................................................................................. .8 Diagrama de clases . ............................................................... 8 Diagrama de objetos .......................................................................................... 9 Diagrama de casos de us0 ..... .............................................................. 10

..................................................... ............................................................. Diagrama de actividades .................................................

Diagrama de colaboraciones ......... Diagrama de componentes ............. Diagrama de distribucih ................................................................................ Otras caracten'sticas ................................................................ Paquetes .......................................................................................................... Notas ................................................................................. Para quC tantos diagramas ....................................... Resumen .................................................. Preguntas y respuestas ............................ Taller ................................................................................................................... Cuestionario ..................... Ejercicios ........................................................................................................
HORA

11

14 14 14

.17 17 17 19

ORIENTAC16N A OBJETOS

Objetos, objetos por doquier .................... ......... .20 Algunos conceptos ............................................................................................... .22 Abstracci6n ..................... ........22 Herencia .......................................................................................................... 23 Polimorfkmo Envfo de mensajes Asociaciones ................................................................................................... Agregaci6n ..... .......................... La recompensa .....................................................................................................

.26 28 .30

1 vi

Aprendiendo UML en 24 horas

Resumen .................. ....................... Preguntas y respuestas .......................................................................................... Taller .....................................

30 31 31 33 33 .36

..............................................................................................
Ejercicios .......................................
HORA 3 US0 DE LA ORlENTACldN A
OBJETOS

.......32

Concepcidn de una clase ...................................................................................... Atributos ................................ Operaciones ......................................................................................................... Atributos, operaciones y concepci6n ... Responsabilidades y restriccio Notas adjuntas ....................................... QuC es lo que hacen las clases y c6mo encontrarlas ............................................ Resumen ................................................ Preguntas y respuestas ........................................................................................ Taller ..................................................... Ejercicios ........................................
HORA 4 US0 DE RELACIONES

40 43

45

.............................................................................. .46 Asociaciones .......41 Restricciones en las asociaciones ... Clases de asociacidn ...................................................................................... ..48 Vinculos ......................................... ........ .......48 Multiplicidad ....................................................................................................... .49

Resumen ........................................................................................... Taller ............................................................................................... Cuestionarios

HORA 5

AGREGACl6N. COMPOSlCl6N, INTERFACES Y REALlZACl6N

57 58 59 59 59

Agregaciones .... ............................................................................... Restricciones en las agregaciones .................

................................................................ Contextos .........................................................................................

Contenido

vii 1

Interfaces y realizaciones ...................................................................................... Visibilidad ............... Ambito ................... Resumen ..... ..... Preguntas y respuestas ......................................................... ................................. Cuestionario ....................................................................................................

61

64
.64 64 .64
67

........................
HORA 6
lNTRODUCC16N A LOS CASOS DE U S 0

QuC son 10s casos de us0 ...................................................................................... 68 Importancia de 10s casos de us0 Un ejemplo: la maquina de gaseosas .................................................................... 69 El caso de us0 Comprar gaseosa Casos de us0 adicionales .. Inclusi6n de 10s casos de us0 .. Extensidn de 10s casos de us0 Inicio del anfilisis de un caso de us0 ... ................................................... 73 Resumen ................................................................................................... ............. 73 .............................................74 Preguntas y respuestas . Taller ............................................................................................... ..................... 74 ......................................................................74 .............................................74 HORA 7 DIAGRAMAS DE CASOS DE us0

75

Representaci6n de un modelo de caso de us0 .... Una nueva visita a la mBquina de gaseosas .................................................... 76 Secuencia de pasos en 10s escenarios ................. Concepci6n de las relaciones Inclusi6n .... ........ Extensi6n ........................................................................................................ 79 Generalizaci6n .................................................................. Agrupamiento .................................................................................................. 8 1 Diagramas de casos de us0 en el proceso de anhlisis .......................................... 81 Aplicacidn de 10s modelos de caso de us0 ..........................................................8 1 Comprensi6n del dominio .............................................................................. 82 Comprensi6n de 10s usuarios .......................................................................... 82 Comprensi6n de 10s casos de us0 . ............................................................82 Profundizaci6n ................................................................................................ 83 D6nde estamos ................... .............................................................................85 . Elementos estructurales .............................................................................86 Relaciones ............................... ......................................................................... 86 Agrupamiento .............................................................................

I viii

Aprendiendo UML en 24 horas

., ....................................................................................................... Anotacion Extensi6n .......

.86 .87
.87

..............................................................................
El Panorama .......... Resumen .............................................................................................................. Preguntas y respuestas .................. .........

.87 ..88
89

................................................................................................
Cuestionario ...........................................................................

................................................
DE ESTADOS HORA 8 DIAGRAMAS

91

QuC es un diagrama de estados .... ......................................... Simbologia ..................................................................................................... Adici6n de detalles a1 icono de estado ...................... Sucesos y acciones .................................................... Condiciones de seguridad ................................................................................

.92

................................................
Subestados concurrentes

95 .96

................................................ .96 ................................................ .97 ................................ 98 Mensajes y seiiales .. Por quC son importantes 10s diagramas de estados .............................................. 99
Adiciones al panorama Preguntas y respuestas

.......................

101

Cuestionarios . Ejercicios ......................................................................................................

DE SECUENCIAS HORA 9 DIAGRAMAS

102 103 104 105 106

QuC es un diagrama de secuencias .................................... Objetos .............. ....................................................................... Mensaje ................................................................................... ............................................................................................... Tiempo La GUI ......................................................................................... La secuencia .................... ....................................................................... El diagrama de secuencias ..................................................... El caso de us0 ................ ............................................. Instancias y genCricos ........................................................................................ ............................................... Un diagrama de secuencias de instancias Un diagrama de secuencias genCrico ........ ............................................... Creaci6n de un objeto en la secuencia C6mo representar la recursividad ......................................................................

108 108 109 112 114

Contenido

IX

Adiciones a1 panorama ............................ ................................................ Resumen ... ............................................................. ............................ Preguntas y respuestas ............................... Taller .. ............................................................. Cuestionario ............................................ ........................... Ejercicios .... .............................................................
HORA 10 DIAGRAMAS DE COLABORACIONES

1 15 1 I5 116 116 116 117

119

QuC es un diagrama de colaboraciones ........................ ........................... 120 La GUI .......................... .................................................................. 121 Cambios de estado .................................................... .................. 122 La miquina de gaseosas ............................................................ 122 Creaci6n de un objeto ................................................... .............. 124 ........................................................... 125 Algunos conceptos mis . Varios objetos recepto ........................ Representaci6n de 10s .......................................................... 126 Objetos activos ..................................................... Sincronizacih ....................... ........................................................ 127 Adiciones a1 panorama ................................................... Resumen ................................ ............................................................. 129 Preguntas y respuestas ................................................................ Taller .................................... ........................................................ Cuestionario ...................................................................... Ejercicios ......................... .......................................................... 130
HORA 11 DIAGRAMAS DE ACTIVIDADES

133

Objetivos .. .................................................................. QuC es un diagrama de actividades ..................................... Decisiones, decisiones, decisiones ................................. Rutas concurrentes .............. ................................................................ Indicaciones ........................................................................... Aplicaci6n de 10s diagramas de actividades ....................... Una operaci6n: Fibs .............................................................. ....................................... Proceso de creaci6n de un documento Marcos de responsabilidad ........................................................ Diagramas hibridos ................ ........................................................ Adiciones a1 panorama ............................................................ Resumen ............................................. ................................................... Preguntas y respuestas ........................................................ ............................................... Taller ................................................... Cuestionario ........................................................ .................................. Ejercicios ........................................

I35

138 142 145 146 146 147

Aprendiendo UML en 24 horas

HORA 12 DIAGRAMAS DE COMPONENTES

149

QuC es un componente ...................... ........................................................... .................................................... Componentes e interfaces Sustitucidn y reutilizacidn ........................................................................... Tipos de componentes ................................................ QuC es un diagrama de componentes .......................................................... Representacidn de un componente .................... Cdmo representar las interfaces .... Aplicacidn de 10s diagramas de componentes ........... Una pigina Web con un subprograma Java ...... Una pagina Web con controles ActiveX ............

150 .I50 .15 1 152

.................................................................... ............ ....................................................................... Preguntas y respuestas ................................................ Taller ........................ ..................................................................... ....................................................... ......................... Cuestionario ........................................................................ Ejercicios ...........
norama
HORA

157 159 160 160 160 163 164 166 166 167 169 171 172 172
173

13 DIAGRAMAS DE DlSTRlBUCl6N QuC es un diagrama de distribucidn ........... ............................. Aplicacidn de 10s diagramas de distribucidn Un equipo domCstico ..................................... ...................................... .................................................................... Una red token-ring .

........................... .......................................................... Red inalhbrica Ricochet de Metricom ....................................

Los diagramas de distribucidn en el Resumen ........................................................

........................... .......................................................... Taller .............................................. ....................................... ............................................................. .............................................

HOW

14 NOCIONES DE LOS FUNDAMENTOS DEL UML

Estructura del UML ............................................... Capa del metamodel ........................................... El paquete de Fundamentos ............................................... El paquete de 10s elementos de comportamiento ............... Administracidn de modelos ................................................. Extensidn del UML ...................... .......................................

175

179

Contenido

Estereotipos ........................................................................................................

179 180 180 ............ 181 . Generalizacion ............................................................................................. .18 1

.............................................................................. ..............................................................

.I

Componente .................................................................................................. Algunos otros estereotipos ....... Restricciones

182

....
185 185 185
187

Preguntas y respuestas ........................................................................................ Taller .............................. Cuestionario ..................................................................................................

HORA 15
ADAPTACldN DEL

UML EN UN PROCESO DE

DESARROLLO

Metodologias: antiguas y recientes ..................... El mCtodo antiguo ........................................................................................ El mttodo reciente .......................... Lo que debe hacer un proceso de desarrollo ...................................................... GRAPPLE ............................................ RAD3: la estructura de GRAPPLE .. Recopilaci6n de necesidades ....................... Analisis .......................................................................................................... Diseiio ............................................. Desarrollo ...................................................................................................... Distribuci6n ................................................ ................. Resumen de GRAPPLE ....................... ...................................... Resumen ................................................................................ Preguntas y respuestas ........................................................................................ Taller .................................................................................. Cuestionario ..................................................................................................

188 188 190

195 197 198 199 199 200 201 20 1 201

PARTE II ESTUDIODE UN CASO

HORA 16
I

PRESENTACldN DEL CASO POR ESTUDIAR

205

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

206 206

1 xii

Aprendiendo UML en 24 horas

Resumen. .............................................................. ......................................... Preguntas y respuestas ................................ ..................................................................... Taller .......... ........................................... Cuestionario .................................. Ejercicios ..........................................................................
HORA 17

220 221 22 1 221 .222

ELABORACldN DE UN ANALISIS DE DOMlNlO 223 Anilisis de la entrevista del proceso del negocio .............................................. 224 225 Desarrollo del diagrama de clases inicial .......................... Agrupaci6n de las clases ............... .......................................................... 228 Conformaci6n de asociaciones ............................................... Asociaciones con el cliente ... ...................................................... 229 Asociaciones con el Mesero .................................................. Asociaciones con el Chef ............ ................................................ 235 Asociaciones con el Mozo de piso ...................................... .............. 236 Asociaciones con el Gerente . ........................................................ 236 Una digresi6n .............................................................. Formaci6n de agregados y objetos compuestos ................................................ 238 Llenado de las clases ........................................................... ................... 239 El Cliente ................ ................................................................ 240 El Empleado ................................................................... La Cuenta ................ Detalles generales de 10s Diccionario del modelo ....................................................... 242 Organizaci6n del diagrama ................................................ Lecciones aprendidas ................ ............................................................ 243 Resumen ........................ ...................244 Preguntas y respuestas .............. ................................................................. 244

..............................................................
Cuestionario ................ Ejercicios ........................................................
HORA 18
RECOPlLACldN DE LAS NECESIDADES DEL SISTEMA

..................................

245 247

Desarrollo de la idea .... ..................................................... Preparaci6n para la reco La sesi6n JAD de necesidades ............................................................... El resultado ...................................................... .............................. LAhora quC? ....................... ............................................................. Resumen ............................................................... ................................ Preguntas y respuestas ........ .................................................... Taller .......................................................................... .............................

258 261 264 265 ,265

.................................................... Ejercicio .......................................................... .................................

Contenido

xiii

HORA 19 DESARROLLO DE LOS CASOS DE us0

267

268 Cuidado y provisidn de 10s casos de us0 .................... ........................... El analisis de 10s casos de us0 ........................... ,269 El paquete Mesero .................................................. Tomar una orden ............................... ............................ 271 Transmitir la orden a la cocina ................... Cambiar una orden . ......................................... Sondeo del progreso ............................ 273 Notificar a1 chef del progreso de 10s clientes en sus alimentos .................... 273 ........................... .275 Totalizar una cuenta ..................... Imprimir una Cuenta ................... ................................................... 275 .................................................. ,276 Llamar a un Asistente ................... Casos de us0 restantes ................. Componentes del sistema ................. Resumen ............................................................................................................. .278 ............................ 278 Preguntas y respuestas .................... Taller .................................................................................................................. 279 ........ ......... ........... 279 ...................................................................................... ,279 HORA 20
ORlENTACldN A LAS INTERACCIONES Y CAMBIOS DE ESTADO

............................

281 282 283 283 284 284

................ Las partes funcionales del sistema El paquete Mesero ........................................................................................

.................

............................
El paquete Asistente Mesero El paquete Asistente Chef ............................................................................ El paquete Cantinero .......... El paquete Encargado Del Guardarropa ........................................................ Colaboracidn en el sistema Tomar una orden ..... Cambiar una orden . .................................................................. Sondeo del progreso Implicaciones ............... Resumen ............................................................................................................. Preguntas y respuestas . Taller ................................................................................................................. Cuestionario ........... . . Ejercicios .....................................................................................................

289 .29 1 .292 ,292

I xiv
HORA 21

Aprendiendo UML en 24 horas

DISENO DEL ASPECTO, SENSACldN Y DlSTR!BUCl6N

293

Algunos principios generales en el diseiio de las GUI ...................................... 294 ................ La sesi6n JAD para la GUI . De 10s casos de us0 a las interfaces de usuario .................................................. 297 ...299 Diagramas UML para el diseiio de la GUI Esbozos de la distribucih del sistema .............................................................. 300 ...301 ucion ...................................................... 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 .......................... Preguntas y respuestas ....

Ejercicios ..................
HORA 22 N O C I ~ DE N LOS PATRONES DE DISENO

309

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

PARTE 111 VISION DEL FUTURO

HORA 23
MODEIADO DE SISTEMAS INCRUSTADOS

321
323

.......................................................... 324 ......................................................... .325

iQuC es un sistema incrustado?

....
..........................................................
328

Subprocesos .................................................................................................. 328 Intermpciones ............. ...329 Sistema operativo .......................................................................................... 330

Contenido

xv

Modelado de TecnoApreth ........ ................................ Clases ............................................................................................................ Casos de us0 ............................ Interacciones .................................................................................................. Cambios de estado generales .................. Distribucidn ............................................ Flexiones en sus mfisculos ............................ Preguntas y respuestas

332 335

....................................................................................... 339 ................................... ..339 ........................................................................................ 340 ....................................................... ,340 ....................................................................................... 340
341

HORA 24 EL FUTURO DEL UML

Extensiones para 10s negocios ........................................ ........ Lecciones de las extensiones de negocios .......................................................... Interfaces grhficas de usuario ........................................ ..................................................... Conexiones a casos de us0 Modelado de la GUI .................................................. Sistemas expertos ..................................................................... Componentes de un sistema experto .........................................

,342 343 .344 .346 ,348 352 353 353 353

.....................................................
ientos ...........................

...................................................................... Eso es todo, amigos ....... Resumen ................................................................................................... .......................................................... Preguntas y respuestas ...... Taller .................................................................................................................. Cuestionario ......... .......................................................................

PARTE IV APENDICES
AP~NDICE A RESPUESTAS A LOS CUESTIONARIOS AP~NDICE B HERRAMIENTAS DE MODELADO PARA EL UML

355
357
369

Rational Rose

............................................................................

370

1 xvi

Aprendiendo UML en 24 horas

AP~NDICE C UN RESUMEN GRAFICO

377

Diagrama de actividades ................................. ........................... .................................................. Diagrama de clases ..... Diagrama de colaboraciones ........................... ............................... ......................................................... Diagrama de component Diagrama de distribuci6n ............................. ...................................... Diagrama de secuencias ....................................................... Diagrama de estados .......................... ................................................ Diagrama de casos de us0 .............................................................
~NDICE

378 380 382 382 383 384

387

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 reseiias de tecnologias avanzadas de computacidn y es autor de ActiveX No experience required y Dynamic HTML Muster the Essentials. Tiene un doctorado de la Universidad de Wisconsin, y es profesor adjunto en la Universidad del Norte de Florida.

Dedicato ria
A mi maravillosa madre, Sara Riba Schmuller; quien me enseiid a aprender por mi' mismo.

Reconocimientos
Escribir un libro es un proceso arduo; per0 por fortuna, el equipo de Macmillan Computer Publishing lo ha hecho m8s f8cil. 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 tkcnicos, Bill Rowe y Michael Tobler se aseguraron de que el contenido fuera tkcnicamente correct0 y se 10s agradezco. La editora, Susan Moore, 10s destacados artistas de Macmillan y el personal de producci6n convirtieron el manuscrito y sus diversos diagramas en el libro que ahora esti 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 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 cooperacibn. 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 divisidn, falleci6 mientras escribia este libro. El era el corazdn 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.

1
I
I

Pearson Educacion Latinoamerica

El personal de Pearson Educacidn LatinoamCrica esth cornprometido en presentarle lo mejor en material de consulta sobre computaci6n. Cada libro de Pearson Educaci6n ' LatinoamCrica es el resultado de meses de trabajo de nuestro personal, que investiga y refina la informacidn que se ofrece. Como parte de este compromiso con usted, el lector de Pearson Educacidn LatinoamCrica lo invita a dar su opinidn. Por favor hhganos saber si disfruta este libro, si tiene alguna dificultad con la informacidn y 10s ejemplos que se presentan, o si tiene alguna sugerencia para la prdxima edicidn. Sin embargo, recuerde que el personal de Pearson Educaci6n LatinoamCrica no puede actuar como soporte tCcnico 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 Educacidn LatinoamCrica, existen muchas formas de entrar en contacto con nosotros. Responderemos a todos 10s lectores que podamos. Su nombre, direccidn y numero telefdnico jamas formarhn parte de ninguna lista de correos ni seran usados para otro fin, mas que el de ayudarnos a seguirle llevando 10s mejores libros posibles. Puede escribirnos a la siguiente direccidn: Pearson Educacidn LatinoamCrica Attn: Editorial Divisidn Computacidn Calle Cuatro No. 25, 2" Piso, Col. Fracc. Alce Blanco

Naucalpan de Juirez, Edo. de Mexico. C.P. 53370 Si lo prefiere, puede mandar un fax a Pearson Educacidn LatinoamCrica a1 (525) 5387-0811. TambiCn puede ponerse en contacto con Pearson Educaci6n LatinoamCrica a travCs de nuestraphgina Web: http://www.pearson.com.mx

lntroduccion
Todo gira en torno de una visibn. Un sistema complejo toma forma cuando alguien tiene la visidn de cbmo 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 Unificado de Modelado) es una herramienta que cumple con esta funcibn, ya que le ayuda a capturar la idea de un sistema para comunicarla posteriormente a quien estC 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 comprensidn e incluiri ejercicios que le permitiran practicar sus reciCn adquiridos conocimientos. Dividi este libro en tres partes: la primera parte le da un panorama del UML y le explica la orientacibn a objetos, misma que conforma 10s conceptos fundamentales de la diagramacidn de objetos y clases. Examinaremos 10s casos de us0 (una estructura para mostrar la forma en que un sistema lucirii ante el usuario, para luego mostrar cdmo 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 mostraran la forma en que el UML se adapta a1 context0 de un proyecto de desarrollo. Vera la forma en que 10s elementos del UML funcionan en conjunto para modelar un sistema. Por ultimo, en la tercera parte aplicaremos el UML para diseiiar patrones y sistemas incrustados, y examinaremos su camp0 de aplicacidn en dos keas mas. Existen diversos fabricantes que cuentan con paquetes que le permitiran generar diagramas UML y coordinarlos en un modelo. Los mas notables son Rational Rose y SELECT Enterprise, aunque cabe mencionar que Visual UML es otro digno contendiente. Microsoft esta 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 necesitarti sera un lapiz y papel para dibujar 10s diagramas y una sana curiosidad respecto a1 estado actual del diseiio de sistemas.
iIniciemos !
t

!
I

12

Aprendiendo UML en 24 horas

Convenciones utilizadas en este libro

En 10s diagramas incluidos en este libro no utilizamos vocales con acento, ni la letra eiie. Esto debido a que el alfabeto inglCs, de donde procede la mayoria de 10s lenguajes de programacibn, no 10s incluye y el empleo de esos caracteres en sus diagramas podria acarrearle problemas tanto en el UML como en el lenguaje de programacih que piense

Una Nota presenta interesantes secciones de inforrnacion relacionadas con el tema que se trate.

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

PARTE I
Para iniciar
Hora
1 lntroduccion al UML 2 Orientacion a objetos 3 Us0 de la orientacion a objetos
4 Us0 de relaciones

5 Agregacion, composicion, interfaces y realizacion

6 lntroduccion a 10s casos de us0 7 Diagramas de casos de us0 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 desarrollo

(6

Hora 1

La comunicacidn de la idea es de suma importancia. Antes del advenimiento del UML, el desarrollo de sistemas era, con frecuencia, una propuesta a1 azar. Los analistas de sistemas intentaban evaluar 10s requerimientos de sus clientes, generar un anilisis de requerimientos en algun tipo de notacidn que ellos mismos comprendieran (aunque el cliente no lo comprendiera), dar tal anilisis a uno o varios programadores y esperar que el product0 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 a1 cliente, es decir, probablemente produjo un documento que el cliente no pudo comprender. Tal vez ese documento tampoco fue comprendido por 10s programadores quienes, por ende, pudieron generar un programa dificil de utilizar y no generar una solucidn a1 problema original del cliente. jAlguien se preguntari por quC muchos de 10s sistemas en us0 son ineficientes, engorrosos y dificiles de utilizar?

Por que es necesario el UML

En 10s principios de la computacidn, 10s programadores no realizaban anilisis muy profundos sobre el problema por resolver. Si acaso, garabateaban algo en una servilleta. Con frecuencia comenzaban a escribir el programa desde el principio, y el c6digo necesario se escribia conforme se requeria. Aunque anteriormente esto agregaba un aura de aventura y atrevimiento a1 proceso, en la actualidad es inapropiado en 10s negocios de alto riesgo. Hoy en dia, es necesario contar con un plan bien analizado. Un cliente tiene que comprender quC es lo que hari un equipo de desarrolladores; ademis tiene que ser capaz de sefialar cambios si no se han captado claramente sus necesidades (0si cambia de opinidn 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 quC lugar toma su trabajo en la solucidn final (asi como saber cuil es la solucidn en general). Conforme aumenta la complejidad del mundo, 10s sistemas informiticos tambiCn deberh crecer en complejidad. En ellos se encuentran diversas piezas de hardware y software que se comunican a grandes distancias mediante una red, misma que est5 vinculada a bases de datos que, a su vez, contienen enormes cantidades de informacidn. Si desea crear sistemas que lo involucren con este nuevo milenio jc6mo manejari tanta complejidad? La clave esti en organizar el proceso de diseiio de tal forma que 10s analistas, clientes, desarrolladores y otras personas involucradas en el desarrollo del sistema lo comprendan y convengan con 61. El UML proporciona tal organizacidn. Un arquitecto no podria crear una compleja estructura como lo es un edificio de oficinas sin crear primer0 un anteproyecto detallado; asimismo usted tampoco podria generar un complejo sistema en un edificio de oficinas sin crear un plan de diseiio detallado. La idea

lntroduccion al UML

71

es que asi como un arquitecto le muestra un anteproyecto a la persona que lo contrat6, usted deberi mostrarle su plan de diseiio a1 cliente. Tal plan de diseiio debe ser el resultad0 de un cuidadoso anilisis de las necesidades del cliente. Otra caracterfstica 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 d i d o . Hay otro aspect0 de la vida moderna que demanda un diseiio sblido: las adquisiciones corporativas. Cuando una empresa adquiere a otra, la nueva organizacidn debe tener la posibilidad de modificar aspectos importantes de un proyecto de desarrollo que estC en progreso (la herramienta de desarrollo, el lenguaje de codificacidn, y o@ascosas). Un anteproyecto bien diseiiado facilitari la conversi6n. Si el diseiio es d i d o , un cambio en la implementacidn procederi sin problemas. La necesidad de diseiios s6lidos ha traido consigo la creaci6n de una notacidn 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 electrdnica). El UML es esa misma notaci6n.

La concepcion del UML

El UML es la creacidn 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 disefi6 su propia metodologia para el anilisis y diseiio orientado a objetos. Sus metodologias predominaron sobre las de sus competidores. A mediados de 10s aiios noventa empezaron a intercambiar ideas entre si y decidieron desarrollar su trabajo en conjunto.

Las horas 2, "orientacion a objetos", y 4, "Us0 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 ingresd 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 titi1 a sus propdsitos, 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 versidn 1.0 del UML y lo pus0 a consideracidn del OMG (Grupo de administracidn de objetos) como respuesta a su propuesta para un lenguaje de modelado estindar.

18

Hora 1

El consorcio aumentd y gener6 la versi6n 1.1, misma que se pus0 nuevamente a consideraci6n del OMG. El grupo adopt6 esta versi6n a finales de 1997. El OMG se encargo de la conservacidn del UML y produjo otras dos revisiones en 1998. El UML ha llegado a ser el estandar de facto en la industria del software, y su evoluci6n continh

Diagramas del UML

El UML esta compuesto por diversos elementos graficos 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 cuales son 10s elementos y las reglas, veamos directamente 10s diagramas ya que 10s utilizara para hacer el analisis del sistema.

Este enfoque es similar a aprender un idiorna extranjero rnediante el us0 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 interpretacibn del artista del edificio. Es importante destacar que un modelo UML describe lo que supuestamente hara un sistema, per0 no dice c6mo implementar dicho sistema.

A continuaci6n se describiran brevemente 10s diagramas mas comunes del UML y 10s conceptos que representan. Posteriormente, en la parte I Vera 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 iintkntelo 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 encontrara con que las cosas naturalmente se albergan en categorias (autom6viles, 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 nlimero de serie y la capacidad. Entre las acciones

lntroduccion al UML

91

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 notacidn del UML que captura 10s atributos y acciones de una lavadora. Un rectingulo es el simbolo que representa a la clase, y se divide en tres Areas. El Area superior contiene el nombre, el Area central contiene 10s atributos, y el Area inferior las acciones. Un diagrama de clases esti formado por varios rectingulos de este tipo conectados por lineas que muestran la manera en que las clases se relacionan entre si.

FIGURA 1.1
El sirnbolo UML de una clase.
rnarca modelo numero de serie capacidad agregar ropa() agregar detergente() sacar ropa()

iQuC objetivo tiene pensar en las clases, asi como sus atributos y acciones? Para interactuar con nuestro complejo mundo, la mayoria del software modern0 simula algdn aspecto del mundo. DCcadas de experiencia sugieren que es m8s sencillo desarrollar aplicaciones que simulen algun aspecto del mundo cuando el software representa clases de cosas reales. Los diagramas de clases facilitan las representaciones a partir de las cuales 10s desarrolladores podrin trabajar.
A su vez, 10s diagramas de clases colaboran en lo referente a1 anilisis. Permiten a1 analista hablarle a 10s clientes en su propia terminologia, lo cual hace posible que 10s clientes indiquen importantes detalles de 10s problemas que requieren ser resueltos.

Diagrama de objetos
Un objeto es una instancia de clase (una entidad que tiene valores especificos de 10s atributos y acciones). Su lavadora, por ejemplo, podria tener la marca Laundatorium, el modelo Washmeister, el nlimero 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 simbolo es un rectingulo, como en una clase, per0 el nombre esti subrayado. El nombre de la instancia especifica se encuentra a la izquierda de 10s dos puntos (:), y el nombre de la clase a la derecha.

I 10

Hora 1

FIGURA 1.2
El simbolo UML del objeto.

Diagrama de casos de us0

Un caso de us0 es una descripcion de las acciones de un sistema desde el punto de vista del usuario. Para 10s desarrolladores del sistema, Csta 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 mostrark un ejemplo 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 us0 UML.

FIGURA1.3
Diagranza de casos de us0 UML.

Usuario de la lavadora

K-

Lavar ropa

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 reciCn nacida, infante, adolescente, joven o adulta. Un elevador se moveri hacia arriba, estar6 en estado de reposo o se mover6 hacia abajo. Una lavadora podri 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 pequefia realidad. La figura muestra las transiciones de la lavadora de un estado a1 otro. El simbolo que esti en la parte superior de la figura representa el estado inicial y el de la parte inferior el estado final.

lntroduccion at UML

11

FIGURA 1.4
Diagrarna de estados UML.

t
Lavado

Q
Diagrama de secuencias
Los diagramas de clases y 10s de objeto representan informaci6n esthtica. No obstante, en un sistema funcional 10s objetos interactfian entre si, y tales interacciones suceden con el tiempo. El diagrama de secuencias UML muestra la mecinica de la interacci6n 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 veri, un objeto puede estar conformado por otros objetos). iQuC sucederh cuando invoque a1 caso de us0 Lavar ropa? Si damos por hecho que complet6 las operaciones agregar ropa, agregar detergente y activar, la secuencia seria mis o menos asi: 1. El agua empezari a llenar el tambor mediante una manguera. 2. El tambor permaneceri inactivo durante cinco minutos.
3. 4. 5. 6. 7.

La manguera dejari de abastecer agua. El tambor girari de un lado a otro durante quince minutos. El agua jabonosa saldrh por el drenaje. Comenzarh nuevamente el abastecimiento de agua. El tambor continuari girando.

I12

Hora 1

8. El abastecimiento de agua se detendri. 9. El agua del enjuague saldri por el drenaje. 10. El tambor girari en una sola direcci6n y se incrementari su velocidad por cinco minutos. 11. El tambor dejara de girar y el proceso de lavado habri 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. FIGURA1.5
Diagrama de secuencias UML.

Drenaje

- Reabastecer de agua

Detenerse

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 de18 a1 10 como el estado de centrifugado.

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

lntroduccion al UML

13 I

FIGURA 1.6
Diagrama de actividades UML.

Girar el tambor de un lado a otro 15 rninutos

I .
Vaciar el agua jabonosa

Reiniciar el abastecimientode agua

Diagrama de colaboraciones
Los elementos de un sistema trabajan en conjunto para cumplir con 10s objetivos del sistema, y un lenguaje de modelado deberfi 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 detendri el flujo de agua y el tambor comenzari a girar de un lado a otro.
FIGURA 1.7
Diagrama de colaboraciones UML.
2: Girar de un lado a otm

Cronometro interno

Manguera de agua

r -T

Diagrama de componentes
Este diagrama y el siguiente dejarfin el mundo de las lavadoras, dado que estin intimamente ligados con 10s sistemas informfiticos. El modern0 desarrollo de software se realiza mediante componentes, lo que es particularmente importante en 10s procesos de desarrollo en equipo. Sin extenderme mucho en este punto le mostrare, en la figura 1.8, la manera en que el UML representa un componente de software.
FIGURA 1.8
Diagrama de componentes UML.

Componente

G I

I' 4

Hora 1

Diagrama de distribucion
El diagrama de distribuci6n UML muestra la arquitectura fisica de un sistema informhtico. 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 esthn representadas por lineas que conectan a 10s cubos. La figura 1.9 presenta un ejemplo.

FIGURA1.9
Diagrarna de distribucidn UML.
"Procesador" Pequefio servidor Qube 2700WG de Cobalt Networks
/

Vectra VL Serie 7

Dell Dimension XPS R450

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

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

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

1
Paquete 1

0
Clase 1

lntroduccion al UML

15

Notas
Es frecuente que alguna parte del diagrama no presente una Clara explicaci6n del porquC esti alli o la manera en que trabaja. Cuando Cste sea el caso, la nota UML sera titil. Imagine a una nota como el equivalente gr6fko de un papel adhesivo. La nota es un recthngulo con una esquina doblada, y dentro del rectbgulo se coloca la explicaci6n. Usted adjunta la nota a1 elemento del diagrama conecthdolos mediante una linea discontinua.

FIGURA 1.11
En cualquier diagrama, podra agregar comentarios aclaratorios mediante una nota.
respecto a la Clase 1
I I

0
Clase 1

Estereotipos
El UML otorga varios elementos de utilidad, pero no es un conjunto minucioso de ellos. De vez en cuando diseiiari un sistema que requiera algunos elementos hechos a la medida. Los estereotipos o clisCs le permiten tomar elementos propios del UML y convertirlos en otros. Es como comprar un traje del mostrador y modificarlo para que se ajuste a sus medidas (contrario a confeccionarse uno completamente nuevo). Imagine a un estereotipo como este tip0 de alteraci6n. Lo representari como un nombre entre dos pares de parkntesis angulares y despuCs 10s aplicari correctamente. 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 elemento para representar una interfaz, podri utilizar el simbolo de una clase con dnterfazv situada justo sobre el nombre de la clase, como se muestra en la figura 1.12.

FIGURA 1.12
Un estereotipo le pemzite crear nuevos elementos a partir de otros existentes.

n
U

116

Hora 1

Para que tantos diagramas

Como puede ver, 10s diagramas del UML le penniten 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 lo 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 operacidn, 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 notacidn fAcil de comprender, el proceso de desarrollo tiene una gran cantidad de errores. El UML es un sistema de notacidn que se ha convertido en esthndar en el mundo del desarrollo de sistemas. Es el resultado del trabajo hecho por Grady Booch, James Rumbaugh e Ivar Jacobson. El UML esth constituido por un conjunto de diagramas, y proporciona un esthndar que permite a1 analista de sistemas generar un anteproyecto de varias facetas que Sean comprensibles para 10s clientes, desarrolladores y todos aquellos que e s t h involucrados en el proceso de desarrollo. Es necesario contar con todos esos diagramas dado que cada uno se dirige a cada tipo de persona implicada en el sistema. Un modelo UML indica que es lo que supuestamente harh el sistema, mas no cbmo lo has&

Preguntas y respuestas
P He visto que se refiere a1 Lenguaje Unificado de Modelado como UML y como el UML. LCuhl es el correcto? R Los creadores del lenguaje prefieren el us0 de el UML. P Ha indicado que el UML es adecuado para 10s analistas. No obstante, el diagrama de distribucibn no parece ser algo muy 6til en la fase de anidisis en el desarrollo de un sistema. iNo seria m b apropiado para una fase posterior?

lntroduccion al UML

17

R En realidad nunca seri demasiado pronto para empezar a pensar en la distribucibn

(u otras 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 sistema. En algunas ocasiones, el cliente dicta esto; en otras, el cliente desea una recomendacibn del equipo de desarrollo. Ciertamente, un arquitecto de sistemas encontrari dtil a1 diagrama de distribucibn.

P Ha mencionado que es posible hacer diagramas hibridos. LUML,perdhn, el UML, impone limitaciones respecto a 10s elementos que podrh 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. Podr6 colocar simbolos de clases en un diagrama de distribucibn, per0 ello no sera muy btil.

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

Cuestionario
1. iPorquC es necesario contar con diversos diagramas en el modelo de un sistema? 2. iCuiles diagramas le dan una perspectiva estitica de un sistema? 3. iCu6les diagramas le dan una perspectiva d i n h i c a de un sistema (esto es, muestran el cambio progresivo)?

Ejercicios
1. Suponga que creari un sistema informitico que jugari ajedrez con un usuario. iCuiles diagramas UML serian M e s para diseiiar el sistema? iPor quC? 2. Para el sistema del ejercicio que ha completado, liste las preguntas que formulma a un usuario potencial y por quC las hma.

3RA

Orlientacion 3bjetos
E!5 fundamental que comprenda todo lo relacionado a la orientaci6n a otIjetos para el proceso que realizark especificamente, es importante que ccmozca algunos conceptos sobre la orientaci6n a objetos. EI n esta hora se tratarin 10s siguientes temas:
Abstracci6n Herencia Polimorfismo Encapsulamiento o encapsulaci6n Envio de mensajes Asociaciones Agregacih

Lia orientacidn a objetos ha tomado por asalto y en forma legitima a1 mundo dc: 1 software. Como medio para la generaci6n de programas, tiene varias venjas. ta. Fomenta una metodologia basada en componentes para el desarrollo

Hora 2

de software, de manera que primer0 se genera un sistema mediante un conjunto de objetos, luego podrh ampliar el sistema agreghndole funcionalidad a 10s componentes que ya habia generado o agreghndole nuevos componentes, y finalmente podrh volver a utilizar 10s objetos que generd para el sistema cuando Cree uno nuevo, con lo cual reducirh 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 administraci6n de objetos), una corporacidn 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 ddlares en 10s siguientes tres a cinco afios. El UML influye en esto a1 permitirle generar modelos de objetos fhciles de usar y comprender para que 10s desarrolladores puedan convertirlos en software. La orientacidn a objetos es un paradigma (un paradigma que depende de ciertos principios fundamentales). En esta hora comprenderh dichos principios y verh quC es lo 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, esthn a nuestro alrededor, ellos conforman nuestro mundo. Como indiquC en la hora anterior, el software actual simula a1 mundo (0un segmento de Cl), y 10s programas, por lo general, imitan a 10s objetos del mundo. Si comprende algunas cuestiones bhsicas de 10s objetos, entenderh c6mo se deben mostrar Cstos en las representaciones de software. Antes que nada, un objeto es la instancia de una clase (0categoria). 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 mhs). 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), seria muy probable que incorporkamos algunos de sus atributos y acciones en nuestro software. En el mundo de la orientacidn a objetos, una clase tiene otro propdsito ademhs de la categorizaci6n. En realidad es una plantilla para fabricar objetos. Imaginelo como un molde de galletas que produce muchas galletas (algunos alegman que esto es lo mismo que la categorizacibn, pero evitemos dicho debate).

Orientacion a objetos

21

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), tendrh un mecanismo para fabricar nuevas instancias a partir de su clase; es decir, podrh crear nuevos objetos (vea la figura 2.1).

En la hora 3, "Us0 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 como nurnero de serie se escribiran como nurneroserie.

Esto es particularmente importante en el desarrollo de software orientado a objetos. Aunque este libro no se enfoca a la programaci6n, le ayudara a comprender la orientaci6n a objetos si sabe que las clases en 10s programas orientados a objetos pueden crear nuevas instancias.
FIGURA2.1
La clase Lavadora (modelo original) es una plantilla para generar nuevas instancias de Lavadoras.

Lavadora marca modelo numeroserie capacidad agregarRopa0 agregarDetergente0 sacarRopa()

Es importante que recuerde que el prop6sito de la orientaci6n a objetos es desarrollar software que refleje particularmente (es decir, que modele) un esquema del mundo. Entre mhs atributos y acciones tome en cuenta, mayor sera la similitud de su modelo con la realidad. En el ejemplo de la lavadora, tendrh un modelo mhs exacto si incluye 10s siguientes atributos: volumen del tambor, cron6metro interno, trampa, motor y velocidad del motor. Podria hacerlo mhs 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).

I22

Hora 2

FIGURA2.2
La adicidn de atributos y acciones a1 modelo lo acerca a la realidad.

Lavadora rnarca rnodelo numeroserie capacidad volurnenTarnbor cronometrolnterno trarnpa motor velocidadMotor agregarRopa() agregarDetergente0 sacarRropa() agregarBlanqueador0 cronometrarRernojo() cronornetrarLavado() cronornetrarEnjuague() cronometrarCentrifugado()

Algunos conceptos
La orientacidn a objetos se refiere a algo mhs que tan s610 atributos y acciones; tambiCn considera otros aspectos. Dichos aspectos se conocen como abstruccibn, herenciu, polirnorJisrno y encapsulamiento o encapsulacio'n. Otros aspectos importantes de la orientacidn a objetos son: el envio de mensajes, las asociaciones y la agregacibn. Examinemos cada uno de estos conceptos.

A bst raccion
La abstraccidn se refiere a quitar las propiedades y acciones de un objeto para dejar s610 aquellas que Sean necesarias. iQuC significa esto liltimo? Diferentes tipos de problemas requieren distintas cantidades de informacidn, aun si estos problemas pertenecen a un k e a en comlin. En la segunda fase de la creacidn de la clase Lavadora, se podrian agregar mhs atributos y acciones que en la primera fase. LVale la pena? Valdria la pena si usted pertenece a1 equipo de desarrollo que generarh finalmente la aplicacidn que simule con exactitud lo que hace una lavadora. Un programa de este tip0 (que podria ser muy litil para 10s ingenieros de diseiio que actualmente estCn trabajando en el diseiio de una lavadora) deberh ser tan cornpleto que permita obtener predicciones exactas respecto a lo que ocurriria cuando se fabrique la lavadora, funcione a toda su capacidad y lave la ropa. De hecho, para este caso podrh quitar el atributo del ndmero de serie, dado que posiblemente no sera de mucha ayuda. Por otra parte, si va a generar un software que haga un seguimiento de las transacciones en una lavanderia que cuente con diversas lavadoras, posiblemente no valdrh la pena. En este programa no necesitarh todos 10s atributos detallados y operaciones del p h a f o anterior, no obstante, quizh necesite incluir el nlimero de serie de cada objeto Lavadora.

Orientacion a objetos

23

En cualquier caso, con lo que se quedari luego de tomar su decisi6n respecto a lo que incluiri o desechari, sera una abstracci6n de una lavadora.

Herencia
Como ya se mencion6 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 caracten'sticas de la clase de la que proviene. A esto se le conoce como herenciu. No importa quk atributos y acciones decida usar de la clase Lavadora, cada objeto de la clase heredari dichos atributos y operaciones.

Un objeto no s610 hereda de una clase, sino que una clase tambikn puede heredar de otra. Las lavadoras, refrigeradores, homos de microondas, tostadores, lavaplatos, radios, licuadoras y planchas son clases y forman parte de una clase mis genirica llamada: Electrodomesticos. Un electrodomkstico cuenta con 10s atributos de interruptor y cable elkctrico, y las operaciones de encendido y apagado. Cada una de las clases Electrodomestico heredari 10s mismos atributos; por ello, si sabe que algo es un electrodomistico, de inmediato sabri que cuenta con 10s atributos y acciones de la clase Electrodomestico.
Otra forma de explicarlo es que la lavadora, refrigerador, homo de microondas y cosas por el estilo son subcluses de la clase Electrodomestico. Podemos decir que la clase Electrodomestico es una superclase de todas las demis. La figura 2.3 le muestra la relacidn de superclase y subclase.

FIGIJRA 2.3
Los electrodom6sticos heredan 10s atributos y acciones de la clase Electrodomestico. Cada electrodomkstico es una subclase de la clase Electrodomestico. La clase Electrodomestico es una superclase de cada subclase.
Electrodomestico

I24

Hora 2

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.
FIGUM 2.4 Las superclases
tambih pueden ser

Articulos del hogar

Electrodomestico

Mobiliario

Polimorfism0
En ocasiones una operacidn tiene el mismo nombre en diferentes clases. Por ejemplo, podri abrir una puerta, una ventana, un peribdico, un regalo o una cuenta de banco, en cada uno de estos casos, realizari una operacidn diferente. En la orientacidn a objetos, cada clase sabe cdmo realizar tal operacidn. Esto es el polimorfismo (vea la figura 2.5).
FIGURA2.5 .
En el polimo@smo, una operacidn puede tener el mismo nombre 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 computacidn, y deben estar conscientes de diferencias importantes entre las operaciones que pudieran tener el mismo nombre. Y podrin generar clases de software que sepan lo que se supone que harhn. No obstante, el polimorfismo tambiCn es importante para 10s modeladores ya que les permite hablar con el cliente (quien est5 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 accidn (como abrir) que pueden

Orientacion a objetos

25 I

tener mhs de un significado. El polimorfismo permite a1 modelador mantener tal terrninologia 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: LC6mo funciona?
Y el otro responde: LC6mo hacen que las rosetas de maiz estallen? LAquitn le importa?

La esencia del encapsulamiento (0encapsulaci6n) es que cuando un objeto trae consigo su funcionalidad, esta Gltima se oculta (vea la figura 2.6). Por lo general, la mayoria de la gente que ve la televisi6n no sabe o no se preocupa de la complejidad electr6nica que hay detrfis de la pantalla ni de todas las operaciones que tienen que ocurrir para mostrar una imagen en la pantalla. La televisi6n hace lo que tiene que hacer sin mostrarnos el proceso necesario para ello y, por suerte, la mayoria de 10s electrodomCsticos funcionan asi.
FIGIJRA 2.6
LO5

objetos encapsulan ,lo que hacen; es

deci < ocultan la funcionialidad interna de sus ,operaciones, de oitros obietos Y de

La television oculta sus operaekmes de la persona que la ve.

LCuhl es 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 serh necesario modificar 10s demhs objetos.

Hora 2

En el mundo real, tambiCn verfi 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, lo repararfi o lo reemplazarfi; 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 lo que hace a otros objetos y a1 mundo exterior, por lo cual a1 encapsulamiento tambiCn se le conoce como ocultamiento de la informacidn. Per0 un objeto tiene que presentar un rostro a1 mundo exterior para poder iniciar sus operaciones. Por ejemplo, la televisidn tiene diversos botones y perillas en si misma o en el control remoto. Una lavadora tiene diversas perillas que le permiten establecer 10s niveles de temperatura y agua. Los botones y perillas de la televisidn y de la lavadora se conocen como integaces.

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 operacih, y el objeto receptor ejecutarfi la operaci6n. Una televisidn y su control remoto pueden ser un ejemplo muy intuitivo del mundo que nos rodea. Cuando desea ver un programa de televisidn, busca el control remoto, se sienta en su silla favorita y presiona el b o t h de encendido. iQuC ocurre? El control remoto le envia, literalmente, un mensaje a1 televisor para que se encienda. El televisor recibe el mensaje, lo identifica como una peticidn para encenderse y asi lo hace. Cuando desea ver otro canal, presiona el b o t h correspondiente del control remoto, mismo que envia otro mensaje a la televisidn (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 podrfi hacer si se levanta de la silla, va a la televisidn y presiona 10s botones correspondientes (ialguna vez lo habrfi hecho ya!). La interfaz que la televisidn le presenta (el conjunto de botones y perillas) no es, obviamente, la misma que le muestra a1 control remoto (un receptor de rayos infrarrojos). La figura 2.7 le muestra esto.

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

Orientacidn a objetos

27

FIG^IRA 2.7
Ejennplo de un mensaje enviado de un objeto a ot ro: el objeto COIttrol remoto envia un mensaje a1 objcto televisidn p a nz encenderse. El olbjeto televisidn recibe el mensaje mea!ante su interfaz, un raceptor infrarrojo.

FIGURA 2.8
Corzfrecuencia 10s etos se relacionan obj, ent, re sf de alguna fonna. Cuando usted enc,iende su televisidn, ten, drd una asociacidn en una sola direccidn cori ella.

a
Encender P

En ocasiones, un objeto podna asociarse con otro en mAs de una forma. Si usted y su colaborador son amigos, ello servir5 de ejemplo. Usted tendria una asociacidn es amigo de, asi como es colaborador de, como se aprecia en la figura 2.9.

FIC ium 2.9

En ocasiones, 10s ob,ietos pueden as1xiarse en mas de una fomuz.

Tom

Bill

I 28

Hora 2

Una clase se puede asociar con mhs de una clase distinta. Una persona puede viajar en autombvil, per0 tambikn puede hacerlo en autobds (vea la figura 2.10).
FIGURA2.10
Una clase puede asociarse con mds de una clase distinta.

La multiplicidad (0diversificaci6n) 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 esthn en una asociaci6n de uno a uno. Sin embargo, en un seminario hay diversos instructores que impartirhn el curso a lo largo del semestre, por lo tanto, el curso y el instructor tienen una asociaci6n de uno a muchos. Podrh encontrar todo tipo de multiplicidades si echa una mirada a su alrededor. Una bicicleta rueda en dos neumhticos (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 rat6n, un monitor, una unidad de CD-ROM, uno o varios discos duros, un m6dem, 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 esth constituido de diversos tipos de componentes (vea la figura 2.1 1). Tal vez conozca varios ejemplos de agregaciones.

Orientacion a objetos

29 I

FIGURA 2.1 1
Una computadora es un ejemplo de agregacidn: un objeto que se conforma de una combinacibn de diversos tipos de objetos.

Un tipo de agregaci6n trae consigo una estrecha relaci6n entre un objeto agregado y sus objetos componentes. A esto se le conoce como composicio'n. El punto central de la composicidn es que el componente se considera como tal s610 como parte del objeto compuesto. Por ejemplo: una camisa est6 compuesta de cuerpo, cuello, mangas, botones, ojales y puiios. Suprima la camisa y el cuello sera in6til. En ocasiones, un objeto compuesto no tiene el mismo tiempo de vida que sus propios componentes. Las hojas de un irbol pueden morir antes que el hbol. Si destruye a1 irbol, tambitn las hojas moririn (vea la figura 2.12). La agregaci6n y la composicidn son importantes dado que reflejan casos extremadamente comunes, y ello ayuda a que Cree modelos que se asemejen considerablemente a la realidad.

I 30
FIGURA2.12
En una composicidn, un componente puede morir antes que el objeto compuesto. Si destruye a1 objeto compuesto, destruira' tambiin a 10s componentes.

Hora 2

La recompensa
Los objetos y sus asociaciones conforman la columna vertebral de la funcionalidad de 10s sistemas. Para modelarlos, necesitara comprender lo que son las asociaciones. Si esti consciente de 10s posibles tipos de asociaciones, tendra una amplia gama de posibilidades cuando hable con 10s clientes respecto a sus necesidades, obtendri sus requerimientos y creari 10s modelos de 10s sistemas que 10s ayudarin 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 dorninio), y esclarecer sus puntos de vista a1 cliente en tkrminos que 61 o ella puedan comprender. Es alli donde se aplica el UML. En las siguientes tres horas, aprenderfi 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 6rea del problema en que trabaje determinari cuintos de 10s atributos y acciones debe tomar en cuenta. La herencia es un aspect0 importante de la orientacih a objetos, un objeto hereda 10s atributos y operaciones de su clase. Una clase tambiCn puede heredar atributos y acciones de otra.

Orientacion a objetos

31 I

El polimorfismo es otro aspect0 importante, ya que especifica que una accidn puede tener el mismo nombre en diferentes clases y cada clase ejecutarh tal operacidn 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 lo general, 10s objetos se asocian entre si y esta asociacidn puede ser de diversos tipos. Un objeto en una clase puede asociarse con cualquier cantidad de objetos distintos en otra clase. La agregacidn es un tip0 de asociacidn. Un objeto agregado consta de un conjunto de objetos que lo componen y una composicidn es un tipo especial de agregacidn. En un objeto compuesto, 10s componentes s610 existen como parte del objeto compuesto.

Preguntas y respuestas
P Usted dijo que la orientacibn a objetos ha tomado por asalto al mundo del software. iQuC no hay algunas aplicaciones importantes que no e s t h orientadas a objetos? R Si, y se conocen como sistemas heredados (programas que en muchos casos son ejecutados para mostrar su Cpoca). La orientacidn 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 orientacidn a objetos.

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

Cuestionario
1. 2. 3. 4. iQu6 es un objeto? iC6mo trabajan 10s objetos en conjunto? iQuC establece la multiplicidad? iPueden asociarse dos objetos entre si en mis de una manera?

I32

Hora 2

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

4ORA

Jso de la orientacion
I

objetos
A continuacidn conjugaremos las caracten'sticas del UML con 10s conceptos de la orientacidn a objetos. Aqui reafirmari su conocimiento de la orientacidn a objetos a1 tiempo que aprenderi otras cosas del UML. En esta hora se tratarin 10s siguientes temas: Concepcidn de una clase Atributos Operaciones Responsabilidades y restricciones QuC es lo que hacen las clases y cdmo encontrarlas

oncepcion de una clase

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

I34

Hora 3

FIGURA3.1
La representacidn U M L de una clase.

l----l

I
Lavadoralndustrial Electrodornesticos

Otra estructura del UML, el paquete, puede jugar un papel en el nombre de la clase. Como indiquC en la hora 1, Introduccibn a1 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.

Si la clase Lavadora es parte de un paquete llamado Electrodomesticos, podri darle el nombre E1ectrodomesticos::Lavadora.El par de dos puntos separa a1 nombre del paquete, que esti 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 nornbres se han evitado 10s caracteres acentuados (corno en Electrodornesticos) y la letra eAe. 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 problernas, tanto en el UML corno en el lenguaje de programacion que piense utilizar para traducir 10s rnodelos. Por ello, evitarernos 10s acentos en todos 10s diagrarnas que se presentan a lo largo de este libro, de igual rnanera, evitarernos el us0 de la letra eAe, rnisrna que sustituirernos - e n su caso- por ni (corno en Anio, en lugar de Afio).

FIGURA3.3
Una clase con un nombre de ruta.

i__l
Electrodornesticos: :Lavadora

At ributos
Un atributo es una propiedad 0 caracteristica de una clase y describe un rango de valores que la propiedad podri contener en 10s objetos (esto es, instancias) de la clase. Una clase podri contener varios o ningdn atributo. Por convencibn, si el atributo consta de una sola palabra se escribe en min6sculas; por otro lado, si el nombre contiene mis de una palabra, cada palabra sera unida a la anterior y comenzari con una letra may6scula, a excepcibn de la primer palabra que comenzarh en mindscula. La lista

Us0 d e la orientacion a objetos

..

35 I

de nombres de atributos iniciara luego de una linea que la separe del nombre de la clase, como se aprecia en la figura 3.4. FIGURA 3.4
Una clase y sus atributos.
Lavadora marca modelo numeroserie 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 minliscula, y esti precedido de dos puntos que a su vez estan precedidos del nombre de la clase, y todo el nombre esti subrayado.
El nombre m i l a v a d o r a : Lavadora es una instancia con nombre; per0 tarnbien es posible tener una instancia anonima, como :Lavadora.

FIGURA 3.5 Un objeto cuenta con

un valor especljCco en cada uno de 10s atributos que lo
cornponen.

miLavadora:Lavadora marca = "Laundatorium" modelo = "Washrneister" numeroserie = "GL57774" capacidad = 16

El UML le da la opci6n de indicar informacih adicional de 10s atributos. En el simbolo de la clase, podra especificar un tip0 para cada valor del atributo. Entre 10s posibles tipos se encuentran cadena (string), nlimero 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 podri 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, utilizarernos 10s nombres en ingles para cefiirnos a 10s tipos que aparecen en 10s lenguajes de programacion.

I36

Hora 3

FIGURA 3 . 6
Un atributo puede mostrar su tipo asi como su valor predeterminado.

Lavadora rnarca: string = "Laundatoriurn" modelo: string nurneroserie: string capacidad: integer

Operaciones
Una operucibn 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 operacidn se escribe en mindsculas si consta de una sola palabra. Si el nombre constara de mis de una palabra, dnalas 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.

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

Lavadora rnarca rnodelo nurneroserie capacidad agregarRopa() sacarRopa() agregarDetergente0 activar()

Asi como es posible establecer informaci6n adicional de 10s atributos, tambiCn lo es en lo concerniente a las operaciones. En 10s parkntesis que preceden a1 nombre de la operaci6n podri mostrar el parametro con el que funcionara la operaci6n junto con su tip0 de dato. Lafuncidn, que es un tipo de operacibn, devuelve un valor luego que finaliza su trabajo. En una funci6n podra mostrar el tip0 de valor que regresari.

Estas secciones de informacion acerca de una operaci6n se conocen como la firmu de la operaci6n. La figura 3.8 le muestra c6mo representar la firma.

Us0 de la orientacion a objetos

37 I

FIGURA 3.8
Lafirma de una operacidn.

I I

Lavadora rnarca rnodelo nurneroserie capacidad

agregarRopa(C:String) sacarRopa(C:String) agregarDetergente(D:lnteger) activar():Boolean

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 practica mostrari mis de una clase a la vez; cuando lo 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 podri tan s610 mostrar el nombre de la clase y dejar ya sea el 5rea de atributos o el de operaciones (0ambas) vacia, como se muestra en la figura 3.9.
FIGURA3 . 9
En la practica, no siempre rnostrard todos 10s utributos y operaciones de una clase.

En ocasiones sera bueno mostrar algunos (pero no todos) de 10s atributos u operaciones. Para indicar que s610 enseiiara algunos de ellos, seguiri la lista de aquellos que mostrari 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 abreviur una clase. La figura 3.10 le muestra el us0 de 10s puntos suspensivos.
FIGURA3.10
Los puntos suspensivos indican atributos u operaciones que no se encuentran en todo el conjunto.

I ...
Lavadora rnarca
I

agregarRopa0

I 38

Hora 3

Si usted tiene una larga lista de atributos u operaciones podrfi utilizar un estereotipo para organizarla de forma que sea~~mfis comprensible. Un estereotipo es el mod0 en que el UML le permite extenderlo, es decir, crear nuevos elementos que son especfficos de un problema en particular que intente resolver. Como lo mencion6 en la hora 1, usted muestra un estereotipo como un nombre bordeado por dos pares de parkntesis angulares. Para una lista de atributos, podrfi utilizar un estereotipo como encabezado de un subconjunto de atributos, como en la figura 3.1 1.
FIGURA3.1 1
Podrd usar un estereotipo para organizur una lista de atributos u operaciones.
Lavadora 4nfo identificacion. marca modelo numeroserie .info maquinan capacidad

agregarRopa0 sacarRopa() agregarDetergente0 <<relacionado con la maquina,,

El estereotipo es una estructura flexible, la cual podra utilizar de diversos rnodos. Por ejernplo, podra utilizar el estereotipo sobre el nornbre de una clase en un sirnbolo de clase para indicar algo respecto al papel de la clase.

Responsabilidades y restricciones
El simbolo de clase le permite establecer otro tipo de informaci6n de si misma. En un 5rea bajo la lista de operaciones, podrfi mostrar la responsabilidad de la clase. La responsabilidad es una descripcih de lo que harfi la clase, es decir, lo que sus atributos y operaciones intentan realizar en conjunto. Una lavadora, por ejemplo, tiene la responsabilidad de recibir ropa sucia y dar por resultado ropa limpia. En el simbolo, indicarfi las responsabilidades en un h e a inferior a la que contiene las operaciones (vea la figura 3.12).

Us0 de la orientacion a objetos

39 I

FIGURA3.12
En un sirnbolo de clase, que ira debajo de la lista de operaciones, escribira las responsabilidades de la clase.

Lavadora 4nfo identificacion,, marca modelo numeroserie 4nfo maquina,, capacidad

I

-relacionado con la ropa>> agregarRopa0 sacarRopa() agregarDetergente0 .relacionado con la maquina,, activaro

2
Recibe ropa sucia y devuelve ropa lirnpia

La idea es incluir informaci6n suficiente para describir una clase de forma inequivoca. Una manera mis formal es agregar una restriccion, un texto libre bordeado por llaves; este texto especifica una o varias reglas que sigue la clase. Por ejemplo, suponga que en la clase Lavadora usted desea establecer que la capacidad de una lavadora sera de 7, 8 o 9 Kg (y asi, restringir el atributo capacidad de la clase Lavadora). Usted escribiri {capacidad= 7, 8 o 9 Kg} junto al simbolo de la clase Lavadora. La figura 3.13 le muestra c6mo hacerlo.

FIGURA3.13
La regla entre llaves restringe a1 atributo capacidad para contener uno de tres posibles valores.
rnarca modelo numeroserie (capacidad = 7, 8 o 9 Kg) agregarRopa() sacarRopa() agregarDetergente0

El UML funciona con otra forma -aun mas formal- de agregar restricciones que hacen mas explicitas las definiciones. Es todo un lenguaje conocido corno OCL (Lenguaje de restriccidn de objetos). OCL cuenta con su propio conjunto de reglas, terminos y operadores, lo que lo convierte en una herramienta avanzada y, en ocasiones, util.

I40

Hora 3

Notas adjuntas
Por encima y debajo de 10s atributos, operaciones, responsabilidades y restricciones, puede agregar mayor informaci6n a una clase en la figura de notas adjuntas. Con frecuencia agregarh una nota a un atributo u operaci6n. La figura 3.14 le muestra una nota que se refiere a una norma gubernamental que indica d6nde encontrar la manera en que se generan 10s ndmeros de serie para 10s objetos de la clase Lavadora.
FIGURA 3.14
Una nota adjunta proporciona mayor informacidn respecto a la clase.
rnarca rnodelo nurneroserie capacidad

---------

agregarRopa0 sacarRopa() agregarDetergente0 activar()

4
Vease la norrna gubernarnental EV5-2241 de 10s Estados Unidos para la generacion de nurneros de serie

Una nota puede contener tanto una irnagen corno texto.

Que es lo que hacen las clases y como encontrarlas

Las clases son el vocabulario y terminologia de un k e a del conocimiento. Conforme hable con los clientes, analice su irea de conocimiento y diseiie sistemas de computacih que resuelvan 10s problemas de dicha kea, comprenderh la terminologia y modelarh 10s tCrminos como clases en el UML. En sus conversaciones con 10s clientes preste atenci6n a 10s sustantivos que utilizan para describir las entidades de sus negocios; ya que dichos sustantivos se convertirhn en las clases de su modelo. TambiCn preste atencidn a 10s verbos que escuche, dado que constituiran las operaciones de sus clases. Los atributos surgirhn como sustantivos relacionados con 10s nombres de la clase. Una vez que tenga una lista basica de las clases, pregunte a 10s clientes quC es lo que cada clase hace dentro del negocio. Sus respuestas le indicarhn las responsabilidades de la clase. Suponga que usted es un analista que generarh un modelo del juego de baloncesto, y que entrevista a un entrenador para comprender el juego. La conversaci6n podria surgir como sigue:

Us0 de la orientacion a objetos

Analista: Entrenador, ide quC se trata el juego? Entrenador: Consiste en arrojar el bal6n a travCs de un aro, conocido como cesto, y hacer una mayor puntuaci6n que el oponente. Cada equipo consta de cinco jugadores: dos defensas, dos delanteros y un central. Cada equipo lleva el baldn a1 cesto del equipo oponente con el objetivo de hacer que el bal6n sea encestado. Analista: iC6mo se hace para llevar el bal6n al otro cesto? Entrenador: Mediante pases y dribles. Pero el equipo tendrh que encestar antes de que termine el lapso para tirar. Analista: iEl lapso para tirar? Entrenador: Asi es, son 24 segundos en el baloncesto profesional, 30 en un juego intemacional, y 35 en el colegial para tirar el baldn luego de que un equipo toma posesi6n de 61. Analista: iC6mo funciona el puntaje? Entrenador: Cada canasta vale dos puntos, a menos que el tiro haya sido hecho detrhs de la linea de 10s tres puntos. En tal caso, serhn tres puntos. Un tiro libre contarh como un punto. A prop6sit0, un tiro libre es la penalizaci6n que paga un equipo por cometer una infracci6n. Si un jugador infracciona a un oponente, se detiene el juego y el oponente puede realizar diversos tiros a1 cesto desde la linea de tiro libre. Analista: HBbleme mhs acerca de lo que hace cada jugador. Entrenador: Quienes juegan de defensa son, en general, quienes realizan la mayor parte de 10s dribles y pases. Por lo general tienen menor estatura que 10s delanteros, y Cstos, a su vez, son menos altos que el central (que tambiCn se conoce como poste). Se supone que todos 10s jugadores pueden burlar, pasar, tirar y rebotar. Los delanteros realizan la mayoria de 10s rebotes y 10s disparos de mediano alcance, mientras que el central se mantiene cerca del cesto y dispara desde un alcance corto. Analista: ~QuC hay de las dimensiones de la cancha? Y ya que estamos en eso jcuhnto dura el juego? Entrenador: En un juego internacional, la cancha mide 28 metros de longitud y 15 de ancho; el cesto se encuentra a 3.05 m del piso. En un juego profesional, el juego dura 48 minutos, divididos en cuatro cuartos de 12 minutos cada uno. En un juego colegial e internacional, la duraci6n es de 40 minutos, divididos en dos mitades de 20 minutos. Un cron6metro del juego lleva un control del tiempo restante. La plBtica podria continuar, per0 hagamos una pausa y veamos con quC contamos. Aqui hay varios sustantivos que ha descubierto: bal6n, cesto, equipo, jugadores, defensas, delanteros, centro (0 poste), tiro, lapso para tirar, linea de 10s tres puntos, tiro libre, infraccibn, linea de tiro libre, cancha, crondmetro del juego. Y 10s verbos: tirar, avanzar, driblar (0burlar), pasar, infraccionar, rebotar. TambiCn cuenta con cierta informacidn adicional respecto a algunos de 10s sustantivos (como las

I42

Hora 3

estaturas relativas de 10s jugadores de cada posicibn, las dimensiones de la cancha, la cantidad total de tiempo en un lapso de tiro y la duraci6n de un juego). Finalmente, su propio sentido comun podria entrar en accibn para generar ciertos atributos por usted mismo. Usted sabe, por ejemplo, que el balbn cuenta con ciertos atributos, como volumen y dihmetro.

A partir de esta informacibn, podrh crear un diagrama como el de la figura 3.15. En 61 se muestran las clases y se proporcionan ciertos atributos, operaciones y restricciones. El diagrama tambiCn muestra las responsabilidades. Podria usar este diagrama como fundamento para otras conversaciones con el entrenador para obtener mayor informacibn.

FIGURA3.15
Un diagrama inicial para modelar el juego de baloncesto.

Balon

1 w +m u
estatura avanzar() driblarBalon() pasarBalon() tirarBalon() rebotaro infraccionarODonente0 la mayor parte del drible y pase Delantero Centro lnfraccion
I

realiza la mayor parte de 10s tiros de media distancia

perrnanece cerca del cesto, tirade una distancia cercana

DeTresPuntos

(profesional = 24 segs. colegial = 35 segs. internacional = 30 segs.)

U
TiroLibre

E l I
CronometroDeJuego Duracion

(profesional= 4 cuartos de 12 mins. colegial e internacional = 2 mitades de 20 mins.) (profesional = 48 mins. colegial e internacional = 40 mins.)

I I

Linea DeTiroLibre

Cancha

I I

Us0 de la orientacion a obietos

43 I

Resumen
Un rectingulo es, en el UML, la representacidn simbdlica de una clase. El nombre, atributos, operaciones y responsabilidades de la clase se colocan en Areas delimitadas dentro del rectingulo. Puede utilizar un estereotipo para organizar las listas de atributos y operaciones y ademis abreviar una clase a1 mostrar s610 un subconjunto de sus atributos y operaciones. Esto hace un diagrama de clases menos complejo. Podri mostrar el tip0 de un atributo, su valor inicial y enseiiar 10s valores con que funciona una operacidn, asi como sus tipos. En una operacidn, esta informacidn se conoce como firma. Para reducir la ambiguedad en la descripcidn de una clase agregue restricciones. El UML tambih le permite indicar mayor informacidn respecto a una clase mediante notas adjuntas a1 rectingulo que la representa. Las clases representan el vocabulario de un Area del conocimiento. Las conversaciones con el cliente o un experto en el Area dejarin entrever 10s sustantivos que se convertirin en clases en un modelo, y 10s verbos se transformarin en operaciones. Podri utilizar un diagrama de clases como una forma de estimular a1 cliente a que diga mis respecto a su Area y que ponga en evidencia cierta informacidn adicional.

Preguntas y respuestas
P Usted mencion6 el us0 del sentido comun para generar el diagrama de clases del baloncesto. Ello suena bien en tal instancia pero, ;quC ocurre cuando tengo que analizar un hrea desconocida para mi (donde el sentido comun no sera de mucha ayuda)? R Por lo general, contar6 con cierto apoyo en un Area desconocida para usted. Antes de que se reiina con un cliente o con un experto en el campo, intente convertirse en un subexperto. PrepArese para la reunidn y lea cuanta documentacidn relacionada tenga a la mano. Pregunte a sus entrevistados respecto a documentos o manuales que hayan escrito. Cuando haya terminado de leer, tendri cierto conocimiento bisico y podri realizar las preguntas indicadas. P ;En qu6 momento tendria que mostrar la firma de una operacibn? R Tal vez, luego de la fase de anilisis de un proceso de desarrollo, conforme se adentre en el diseiio. La firma es una seccidn de informacidn que 10s desarrolladores podrian encontrar muy iitil.

I44

Hora 3

Taller
Para repasar lo que ha aprendido respecto a la orientacidn a objetos, intente responder a las siguientes preguntas. Las respuestas las encontrarh en el ApCndice A, Respuestas a 10s cuestionarios.

Cuestionario
1. 2. 3. 4.

iC6mo representa una clase en el UML? iQut informacidn puede mostrar en un simbolo de clase? iQuC es una restriccibn? iPara quC adjuntaria una nota a un simbolo de clase?

Ejercicios
1. He aqui una breve (e incompleta) descripcidn del balompiC: Un equipo de balompiC (0ftitbol soccer) consiste en 11 jugadores de campo (1 portero y el resto, jugadores de cancha que, en ocasiones, se organizan en cuatro defensas, tres centrales y tres delanteros). Los jugadores pueden usar cualquier parte de su cuerpo (except0 las manos) para introducir el bal6n a la porteria del equipo contrario. La dnica excepci6n a esta regla la tiene el portero, quien puede utilizar tambitn las manos para jugar el balbn, per0 s610 dentro del 6rea de meta. El campo de juego es un rectingulo de una longitud maxima de 120 m y minima de 90 m; y con una anchura no mayor de 90 m, ni menor de 45. Para partidos internacionales, la longitud serh de 110 m como mhximo y 100 como minimo; y una anchura no superior a 75 m ni inferior a 64. En cualquier caso, deberh ser mayor la longitud que la anchura. El campo de juego se dividirh en dos mitades transversales de igual tamaiio. El centro del campo sera marcado con un punto visible, alrededor del cual se trazara una circunferencia de 9.15 m de radio. La meta del juego es pasar el bal6n a 10s delanteros, quienes esthn mejor preparados para patear el bal6n a la porteria. El portero (0arquero) es la tiltima linea de defensa que intentarh bloquear, con cualquier parte de su cuerpo, 10s tiros de sus opositores. Cada vez que evita un gol, es decir, que el bal6n entre a la porteria, habrh salvado su meta. Cada go1 equivale a un punto. Un juego dura 90 minutos, divididos en dos periodos de 45 minutos cada uno. Vhlgase de la anterior informaci6n para crear un diagrama como el de la figura 3.15. Si usted conoce mas del balompit de lo que he descrito, agregue tal informaci6n a su diagrama. 2. Si usted conoce mhs del baloncesto de lo que hay en la figura 3.15, agregue la informacidn a tal diagrama.

H ORA

Us0 de relaciones
En la hora anterior creamos un conjunto de clases que representaban el vocabulario del baloncesto. Aunque ello le da las bases para una mayor exploraci6n de lo que es el baloncesto, tal vez haya sentido que algo le falta. Ese algo es un sentido en el que las clases se relacionan entre si. Si observa el modelo (vea la figura 3.15), veri que no se indica la manera en que un jugador se relaciona con un bal6n, ni c6mo 10s jugadores conforman un equipo, ni la forma en que procede el juego. Es como si hubiera constmido una lista de elementos, en lugar de una representacibn de un Lea del conocimiento. Es importante saber c6mo se conectan las clases entre si. Ahora trazaremos las conexiones entre las clases y completaremos la representacibn. En esta hora se tratarin 10s siguientes temas: Asociaciones Multiplicidad Asociaciones calificadas

I46

Hora 4

Asociaciones reflexivas Herencia y generalizacidn Dependencias

Asociaciones
Cuando las clases se conectan entre si de forma conceptual, esta conexi6n se conoce como asociacidn. El modelo inicial de baloncesto le darh algunos ejemplos. Examinemos uno de ellos: la asociacidn entre un jugador y un equipo. Podrh caracterizar tal asociacidn con la frase: un jugador participa en un equipo. Visualizarh la asociacidn como una linea que conectarh a ambas clases, con el nombre de la asociaci6n (participa en) justo sobre la linea. Es fitil indicar la direccidn de la relacidn, y lo harh con un trihngulo relleno que apunte en la direcci6n apropiada. La figura 4.1 le muestra c6mo visualizar la asociacion Participa en entre el jugador y el equipo.

FIGURA4.1
Una usociacidn entre
un jugador y un

equipo.

Cuando una clase se asocia con otra, cada una de ellas juega un papel dentro de tal asociacidn. Puede representar estos papeles en el diagrama escribikndolos cerca de la linea que se encuentra junto a la clase que juega el papel correspondiente. En la asociacidn entre un jugador y un equipo, si el equipo es profesional, Cste es un empleador y el jugador es un empleado. La figura 4.2 le muestra c6mo representar dichos papeles.

FIGURA 4.2
Por lo general, en una asociacion cada clase juega un papel. Puede representar tales papeles en el diagrarna.

lJugadorl

Participa en, Empleador

Empleado

La asociacidn puede funcionar en direccidn inversa: un equipo emplea a jugadores. Podrh mostrar ambas asociaciones en el mismo diagrama con un trihngulo relleno que indique la direccidn de cada asociacidn, como en la figura 4.3.

Us0 de relaciones

47 I

FIGURA 4.3
Pueden aparecer dos asociaciones entre clases en el mismo diagrama.

Jugador
U
r

Participa en b

Equipo

4 Emplea

Las asociaciones podrian ser mis complejas que tan s610 una clase conectada a otra. Varias clases se pueden conectar a una. Si toma en cuenta 10s defensas, delanteros y central, asi como sus asociaciones con la clase Equipo, tendri el diagrama de la figura 4.4.

Delantero Participa en b

Equipo

FIGURA4.5
Puede establecer una restriccidn en una asociacidn. En este caso, la asociacidn Atiende esta restringida para que el Cajero atienda a1 Cliente en turno.

Otro tip0 de restricci6n es la relaci6n 0 (distinguida como {Or}) en una linea discontinua que conecte a dos lineas de asociaci6n. La figura 4.6 modela a un estudiante de educaci6n media superior que elegiri entre un curso acadkmico o uno comercial.

I48

Hora 4

FIGURA4.6 La relacidn 0 entre

dos asociaciones en una restriccidn.

Elige Estudiante de educacion media superior

I

Academic0

I&
I

Elige

Cornercial

Clases de asociacion
Una asociacidn, a1 igual que una clase, puede contener atributos y operaciones. De hecho, cuando Cste sea el caso, usted tendrh una cluse de usociacion. Puede concebir a una clase de asociacidn de la misma forma en que lo hma con una clase esthndar, y utilizarh una linea discontinua para conectarla a la linea de asociacidn. Una clase de asociacidn puede tener asociaciones con otras clases. La figura 4.7 le muestra una clase de asociacidn para la asociacidn Participa en entre un jugador y un equipo. La clase de asociacidn, Contrato, se asocia con la clase DirectorGeneral.
FIGURA4.7
Una clase de asociacidn modela 10s atributos y operaciones de una asociacidn. Se conecta a una asociacidn mediante una linea discontinua, y puede asociarse a otra clase.

I
DirectorGeneral

Vincu10s
Asi como un objeto es una instancia de una clase, una asociacidn tambiin cuenta con instancias. Si podemos imaginar a un jugador especifico que juega para un equipo especifico, la relacidn Participa en se conocerh como vinculo, y usted lo representarh como una linea que conecta a dos objetos. Tal como tuvo que subrayar el nombre de un objeto, deberh subrayar el nombre de un vinculo, como en la figura 4.8.

FIGURA4.8
instancia de una asociacidn. Conecta a 10s objetos en lugar de las clases. Debera subrayar el

un,,inculo

Participa en b gustavo naiera :Jugador nacional : Equipo

es la

Us0 de relaciones

49 I

Multiplicidad
La asociacidn trazada entre Jugador y Equipo sugiere que las dos clases tienen una relacidn de uno a uno. No obstante, el sentido comljn nos indica que Cste no es el caso. Un equipo de baloncesto cuenta con cinco jugadores (sin contar a 10s sustitutos). La asociacidn Tiene (Has) debe participar en este recuento. En la otra direccidn, un jugador puede participar s610 en un equipo, y la asociacidn Participa en debe responder de esto. Tales especificaciones son ejemplos de la rnultiplicidud la cantidad de objetos de una clase que se relacionan con un objeto de la clase asociada. Para representar 10s niimeros en el diagrama, 10s colocar6 sobre la linea de asociacidn junto a la clase correspondiente, como se denota en la figura 4.9.
FIGURA4.9
La multiplicidad seriala la cantidad de objetos de una clase que pueden relacionarse con un objeto de una clase asociada.

i
Jugador 5 Participa e n ,

La multiplicidad de este ejemplo no es la iinica que existe. Hay varios tipos de multiplicidades (una multiplicidad de multiplicidades, por decirlo asi). Una clase puede relacionarse con otra en un esquema de uno a uno, uno a muchos, uno a uno o mis, uno a ninguno o uno, uno a un interval0 definido (por ejemplo: uno a cinco hasta diez), uno a exactamente n (como en este ejemplo), o uno a un conjunto de opciones (por ejemplo, uno a nueve o diez). El UML utiliza un asterisco (*) para representar mas y para representar muchos. En un contexto 0 se representa por dos puntos, como en l..* (uno o mis). En otro contexto, 0 se representa por una coma, como en 5, 10 (5 o lo). La figura 4.10 le muestra cdmo concebir las posibles multiplicidades.

Cuando la clase A tiene una multiplicidad de uno a ninguno o uno con la clase B, la clase B se dice que es opcional para la clase A.

150

Hora 4

FIGURA4.10
Posibles multiplicidudes y cdmo repre-

Esta casado con b

Esposa uno a uno

Casa

Tiene b

0,~ Chimenea

uno a ninguno o uno

tiempo completo

Triciclo 1

Tiene b

3 Ruedas
uno a tres

1 1

HueVera I

Contiene b

12,24

1 1
Huevos

uno a 12 o 24

Asociaciones calificadas
Cuando la multiplicidad de una asociacidn es de uno a muchos, con frecuencia se presenta un reto muy particular: la bdsqueda. Cuando un objeto de una clase tiene que seleccionar un objeto particular de otro tipo para cumplir con un papel en la asociacidn, la primera clase deberi atenerse a un atributo en particular para localizar a1 objeto adecuado. Normalmente, dicho atributo es un identificador que puede ser un ndmero de identidad. Por ejemplo, cuando usted realiza una reservacidn en un hotel, el hotel le asigna un ndmero de confirmacidn. Si usted quiere hacer preguntas respecto a la reservacidn, deberi proporcionar el ndmero de confirmacidn. En el UML la informacidn de identidad se conoce como cal$cador. Su simbolo es un pequeiio rectingulo adjunto a la clase que hari la bdsqueda. La figura 4.1 1 muestra la representacidn. La idea es reducir, con eficiencia, la multiplicidad de uno a muchos a una multiplicidad de uno a uno.

Us0 de relaciones

51 I

FIGURA4.11
Un calcficador en una asociacidn resuelve el problema de la

Recepcionista Nurnero de confirrnacion

Localizab

Reservacion

Asociaciones ref lexivas

En ocasiones, una clase es una asociacidn consigo misma. Esto puede ocurrir cuando una clase tiene objetos que pueden jugar diversos papeles. Un OcupanteDeAutomovil puede ser un Conductor o un Pasajero. En el papel del conductor, el OcupanteDeAutomovil puede llevar ninguno o mas OcupanteDeAutomovil, quienes jugaran el papel de pasajeros. Esto lo representarh mediante el trazado de una linea de asociacidn a partir del rectangulo de la clase hacia el mismo rectangulo de la clase, y en la linea de asociacidn indicari 10s papeles, nombre de la asociacidn, direccidn de la asociacidn y multiplicidad como ya lo hizo antes. La figura 4.12 le presenta este ejemplo.

FIGURA4.12
En una asociacidn refexiva, trazard la linea de la clase hacia si misma y podra incluir 10s papeles, nombre de la asociacidn y su direccidn, asi como su multiplicidad.

Conduce

Herencia y generalizacion
Uno de 10s sellos distintivos de la orientacidn a objetos es que captura uno de 10s mayores aspectos del sentido comlin en cuanto a la vida diaria: si usted conoce algo de una categoria de cosas, automaticamente sabra algunas cosas que podra transferir a otras categorias. Si usted sabe que algo es un electrodomkstico, ya sabra que contar5 con un intenuptor, una marca y un nlimero de serie. Si sabe que algo es un animal darB por hecho que come, duerme, tiene una forma de nacer, de trasladarse de un lugar a otro y algunos otros atributos (y operaciones) que podria listar si pensara en ello por algunos instantes. La orientacidn a objetos se refiere a esto como herencia. El UML tambikn lo denomina generulizacidn. Una clase (la clase secundaria o subclase) puede heredar 10s atributos y operaciones de otra (la clase principal o superclase). La clase principal (o madre) es mas genkrica que la secundaria (0hija).

I52

Hora 4

En la generalizacion, una clase secundaria (hija) es sustituible por una clase principal (madre). Es decir, donde quiera que se haga referencia a la clase madre, tarnbien se hace referencia a la clase hija. Sin embargo, en el caso contrario no es aplicable.

La jerarquia de la herencia no tiene que finalizar en dos niveles: una clase secundaria puede ser principal para otra clase secundaria. Un Mamifero es una clase secundaria de Animal, y Caballo es una clase secundaria de Mamifero. En el UML representari la herencia con una linea que conecte a la clase principal con la secundaria. En la parte de la linea que se conecta con la clase principal, colocari un triingulo sin rellenar que apunte a la clase principal. Este tip0 de conexitin se interpreta con la frase es un t i p de. Un Mamifero es un t i p de Animal, y un Caballo es un t i p de Mamifero. La figura 4.13 le muestra esta particular jerarquia de la herencia, junto con otras clases. Observe la apariencia del trihngulo y las lineas cuando varias clases secundarias son herencia de una clase principal. A1 disponer el diagrama de este modo, trae por resultado un diagrama m6s ordenado en lugar de mostrar todas las lineas y triingulos, aunque el UML no le prohibe colocarlos todos en la imagen. TambiCn vea que no coloc6 10s atributos y operaciones heredadas en 10s rectingulos de las subclases, dado que ya 10s habia representado en la superclase.
FIGURA4.13
Una jerarquia de herencia en el reino animal.

T
Animal

A
Caballo

Cuando modele la herencia, tenga la seguridad de que la clase secundaria satisfaga la relacion es un tip0 de con la clase principal. Si no se curnple tal relacion, tal vez una asociacion de otro tip0 podria ser mas adecuada.

Us0 de relaciones
~ ~ ~ ~ ~

53 I

Con frecuencia las clases secundarias agregan otras operaciones y atributos a 10s que han heredado. Por ejemplo: un Mamifero tiene pel0 y da leche, dos atributos que no se encuentran en la clase Animal. Una clase puede no provenir de una clase principal, en cuyo caso seri una clase base o clase ruiz. Una clase podrfa no tener clases secundarias, en cuyo caso seri una clase final o clase hoja. Si una clase tiene exactamente una clase principal, tendrh una herencia simple. Si proviene de varias clases principales, tendri una herencia mriltiple.

Descubrimiento de la herencia
En el proceso de plitica con un cliente, un analista descubriri la herencia de varias formas. Es posible que las clases candidatas que aparezcan incluyan tanto clases principales como clases secundarias. El analista deberi darse cuenta que 10s atributos y operaciones de una clase son generales y que se aplicarin a, quizh, varias clases (mismas que agregarin sus propios atributos y operaciones). El ejemplo del baloncesto de la hora 3, Us0 de la orientaci6n a objetos, tiene las clases Jugador, Defensa, Delantero y Central. El Jugador tiene atributos como nombre, estatura, peso, velocidadAlCorrer y saltovertical. Tiene operaciones como dnblar(), pasar(), reborn() y tirar(). Las clases Defensa, Delantero y Centro hered=& tales atributos y operaciones, y agregarin 10s suyos. La clase Defensa podria tener las operaciones correrAlFrente0 y quitarBalon(). El Central podria tener retacarBalon0. De acuerdo con 10s comentarios del entrenador respecto a las estaturas de 10s jugadores, el analista tal vez quisiera colocar restricciones en las estaturas para cada posicibn. Otra posibilidad es que el analista note que dos o mis clases tienen ciertos atributos y operaciones en comdn. El modelo del baloncesto tiene un CronometroDeJuego (que controla el tiempo que resta en un period0 de juego) y un LapsoDeTiro (que controla el tiempo restante desde el instante que un equipo tom6 posesidn del baldn, hasta que intente encestar). Si nos damos cuenta de que ambos controlan el tiempo, el analista podria formular una clase Reloj con una operaci6n controlarTiempo() que podrfan heredar tanto CronometroDeJuego como LapsoDeTiro.

Dado que LapsoDeTiro controla 24 segundos (profesional) o 35 segundos (colegial) y el CronornetroDeJuego controla 12 rninutos (profesional) o 20 rninutos (colegial), controlarTiernpo() sera polirnorfico.

Clases abstractas
En el modelo del baloncesto, el par de clases que mencionC -Jugador y Reloj- son dtiles puesto que funcionan como clases principales para clases secundarias importantes. Las clases secundarias son importantes en el modelo dado que finalmente usted querri

I54

Hora 4

tener instancias de tales clases. Para desarrollar el modelo, necesitara instancias de Defensa, Delantero, Centro, CronometroDeJuego y LapsoDeTiro.
No obstante, Jugador y Reloj no proporcionan ninguna instancia a1 modelo. Un objeto de la clase Jugador no serviria a ningun propbsito, asi como tampoco uno de la clase Reloj.

Las clases como Jugador y Reloj --que no proveen objetos- se dice que son abstractas. Una clase abstracta se distingue por tener su nombre en cursivas. La figura 4.14 muestra las dos clases abstractas y sus clases secundarias. FIGURA4.14
Dos jerarquias de herencia con clases abstractas en el modelo de baloncesto.

Jugador nombre tamaiio velocidadAlCorrer saltovertical

correrAlFrente0 quitarBalon()

CronometroDelJuego

LapsoDeTiro

Dependencias

En otro tipo de relacibn, una clase utiliza a otra. A esto se llama LLpendencia. El us0 mas comun de una dependencia es mostrar que la firma de la operacibn de una clase utiliza a otra clase. Suponga que diseiiara un sistema que muestra formularios corporativos en pantalla para que 10s empleados 10s Ilenen. El empleado utiliza un menu para seleccionar el formulario por llenar. En su diseiio, tiene una clase Sistema y una clase Formulario. Entre sus

__

Us0 de relaciones

55 1

muchas operaciones, la clase Sistema tiene mostrarFormulario(fForm). El formulario que el sistema desplegari, dependeri, obviamente, del que elija el usuario. La notacidn del UML para ello es una linea discontinua con una punta de flecha en forma de triingulo sin relleno que apunta a la clase de la que depende, como muestra la figura 4.15. FIGURA4.15
Unaflecha representada por una linea discontinua con una punta de flecha en forma de triangulo sin relleno simboliza una dependencia.

Resumen
Sin las relaciones, un modelo de clases seria poco menos que una lista de cosas que representman un vocabulario. Las relaciones le muestran c6mo se conectan 10s t6rminos del vocabulario entre si para dar una idea de la secci6n del mundo que se modela. La asociacidn es la conexidn conceptual fundamental entre clases. Cada clase en una asociaci6n juega un papel, y la multiplicidad especifica cuhtos objetos de una clase se relacionan con un objeto de la clase asociada. Hay muchos tipos de multiplicidad. Una asociaci6n se representa como una linea entre 10s rectiingulos de clases con 10s papeles y multiplicidades en cada extremo. A1 igual que una clase, una asociacidn puede contener atributos y operaciones. Una clase puede heredar atributos y operaciones de otra clase. La clase heredada es secundaria de la clase principal que es de la que se hereda. Descubriri la herencia cuando encuentre clases en su modelo inicial que tengan atributos y operaciones en comdn. Las clases abstractas s610 se proyectan como bases de herencia y no proporcionan objetos por si mismas. La herencia se representa como una linea entre la clase principal y la secundaria, con un triingulo sin rellenar que se adjunta (y apunta a) la clase principal. En una dependencia, una clase utiliza a otra. El us0 mis comdn de una dependencia es mostrar que una firma en la operaci6n de una clase utiliza a otra clase. Una dependencia se proyecta como una linea discontinua que redne a las dos clases en la dependencia, con una punta de flecha en forma de triingulo sin relleno que adjunta (y apunta a) la clase de la que se depende.

Preguntas y respuestas
P iEn alguna ocasi6n se le puede poner nombre a una relaci6n de herencia, como se hace en una asociaci6n? R El UML no le impide que adjudique un nombre a una relacidn de herencia, per0 por lo general esto no es necesario.

I56

Hora 4

Taller
El cuestionario y 10s ejercicios se han diseiiado para reafirmar su conocimiento del UML en el Lea de las relaciones. Cada pregunta y ejercicio requiere que usted piense en la simbologia del modelado que ha aprendido y la aplique a una situacibn. Las respuestas se encuentran en el ApCndice A, Respuestas a 10s cuestionarios.

Cuestionarios
1. iC6mo representaria la multiplicidad?

2. LCbmo descubriri la herencia? 3. iQu6 es una clase abstracta? 4. iCuil es el efecto de un calificador?

Ejercicios
1. Tome como base el modelo del baloncesto de la Hora 3, y agregue vinculos que expresen las relaciones que ha visto en esta hora. Si conoce el juego del baloncesto, siCntase con libertad de agregar 10s vinculos que representen su conocimiento. 2. De acuerdo con un viejo adagio: Un abogado que se defiende a si mismo, tiene por cliente a un tonto. Cree un modelo que refleje esta pieza de sabiduria.

H ORA

Agregacion, cornposicion, interfaces y realizacion

Continuaremos con las relaciones entre clases y comprenderA nuevos conceptos respecto a las clases y sus diagramas. En esta hora se tratarh 10s siguientes temas: Agregaciones Composiciones Contextos Interfaces y realizaciones Visibilidad

Hora 5

Ya ha visto lo concerniente a asociacibn, multiplicidad y herencia y esti casi listo para crear diagramas de clases significativos. Conforme explore otros tipos de relaciones y detalles relacionados con las clases comprenderi las piezas finales del rompecabezas. La meta final es crear una idea estitica de un sistema, con todas las conexiones entre las clases que lo conforman.

Ag regaciones
.
En ocasiones una clase consta de otras clases. Este es un tip0 especial de relaci6n conocida como agregacidn o acumulacidn. Los componentes y la clase que constituyen son una asociaci6n que conforma un todo. En la hora 2, "Orientaci6n a objetos", mencionC que su computadora es un conjunto de elementos que consta de gabinete, teclado, rat6n, monitor, unidad de CD-ROM, una o varias unidades de disco duro, m6dem, unidad de disquete, impresora y, posiblemente, altavoces. AdemAs de las unidades de disco, el gabinete contiene la memoria RAM, una tarjeta de video y una tarjeta de sonido (tal vez algunos otros elementos).

Puede representar una agregaci6n como una jerarquia dentro de la clase completa (por ejemplo el sistema computacional) en la parte superior, y 10s componentes por debajo de ella. Una linea conectara el todo con un componente mediante un rombo sin relleno que se colocari en la linea mis cercana a1 todo. La figura 5.1 le muestra el sistema de c6mputo como una agregaci6n.
FIGURA5.1
Una asociacio'n por agregacidn se representa por una linea entre el componente y el todo con un rombo sin relleno que conforma a1 todo.

'?

Aunque este ejemplo le muestra cada componente correspondiente a un todo, en una agregaci6n Cste no seri necesariamente el caso. Por ejemplo: en un sistema casero de entretenimiento, un control remoto podria ser un componente de una televisibn, aunque tambiCn podria ser un componente de una reproductora de casetes de video.

Agregacion, composicion, interfaces y realizacion

59

Restricciones en las agregaciones

En ocasiones el conjunto de componentes posibles en una agregacidn se establece dentro de una relacidn 0. En ciertos restaurantes, una comida consta de sopa o ensalada, el plato fuerte y el postre. Para modelar esto, utilizma una restriccidn: la palabra 0 dentro de llaves con una linea discontinua que conecte las dos lineas que conforman a1 todo, como lo muestra la figura 5.2.

FIGURA 5.2
Puede establecer una restriccidn a una agregacidn para mostrar que un componente u otro es parte del todo.

LJ
Comida

Cornposiciones
Una composicidn es un tip0 muy representativo de una agregacidn. Cada componente dentro de una composici6n puede pertenecer tan s610 a un todo. Los componentes de una mesa de caf6 (la superficie de la mesa y las patas) establecen una composicidn. El simbolo de una cornposicion es el mismo que el de una agregacidn, except0 que el rombo esth relleno (vea la figura 5.3).
FIGURA 5.3
En una composicidn, cada componente pertenece solamente a un todo. Un rombo relleno representa esta relacion.

I
MesaDeCafe

I),
Pata

SuperficieDeLaMesa

Contextos
Cuando modele un sistema podrian producirse, con frecuencia, agrupamientos de clases, como agregaciones o composiciones. En tal caso, deberi enfocar su atencidn en un agrupamiento o en otro, y el diagrama de contexto le proporciona la caracteristica de modelaje que requiere para tal fin. Las composiciones figuran en gran medida dentro de 10s diagramas de contexto. Un diagrama de contexto es como un mapa detallado de alguna seccidn de un mapa de mayores dimensiones. Pueden ser necesarias varias secciones para capturar toda la informacidn detallada.

160

Hora 5

He aqui un ejemplo: suponga que esth creando un modelo de una camisa y la forma en que se podria combinar con algun atuendo y un guardarropa. Un tip0 de diagrama de contexto (vea la figura 5.4) le mostrarh la camisa como un gran rectingulo de clase, con un diagrama anidado en el interior, el cual le muestra cdmo 10s componentes de la camisa esthn relacionados entre si. Este es un diagrama de contexto de composici6n (dado que la sola camisa retine a cada componente se le denomina de composicidn).
FIGURA5.4
Un diagrama de contento de composicidn le muestra 10s componentes de una clase como un diagrama anidado dentro de un enorme recta'ngulo de clase.

Camisa

esta cosida en

I
Boton

5,6
Botonadura

7Ojal

El diagrama de contexto de composicidn enfoca la atencidn en la camisa y sus componentes. Para mostrar la camisa en el contexto del guardarropa y de alglin atuendo, tendri que ampliar su imbito. Un diagrama de contexto del sistema lo hari por usted. Podri mostrar la forma en que la clase Camisa se conecta con las clases Guardarropa y Atuendo. como se ve en la figura 5.5.
FIGURA5.5
Un diagrama de
contexto del sistema le muestra 10s componentes de una clase y la forma en que la clase se relaciona con las otras que hay en el sistema.

L$

Guardarropa

fI
Atuendo

Agregacion, cornposicion, interfaces y realizacion

61

Podrh ver de cerca alguna otra clase y presentar sus detalles en algdn otro diagrama de contexto.

Interfaces y realizaciones
Una vez que haya creado varias clases, tal vez se dC cuenta que no pertenecen a una clase principal, pero en su comportamiento debe incluir algunas de las mismas operaciones con las mismas firmas de la primera clase. Podria codificar las operaciones en una de las clases y reutilizarlas en otras. Una segunda posibilidad es que desarrolle una serie de operaciones para las clases en un sistema, y reutilizarlas para las clases de otro sistema. De cualquier manera, desearh contar con algtin medio para capturar el conjunto reutilizable de operaciones. La interfaz es la estructura del UML que le permite hacerlo. Una intefaz es un conjunto de operaciones que especifica cierto aspect0 de la funcionalidad de una clase, y es un conjunto de operaciones que una clase presenta a otras. Con un ejemplo podriamos aclarar lo anterior. El teclado que usted utiliza para comunicarse con su equipo es una interfaz reutilizable. Su operacidn basada en la opresidn de teclas ha provenido de la mhquina de escribir. La disposicidn de las teclas es casi la misma que en una mhquina de escribir, pero el punto principal es que la operacidn por opresidn de teclas ha sido cedida de un sistema a otro. Otras operaciones (Mayds, Bloq Mayds y Tab) tambiCn se integraron a partir de la mhquina de escribir.

Por supuesto, el teclado de una computadora incluye diversas operaciones que no encontrarh en una mhquina de escribir: Control, Alt, RePhg, AvPhg y otras. Asi pues, la interfaz puede establecer un subconjunto de las operaciones de una clase y no necesariamente todas ellas.
Puede modelar una interfaz del mismo mod0 en que modelma una clase, con un simbolo rectangular. La diferencia sera que, como un conjunto de operaciones, una interfaz no tiene atributos. Recordarh que puede omitir 10s atributos de la representacidn de una clase. LEntonces, cdmo distinguiria entre una interfaz y una clase que no muestra sus atributos? Una forma es utilizar la estructura estereotipo y especificar la palabra ccinterfazw sobre el nombre de la interfaz en el recthgulo. Otra es colocar la letra I a1 principio del nombre de una interfaz. En cierto sentido, es como si el teclado de la computadora garantizara que esta parte de su funcionalidad hma las veces del teclado de una mhquina de escribir. Bajo este esquema, la relacidn entre una clase y una interfaz se conoce como realizacidn. Esta relacidn esth modelada como una linea discontinua con una punta de flecha en forma de trihngulo sin rellenar que adjunte y apunte a la interfaz. La figura 5.6 le muestra cdmo se lleva a cab0 esto.

162

Hora 5

FIGURA5.6
Una integaz es un conjunto de operaciones que realiza una clase. Esta Lltima se relaciona con una interfaz mediante la realizacidn, misma que se indica por una linea discontinua con una punta de f l e c k en forma de trihngulo sin rellenar que apunte a la integaz.
cantidadDeTeclas DeEscribir

TeclazoO ...

Otra forma (omitida) de representar una clase y su interfaz es con un pequeiio circulo que se conecte mediante una linea a la clase, como se ve en la figura 5.7.
FIGURA5.7 La forma omitida de
representar una clase que realice una interfaz.

Una clase puede realizar mis de una interfaz, y una interfaz puede ser realizada por mis de una clase.

Visibilidad
El concept0 de visibilidad esti muy relacionado con las interfaces y la realizacibn. La visibilidad se aplica a atributos u operaciones, y establece la proporcidn en que otras clases podrin utilizar 10s atributos y operaciones de una clase dada (0en operaciones de una interfaz). Existen tres niveles de visibilidad: Nivel pziblico, en el cual la funcionalidad se extiende a otras clases. En el nivel protegido la funcionalidad se otorga s610 a las clases que se heredan de la clase original. En el nivel privudo s610 la clase original puede utilizar el atributo u operaci6n. En una televisibn, modificarVolumen() y cambiarCanal() son operaciones pdblicas, en tanto que dibujarImagenEnPantalla() es privada. En un autom6vi1, aceleraro y frenar() son operaciones pdblicas, per0 actualizarKilometraje() o actualizarMillaje() es protegida. La realizaci6n, como podria imaginar, implica que el nivel pdblico se aplique a cualquier operacidn en una interfaz. La protecci6n de operaciones mediante cualquiera de 10s otros niveles tal vez no tendria sentido, dado que una interfaz se orienta a ser realizada por diversas clases. Para indicar el nivel publico, anteceda el atributo u operaci6n con un signo de suma (+), para revelar un nivel protegido, anteckdalo con un simbolo de ndmero (#), y para indicar el nivel privado, antecCdalo con un gui6n (-). La figura 5.8 muestra 10s atributos y operaciones publicos, protegidos y privados tanto en una televisi6n como en un autom6vil.

Agregacion, cornposicion, interfaces y realizacion

63 I

FIGURA5.8
Los atributos y opera. ciones publicos y privados, 1tanto de una tezevisidrz como de un automdvil.

ITelevision

I
I

IAutornovil
+ fabricante

+ rnarca ... I+ rnodificarVolurnen()

I
I

I + acelerar() 13)
+ frenar()
#actualizarKilornetraje()

- colorearlrnagenEnPantalla()

Ambito
El imbito es otro concept0 referente a 10s atributos y operaciones, y la forma en que se relacionan dentro de un sistema. Hay dos tipos de imbitos, el de instancia y el de archivador. En el primer0 cada instancia cuenta con su propio valor en un atributo u operaci6n. En un imbito de archivado, s610 habri un valor del atributo u operaci6n en todas las instancias de la clase. Un atributo u operacidn con el imbito de archivador, aparece con su nombre subrayado. Este tip0 de imbito se utiliza con frecuencia cuando un grupo especifico de instancias (ningunas otras) tienen que compartir 108 valores exactos de un atributo privado. El imbito de instancia es, por mucho, el tip0 mas comdn de Bmbito.

Resumen
Para completar sus nociones de clases y la forma en que se conectan, es necesario comprender algunas relaciones adicionales. Una agregaci6n establece una asociacidn para conformar un todo: una clase todo se genera de clases que la componen. Un componente en una agregaci6n puede ser parte de m6s de un todo. Una composici6n es una conformacidn muy intimamente ligada con la agregaci6n en el sentido de que un componente de una composici6n puede ser parte solamente de un todo. La representacibn del UML de las agregaciones es similar a la representacibn de las composiciones. La linea de asociacidn que une la parte con un todo tiene un rombo. En una agregacibn, el rombo no est6 relleno, en tanto que en una composici6n si lo esth. Un diagrama de contexto enfoca la atenci6n en una clase especifica dentro de un sistema. Un diagrama de contexto de composici6n es como un mapa detallado de un mapa mayor. Muestra un diagrama de clases anidado dentro de un gran simbolo rectangular de clase. Un diagrama de contexto de sistema muestra la forma en que el diagrama de clases compuestas se relaciona con otros objetos del sistema. Una realizacidn es una asociaci6n entre una clase y una interfaz, una coleccidn de operaciones que cierta cantidad de clases podri utilizar. Una interfaz se representa como una clase sin atributos. Para distinguirla de una clase cuyos atributos hayan sido omitidos del diagrama, el estereotipo ccinterfazn apareceri por encima del nombre de la interfaz. Otra posibilidad es la de anteceder el nombre de la interfaz con una I mayuscula. La realizacidn se representa en el UML mediante una linea discontinua con una punta de flecha en forma de triingulo sin rellenar que conecta a la clase con la interfaz. Otra forma para representar una realizaci6n es con una linea continua que conecte a una clase con un pequeiio circulo, para que el circulo se interprete como la interfaz.

1 64

Hora 5

En tCrminos de visibilidad, todas las operaciones en una interfaz son pliblicus, de mod0 que cualquier clase podri utilizarlas. Los otros dos niveles de visibilidad son protegido (la funcionalidad se extiende a las clases secundarias de aquella que contiene 10s atributos y operaciones) y privudo (atributos y operaciones que se pueden utilizar s610 dentro de la clase que 10s contiene). Un signo de suma (+) denota a la visibilidad pdblica, el simbolo de n ~ m e r o (#) la protegida y el gui6n (-) la privada. El Bmbito es otro aspect0 de 10s atributos y operaciones. En un Bmbito de instancia, cada objeto de una clase cuenta con su propio valor en un atributo u operaci6n. En un imbito de archivador, s610 hay un valor para un atributo u operaci6n en particular a travCs de un conjunto de objetos de una clase. Los objetos que no estCn en este conjunto no podran acceder a1 valor contenido en el Bmbito de archivador.

Preguntas y respuestas
P ;Se considera transitiva a la agregacidn? Es decir, si la clase 3 es un componente de la clase 2, y la clase 2 es un componente de la clase 1, ;la clase 3 serh un componente de la clase l? R Asi es, la agregacibn es transitiva. En nuestro ejemplo, 10s botones y la bola del rat6n son parte del ratbn, a la vez que son parte de la computadora. P ;La palabra interfaz implica Tnterfaz de usuario o GUI? R No. Es algo mis genCrico. Una interfaz es tan s610 un conjunto de operaciones que una clase presenta a las demis clases. De hecho, una de estas operaciones podria ser (aunque no necesariamente) la del usuario.

Taller
El cuestionario y 10s ejercicios verificarin y fortalecerin su conocimiento respecto a1 tema de las agregaciones, composiciones, contextos e interfaces. Las respuestas las podrfi ver en el ApCndice A, Respuestas a 10s cuestionarios.

Cuestionario
1. LCuBl es la diferencia entre una agregaci6n y una composici6n? 2. iQuC es la realizacGn? 3. Mencione 10s tres niveles de visibilidad y describa lo que significa cada uno de ellos.

Ejercicios
1. Cree un diagrama de contexto de composicidn de una revista. Tome en cuenta la tabla de contenido, la editorial, 10s articulos y las columnas. Luego, Cree un diagrama de contexto del sistema que muestre a la revista junto con el suscriptor y el comprador en el puesto de revistas.

Aqregacion, composicion, interfaces y realizacion

65 I

2. En la actualidad, el tip0 mis popular de GUI es la interfaz WIMP (ventanas, iconos, mends y puntero, por sus siglas en inglCs). Dibuje un diagrama de clases de la interfaz WIMP, y haga us0 de todo el conocimiento adecuado del UML que ha adquirido hasta ahora. Ademis de las clases indicadas en las siglas, incluya 10s elementos relacionados como las barras de desplazamiento y el cursor, asi como cualquiera de las otras clases necesarias.

HORA
lntroduccion a 10s ca de us0
Ahora que ha visto lo correspondiente a las clases y sus relaciones, es el momento de volver nuestra atencidn a otra hrea principal del UML: 10s casos de uso. En esta hora se tratarh 10s siguiente

QuC son 10s casos de us0

Importancia de 10s casos de usb Inclusidn de 10s casos de us0 Extensi6n de 10s casos de us0 Inicio de un anfilisis de un caso de us0 En las tres horas anteriores hemos visto 10s diagramas que proporcionan una idea estfitica de las clases en un sistema. Ahora veremos a 10s diagramas que establecen una idea dinhmica y mostraremos la forma en que el sistema y sus clases cambian con el tiempo. Las ideas estfiticas ayudan a que un analista se cornunique con un cliente. La idea dinfimica, como verh, ayudarh a1 analista a comunicarse con un grupo de desarrolladores, y ayudarh a estos iiltimos a crear programas.

168

Hora 6

El cliente y el equipo de desarrollo conforman un importante conjunto de integrantes en un sistema. No obstante, una parte de igual importancia no se ha tomado en cuenta: el usuario. Ni la idea estatica ni la dinarnica mostrarin el comportamiento del sistema desde el punto de vista del usuario. Comprender tal punto de vista es clave para generar sistemas que Sean tanto dtiles como funcionales; esto es, que cumplan con 10s requerimientos y que sea fAcil (e, incluso, divertido) trabajar con ellos. El modelado de un sistema desde el punto de vista de un usuario es el trabajo de 10s casos de USO. En esta hora comprendera todo lo relacionado con 10s casos de us0 y su funci6n. En la siguiente hora aprendera a utilizar el diagrama de casos de us0 del UML para visualizar un caso de USO.

Que son 10s casos de us0

Recientemente adquiri una mhquina de fax. Cuando fui a comprarla, en un almacCn de venta de equipo para oficinas, encontrC una enorme gama de opciones. LC6mo hice para decidirme por una en particular? Me preguntk exactamente quC es lo que deseaba hacer con una mhquina de fax. iQuC caracteristicas deseaba? LCu6les funciones necesitaba que tuviera? LDeseaba utilizar papel comun o tCrmico? LQueria generar copias? LConectarlo a mi computadora? LUtilizarlo como digitalizador? iTendria que enviar faxes a tal velocidad que necesitma una funcidn de marcado rippido? LQuema utilizar la mhquina de fax para diferenciar entre una llamada telef6nica y un fax entrante? Todos seguimos un procedimiento como Cste cuando realizamos una compra que no sea impulsiva. Lo que hacemos es seguir un tip0 de analisis del caso de USO: nos preguntamos c6mo utilizaremos el product0 o sistema que queremos comprar, de mod0 que podamos obtener algo que cumpla con nuestras necesidades. Lo importante es saber cuales son esos requerimientos. Este tipo de analisis es particularmente crucial para la fase de analisis del desarrollo de un sistema. La forma en que 10s usuarios utilicen un sistema le da la pauta para lo que diseiiara y crear8. El caso de us0 es una estructura que ayuda a 10s analistas a trabajar con 10s usuarios para determinar la forma en que se usara un sistema. Con una coleccidn de casos de us0 se puede hacer el bosquejo de un sistema en tCrminos de lo que 10s usuarios intenten hacer con 61. Imaginese a1 caso de us0 como una colecci6n de situaciones respecto a1 us0 de un sistema. Cada escenario describe una secuencia de eventos. Cada secuencia se inicia por una persona, otro sistema, una parte del hardware o por el paso del tiempo. A las entidades que inician secuencias se les conoce como adores. El resultad0 de la secuencia debe ser algo utilizable ya sea por el actor que la inici6, o por otro actor.

lntroduccion a 10s casos de us0

69

Importancia de 10s casos de us0

Asi como el diagrama de clases es un buen medio para estimular a un cliente a que hable respecto a un sistema desde su propio punto de vista, el caso de us0 es una excelente herramienta para estimular a que 10s usuarios potenciales hablen, de un sistema, desde sus propios puntos de vista. No siempre es f6cil para 10s usuarios explicar c6mo pretenden utilizar un sistema. Puesto que el desarrollo tradicional de 10s sistemas era, con frecuencia, algo asi como una ciencia oculta, con muy poca informacidn para 10s usuarios, a aquellos que osaban preguntar se les daba informaci6n muy poco explicita o ciertamente confusa respecto a lo que utilizman.

La idea es involucrar a 10s usuarios en las etapas iniciales del anflisis y diseiio del sistema. Esto aumenta la probabilidad de que el sistema sea de mayor provecho para la gente a la que supuestamente ayudari, en lugar de ser un manojo de expresiones de computaci6n incomprensibles e inmanejables por 10s usuarios finales.

Un ejemplo: la maquina de gaseosas

Suponga que empezars a disefiar una miquina despachadora de gaseosas. Para obtener el punto de vista del interesado, entrevistari a varios usuarios potenciales respecto a la manera en que utilizarin dicha miquina. Dado que la funcidn principal de una miquina de gaseosas es permitir a un cliente adquirir una lata de gaseosa, probablemente las personas le dirin que se enfrentari a diversos un caso de USO, en otras palabras- que podria etiquetar como Comprar escenarios gaseosa. Examinemos cada posible escenario en este caso de uso. Recuerde que tales escenarios podrian aparecer durante la conversacidn con 10s usuarios.
FIGURA6.1
Un caso de us0 establece un conjunto de escenarios para realizar algo utilpara un actol: En este ejemplo, un caso de us0 es Comprar gaseosa .

Hora 6

El caso de us0 Comprar gaseosa

El actor, en este caso de uso, es un cliente que desea comprar una lata de gaseosa. El escenario iniciari cuando el cliente inserte dinero, posteriormente realizari una selecci6n; y si todo funciona bien, la miquina contari con, a1 menos, una lata de la gaseosa elegida, misma que pondri a1 alcance del cliente. Ademis de la secuencia, hay otros aspectos del escenario anterior que merecen cierta consideracibn. iQuC condiciones llevaron a1 cliente a iniciar el escenario en el caso de us0 Comprar gaseosa? La sed es la mis obvia. iQuC se obtiene como resultado de tal escenario? Nuevamente, lo obvio es que el cliente tenga una gaseosa en su poder.
iLo que he descrito es la h i c a posibilidad de Comprar gaseosa? Habria otras cuestiones que saltman a la vista; por ejemplo, es posible que la miquina no tenga la gaseosa que desee el cliente; tambiCn es posible que el cliente no tenga el importe exact0 de la gaseosa. iCdmo disefiaria a la miquina de gaseosas para controlar tales escenarios?

Veamos el caso en que la miquina se haya quedado sin gaseosa, otra secuencia de pasos en el caso de us0 Comprar gaseosa. Imaginelo como una ruta alternativa dentro del caso de uso. El cliente inicia el caso de us0 a1 insertar dinero en la miquina y posteriormente hace una selecci6n. La miquina no cuenta con ninguna lata de la gaseosa seleccionada, por lo que mostrari un mensaje a1 cliente que indicari que no tiene de esa marca. Lo ideal seria que el mensaje le pida a1 cliente que haga otra selecci6n. La maquina tambiCn deberia dar la opci6n de devolver el dinero a1 cliente. En este punto, el cliente selecciona otra marca que la maquina entregari (siempre y cuando cuente con provisiones de esta marca), o devolvera el dinero. La condici6n previa es un cliente sediento y el resultado es una lata de gaseosa o la devoluci6n del dinero.

Claro que el escenario de quedarse sin gaseosa seria posible: el mensaje No hay de esta marca podria aparecer en cuanto las provisiones de la maquina se acabaran y permanecer a la vista hasta que la maquina sea reabastecida. En tal caso, el usuario podria no insertar el dinero en primera instancia. El cliente para el que usted diseiiara la maquina podria preferir el primer escenario: si el cliente ya insert6 dinero, la tendencia podria ser hacer otra seleccion en lugar de pedir a la maquina que lo devuelva.

Analicemos ahora el escenario de la cantidad de dinero incorrecta. Nuevamente, el usuario inicia el caso de us0 en la forma usual y posteriormente hace una selecci6n. Asumamos que la miquina tiene provisidn de la marca elegida. En la miquina hay una reserva de moneda fraccionaria y devuelve la diferencia a1 despachar la gaseosa. Si la

lntroduccion a 10s casos de us0

71 I

mhquina no cuenta con una reserva de moneda fraccionaria, devolverh el dinero y mostrarh un mensaje que pida a1 usuario el importe exacto. La condicidn previa es la ya indicada. El resultado sera una lata de gaseosa junto con el cambio, o la devolucidn del dinero originalmente depositado. Otra posibilidad es que tan pronto como se agote la moneda fraccionaria, aparezca un mensaje que informe a 10s clientes que se requiere el importe exacto. El mensaje permaneceria a la vista hasta que la mtiquina sea reabastecida con moneda fraccionaria.

Casos de us0 adicionales

Ya ha examinado a la mhquina de gaseosas desde el punto de vista de un usuario: el cliente. Hay otros usuarios que intervienen, como el proveedor que tiene que reabastecer a la mhquina, el recolector de dinero (que tal vez sea el mismo que el proveedor) que tiene que recoger el dinero acumulado en la alcancia de la mhquina, etcttera. Esto nos indica que debemos crear a1 menos dos casos de uso: Reabastecer y Recolectar dinero, cuyos detalles surgirhn durante las entrevistas con 10s proveedores y 10s recolectores. Veamos el caso de us0 de Reabastecer. El proveedor inicia este caso de us0 dado que algdn intervalo (digamos, dos semanas) ha pasado. El representante del proveedor le quita el seguro a la mhquina (tal vez mediante una llave y un cerrojo, per0 eso entra dentro de la implementacidn),jala la puerta para abrir la mhquina, y llena el compartimiento de cada marca hasta su capacidad. El representante tambitn rellena la reserva de moneda fraccionaria. Luego, cierra el frente de la mhquina y vuelve a poner el seguro. La condicidn previa es el paso del intervalo, el resultado es que el proveedor cuenta con un nuevo conjunto de ventas potenciales. Para el caso de us0 de Recolectar el dinero, el recolector inicia debido tambitn a que ha pasado cierto tiempo. La persona deberh seguir la misma secuencia que en Reabastecer para abrir la mhquina. El recolector sacarh el dinero de la mhquina y seguirh 10s pasos de Reabastecer para cerrar y poner el seguro a la mhquina. La condicidn previa es el paso del intervalo y el resultado es el dinero en las manos del recolector. Vea que cuando derivamos un caso de uso, no nos preocupamos por la forma de implementarlo. En nuestro ejemplo, no nos interesamos en 10s aspectos internos de la mhquina de gaseosas. Tampoco por la forma en que funcione el mecanismo de refrigeracidn, o por la forma en que la mhquina controle la cantidad de dinero que contenga. Tan s610 intentamos ver la forma en que la mhquina lucid para alguien que tenga que utilizarla. El objetivo es derivar una colecci6n de casos de us0 que, finalmente, mostraremos a las personas que diseiien la maquina de gaseosas y a las personas que la construirh. Por aiiadidura, nuestros casos de us0 reflejan lo que 10s clientes, recolectores y proveedores desean, por lo que el resultado sera una mhquina que todos esos grupos puedan utilizar con facilidad.

Hora 6

Inclusion de 10s casos de us0

En 10s casos de us0 Reabastecer y Recolectar dinero, tal vez distingui6 ciertos pasos en com6n. Ambos empezaban con abrir la miquina, y finalizaban con el cierre de la miquina y su aseguramiento. LPodriamos eliminar la duplicaci6n de pasos de un caso de us0 a1 otro?
Si podemos. La forma de hacerlo es tomar cada secuencia de pasos en comdn y conformar un caso de us0 adicional a partir de ellos. Combinemos 10s pasos necesarios para quitar el seguro y abrir la miquina y 1lamCmoslos Exhibir el interior y 10s pasos cerrar la miquina y asegurarla en otro caso de us0 llamado Cubrir el interior.

Con estos nuevos casos de us0 a la mano, el caso de us0 Reabastecer inicima con el caso de us0 Exhibir el interior. Luego, el representante del proveedor seguiria 10s pasos ya indicados, y concluiria con el caso de us0 Cubrir el interior. De forma similar, el caso de us0 Recolectar dinero iniciaria con Exhibir el interior, procederia como se indic6, y finalizma con el caso de us0 Cubrir el interior. Como ve, Reabastecer y Recolectar dinero incluyen 10s nuevos casos de uso. Por ello, a esta tkcnica de aprovechamiento de un caso de us0 se le conoce como inclusion de un caso de USO.

La inclusion de un caso de us0 tarnbien se conoce corno usar un caso de USO. Creo que el terrnino incluir tiene dos ventajas. La prirnera, es mas Clara: 10s pasos en un caso de uso, incluyen 10s de otro. La segunda, se evita la confusion potencial de las palabras usar y uso en un context0 tan estrecho. Asi, no tendrernos que decir prornover el us0 rnediante el us0 reiterativo de un caso de uso.

Extension de 10s casos de us0

Es posible volver a utilizar un caso de us0 de una forma distinta a una inclusi6n. En ocasiones crearemos un caso de us0 agregindole algunos pasos a un caso de us0 existente. Regresemos a1 caso de us0 Reabastecer. Antes de colocar nuevas latas de gaseosas en la miquina, suponga que el representante del proveedor nota las marcas que se han vendido bien, asi como las que no se han vendido tan bien. En lugar de s610 reabastecer todas las marcas, el representante podria sacar aquellas que no se han vendido bien, y reemplazarlas por latas de las marcas que han probado ser mis populares. De esta forma, tendria que indicar a1 frente de la miquina el nuevo surtido de marcas disponibles. Si agregamos estos pasos a Reabastecer, tendremos un nuevo caso de us0 que llamariamos Reabastecer de acuerdo a las ventas. Este nuevo caso de us0 es una extensih del original, accidn a la que se le conoce como extension de un caso de USO.

lntroduccion a 10s casos de us0

73 1

lnicio del analisis de un caso de us0

En nuestro caso, nos hemos involucrado directamente con 10s casos de us0 y nos hemos enfocado en algunos de ellos. En el mundo real, por lo general, seguirh un conjunto de procedimientos cuando empiece un anhlisis de casos de uso. Empezarh con entrevistas a 10s clientes (y entrevistas con expertos) que lo lleven a 10s diagramas iniciales de clases que indicamos en la hora 3. Esto le darh cierta idea del 6rea en la que trabajarh y una familiaridad con 10s tCrminos que utilizarh. Posteriormente, contarh con un fundamento para hablar con 10s usuarios. Entrevistara a 10s usuarios (preferentemente en grupos) y les pedirh que le indiquen todo lo que ellos hman con el sistema que usted disefiarfi. Sus respuestas conformarhn un conjunto candidato de casos de uso. Luego, es importante describir brevemente cada caso de uso. TambiCn tendrh que derivar una lista de todos 10s actores que iniciarhn y se beneficiarhn de 10s casos de uso. Cuenta mis informacidn obtenga en esta fase, aumentarh su aptitud para hablar con 10s usuarios en su propio idioma. Los casos de us0 aparecerhn en varias fases del proceso de desarrollo. Le ayudarhn con el diseiio de una interfaz del usuario, coadyuvarhn con las opciones de desarrollo de 10s programadores y establecerhn las bases para probar el sistema reciCn generado. Para mayor informaci6n en el tema del anhlisis de 10s casos de uso, va a tener que aplicar el UML, y ello se harh en la siguiente hora.

Resumen
El caso de us0 es una estructura para describir la forma en que un sistema lucirh para 10s usuarios potenciales. Es una colecci6n de escenarios iniciados por una entidad llamada actor (una persona, un componente de hardware, un lapso u otro sistema). Un caso de us0 deberfa dar por resultado algo de valor ya sea para el actor que lo inici6 o para otro. Es posible volver a utilizar casos de uso. Una forma (inclusidn) es utilizar 10s pasos de un caso de us0 como parte de la secuencia de pasos de otro caso de uso. Otra forma (extensi6n) es crear un nuevo caso de us0 mediante la adicidn de pasos a un caso de us0 existente. La entrevista directa con 10s usuarios es la mejor tdcnica para derivar casos de uso. Cuando se deriva un caso de uso, es importante destacar las condiciones para iniciar el caso de uso, y 10s resultados obtenidos como consecuencia del mismo.

Harh las entrevistas a 10s usuarios despuCs de entrevistar a 10s clientes y generar una lista de prospectos de clases. Esto le darh un fundamento en la terminologia que utilizarh para hablar con 10s usuarios. Es una buena idea entrevistar a un grupo de usuarios. El objetivo es derivar un conjunto candidato de casos de us0 y todos 10s posibles actores.

I74

Hora 6

Preguntas y respuestas
En realidad ipara quC necesito el concept0 del caso de uso? iQuC no s610 podriamos preguntar a 10s usuarios lo que deseen ver en el sistema y dejarlo asi? En realidad, no. Tenemos que crear una estructura de lo que 10s usuarios nos digan, y 10s casos de us0 la proporcionan. La estructura se vuelve 6til cuando tiene que llevar 10s resultados de sus entrevistas con 10s usuarios y comunicarlos a 10s clientes y desarrolladores. iQuC tan dificil es derivar 10s casos de uso? De acuerdo con mi experiencia, el listado de casos de us0 -a1 menos 10s de alto nivel- no es muy complejo. Hay ciertas dificultades a1 profundizar en cada una e intentar lograr que 10s usuarios listen 10s pasos de cada escenario. Cuando genere un sistema que reemplace una manera existente de hacer las cosas, 10s usuarios tipicamente ya sabrfin 10s pasos bastante bien y 10s habrh utilizado con tanta regularidad que se les dificultarfi estructurarlos. Es una buena idea tener un panel de usuarios, ya que la discusidn en grupo por lo general trae consigo ideas que un usuario en particular podria tener problemas para expresar.

Esta hora se b a d en teoria mfis que en el UML. En este taller, el objetivo sera comprender 10s conceptos tedricos y aplicarlos en diversos contextos. La prfictica, que veremos en la siguiente hora, le ayudarfi a reafirmar 10s conceptos cuando aprenda a visualizarlos mediante el UML. Las respuestas aparecen en el ApCndice A, Respuestas a 10s cuestionarios.

Cuestionario
1. iCdmo se llama a la entidad que inicia un caso de uso?

2. iQuC se entiende con incluir un caso de uso? 3. iQuC se entiende con extender un caso de uso? 4. LUn caso de us0 es lo mismo que un escenario?

Ejercicios
1. En el caso del ejemplo de la mfiquina de gaseosas, Cree otro caso de us0 que incluya a 10s casos de us0 Exhibir el interior y Cubrir el interior. 2. Los casos de us0 pueden ayudarle a analizar un negocio y un sistema. Imagine a una gran tienda de equipos de cdmputo que venda hardware, perifkricos y software. LQuitnes serian 10s actores? LCufiles serian algunos de 10s principales casos de uso? LCufiles serian algunos de 10s escenarios dentro de cada caso de uso?

HORA

Diagramas de casos de us0

El caso de us0 es un poderoso concept0 que ayuda a un analista a comprender la forma en que un sistema debera comportarse. Le ayuda a obtener 10s requerimientos desde el punto de vista del usuario. Es necesario aprender a visualizar 10s conceptos del caso de us0 que conocid en la hora anterior. En esta hora se trataran 10s siguientes temas: Representacidn de un modelo de caso de us0 Concepcidn de las relaciones entre casos de us0 Diagramas de casos de us0 en el proceso de analisis Aplicacidn de 10s modelos de caso de us0 Vera la idea general del UML El caso de us0 es muy poderoso, per0 lo es a6n m8s cuando se visualiza por medio del UML. Esta visualizacidn le permitiri mostrar 10s casos de us0 a 10s usuarios para que ellos le puedan dar mayor informacidn. Es un hecho que 10s usuarios con frecuencia saben mas de lo que dicen: el caso de us0 ayuda a romper el hielo. A su vez, una representacidn visual le ayuda a combinar 10s diagramas de casos de us0 con otro tip0 de diagramas. Una de las finalidades del proceso de analisis de un sistema es generar una coleccidn de casos de uso. La idea es tener la posibilidad de catalogar y

I76

Hora 7

hacer referencia a esta coleccibn, que sirve como el punto de vista de 10s usuarios acerca del sistema. Cuando llegue el momento de actualizar el sistema, el catilogo de casos de us0 funcionari como un fundamento para obtener 10s requerimientos de la actualizacibn.

Representacion de un modelo de caso de us0

Hay un actor que inicia un caso de us0 y otro (posiblemente el que inici6, pero no necesariamente) que recibiri algo de valor de 61. La representacibn grifica es directa. Una elipse representa a un caso de uso, una figura agregada representa a un actor. El actor que inicia se encuentra a la izquierda del caso de uso, y el que recibe a la derecha. El nombre del actor aparece justo debajo de 61, y el nombre del caso de us0 aparece ya sea dentro de la elipse o justo debajo de ella. Una linea asociativa conecta a un actor con el caso de uso, y representa la comunicacibn entre el actor y el caso de uso. La linea asociativa es sblida, como la que conecta a las clases asociadas. Uno de 10s beneficios del anilisis del caso de us0 es que le muestra 10s confines entre el sistema y el mundo exterior. Generalmente, 10s actores estin fuera del sistema, mientras que 10s casos de us0 estin dentro de 61. Utilizari un rectingulo (con el nombre del sistema en algtin lugar dentro de 61) para representar el confin del sistema. El rectingulo envuelve a 10s casos de us0 del sistema.
Los actores, casos de us0 y lineas de interconexibn componen un modelo de caso de uso. La figura 7.1 le muestra estos simbolos. FIGURA 7.1
En un modelo de caso de USO, unafigura agregada representa a un actor; una elipse a un caso de us0 y una linea asociativa representa la comunicacidn entre el actor y el caso de USO.

Actor

Actor

Una nueva visita a la maquina de gaseosas

Apliquemos 10s simbolos a1 ejemplo de la hora anterior. Como recuerda, desarrollb 10s casos de us0 para una miquina de gaseosas. El caso de us0 Comprar gaseosa se encuentra dentro del sistema junto con Reabastecer y Recolectar dinero. Los actores son el Cliente, Representante del proveedor y el Recolector. La figura 7.2 le muestra un modelo UML de caso de us0 para una miquina de gaseosas.

Diagramas de casos de us0

77 I

FIGURA7.2
Un modelo de caso de de la maquina de gaseosas de la hora 6.
us0 proveniente

Cliente

Cliente

Representante del proveedor

Recolector

x
.

O K
Reabastecer

del Representante proveedor

Recolector

Secuencia de pasos en 10s escenarios

Cada caso de us0 es una coleccidn de escenarios y cada escenario es una secuencia de pasos. Como puede ver, tales pasos no aparecen en el diagrama. No se encuentran en notas adjuntas a 10s casos de uso. Aunque el UML no lo prohibe, la claridad es clave en la generacidn de cualquier diagrama y el adjuntar notas a cada caso de us0 podria volverlo confuso. LCdmo y ddnde hma la secuencia de pasos? El us0 de 10s diagramas de casos de us0 seri, por lo general, parte de un documento de disefio que el cliente y el equipo de disefio tomarin como referencia. Cada diagrama tendri su propia pigina, de igual manera, cada escenario de caso de us0 tendri su propia pigina, donde se listari en mod0 de texto a: El actor que inicia a1 caso de us0 Condiciones previas para el caso de us0

Pasos en el escenario
Condiciones posteriores cuando se finaliza el escenario El actor que se beneficia del caso de us0 TambiCn puede enumerar las conjeturas del escenario (por ejemplo, que un cliente a la vez utilizari la miquina de gaseosas) y una breve descripcidn de una sola frase del escenario.

I 78

Hora 7

La hora 6, Introducci6n a 10s casos de uso, present6 algunos escenarios alternativos del caso de us0 Comprar gaseosa. En su descripcibn, tambiCn podria poner estos escenarios de manera separada (Sin el producto y Cambio incorrecto), o podria considerarlos como excepciones a1 primer escenario del caso de uso. La forma exacta de hacerlo s610 le concernira a usted, su cliente y 10s usuarios.

Q
G

Para rnostrar 10s pasos en un escenario, hay otra posibilidad que es utilizar un diagrama de actividades UML sobre el cual hablaremos en la hora 11, Diagrarnas de actividades.

Concepcion de las relaciones entre casos de us0

El ejemplo de la hora 6 tambiCn mostro dos formas en que 10s casos de us0 se pueden relacionar entre si. Una de ellas, la inclusicin, le permite volver a utilizar 10s pasos de un caso de us0 dentro de otro. La otra, extensicin, le permite crear un caso de us0 mediante la adici6n de pasos a uno existente. Existen otros dos tipos de relaciones que son generalizaci6n y agrupamiento. Como en las clases, la generalizacicin cuenta con un caso de us0 que se hereda de otro. El agrupamiento es una manera sencilla de organizar 10s casos de uso.

Inclusion
Examinemos 10s casos de us0 Reabastecer y Recolectar dinero del ejemplo de la hora 6. Ambos se inician mediante la apertura de la miquina, y finalizan con el cierre y sellado de la misma. El caso de us0 Exhibir el interior se cre6 para capturar el primer par de pasos; y Cubrir el interior para el scgundo. Tanto Reabastecer, como Recolectar dinero incluyen este par de casos de uso. Para representar a la inclusi6n utilizari el simbolo que us6 para la dependencia entre clases: una linea discontinua con una punta de flecha que conecta las clases apuntando hacia la clase dependiente. Justo sobre la linea, agregari un estereotipo: la palabra incluir bordeada por dos pares de parkntesis angulares. La figura 7.3 le muestra la relacidn de 4nclusibnn en el modelo de caso de us0 de la miquina de gaseosas.

Tenga en cuenta que un caso de us0 incluido nunca aparecera solo. Sirnplemente funciona corn0 parte de un caso de us0 que lo incluya.

En la notaci6n de texto que sigue 10s pasos en la secuencia, indicara 10s casos de us0 incluidos. El primer paso en el caso de us0 Reabastecer podria ser <<incluir>> (Exhibir el interior).

Diagramas de casos de us0

79 I

FIGURA7.3
El modelo de caso de us0 en la maquina de gaseosas con la inclusion.

Cliente

K?A
,

Maquina de gaseosas

el interior

Representante del proveedor

-K -K
Cliente

Representante del proveedor

Recolector

K-

3
Recolector

Extension
La hora 6 mostrd que el caso de us0 Reabastecer podria ser la base de otro caso de uso: Reabastecer de acuerdo a las ventas. En lugar de s610 reabastecer la mhquina de gaseosas para que todas las marcas tengan la misma cantidad de latas, el representante podria anotar aquellas que se venden mejor y reabastecer acorde con ello. Por lo que podemos decir que el nuevo caso de us0 extiende a1 original dado que agrega otros pasos a la secuencia del caso de us0 original, que se conoce como el caso de us0 base. La extensidn s610 se puede realizar en puntos indicados de manera especifica dentro de la secuencia del caso de us0 base. A estos puntos se les conoce como puntos de extensidn. En el caso de us0 Reabastecer, 10s nuevos pasos (anotar las ventas y abastecer de manera acorde) se dman luego que el representante haya abierto la mhquina y estC listo para llenar 10s compartimientos de las marcas de gaseosas. En este ejemplo, el punto de extensidn es Llenar 10s compartimientos. Como la inclusidn, podrh concebir la extensidn con una linea de dependencia (linea discontinua con punta una punta de flecha), junto con un estereotipo que muestra extender entre parentesis angulares. Dentro del caso de us0 bhsico, el punto de extensidn aparecerh debajo del nombre del caso de uso. La figura 7.4 le muestra la relacidn de extensidn para Reabastecer y Reabastecer de acuerdo a las ventas, junto con la inclusidn de relaciones para Reabastecer y Recolectar dinero.

I80

Hora 7

FIGURA 7.4 Un diagrama de casos

de us0 que muestra la extensidn y la inclusidn.

10s compartimientos

-extender. (llenar Ios compartimientos)

Reabastecer de acuerdo a las ventas

Generalizacion
Las clases pueden heredarse entre si y esto tambiCn se aplica a 10s casos de uso. En la herencia de 10s casos de uso, el caso de us0 secundario hereda las acciones y significado del primario, y ademis agrega sus propias acciones. Puede aplicar el caso de us0 secundario en cualquier lugar donde aplique el primario. En el ejemplo, debera imaginar un caso de us0 Comprar un vaso de gaseosa que se hereda de Comprar gaseosa. El caso de us0 secundario tiene acciones como agregar hielo y mezclar marcas de gaseosas. Modelar6 la generalizacih de casos de us0 de la misma forma que lo hace con las clases: con lineas continuas y una punta de flecha en forma de trihgulo sin rellenar que apunta hacia el caso de us0 primario, como se muestra en la figura 7.5.
FIGURA7.5
Un caso de uso puede heredar el sentido y comportamiento de otro.

La relaci6n de generalizacibn puede establecerse entre actores, asi como entre casos de uso. Quiz6 tenga personificados a1 representante del proveedor, a1 recolector y a1 agente del proveedor. Si cambia el nombre del representante como Reabastecedor, tanto Cste como el Recolector ser6n secundarios del Agente Proveedor, como muestra la figura 7.6.
FIGURA7.6
Como las clases y 10s casos de USO, 10s actores pueden estar en una relacidn de generalizacidn.

Y
Reabastecedor

Agente proveedor

A A

Recolector

Diagramas de casos de us0

Ag rupamiento
En ciertos diagramas de casos de uso, podria tener varios casos de us0 que querri organizar. Esto puede ocurrir cuando un sistema consta de varios subsistemas. Otra posibilidad seria cuando entrevista a 10s usuarios para obtener 10s requerimientos de un sistema. Cada requerimiento podria ser representado como un caso de us0 por separado. Necesitari alguna forma de ordenar 10s requerimientos por categorias. La forma mis directa de organizar seria agrupar en un paquete 10s casos de us0 que se relacionen. Recuerde que un paquete aparece como una carpeta tabular. Los casos de us0 agrupados aparecerin dentro de la carpeta.

Diagramas de casos de us0 en el proceso de analisis

Con el ejemplo dado y con el cual ha trabajado, aplic6 directamente la simbologia del caso de uso. Ahora nos regresaremos un poco y colocaremos 10s casos de us0 en el context0 de un esfuerzo de anilisis. Las entrevistas al cliente deberin iniciar el proceso. Estas entrevistas producirin diagramas de clases que fungirin como las bases de su conocimiento para el dominio del sistema (el Area en el cual resolver5 10s problemas). Una vez que conozca la terminologia general del Area del cliente, estari listo para hablar con 10s usuarios. Las entrevistas con 10s usuarios comienzan en la terminologia del dominio, aunque deberin alternarse hacia la terminologia de 10s usuarios. Los resultados iniciales de las entrevistas deberin revelar a 10s actores y casos de us0 de alto nivel que describirin 10s requerimientos funcionales en tCrminos generales. Esta informaci6n establece 10s confines y imbito del sistema. Las entrevistas posteriores con 10s usuarios profundizarin en estos requerimientos, lo que dari por resultado modelos de casos de us0 que mostrarin 10s escenarios y las secuencias detalladamente. Esto podria resultar en otros casos de us0 que satisfagan las relaciones de inclusi6n y extensi6n. En esta fase, es importante confiar en su comprensi6n del dominio (a partir de 10s diagramas de clases derivados de las entrevistas con el cliente). Si no comprende adecuadamente el dominio, podria crear demasiados casos de us0 y demasiados detalles (situacibn que podria, definitivamente, obstaculizar el diseiio y el desarrollo).

Aplicacion de 10s modelos de caso de us0

Para ayudarle a comprender con mis profundidad 10s modelos de casos de us0 y c6mo aplicarlos, vamos a ver un ejemplo mis complejo que una miquina de gaseosas. Suponga que deberi diseiiar una red de Area local (LAN) para una firma de consultoria, y que tendri que comprender la funcionalidad para poder crearla. iC6mo empezma?

I 82

Hora 7

Una LAN es una red de cornunicaciones que una organizacion utiliza en un arnbito lirnitado. Perrnite a 10s usuarios cornpartir recursos e inforrnacion.

Comprension del dominio

Empecemos con las entrevistas a1 cliente para crear un diagrama de clases que refleje cdmo es la vida en el mundo de la consultoria. El diagrama de clases podria incluir las siguientes clases: Consultor, Cliente, Proyecto, Propuesta, Datos e Informe. La figura 7.7 le muestra la forma en que podria lucir el diagrama.
FIGURA7.7
Un diagrama de clases para el mundo de la consultoria.
I

1 ..

* Y

sirve

Cliente

lee

I..*

Propuesta

A .,* se presenta a
1 4 aparece en

1..

1A * apareceen

I..*

Dam

Comprension de 10s usuarios

Ahora que el dominio esta a la mano, vuelva su atencidn a 10s usuarios debido a que el objetivo sera entender 10s tipos de funcionalidad por crear en el sistema. En el mundo real, entrevistma a 10s usuarios. En este ejemplo, basari sus ideas en cierto conocimiento general de las LANs y del dominio. No obstante, tenga presente que en el analisis de sistemas del mundo real, nada puede sustituir a las entrevistas con las personas. Un grupo de usuarios serin consultores, otros podrfan ser oficinistas. Entre otros usuarios en potencia se encontrarin funcionarios corporativos, vendedores, administradores de red, administradores de oficina y administradores de proyectos. (LSe le ocurren otros?) En este punto, seria conveniente a mostrar a 10s usuarios en una jerarquia de generalizacidn, como se observa en la figura 7.8.

Comprension de 10s casos de us0

iQuC hay de 10s casos de uso? Hay algunas posibilidades: Establecer niveles de seguridad, Crear una propuesta, Almacenar una propuesta, Utilizar correo electrdnico, Compartir informacidn de la base de datos, Realizar la contabilidad, Conectarse a la LAN desde fuera de ella, Conectarse a Internet, Compartir informacidn de la base

Diagramas de casos de us0

83 I

de datos, Indizar las propuestas, Utilizar propuestas previas y Compartir impresoras. De acuerdo con esta informacibn, la figura 7.9 le muestra el diagrama de casos de us0 de alto nivel que hemos generado.
FIGURA7.8 La jerarquia de
usuarios que interactuarbn con la LAN.

EmDleado

Funcionario Administrador Consultor

Oficinista

Adrninistrador Administrador de oficina de proyectos

Administrador de la red

Este conjunto de casos de us0 constituye 10s requerimientos funcionales de la LAN.

Profundizacion
Elaboremos uno de 10s casos de us0 de alto nivel y generemos un modelo de caso de uso. Una actividad extremadamente importante en una firma de consultoria es la generacibn de propuestas, asi que examinemos el caso de us0 Crear una propuesta. Las entrevistas con 10s consultores probablemente le indicaran cuantos pasos se necesitan en este caso de uso. Para empezar, el actor inicial es un consultor. El consultor tiene que iniciar una sesibn en la LAN y ser verificado como usuario valido. Luego tendrg que utilizar alglin software integrado para oficina (procesador de textos, hoja de calculo y graficos) para escribir la propuesta. En el proceso, el consultor podria volver a utilizar porciones de propuestas previas. La firma de consultoria podria tener una directiva de que un funcionario corporativo y otros dos consultores revisen una propuesta antes de que llegue a manos del cliente. Para ello, el consultor almacena la propuesta en un hrea central accesible mediante la LAN, y envia a 10s correos electrbnicos de 10s tres revisores un mensaje que indique que la propuesta se encuentra lista, asi como su ubicacibn.

~ 8 4

Hora 7

Luego de recibir 10s comentarios y hacer las modificaciones necesarias (nuevamente, con el software integrado para oficina), el consultor imprime la propuesta y la envia por correo a1 cliente. Cuando todo termina, el consultor se retira de la red. El consultor habra completado una propuesta y es el actor que se beneficia del caso de uso.
FIGURA7.9
Un diagrama de cusos de us0 de alto nivel que representa una LAN para una$rma de consultoria.

Funcionario corporativo

Adrninistrador de oficina

Adrninistrador de proyecto

Consultor

Adrninistrador de red

Oficinista

x x x x x

AN

0
Crear propuestas

base de datos

0
Utilizar propuestas previas

OO
Cornpartir impresoras

Conectar a Internet

Diagramas de casos de us0

85

En la secuencia anterior, es claro que ciertos pasos se repetir6n de un caso de us0 a otro, y ello le llevarfi a otros casos de us0 (posiblemente incluidos) en 10s que tal vez no habia pensado. Iniciar una sesidn y ser verificado son dos pasos que pueden incluir varios casos de uso. Por ello, crear6 un caso de us0 Verificar usuario que incluya Crear una propuesta. Otro par de casos de us0 son Utilizar software de oficina y Finalizar sesidn de la red. Podrian aparecer otros detalles del proceso de una propuesta cuando vea que las propuestas elaboradas para 10s clientes nuevos son diferentes a las de 10s clientes constantes. En si, las propuestas a 10s nuevos clientes probablemente incluyen informaci6n promocional de la empresa. Con 10s clientes constantes, no ser6 necesario enviar tal informacidn. Asi pues, otro nuevo caso de uso, Crear una propuesta para un cliente nuevo extender6 a Crear una propuesta. La figura 7.10 le muestra el diagrama de casos de us0 que resulta de este analisis del caso de us0 Crear una propuesta.
FIGURA7.10
El caso de us0 Crear una propuesta en la LAN de una firma de consultoria.

.
Q propuesta +
I I

<<extender,) , ,ccincIuir,, la sesion de la red

, de- oficina a

Crear una propuesta

Este ejemplo aterriza un punto importante, uno que habia destacado anteriormente: El anfilisis del caso de us0 describe el comportamiento de un sistema. No toca a la implementacidn. iEsto es particularmente importante en este caso, dado que el diseiio de una LAN supera, por mucho, el alcance de este libro!

Donde estamos
~ ~ ~~~~~ ~ ~

Este es un buen momento para ver la estructura general del UML dado que ya ha avanzado en dos de sus principales aspectos: la orientacidn a objetos y el analisis de casos de uso. Ha visto sus fundamentos y simbologia, asi como explorado algunas aplicaciones.

186

Hora 7

En las horas 2 a la 7 ha trabajado con: Clases Objetos Interfaces Casos de us0 Actores Asociaciones Generalizaciones Realizaciones Agregaciones Composiciones Estereotipos Restricciones Notas Paquetes Extensiones Inclusiones

Intentemos dividir este conjunto de elementos en categorias.

Elementos estructurales
Las clases, objetos, actores, interfaces y casos de us0 son cinco de 10s elementos estructurales en el UML. Aunque tienen diversas diferencias (mismas que, como ejercicio, deberi indicar), son similares en el sentido de que representan partes ya sea fisicas o conceptuales de un modelo. Conforme avance en la parte I, veri otros elementos estructurales.

Relaciones
La asociacibn, generalizacibn, dependencia y realizacibn, son las relaciones en el UML. (La inclusi6n y extensi6n son dos tipos de dependencias.) Sin las relaciones, 10s modelos UML no serfan m6s que listas de elementos estructurales. Las relaciones conectan a tales elementos y de ese mod0 conectan 10s modelos con la realidad.

Agrupamiento
El paquete es el ~ n i c o elemento de agrupamiento en el UML, Cste le permite organizar 10s elementos estructurales en un modelo. Un paquete puede contener cualquier tiPo de elemento estructural, y diferentes tipos a la vez.

Anotacion
La nota es el elemento de anotaci6n del UML; Cstas le permiten adjuntar restricciones, comentarios, requerimientos y grhficos explicativos a sus modelos.

Diagramas de casos de us0

87 I

Extension
Los estereotipos o clisCs son dos estructuras que el UML proporciona para extender el lenguaje. Le permiten crear nuevos elementos ademas de 10s existentes, de mod0 que pueda modelar de forma adecuada la seccidn de realidad en la que se centrari su sistema.

...y mas
Ademis de 10s elementos estructurales, relaciones, agrupamientos, anotaciones y extensiones, el UML cuenta con otra categoria: elementos de comportamiento. Tales elementos le muestran la forma en que las partes de un modelo (como 10s objetos) cambian con el tiempo. Aun no sabe utilizarlos, per0 10s ver6 en la siguiente hora.

El Panorama
Ahora ya tiene una idea de la forma en que el UML se organiza. La figura 7.1 1 esquematiza esta organizacidn por usted. Conforme vea las siguientes horas de la parte I, tenga esta organizacidn en mente. Le hari adiciones conforme avance y este panorama le mostrara ddnde agregar el nuevo conocimiento que adquiera.

FIGURA7.11
La organizacidn del UML, en terrninos de 10s elernentos clue ha utilizado hasta ahora.

Elernentos estructurales

0
Caso de us0 Relaciones Asociacion

D --

- - - - - - - -> - - - - - - - 5>
Agrupacion

Generalizacion Dependencia Realizacion Extension

c( Estereotipo>> (Restriccion}

Paquete

(valor etiquetado) Anotacion

Hora 7

Resumen
El caso de us0 es una poderosa herramienta para obtener 10s requerimientos funcionales. Los diagramas de casos de us0 agregan mayor poder: debido a que conciben 10s casos de uso, facilitan la comunicacidn entre 10s analistas y 10s usuarios, y entre 10s analistas y 10s clientes. En un diagrama, el simbolo del caso de us0 es una elipse. El simbolo de un actor es una figura adjunta. Una linea asociativa conecta a un actor con el caso de uso. Los casos de us0 estin, por lo general, dentro de un recthngulo que representan el confin del sistema. La inclusidn se representa por una linea de dependencia con un estereotipo ccincluirn. La extensidn se representa por una linea de dependencia con un estereotipo <<extender>>. Las otras dos relaciones entre casos de us0 son generalizacidn, en la que un caso de us0 hereda el sentido y acciones de otro, y el agrupamiento, mismo que organiza un conjunto de casos de uso. La generalizacidn se representa por la misma linea que muestra la herencia entre clases. El agrupamiento se representa por el icono del paquete.

Los diagramas de casos de us0 figuran con fuerza en el proceso de analisis. Se empieza con entrevistas con 10s clientes para obtener diagramas de clases. Estos proporcionan una base para entrevistar a 10s usuarios. Tales entrevistas dan por resultado un diagrama de casos de us0 de alto nivel que muestra 10s requerimientos funcionales del sistema. Para crear 10s modelos de caso de uso, profundice en cada caso de us0 de alto nivel. Los diagramas resultantes de caso de us0 d a r h 10s fundamentos para el disefio y desarrollo.
Ahora que ha visto la orientacidn a objetos y 10s casos de uso, esti listo para ver el panorama del UML. Los elementos que ha aprendido de las horas 2 a 7 se encuentran en estas categorias: elementos estructurales, relaciones, organizacidn, anotacidn y extensidn. En la siguiente hora Vera un elemento de la categoria restante: elementos de comportamiento. Tenga en mente este panorama para que se le facilite el aprendizaje del UML.

Preguntas y respuestas
P Me di cuenta que en el diagrama de casos de us0 de alto nivel no mostr6 las asociaciones entre 10s actores y 10s casos de uso. LA quC se debe? R El diagrama de casos de us0 de alto nivel surge en las etapas iniciales de las entrevistas con 10s usuarios. En este punto, esto es mas o menos un ejercicio de recopilacidn de ideas y el objetivo es encontrar 10s requerimientos generales, Ambit0 y
confines del sistema. Las asociaciones tendran mayor sentido cuando posteriores entrevistas con 10s clientes le lleven a profundizar en cada requerimiento y que 10s modelos de casos de us0 tomen forma.

Diagramas de casos de us0

89

P ;Por quC es importante tener en cuenta t a l panorama del UML? ;No bastaria con que sepa utilizar cada tip0 de diagrama? R Si usted comprende la organizacidn del UML, podri manejar situaciones que no haya encontrado antes. Podri reconocer cuando un elemento UML existente no haga el trabajo, y sabri cdmo construir uno nuevo. TambiCn sabri cdmo crear un diagrama hibrido si llegara a ser la Gnica forma de presentar claramente un modelo.

Taller
En este taller continuari con el conocimiento obtenido en la hora 6 y lo usarh como base para el conocimiento de la hora 7. El objetivo es utilizar su nuevo conocimiento para concebir 10s casos de us0 y sus relaciones. Las respuestas aparecen en el ApCndice A, Respuestas a 10s cuestionarios.

Cuestionario
1. Mencione dos ventajas de concebir un caso de uso. 2. Describa la generalizaci6n y el agrupamiento, las relaciones entre 10s casos de us0 que ha visto durante esta hora. Mencione dos situaciones en las que usted agrupma 10s casos de uso. 3. LCuiles son las similitudes entre las clases y 10s casos de uso? LCuiles las diferencias?

Ejercicios
1. Bosqueje el diagrama de un modelo de caso de us0 para un control remoto de una televisidn. Asegdrese de incluir todas las funciones del control remoto como casos de us0 para su modelo.

2. En el segundo ejercicio de la hora 6 indic6 a 10s actores y casos de us0 de un almacCn de cdmputo. Esta vez, dibuje un diagrama de casos de us0 de alto nivel con base en el trabajo que realizd en tal ejercicio. Luego, genere un modelo de caso de us0 para a1 menos uno de 10s casos de us0 de alto nivel. En su trabajo, intente incorporar las relaciones ccincluir,, o <<extender,que Sean necesarias.

HORA

Diagramas de estados
Hasta ahora ha comprendido 10s importantes elementos estructurales del UML. Ahora ver5 un elemento que le muestra c6mo modificar 10s procedi mientos con el tiempo. En esta hora se trataran 10s siguientes temas: QuC es un diagrama de estados Sucesos, acciones y condiciones de seguridad Subestados: secuenciales y concurrentes Estados hist6ricos Por quC son importantes 10s diagramas de estados Adici6n del diagrama de estados a1 panorama del UML A1 finalizar la hora anterior, dije que aqui tratma una nueva categoria de elementos con la cual no habia trabajado, el elemento de comportamiento, Cste muestra la forma en que las partes de un modelo UML cambian con el tiempo. Vera un miembro en particular de diagrama de estados.
1

I92

Hora 8

Cada aiio trae consigo nuevos estilos en ropas y autombviles, las estaciones cambian el color de las hojas de 10s arboles y cada aiio que pasa deja entrever el crecimiento y madurez de 10s nifios. A1 pasar el tiempo y conforme suceden las cosas, hay cambios que afectan a 10s objetos que nos rodean. Esto tambiCn se aplica en cualquier sistema. Conforme el sistema interactha con 10s usuarios y (posiblemente) con otros sistemas, 10s objetos que lo conforman pasaran por cambios necesarios para ajustar las interacciones. Si va a modelar sistemas, necesitari contar con un mecanismo para 10s cambios en el modelo.

Que es un diagrama de estados

Una manera para caracterizar un cambio en un sistema es decir que 10s objetos que lo componen modificaron su estado como respuesta a 10s sucesos y a1 tiempo. He aqui algunos ejemplos rapidos: Cuando acciona el interruptor, la fuente de luz cambia su estado de apagada a encendida. Cuando presiona un b o t h de un control remoto, una televisibn cambia su estado para mostrarle un canal u otro. Luego de un lapso adecuado, una lavadora cambia su estado de lavar a enjuagar.

El diagrama de estados UML captura este tip0 de cambios. Presenta 10s estados en 10s que puede encontrarse un objeto junto con las transiciones entre 10s
estados, y muestra 10s puntos inicial y final de una secuencia de cambios de estado.

Un diagrama de estados tambien se conoce corn0 un motor

de estado.

Tenga en cuenta que un diagrama de estados es intrinsecamente distinto, de manera muy significativa, de uno de clase, de objeto o de un caso de uso. Los diagramas que ya ha visto modelan el comportamiento de un sistema, o a1 menos un grupo de clases, objetos o casos de uso. Un diagrama de estados muestra las condiciones de un solo objeto.

Si mbologia
La figura 8.1 le muestra el recthgulo de vkrtices redondeados que representa a un estado, junto con una linea continua y una punta de flecha, mismas que representan a una transicibn. La punta de la flecha apunta hacia el estado donde se hara la transicibn. La figura tambiCn muestra un circulo relleno que simboliza un punto inicial y la diana que representa a un punto final.

Diagramas de estados

93 I

FIGURA 8.1
Los simbolos UML en un diagrama de estados. El icono para el estado es un rectdngulo de v&rticesredondeados, y el simbolo de una transicidn es una linea continua y una punta de Jecha. Un circulo relleno se interpreta como el punto inicial de una secuencia de estados, y una diana representa a1 punto final.

Adicion de detalles al icono de estado

El UML le da la opci6n de agregar detalles a la simbologia. Asi como es posible dividir un simbolo de clase en tres keas (nombre, atributos y operaciones), puede dividir el icono de estado de igual forma. El Area superior contendri el nombre del estado (que tiene que establecer ya sea que haya la subdivision o no), el Area central contendri las variables de estado, y el Area inferior las actividades. La figura 8.2 le muestra estos detalles.
FIGURA8.2
Puede subdividir el simbolo del estado en areas que muestren el nombre, variables y actividades del estado.

f-LL-1
Variables de estado Actividades

Las variables de estado como cron6metros o contadores son, en ocasiones, de ayuda. Las actividades constan de sucesos y acciones: tres de las mis utilizadas son entrudu (quC sucede cuando el sistema entra a1 estado), salidu (quC sucede cuando el sistema sale del estado), y hacer (quC sucede cuando el sistema esti en el estado). Puede agregar otros conforme sea necesario. Un miquina de fax sirve como ejemplo de un objeto que puede pasar por diversas variables y actividades de estado. Cuando se envia un fax --esto es, cuando se encuentra en estado de envlo de fax- la mAquina de fax anota la fecha y hora en que inicid el envio (10s valores de las variables de estado fecha y hora), y tambiCn anota su ndmero telef h i c o asi como el nombre del propietario (10s valores de las variables de estado telkfono y propietario). A1 encontrarse en este estado, la miquina se encarga de agregar un registro de fecha y hora a1 fax, numero telefhico y nombre del propietario. En otras actividades de este estado, la maquina jalarA las hojas, paginara el fax y finalizari la transmision.

I94

Hora 8

Mientras se encuentre en el estado de inactividad, la miquina de fax mostrari la fecha y la hora en una pantalla. La figura 8.3 le muestra el diagrama de estados.
FIGURA8.3
La rndquina de fax es un buen ejemplo de un estado con variables y actividades.

Envio de fax Fecha = Fecha en curso Hora = Hora de inicio del fax Telefono = Numero telefonico del propietario Propietario = Nombre del propietario entradaharcar el numero de fax salida/finalizar transmision hacedagregar impresion de fecha hacedagregar impresion de tiempo hacedagregar numero de telefono hacedagregar propietario hacedjalar hojas hacedpaginar

Fecha = Fecha en curso Hora = Horaencurso Telefono = Numero de telefono del propietario Propietario = Nombre del propietario entraddfax finalizado saliddiniciar fax hacedmostrar Fecha hacedmostrar Hora

Sucesos y acciones
TambiCn puede agregar ciertos detalles a las lineas de transicion. Puede indicar un suceso que provoque una transici6n (desencadenar un suceso), y la actividad de cdmputo (la accidn) que se ejecute y haga que suceda la modificaci6n del estado. A 10s sucesos y acciones 10s escribiri cerca de la linea de transicidn mediante una diagonal para separar un suceso desencadenado de una accibn. En ocasiones un evento causari una transicidn sin una accidn asociada, y algunas veces una transicih sucederi dado que un estado finalizari una actividad (en lugar de hacerlo por un suceso). A este tip0 de transicidn se le conoce como transicidn no desencadenada. La GUI (interfaz grifica de usuario) con que interactde le dari ejemplos de detalles de la transicibn. Por el momento, asumamos que la GUI puede establecerse en uno de tres estados: Inicializacidn Operaci6n Apagar

Diagramas de estados

95

Cuando encienda su equipo, se ejecutari un proceso de arranque. A1 encender la PC se desencadena un suceso que provoca que la GUI aparezca luego de una transicidn desde el estado de Inicializacibn, y el arranque es una accidn que se realiza durante tal transicidn. Como resultado de las actividades en el estado de inicializacidn, la GUI entra a1 mod0 de Operacidn. Cuando desea apagar su PC, desencadena un suceso que provoca la transicidn hacia el estado de Apagado, y con ello la PC se apaga. La figura 8.4 muestra el diagrama de estados que captura 10s estados y transiciones en la GUI.

Los estados y transiciones de una inte$az grafica del usuario

ncender la

pc

lnicializacion

Operacion

Apagado

Apagar

>

>

+ @ I

hacer/Arrancar

Condiciones de seguridad
La anterior secuencia de estados de la GUI deja mucho que desear. Por ejemplo: si deja solo su equipo o si realizara alguna actividad en la que no tocari a1 ratdn o a1 teclado, podria aparecer un protector de pantallas que evitaria el desgaste de su pantalla. Para decir esto en tCrminos de cambio de estado, si ha pasado cierto tiempo sin que haya interaccidn con el usuario, la GUI hari una transicidn del estado Operacidn a un estado que no aparece en la figura 8.4: el estado de Protector de pantallas. El intervalo se especifica en el panel de control de su sistema operativo (Windows en este caso). Por lo general es de 15 minutos. Cualquier opresidn de una tecla o movimiento del ratdn provocari una transicidn del estado Protector de pantallas a1 estado Operacidn. El intervalo de 15 minutos es una condicidn de seguridud cuando se llega a ella, se realiza la transicidn. La figura 8.5 muestra el diagrama de estados de la GUI con el estado Protector de pantalla y la condicidn de seguridad aiiadida. Vea que la condicidn de seguridad se establece como expresidn booleana.
la pc lnicializacion

El FIGIJRA diagrama 8.5 de estados para la GUI, con el estado Protector de pantalla y la condicidn de seguridad.

I-{ 0 [-k
Operacion Apagado

hacer/Arrancar

[lapso transcurrido]

II

Teclazo o movimiento del raton

Protector

I96

Hora 8

Subestados
Nuestro modelo de la GUI aun esta algo vacio. El estado Operacidn, en particular, es mucho mis sustancioso de lo que he indicado en las figuras 8.4 y 8.5. Cuando la GUI estfi en el estado Operacibn, hay muchas cosas que ocurren tras bambalinas, aunque no Sean particularmente evidentes en la pantalla. La GUI aguarda de forma constante a que usted haga algo (oprimir una tecla, mover el raton u oprimir uno de sus botones). Luego, deberi registrar tales acciones y modificar lo que se despliega para reflejarlas en la pantalla (como mover el cursor cuando usted mueva el ratdn, o mostrar una a cuando usted oprima la tecla a). Con ello la GUI atravesari por varios cambios mientras se encuentre en el estado Operaci6n. Tales cambios seran cambios de estado. Dado que estos estados se encuentran dentro de otros, se conocerin como subestados. Hay dos tipos de subestados: secuencial y concurrente.

Subestados secuenciales
Como su nombre lo indica, 10s subestados secuenciales suceden uno detras de otro. Si retomamos 10s subestados mencionados con anterioridad dentro del estado Operaci6n de la GUI, tendra la siguiente secuencia:

A la espera de acci6n del usuario Registro de una acci6n del usuario Representacidn de la accidn del usuario

La acci6n del usuario desencadena la transicidn a partir de A la espera de accidn del usuario hacia Registro de una acci6n del usuario. Las actividades dentro del Registro trascienden de la GUI hacia la Representacidn de la accion del usuario. DespuCs del tercer estado, la GUI vuelve a iniciar A la espera de acci6n del usuario. La figura 8.6 le muestra c6mo representar 10s subestados secuenciales dentro del estado Operaci6n. FIGURA8.6
Suhestados secuenciales dentro del estado Operacidn de la GUI.

A la espera
del usuario del usuario de la accion del usuario

Subestados concurrentes
Dentro del estado Operacidn, la GUI no s610 aguarda a que usted haga algo. TambiCn verifica el crondmetro del sistema y (posiblemente) actualiza el despliegue de una aplicaci6n luego de un interval0 especifico. Por ejemplo, una aplicacidn podria incluir un reloj en pantalla que tuviera que actualizar la GUI.

Diaqramas de estados

97 I

Todo esto sucede a1 mismo tiempo que la secuencia que ya indiquC. Aunque cada secuencia es, claro, un conjunto de subestados secuenciales, las dos secuencias son concurrentes entre si. Puede representar la concurrencia con una linea discontinua entre 10s estados concurrentes, como en la figura 8.7.
FIGURA8.7
Los subestados concurrentes suceden a1 mismo tiempo. Una linea discontinua 10s separa.

Operacion

del usuario

del usuario

de la accion del usuario

........................................
cronometro del sistema Actualizar despliegue

La separation del estado Operacion en dos componentes podria recordarle algo. LRecuerda cuando tratC el tema de las adiciones y composiciones? Cuando cada componente sea parte de un todo, tratari con una composici6n. Las partes concurrentes del estado Operacion tienen el mismo tipo de relaci6n con 61. Por ello, el estado Operacidn es un estado compuesto. Un estado que consta s610 de subestados secuenciales, tambiCn es un estado compuesto.

Esta d0 s historicos
Cuando se activa su protector de pantallas y mueve su rat6n para regresar a1 estado Operaci6n LquC ocurre? LAcaso su pantalla retoma el estado inicial, como si apenas se hubiera encendido? LO luciri tal como la dej6 antes de que se activara el protector de pantallas? Es obvio, si el protector de pantallas provocara que la pantalla regresara a su estado inicia1 de operacibn, la idea del protector de pantallas seria contraproducente. Los usuarios podrian perder su trabajo y tendrian que reiniciar una sesi6n nuevamente. El diagrama de estados hist6ricos captura esta idea. El UML proporciona un simbolo que muestra que un estado compuesto recuerda su subestado activo cuando el objeto trasciende fuera del estado compuesto. El simbolo es la letra H encerrada en un circulo que se conecta por una linea continua a1 subestado por recordar, con una punta de flecha que apunta a tal subestado. La figura 8.8 muestra este simbolo en el estado Operaci6n.

I98

Hora 8

FIGURA8.8
El estado histdrico, simbolizudo con la H dentro del circulo, le muestra que un estudo compuesto recuerdu su subestado uctivo cuundo el objeto trasciende fuera de tal estudo compuesto.

A la espera de accion del usuario

Action

Registro de una accion del usuario

Representacion de la accion del usuario

Verificar el cronornetro del sisterna

[Lapso transcurrido]

>

<

Actualizar despliegue

[Lapso transcurrido]

I I

Teclazo o novirniento del raton

I
I

En el diagrama de estados no he tratado con las ventanas que estan 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 lo hace), el estado histdrico es profundo. Si sdlo recuerda el subestado principal, el estado histdrico sera supe@ciul. Un estado histdrico 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 nr actividades, por lo que no son estados "completes".
I I

Mensajes y sefiales
En el ejemplo, el suceso desencadenado que provocd la transicidn de Protector de pantalla a Operacidn es la opresidn de una tecla, un movimiento del ratdn o una opresidn de uno de sus botones. Cualquiera de estos sucesos es, en efecto, un mensaje del usuario a la GUI. Esto es un concept0 importante dado 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).

Diagramas de estados

99 I

Un mensaje que desencadena una transici6n en el diagrama de estados del objeto receptor se conoce como sefial. En el mundo de la orientaci6n a objetos, el envio de una seiial es lo 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. LEn verdad es necesario? De hecho, asi es. Es necesario contar con diagramas de estados dado 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 esthticos de un sistema. Muestran las jerarquias y asociaciones, y le indican quC son las operaciones. Per0 no le muestran 10s detalles dinhmicos de las operaciones.
Los desarrolladores, en particular, deben saber la forma en que 10s objetos se supone que se comportarhn, ya que son ellos quienes tendrhn 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 tendrhn que adivinar lo que se supone que harhn 10s objetos. Con una Clara representach 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.

I100

Hora 8

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

Elementos estructurales

[ I
Estado

Elernentos de comportamiento

0
Caso de us0 Relaciones Asociacion

Generalizacion Dependencia Realizacion Extension Estereotipon

_------> _
-_----Agrupacion

Paquete

(Restriccion} [valor etiquetado}

L.'4
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 recthngulo de vCrtices redondeados representa a un estado, y una linea continua con una punta de flecha representa una transicidn de un estado a otro.
El simbolo del estado contiene el nombre del mismo y puede tener variables y actividades del estado. Una transici6n puede suceder como respuesta a un suceso desencadenado, e implicar una respuesta o accibn. Una transicidn tambiCn puede ocurrir por la actividad en un estado: una transition que ocurre de esta forma se conoce como transicidn no desencadenada. Finalmente, una transici6n puede ocurrir cuando se cumple una condici6n particular, o condicidn de seguridad.

Anotacion

En ocasiones, un estado consta de subestados. Los subestados pueden ser secuenciales (ocurrir uno despuCs 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 recordarh su subestado cuando el objeto trascienda de este estado compuesto. Un estado historic0 puede ser superficial o profundo. Tales tkrminos son propios de 10s subestados anidados. Un estado historic0 superjicial recuerda so10 el subestado principal. Un estado historic0 profundo recuerda todos 10s niveles de 10s subestados.

Diagramas de estados

101

Cuando un objeto envia un mensaje que desencadena una transicibn en el diagrama de estados de otro objeto, tal mensaje es una seiial. Una seiial es, por si misma, un objeto, y podra crear una jerarquia de herencia de las sefiales. Es necesario contar con 10s diagramas de estados porque facilitan la comprensibn de 10s objetos de un sistema a 10s analistas, diseiiadores y desarrolladores. Los desarrolladores, en particular, deben saber cdmo se supone que se comportarhn 10s objetos, dado que serhn 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 iCua1 es la mejor manera de empezar a crear un diagrama de estados? R Es muy parecido a crear un diagrama de clases o un modelo 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 listara 10s estados del objeto, y luego se enfocarh en las transiciones. Conforme avance en cada transicibn, debera prever si un suceso desencadenado lo activarh y si se realizarii alguna accibn. 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 jamhs tendra un estado final. P iAlguna 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 usarh y sus esfuerzos (no importa quC tan minuciosos hayan sido) habran sido infructuosos.

Taller
El cuestionario y 10s ejercicios le harhn trascender al estado Aprendizaje de diagramas de estados. Como siempre, encontrarh las respuestas en el ApCndice A, Respuestas a 10s cuestionarios.

Cuestionarios
1. LDe quC forma difiere un diagrama de estados de uno de clases, de objetos o de caso de uso? 2. Defina 10s siguientes tknninos: transicidn, suceso y accidn. 3. LQUC es una transicidn no desencadenada? 4. LCual es la diferencia entre 10s subestados secuenciales y 10s concurrentes?

I102

Hora 8

Eje rcicios
1. Suponga que diseiiarfi 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 crearfi 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. (iQuC tipo de clase es?) Cree un diagrama de clases de las posibles sefiales 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.

9
Diagramas de secuencias
Los diagramas de estados se enfocan a 10s diferentes estados de un objeto. Esto es s610 una pequeiia 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 trataran 10s siguientes temas:

QuC es un diagrama de secuencias LaGUI Diagramas de instancias y diagramas genkricos Us0 de si y mientras Creaci6n de un objeto en la secuencia Representaci6n 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.

I 104

Hora 9

El UML le permite expandir su campo de visi6n y le muestra la forma en que un objeto interacciona con otros. En este campo de vision expandido, incluiri una importante dimensih: 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 al fin. A1 momento de crear un sistema tendri 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 progresih 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 extensi6n que esti debajo (y en forma descendente) de cada objeto seri una linea discontinua conocida como la lfnea de vida de un objeto. Junto con la linea de vida de un objeto se encuentra un pequeiio rectingulo conocido como activacidn, el cual representa la ejecuci6n de una operation que realiza el objeto. La longitud del rectangulo se interpreta como la duracion de la activaci6n. La figura 9.1 muestra un objeto, su linea de vida y su activacih.
FIGURA9.1
Representacidn de un objeto en un diagrama 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 sincr6nico, esperari la respuesta a tal mensaje antes de continuar con su trabajo. Si un objeto envia un mensaje asincrhico, no esperari una respuesta antes de continuar. En el diagrama de secuencias, 10s simbolos del mensaje varian, por ejemplo, la punta de la flecha de un mensaje simple esti formada por dos lineas, la punta de la flecha de un mensaje sincr6nico esta rellena y la de un asincrhico tiene una sola linea, como se aprecia en la figura 9.2.

!
Diagramas de secuencias 105 1

FIGURA9.2
Sirnbolos para 10s rnensajes en un diagrarna de secuencias.

> b
i

Simple Sincronico ~ ~ i ~ ~ ~ ~ ~

Tiempo
El diagrama representa a1 tiempo en direccidn vertical. El tiempo se inicia en la parte superior y avanza hacia la parte inferior. Un mensaje que est6 mas 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 bisico 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 diagrarna de secuencias 10s objetos se colocan de izquierda a derecha en la 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 rnensaje de un objeto a otro. El tiernpo se inicia en la parte superior y continu'a hacia abajo. Aunque un actor es el que nomtalrnente inicia la secuencia, su sirnbolo no es parte del conjunto de sirnbolos del diagrarna de secuencias.

R ? !

[ 3 ;I,

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

I 106

Hora 9

La GUI
En la hora anterior desarrollo 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 alfanumerica; si asumimos que utiliza una aplicacion como un procesador de textos, el caracter correspondiente debera aparecer de inmediato en la pantalla. iQuC ocurre tras bambalinas para que esto suceda?

1. 2. 3. 4. 5. 6.

La GUI notifica a1 sistema operativo que se oprimi6 una tecla.

El sistema operativo le notifica a la CPU. El sistema operativo actualiza la GUI. La CPU notifica a la tarjeta de video. La tarjeta de video envia un mensaje a1 monitor. El monitor presenta el carkter alfanumkrico en la pantalla, con lo que se har5 evidente a1 usuario.

Todo esto ocurre con tanta rapidez que olvidamos que todo ello 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 asincronicos: ninguno de 10s componentes aguarda nada antes de continuar. A1 trabajar con algunas aplicaciones de Windows, tal vez haya sentido algunos de 10s efectos de la comunicacih 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 despuCs de haber oprimido algunas mas.

Diagramas d e secuencias

107 I

FIGURA 9.4
Un diagrarna de secuencias que rnuestra la forrna en que la GUI interacciona con otros objetos.

x x

Teclazo

1 -

I'I

En ocasiones, es muy instructivo 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 podria esperarlo.
FIGURA9.5
Un diagrarna de secuencias puede rnostrar 10s estados de un objeto.

0 1
lnicializacion Operativo

.
f

:retroalimentacioi

.'

0 1
Apagar

I108

Hora 9

En un diagrarna de secuencias, otra forrna de rnostrar el cambio de estado de un objeto es incluir al objeto mas de una vez en el diagrama.

El caso de us0
iQuC es 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 us0 llamado Ejecutar la opresidn de una tecla (vea la figura 9.6). A1 representar grificamente las interacciones del sistema en el caso de uso, el diagrama de secuencias habri, en efecto, delineado el caso de us0 dentro del sistema.
FIGURA9.6 El caso de uso representado grbjicamente por el diagrama de secuencias de lajigura 9.4.
Usuario
I

Ejecutar la opresion de una tecla

Usuario
I

En el siguiente ejemplo, examinark detalladamente la relacidn entre 10s casos de us0 y 10s diagramas de secuencias.

Instancias 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 us0 del ejemplo de la maquina 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 us0 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 miquina. Luego hace una seleccidn. Dado que hablamos del mejor escenario, la miquina tiene a1 menos una lata de la gaseosa elegida y por lo tanto presenta una lata fria a1 cliente. Asumamos que en la miquina de gaseosas hay tres objetos que realizan la tarea que nos ocupa: la fachada (la interfaz que la miquina de gaseosas presenta a1 usuario), el registrador de dinero (que lo recolecta), y el dispensador (que entrega la gaseosa). TambiCn daremos por hecho que el registrador de dinero controlari a1 dispensador. La secuencia sera como sigue:

Diagramas de secuencias

109 I

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

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

Dado que el diagrama de secuencias s610 se centra en un escenario (una instancia) en el caso de us0 Comprar gaseosa, se conoce como diagrama 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.
FIGURA9.7
Este diagrama de secuencias modela tan sdlo el mejor escenario del caso de us0 Comprargaseosa . Por lo tanto, es un diagrama de secuencias de instancias.

I:Fachadal lnsercion (Alimentacion) A E l e c c i o n (Selj Enviar

:Registrador

I (:Dispe;sadorl

?n

I1

Despachar (Seleccion)

(l

Un diagrama de secuencias generic0

Como recordari, el caso de us0 Comprar gaseosa tenia dos escenarios alternos. Uno de ellos se refena a1 hecho de que la miquina 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 us0 a1 momento de crear un diagrama de secuencias, se tratma de un diagrama de secuencias generico. En este caso podri generar el diagrama de secuencias genCrico a partir del diagrama de secuencias de instancias. Para ello tendri 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.

I110

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 regresari el monto alimentado y mostrari un mensaje que indique a1 cliente que inserte el monto exacto. 5. Si la cantidad insertada es menor a1 precio, el registrador no hace nada y la miquina esperarh mis dinero.

Si diseiia una maquina de gaseosas para un cliente, tal vez tenga que tomar una decision de diseAo respecto al paso 5. Podra hacer que la rnaquina aguarde cierto tiempo, calcule la diferencia entre el precio y el rnonto insertado, y que rnuestre un rnensaje que solicite al cliente que inserte la diferencia. Corno parte de la decision, tendra que responder a estas preguntas: ~ Q u e tanto le irnportara esta facultad al cliente? Cuanto costaria irnplernentar la tecnologia que lograra lo anterior? Este es un buen ejernplo de la forrna en que un diagrama de secuencias puede influir en el proceso de analisis.

Para representar cada condici6n en la secuencia, tal condieion la colocari en un si (un si condicional) entre corchetes. Arriba de las flechas de mensaje apropiadas, agregue [alimentacion > precio], [alimentacibn - precio no presente] y [alimentacion - precio presente]. Cada condieion causari una bifurcaci6n del control en el mensaje, que separarh a1 mensaje en rutas distintas. Como cada ruta iri a1 mismo objeto, la bifurcaci6n causari una ramificaci6n del control en la linea de vida del objeto receptor, y separari las lineas de vida en rutas distintas. En alg6n 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.

r
Diagramas de secuencias
c

111

FIGURA9.8
El diagrama de secuencias luego de agregar el escenario de Monto incorrecto a1 caso de us0 Comprar gaseosa .

0
lnsercion (Alirnentacion)

[:Fachadal
.
, I

.,..
I

:Enviar (altmentacion)
I

I.

I I

: Despachar (Seleccion)
[Carnbio en reserva] Regresar carnbio [No hay carnbio en reserva] Devolver (Alimentacion) Transaccionfinalizada Despachar (Seleccion)

) :
I !.

.. ,I I II

I
I

.
.

IAlirnentacion = Preciol

\ I

[Alirnentacion >Prec6 Verificar carnbio [Carnbio en reserva]

1

:I,
: :
, ,

: :
I

Ahora agregaremos el escenario Sin gaseosa.

1. Una vez que el cliente elige una marca agotada, la miquina mostrara un mensaje de Agotado . 2. La miquina mostrara un mensaje que solicitari a1 cliente que haga otra elecci6n. 3. El cliente tendra la opcion de oprimir un b o t h para que se le regrese su dinero. 4. Si el cliente elige una marca en existencia, todo procederi como en el mejor escenario si el monto insertado es correcto. Si no lo es, la miquina seguira por el escenario del Monto incorrecto. 5. Si el cliente elige otra marca agotada, el proceso se repetira 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 m6quina de gaseosas con 10s escenarios Monto incorrecto y Sin marca.

I112

Hora 9

FIGURA9.9
El diagram de secuencias generico de la maquina de gaseosas luego de agregarle el escenario Sin marca a la figura 9.8.

0
Insertion

I:fachadal
[Alimentaclon = Precio] Verificar (Selection) [Seieccion en existencia]

[Selection agatada]
I I -

Mostrar (mensale)

Si empieza a pensar que un diagrama de secuencias esta 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 genCrico y de instancias, asi como estructuras de control. Otro concept0 importante relacionado con 10s diagramas de secuencias, particularmente cuando diseiie software, es la creaci6n 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 representma la creacidn de un objeto cuando represente una secuencia de interacciones entre objetos? El caso de us0 Crear una propuesta del ejemplo de la LAN en una firma de consultoria nos muestra una instancia de la creaci6n de objetos. En este ejemplo concebirh 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 modelarh quedarh como sigue: 1. El consultor querrh volver a utilizar partes de una propuesta existente y busca en un 6rea centralizada de la red una propuesta adecuada. 2. Si el consultor encuentra una propuesta adecuada, abrirh el archivo y, en el proceso, abrirh el software integrado para la oficina relacionada. El consultor guardara el archivo con un nuevo nombre, con lo que crearh un archivo nuevo para la nueva propuesta.

Diaqramas de secuencias

113 I

3. Si el consultor no encuentra una propuesta, abriri la aplicacidn de oficina y creari un archivo para la propuesta. 4. A1 trabajar en la propuesta, el consultor utilizarh las aplicaciones del software integrado para oficina. 5. Cuando el consultor finalice la propuesta, la guardari en el 6rea de almacenamiento centralizada.

Ademis de la creacidn de objetos (en este caso, de archivos), esta secuencia trae consigo el us0 de si asi como de un ciclo mientras. Primer0 veamos lo relacionado con la creacidn de objetos. Cuando una secuencia da por resultado la creacidn de un objeto, tal objeto se representari de la forma usual: como un rectingulo con nombre. La diferencia es que no lo colocari en la parte superior del diagrama de secuencias, sino que lo colocari junto con la dimensidn vertical, de mod0 que su ubicacidn corresponda a1 momento en que se Cree. El mensaje que creari a1 objeto se nombrari Crear(). Los parkntesis implican una operaci6n: en un lenguaje orientado a objetos, una operacidn constructor genera un objeto.

En lugar de usar Crear() o Create() para etiquetar la flecha de un mensaje de creacion de un objeto, podria valerse de un estereotipo llamado ((Crear,,.

En el caso de mientras, a este control de flujo lo representari colocando la condicidn 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 us0 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 no he incluido toda la cornplejidad del caso de us0 Teclazo del ejernplo anterior. Los detalles de la interaccion de la GUI con el sisterna operativo, la CPU y el monitor no son importantes en este caso.

I114

Hora 9

FIGURA9.10
El diagrama de secuencias del caso de us0 "Crear una propuesta ".

E
[iocaiizado] abrir farchwo)

. ...
I.

;
I

_I

I .

, ,
'[trabajar]

?'
war aplicaciones
m

. , ' :
a .0

..

Iflnaiizado] cerrar y almacenar cerrar

'

cerrado

cerrado

Como representar la recursividad

En ocasiones un objeto cuenta con una operacidn que se invoca a si misma. A esto se le conoce como recursividud, y es una caracten'stica fundamental de varios lenguajes de programacidn.
'

He aqui un ejemplo. Suponga que uno de 10s objetos en su sistema sea una calculadora, y que una de sus operaciones sea el chlculo de intereses. Para calcular el inter& compuesto para un period0 que incluya a varios periodos, la operacidn del chlculo de intereses del objeto tendrh que invocarse a si misma varias veces. Para representar esto en el UML, dibujarh una flecha de mensaje fuera de la activacidn que signifique la operacidn, y un pequeiio recthngulo sobrepuesto en la activacidn. Dibuje una flecha de mod0 que apunte a1 pequeiio recthngulo, y una que regresa a1 objeto que inicid la recursividad. La figura 9.1 1 muestra lo anterior.

FIGURA9.1 1
Cdmo reuresentar la recursividad en un diagrama de secuencias.
InteresO

I:Calculladora I

I
I

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

E l o
lase tnterfaz

Estado

0
Caso de us0 Relaciones Asociacion

D -,

Generalizacion

- - - - - - - - + Dependencia
- - - - - - - - D Realizacion
Agrupacion

Secuencia

Extension Estereotipo (Restriccion) {valor etiquetado)

Paquete

17
Resumen
El diagrama de secuencias UML agrega la dimensidn 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 ejecucidn de una de las operaciones del objeto). Puede incorporar 10s estados de un objeto colocihdolos junto a su linea de vida.
Los mensajes (simples, sincrdnicos y asincrdnicos) son flechas que conectan a una linea de vida con otra. La ubicacidn del mensaje en la dimensidn vertical representari el momento en que sucede dentro de la secuencia. Los mensajes que ocurren primer0 esthn mis cerca de la parte superior del diagrama, y 10s que ocurren despuCs cerca de la parte inferior.

Anotacion

I116

Hora 9

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 lo mismo en un ciclo mientras per0 anteceda a1 corchete izquierdo con un asterisco. Cuando una secuencia incluya la creacidn de un objeto, lo representar6 como un recthngulo de la forma acostumbrada. Su posicidn en la dimensidn vertical representarhn el momento en que se cred. En ciertos sistemas, una operacidn puede invocarse a si misma. A esto se le conoce como recursividud. Se representa con una flecha que sale de la activacidn hacia si misma, y un pequeiio rectangulo sobrepuesto a la activacidn.

Preguntas y respuestas
P El diagrama de secuencias parece que podria ser util para miis que tan s610 el analisis de sistemas. iPuedo 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 indic6 la forma de representar la creaci6n de objetos en un diagrama de secuencias. iLos objetos tambih se destruyen, y si es asi, c6mo lo represento? R Los objetos, en efecto, se destruyen. Podr6 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 reafirmar su conocimiento de 10s diagramas de secuencias. Encontrarh las respuestas en el ApCndice A, Respuestas a 10s cuestionarios.

Cuestionario
1. Defina mensaje sincronico y mensaje asincrdnico.

2. En un diagrama de secuencias genCrico jc6mo representma el control de flujo implicito en una instrucci6n condicional? 3. iC6mo representma el control de flujo implicito en una instruccidn de ciclo mientras? 4. En un diagrama de secuencias jcdmo representaria a un objeto reciCn creado?

Diagramas de secuencias

117

Ejercicios
1. Cree un diagrama de secuencias de instancias que muestre lo que ocurre cuando envia con Cxito un fax. Esto es, modele las interactividades entre objetos en el mejor escenario del caso de us0 enviar fax de una miquina de fax. Incluya 10s objetos de la miquina 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 gentrico que incluya escenarios infructuosos (linea ocupada, error de la miquina que envia), asi como del mejor escenario indicado en el ejercicio 1.

*. a -

H ORA

10

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, per0 de una forma significativamente diferente del diagrama de secuencias. En esta hora se tratarh 10s siguientes temas:

QuC es un diagrama de colaboraciones C6mo aplicar un diagrama de colaboraciones Us0 de si y mientras Anidamiento Objetos activos y concurrencia Sincronizaci6n D6nde encajan 10s diagramas de colaboraciones en el UML

1120

Hora 10

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, jpor quC el UML requeriria otro diagrama?, LquC no son lo mismo?, jno es una pCrdida de tiempo? Ambos tipos de diagrama son similares. De hecho, son sema'nticarnente equivalentes. Esto significa que representan la misma informaci6n, y podri convertir un diagrama de secuencias en un diagrama de colaboraciones equivalente y viceversa. Como se infiere, es litil contar con ambas formas. Los diagramas de secuencias destacan la sucesi6n de las interacciones. Los diagramas de colaboraciones destacan el context0 y organizaci6n general de 10s objetos que interactlian. 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 extensi6n de uno de objetos. Ademis de las relaciones entre objetos, el diagrama de colaboraciones muestra 10s mensajes que se envian 10s objetos entre si. Por lo general, evitari la multiplicidad dado que podn'a ser fuente de confusi6n. Para representar un mensaje, dibujari una flecha cerca de la linea de asociaci6n entre dos objetos, esta flecha apunta a1 objeto receptor. El tip0 de mensaje se mostrari en una etiqueta cerca de la flecha; por lo general, el mensaje le indicari a1 objeto receptor que ejecute una de sus operaciones. El mensaje finalizari con un par de parCntesis, dentro de 10s cuales colocari 10s parimetros (en caso de haber alguno) con 10s que funcionari la operaci6n. MencionC que podri convertir cualquier diagrama de secuencias en diagrama de colaboraciones y viceversa. Por medio de esto podra representar la informaci6n de secuencia en un diagrama de colaboraciones. Para ello, agregari una cifra a la etiqueta de un mensaje, misma que corresponded 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 lo haga, veri mas conceptos.

Diagramas de colaboraciones

121 I

FIGURA 10.1
Simbologia del diagrama de colaboraciones.

,\

3:Actualizar()

:Nornbre3

I :NornbreZI
Z:Modificar()

La GUI
Este ejemplo es el caso mis directo. Un actor inicia la secuencia de interaccidn a1 oprimir una tecla, con lo que 10s mensajes ocurririn de manera secuencial. Tal secuencia (a partir de la hora anterior) es: 1. 2. 3. 4. 5. 6. La GUI notifica a1 sistema operativo que se oprimi6 una tecla. El sistema operativo le notifica a la CPU. El sistema operativo actualiza la GUI. La CPU notifica a la tarjeta de video. La tarjeta de video envia un mensaje a1 monitor. El monitor presenta el caricter alfanumkrico en la pantalla, con lo que se harA evidente a1 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 a1 usuario que inicia la secuencia, aunque esta figura no es parte de la simbologia de este diagrama.
FIGURA10.2
Un diagrama de colaboraciones para el ejemplo de la GUI.

9.
:Monitor Z:actualizar(tecleo) 5:rnostrar(tecleo)

I122

Hora 10

Cambios de estado
Puede mostrar 10s cambios de estado en un objeto en un diagrama de colaboraciones. En el rectingulo del objeto indique su estado. Agregue otro rectingulo a1 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 ccse toma>>. La figura 10.3 ilustra un cambio de estado para la GUI, que muestra que el estado de inicializacibn se convierte en el estado operativo.
FIGURA10.3
Un diugrumu de coluboruciones puede incorporur cumbios de estudo.
-

6:retroalirnentacion :Monitor
5: mostrar(tec1eo)

2:actualizar(tecleo)

La maquina de gaseosas
Las cosas se hacen mis interesantes cuando aplica las condiciones a una situaci6n real, como lo hizo en la hora anterior con la miquina de gaseosas. Iniciemos con la mejor situaci6n del caso de us0 Comprar gaseosa, donde la secuencia es:
1. El cliente inserta el dinero en la alcancia que se encuentra en la fachada de la miquina. 2. El cliente hace su elecci6n.

3. El dinero viaja hacia el registrador. 4. El registrador verifica si la gaseosa elegida esti en el dispensador. 5. Dado que es la mejor situacibn, 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 miquina.

El diagrama de colaboraciones es directo, como lo muestra la figura 10.4.

Diagramas de colaboraciones

123

FIGURA10.4
El diugramu de coluboraciones para el mejor cuso de Comprur gaseosa .

+
:Despachador

insertar(alimentacion, seleccion)

i :agregar(alimentacion, seleccion)

:Registrador Z:despachar(seleccion)

Ahora, agreguemos el caso de cantidad incorrecta de dinero. El diagrama tiene que contabilizar varias condiciones:
1. El usuario ha introducido mhs dinero que el necesario para la compra.

2. La mhquina cuenta con la cantidad adecuada de cambio. 3. La maquina no tiene la cantidad correcta de cambio.
Usted representarh las condiciones de la misma forma en que las represent6 en el diagrama de secuencias. Colocarh la condicidn entre corchetes, misma que se antecede a la etiqueta. Lo importante es coordinar las condiciones con la numeracibn. Esto podria ser algo complicado, por lo que haremos el diagrama por secciones. Empezaremos con la condici6n donde el usuario ha insertado mhs dinero del indicado en el precio y el registrador cuenta con el cambio adecuado. Agregara el paso de la mhquina a1 devolver el cambio a1 cliente, y agregarh las condiciones entre corchetes. El paso que devuelve el cambio es una consecuencia del que verifica si hay cambio. Para indicar esto en el paso de devolver cambio utilizarh el mismo numero del mensaje que verifica el cambio, y agregarh un punto decimal y un uno. A esto se le conoce como anidacidn. La figura 10.5 le muestra 10s detalles. iQuC ocurre cuando la mhquina no cuenta con el cambio correcto? Tendrh que mostrar un mensaje que lo indique, devuelva el dinero y pida a1 usuario que inserte el importe correcto. Asi, la transaccibn habrh finalizado. Cuando agregue esta condicibn, agregarh una bifurcacidn en el control de flujo. Numerarh esta bifurcacidn como un mensaje anidado. Dado que es el segundo mensaje anidado, habrh un 2 luego del punto decimal. Finalmente, y debido a que la transaccidn habrh finalizado, harh Clara esta situacibn mediante la adici6n de un estereotipo transacci6n finalizada en este mensaje, y otro en el mensaje que despacha la gaseosa. La figura 10.6 presentarh la situacidn.

I 124
FIGURA10.5
El diagrarna de colaboraciones con parte de la situacidn rnontode dinero inadecuado .

Hora 10

insertar(a1irnentacion.seleccion)

1 .agregar(alirnentacion, seleccion)

(alimentacion= precio] 2.1: despachar(selecci0n) [hay precio de entrada] 3.1: despachar(selecc1on)

[alirnentacion > precio] 2.2: veriilcar Cambio(alimentacion,precio)

FIGURA10.6
El diagrama de colaboraciones Cornprargaseosa con toda la situaci6n montode dinero inadecuado .

4:despachar

[alirnentacion= precio] 2.1: despachar(se1eccion) [hay precio de entradal3.1: despachar(selecci0n)

:Reqistrador [alirnentacion> precio] 2.2: verifica Cambio(alirnentacion,precio)

En el taller, a1 finalizar esta hora, habri un ejercicio que le pediri que complete el diagrama de colaboraciones mediante la adici6n de la situaci6n (no hay gaseosa.

Creacion de un objeto
Para mostrar la creaci6n de objetos, volverC a1 caso de uso Crear propuesta de la firma de consultoria. Una vez mis, la secuencia que modelari seri:
1. El consultor buscari en el irea de almacenamiento centralizada de la red una propuesta adecuada en la cual basarse. 2. Si el consultor localiza una propuesta adecuada, la abriri y en el proceso abriri la aplicaci6n de oficina. El consultor guardari el archivo bajo un nuevo nombre, con lo que creari un nuevo archivo para la nueva propuesta.

3. Si el consultor no encuentra una propuesta, abriri la aplicacidn de oficina y generari un nuevo archivo.

Diagramas de colaboraciones

125

4. A1 trabajar en la propuesta, el consultor utilizara 10s componentes de la aplicacidn de oficina. 5. Cuando el usuario finalice la propuesta, la guardarh en el Area de almacenamiento centralizada. Para mostrar la creacidn de un objeto, agregara un estereotipo crear a1 mensaje que genera a1 objeto. Una vez mas, utilizara instrucciones si (if) y mensaje anidados. TambiCn trabajarh con un ciclo mientras (while). Como en el diagrama de secuencias, para representar a mientras, colocar5 esta condici6n entre corchetes y antecedera a1 del lado izquierdo con un asterisco. La figura 10.7 le muestra este diagrama de colaboraciones completo con la creaci6n del objeto y mientras.
FIGURA 10.7 El diugruma de
colaboruciones Creur unu propuestu .

1:iniciarBusqueda() [encontrado] 4.1: abrir(archiv0) [no encontrado] 4.2: nuevo(archivo) [trabajo] 7: usarAplics() [completado] 10: cerrarYGuardar0

2: Buscar()

< -

:Deposit0

3: Resultado

5:abrirYGuardarCorno(propuesta)
8: usarAplics() 11 : cerrarYGuardar0
14: completado()

crear>> 6: crearArchivoO 9: rnodificaro 12: cerrar()

Algunos conceptos mas

Aunque ha visto algunas bases, no ha visto todo lo relacionado con 10s diagramas de colaboraciones. Los conceptos en esta secci6n son un poco esotkricos, per0 podrian serle fitiles en sus esfuerzos para analizar sistemas.

1126

Hora 10

Varios objetos receptores en una clase

En ocasiones un objeto envia un mensaje a diversos objetos de la misma clase. Por ejemplo: un profesor le pide a un grupo de estudiantes que entreguen una tarea. En el diagrama de colaboraciones, la representacibn de 10s diversos objetos es una pila de rectingulos que se extienden desde atris. Agregari una condicidn entre corchetes precedida por un asterisco para indicar que el mensaje iri a todos 10s objetos. La figura 10.8 le muestra 10s detalles.
FIGURA10.8
Un objeto que envia un mensaje a diversos objetos de una clase.

l
[todos] 1: atender(tarea)

B
:Estudiante
*[position en la fila = 1...n] l:atender()

En algunos casos, el orden del mensaje enviado es importante. Por ejemplo, un empleado bancario dara servicio a cada cliente conforme fue llegando a la fila. Esto lo representari con un mientras cuya condicibn implicari orden (como en posicibn en la fila = 1 ... n) junto con el mensaje y la pila de rectingulos (vea la figura 10.9).
FIGURA10.9
Un objeto que envia un mensaje a varios otros en un orden espec@co.

B I
:Cliente

Representacion de 10s resultados

Un mensaje podria ser una peticibn a un objeto para que realice un cilculo y devuelva un valor. Un objeto Cliente podria solicitar a un objeto Calculadora que calcule el precio total que sea la suma del precio de un elemento y el impuesto. El UML le da una sintaxis para representar esta situacidn. Deberi escribir una expresidn que tenga el nombre del valor devuelto a la izquierda, seguido de :=, a continuacidn el nombre de la operacidn y las cantidades con que opera para producir el resultado. En este ejemplo, la expresi6n podria ser precioTota1 := calcular(precioElemento,impuesto). La figura 10.10 le muestra la sintaxis de un diagrama de colaboraciones.

Diagramas de colaboraciones

127

FIGURA 10.10
Un diagrama de colaboraciones que incluye la sintaxis de un resultado.
1: precio total := calcular(precioElernento, irnpuestos)

A la parte que esta a la derecha de la expresion se le conoce como firma del mensaje.

Objetos activos
En algunas interacciones, un objeto especifico controla el flujo. Este objeto activo puede enviar mensajes a 10s objetos pasivos e interactuar con otros objetos activos. En una biblioteca, un bibliotecario relaciona las peticiones a partir de un patrdn, verifica la informacidn de referencia en una base de datos, devuelve una respuesta a1 peticionario, asigna personas para reabastecer 10s libros, entre otras cosas. Un bibliotecario tambiCn interactda con otros que realicen las mismas operaciones. A1 proceso de que dos o mis objetos activos hagan sus tareas a1 mismo tiempo, se le conoce como concurrencia. El diagrama de colaboraciones representa a un objeto activo de la misma manera que a cualquier otro objeto, except0 que su borde sera grueso y mis oscuro. (Vea la figura 10.11.)
FIGURA10.11
Un objeto activo controla el flujo en una secuencia. Se representa como un rectangulo con un

Si ncronizacion
Otro caso con el que se puede encontrar es que un objeto s610 puede enviar un mensaje despuCs de que otros mensajes han sido enviados. Es decir, el objeto debe sincronizar todos 10s mensajes en el orden debido.

I128

Hora 10

Un ejemplo aclarari esto. Suponga que sus objetos son personas en un corporativo, y que estin ocupados en la campaiia de un nuevo producto. He aqui la secuencia de interacciones:
1. El vicepresidente de comercializacidn le pide a1 de ventas que Cree una campaiia para un producto en particular. 2. El vicepresidente de ventas crea la campaiia y la asigna a1 gerente de ventas.

3. El gerente de ventas instruye a un agente de ventas para que venda el producto de acuerdo con la campaiia. 4. El agente de ventas hace llamadas para vender el producto a 10s clientes en potencia. 5. Luego de que el vicepresidente de ventas ha dado la comisi6n y el gerente de ventas ha expedido la directiva (esto es, cuando se han completado 10s pasos 2 y 3), un especialista en relaciones publicas de la corporaci6n hari una llamada a1 periddico local y colocari un anuncio de la carnpaiia. iC6mo representari la posicidn del paso cinco en la secuencia? Nuevamente, el UML le da una sintaxis. En lugar de anteceder este mensaje con una etiqueta numkrica, lo anteceder5 con una lista de mensajes que tendrin que completarse antes de que se realice el paso cinco. La lista de elementos se separarfi mediante una coma, y finalizari con una diagonal. La figura 10.12 le muestra el diagrama de colaboraciones en este ejemplo.
FIGURA10.12 La sincronizacidn
de mensajes en un diagrama de colaboraciones.
F r ( c a r n p a r i a , producto)

:Gerente ventas

3: vender(campaiia. producto)

Vendedor lientes asignados] 4 IlamadaVentas(carnpaia, producto) Ciiente

Adiciones al panorama
Ahora podrfi agregar el diagrama de colaboraciones a su panorama del UML. Es otro elemento de comportamiento, corno se aprecia en la figura 10.13.

Diagramas de colaboraciones

1291

FIGURA 10.13
El panorama del UML, que incluye a1 dianrama de colaboraciones.

Elementos estructurales Clase

lnterfaz

I I
Estado

Elementos de cornportarniento

0
Caso de us0 Relaciones Asociacion

:Nombrell
I

o n
I

I I

Generalizacion

- - - - - _ _+ _ Dependencia - - - - - - - - D Realizacion
Agrupacion Extension <<Estereotipo>> Paquete {Restriccion} (valor etiquetado)

@
Secuencia

I:Nombre2 I
Colaboracion

Anotacion

17
Resumen
Un diagrama de colaboraciones es otra forma de presentar la informacidn en un diagrama de secuencias. Ambos tipos de diagramas son semgnticamente equivalentes y se recomienda usar ambos cuando construya el modelo 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 asociacih, y una etiqueta numerada que muestra el contenido del mensaje. El numero representa el turno del mensaje en la secuencia. Las condicionales se representan como antes, mediante la colocacidn de la instruccih 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 tknicos que muestran sus encabezados y subtitulos: con un sistema de numeracidn que utiliza puntos decimales para representar 10s niveles del anidamiento.

1130

Hora 10

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

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. iC6mo representa a un mensaje en un diagrama de colaboraciones? 2. iC6mo mostrma informacidn secuencial en un diagrama de colaboraciones?

3. iC6mo mostrma 10s cambios de estado? 4. iQu6 se entiende por la equivalencia sem5ntica de dos tipos de diagramas?

Ejercicios
1. En el ejemplo de la miquina 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 genCfico de la hora 9 para el caso de us0 Comprar gaseosa. Esto es, agregue la situacidn Gaseosa agotada a1 diagrama de colaboraciones de la figura 10.5.

Diagramas de colaboraciones

131

2. En el diagrama de colaboraciones del caso de uso Crear propuesta, el consultor busca en el Brea 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 tkcnicas de modelado de la secci6n Algunos conceptos mBs para cambiar el diagrama de colaboraciones en la figura 10.6.