Aprendiendo Uml en 24 Horas

/ 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

Bradley L. Jones
EDITOR DE DIVISION COMPUTACION: OSCAR MADRIGAL MUNIZ
SUPERVISOR DE TRADUCCION: ANA MARfA MONTANEZ EDITOR DE ADQUISICIONES
SUPERVISOR DE PRODUCCION: LUZ ANGELICA GUTIERREZ ROJO Chris Webb
APRENDIENDO UML EN 24 HORAS EDITOR DE DESARROLLO

Matt Purcell
Versidn en espaiiol de la obra titulada SAMS Teach Yourself UML in 24 hours, de Joseph
EDITORA ADMINISTRATIVA
Schmuller, publicada originalmente en inglCs por SAMS Publishing, una divisidn de
Macmillan Computer Publishing, 201 W. 103rdStreet, Indianapolis, Indiana, 46290, EUA. Jodi Jensen
EDITORA EJECUTIVA
Esta edicidn en espaiiol es la hnica autorizada.
Susan Ross Moore
Authorized translation from the English language edition published by Macmillan Computer CORRECTORES DE ESTILO
Publishing Mike Henry
Copyright 0 1999 Mary Lagu
Rhoda Tinch-Mize
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 INDIZADORA
storage retrieval system, without permission from the Publisher. Sandra Henselmeier
Primera edici6n CORRECTORES DE PRUEBAS

Ben Berg
D.R. 0 2000 por Pearson Educacih de MCxico, S.A. de C.V. Mona Brown
Calle 4 No. 25-2do. Piso
Fracc. Industrial Alce Blanco
REVISORES
T~CNICOS
53370 Naucalpan de Jufirez, Edo. de MCxico Bill Rowe

Michael Tobler
C h a r a Nacional de la Industria Editorial Mexicana Registro No. 1031
ESPECIALISTAEN DESARROLLO
DEL SOFTWARE
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 Dan Scherf
por ningun medio, sea electrdnico, mecinico, fotoquimico, magnCtico o electro6ptico, por foto- DISENO DE PAGINAS INTERIORES
copia, grabacidn o cualquier otro, sin permiso previo por escrito del editor.
Gary Adair
El prCstamo, alquiler o cualquier otra forma de cesi6n de us0 de este ejemplar requeriri tam- DISENADOR DE PORTADA
biCn la autorizacidn del editor o de sus representantes. Aren Howell
ISBN: 968-444-463-X de la versidn en espaiiol REDACTOR
ISBN: 0-672-31636-6 de la version en inglCs Eric Borgert
DISENADOREST~CNICOS
Impreso en Mtxico. Printed in Mexico
1 2 3 4 5 6 7 8 9 0 03 02 01 00 Brandon Allen
Stacey DeRome
Tim Osbom
Staci Somers
Resumen de contenido
Introduccidn i
PARTE I PARA INlClAR 3

Hora 1 Introduccidn a1 UML 5
2 Orientacidn a objetos 19
3 Us0 de la orientacidn a objetos 33
4 Us0 de relaciones 45
5 Agregacidn, composicidn, interfaces
y realizacidn 57
6 Introduccidn a 10s casos de us0 67
7 Diagramas de casos de us0 75
8 Diagramas de estados 91
9 Diagramas de secuencias 103
10 Diagramas de colaboraciones 119
11 Diagramas de actividades 133
12 Diagramas de componentes 149
13 Diagramas de distribucidn 163
14 Nociones de 10s fundamentos del UML 173
15 Adaptaci6n del UML en un proceso de desarrollo 187
PARTE11 ESTUDIO DE UN CASO 203

Hora 16 Presentacidn del caso por estudiar 205
17 Elaboracidn de un anilisis de dominio 223
18 Recopilacidn de las necesidades del sistema 247
19 Desarrollo de 10s casos de us0 267
20 Orientacidn a las interacciones y cambios de estado 28 1
21 Diseiio del aspecto, sensacidn y distribucidn 293
22 Nocidn de 10s patrones de diseiio 309
PARTE 111 VISION DEL FUTURO 321
Hora 23 Modelado de sistemas incrustados 323
24 El futuro del UML 341
PARTE IV APENDICES 355

ApCndice A Respuestas a 10s cuestionarios 357
ApCndice B Herramientas de modelado para el UML 369
ApCndice C Un resumen grlfico 377
hdice 387
Contenido
INTRODUCCI~N 1
PARTE I PARA INICIAR 3

HORA 1 INTRODUCC16N A1 UML 5
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
.....................................................
............................................................. 11
Diagrama de actividades .................................................
Diagrama de colaboraciones .........
Diagrama de componentes .............
Diagrama de distribucih ................................................................................ 14
Otras caracten'sticas ................................................................ 14
Paquetes .......................................................................................................... 14
Notas .................................................................................
Para quC tantos diagramas .......................................

Resumen ..................................................
Preguntas y respuestas ............................
Taller ................................................................................................................... .17
Cuestionario ..................... 17
Ejercicios ........................................................................................................ 17
HORA 2 ORIENTAC16N A OBJETOS 19

Objetos, objetos por doquier .................... ......... .20
Algunos conceptos ............................................................................................... .22
Abstracci6n ..................... ........22
Herencia .......................................................................................................... 23
Polimorfkmo
Envfo de mensajes
Asociaciones ................................................................................................... .26
Agregaci6n ..... .......................... 28
La recompensa ..................................................................................................... .30
Aprendiendo UML en 24 horas
1 vi
Resumen .................. ....................... 30

Preguntas y respuestas .......................................................................................... 31
Taller .....................................
.............................................................................................. 31
Ejercicios ....................................... .......32
HORA 3 US0 DE LA ORlENTACldN A OBJETOS 33
Concepcidn de una clase ...................................................................................... 33
Atributos ................................
Operaciones ......................................................................................................... .36
Atributos, operaciones y concepci6n ...
Responsabilidades y restriccio
Notas adjuntas .......................................
QuC es lo que hacen las clases y c6mo encontrarlas ............................................ 40
Resumen ................................................
Preguntas y respuestas ........................................................................................ 43
Taller .....................................................
Ejercicios ........................................
HORA 4 US0 DE RELACIONES 45
Asociaciones .............................................................................. .46
Restricciones en las asociaciones ... .......41
Clases de asociacidn ...................................................................................... ..48
Vinculos ......................................... ........ .......48
Multiplicidad ....................................................................................................... .49
Resumen ...........................................................................................
Taller ...............................................................................................
Cuestionarios
HORA 5 AGREGACl6N. COMPOSlCl6N, INTERFACES Y REALlZACl6N 57

Agregaciones .... ............................................................................... 58
Restricciones en las agregaciones ................. 59
................................................................ 59
Contextos ......................................................................................... 59
Contenido vii 1
Interfaces y realizaciones ...................................................................................... 61

Visibilidad ...............
Ambito ...................
Resumen ..... .....
Preguntas y respuestas ......................................................... ................................. 64
.64
Cuestionario .................................................................................................... 64
........................ .64
HORA6 lNTRODUCC16N A LOS CASOS DE U S 0 67

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
Preguntas y respuestas . .............................................74
Taller ............................................................................................... ..................... 74
......................................................................74
.............................................74
HORA7 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 .86
Extensi6n ....... .87
.............................................................................. .87
El Panorama .......... .87
Resumen .............................................................................................................. ..88
Preguntas y respuestas .................. .........
................................................................................................ 89
Cuestionario ...........................................................................
................................................
HORA 8 DIAGRAMAS
DE ESTADOS 91
QuC es un diagrama de estados .... .........................................
Simbologia ..................................................................................................... .92
Adici6n de detalles a1 icono de estado ......................
Sucesos y acciones ....................................................
Condiciones de seguridad ................................................................................ 95
................................................ .96
Subestados concurrentes ................................................ .96

................................................ .97
Mensajes y seiiales .. ................................ 98
Por quC son importantes 10s diagramas de estados .............................................. 99
Adiciones al panorama
Preguntas y respuestas ....................... 101
Cuestionarios .
Ejercicios ...................................................................................................... 102
HORA 9 DIAGRAMAS
DE SECUENCIAS 103
QuC es un diagrama de secuencias ....................................
Objetos .............. ....................................................................... 104
Mensaje ...................................................................................
Tiempo ............................................................................................... 105
La GUI .........................................................................................
La secuencia .................... ....................................................................... 106
El diagrama de secuencias .....................................................
El caso de us0 ................ .............................................
Instancias y genCricos ........................................................................................ 108
Un diagrama de secuencias de instancias ............................................... 108
Un diagrama de secuencias genCrico ........ ............................................... 109
Creaci6n de un objeto en la secuencia 112
C6mo representar la recursividad ...................................................................... 114
Contenido IX
Adiciones a1 panorama ............................ ................................................ 1 15

Resumen ... ............................................................. 1 I5
Preguntas y respuestas ............................... ............................ 116
Taller .. ............................................................. 116
Cuestionario ............................................ ........................... 116
Ejercicios .... ............................................................. 117
HORA 10 DIAGRAMAS
DE COLABORACIONES 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
Algunos conceptos mis . ........................................................... 125
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 .............. ................................................................ I35
Indicaciones ...........................................................................
Aplicaci6n de 10s diagramas de actividades .......................
Una operaci6n: Fibs ..............................................................
Proceso de creaci6n de un documento ....................................... 138
Marcos de responsabilidad ........................................................
Diagramas hibridos ................ ........................................................ 142
Adiciones a1 panorama ............................................................
Resumen ............................................. ................................................... 145
Preguntas y respuestas ........................................................
Taller ................................................... ............................................... 146
Cuestionario ........................................................ 146
Ejercicios ........................................ .................................. 147
X Aprendiendo UML en 24 horas
HORA12 DIAGRAMAS
DE COMPONENTES 149
QuC es un componente ...................... ........................................................... 150
Componentes e interfaces .................................................... .I50
Sustitucidn y reutilizacidn ........................................................................... .15 1
Tipos de componentes ................................................
QuC es un diagrama de componentes .......................................................... 152
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 ............
.................................................................... 157
norama ............
....................................................................... 159
Preguntas y respuestas ................................................
Taller ........................ ..................................................................... 160
Cuestionario ....................................................... ......................... 160
Ejercicios ........... ........................................................................ 160
HORA 13 DIAGRAMAS DE DlSTRlBUCl6N 163

QuC es un diagrama de distribucidn ........... ............................. 164
Aplicacidn de 10s diagramas de distribucidn
Un equipo domCstico ..................................... ...................................... 166
Una red token-ring . .................................................................... 166
........................... 167
..........................................................
Red inalhbrica Ricochet de Metricom .................................... 169
Los diagramas de distribucidn en el
Resumen ........................................................ ........................... 171
..........................................................
Taller .............................................. ....................................... 172
.............................................................
............................................. 172
HOW DE LOS FUNDAMENTOS DEL UML

14 NOCIONES 173
Estructura del UML ...............................................
Capa del metamodel ........................................... 175
El paquete de Fundamentos ...............................................
El paquete de 10s elementos de comportamiento ...............
Administracidn de modelos .................................................
Extensidn del UML ...................... ....................................... 179
I Contenido
Estereotipos ........................................................................................................ 179

..............................................................................
180
..............................................................
180
............ 181
.
Generalizacion ............................................................................................. .18 1
.I
Componente .................................................................................................. 182

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

Taller .............................. 185
Cuestionario .................................................................................................. 185
HORA 15 ADAPTACldN DEL UML EN UN PROCESO DE DESARROLLO 187

Metodologias: antiguas y recientes ..................... 188
El mCtodo antiguo ........................................................................................ 188
El mttodo reciente ..........................
Lo que debe hacer un proceso de desarrollo ...................................................... 190
GRAPPLE ............................................
RAD3: la estructura de GRAPPLE ..
Recopilaci6n de necesidades .......................
Analisis .......................................................................................................... 195
Diseiio ............................................. 197
Desarrollo ...................................................................................................... 198
Distribuci6n ................................................ ................. 199
Resumen de GRAPPLE ....................... ...................................... 199
Resumen ................................................................................ 200
Taller .................................................................................. 20 1
Cuestionario .................................................................................................. 201
PARTE II ESTUDIODE UN CASO

HORA 16 PRESENTACldN DEL CASO POR ESTUDIAR 205
I
Aplicaci6n de GRAPPLE a1 problema ................................ 206

Descubrir 10s procesos del negocio .................................................................... 206
Servir a un cliente .............................................
Preparaci6n de platillos ...................................
Limpieza de la mesa ................................................................
Lecciones aprendidas ..............
1 xii Aprendiendo UML en 24 horas
Resumen. .............................................................. 220

Preguntas y respuestas ................................ ......................................... 221
Taller .......... ..................................................................... 22 1
Cuestionario .................................. ........................................... 221
Ejercicios .......................................................................... .222
HORA 17 ELABORACldN DE UN ANALISIS DE DOMlNlO 223

Anilisis de la entrevista del proceso del negocio .............................................. 224
Desarrollo del diagrama de clases inicial .......................... 225
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 ........................................................ .................................. 245
HORA 18 RECOPlLACldN DE LAS NECESIDADES DEL SISTEMA 247

Desarrollo de la idea .... .....................................................
Preparaci6n para la reco
La sesi6n JAD de necesidades ............................................................... 258
El resultado ...................................................... .............................. 261
LAhora quC? ....................... .............................................................
Resumen ............................................................... ................................ 264
Preguntas y respuestas ........ ....................................................
Taller .......................................................................... ............................. 265
....................................................
Ejercicio .......................................................... ................................. ,265
Contenido xiii I
HORA 19 DESARROLLO
DE LOS CASOS DE us0 267
Cuidado y provisidn de 10s casos de us0 .................... ............................ 268
El analisis de 10s casos de us0 ...........................
El paquete Mesero .................................................. ........................... ,269
Tomar una orden ...............................
Transmitir la orden a la cocina ................... ............................ 271
Cambiar una orden . .........................................
Sondeo del progreso ............................ 273
Notificar a1 chef del progreso de 10s clientes en sus alimentos .................... 273
Totalizar una cuenta ..................... ........................... .275
Imprimir una Cuenta ................... ................................................... 275
Llamar a un Asistente ................... .................................................. ,276
Casos de us0 restantes .................
Componentes del sistema .................
Resumen ............................................................................................................. .278
Preguntas y respuestas .................... ............................ 278
Taller .................................................................................................................. 279
........ ......... ........... 279
...................................................................................... ,279
HORA 20 ORlENTACldN A LAS INTERACCIONES Y CAMBIOS DE ESTADO 281
Las partes funcionales del sistema ................
El paquete Mesero ........................................................................................ 282
.................
............................ 283
El paquete Asistente Mesero
El paquete Asistente Chef ............................................................................ 283
El paquete Cantinero .......... 284
El paquete Encargado Del Guardarropa ........................................................ 284
Colaboracidn en el sistema
Tomar una orden .....
Cambiar una orden .
Sondeo del progreso .................................................................. 289
Implicaciones ...............
Resumen ............................................................................................................. .29 1
Preguntas y respuestas .
Taller ................................................................................................................. .292
Cuestionario ...........
. .
Ejercicios ..................................................................................................... ,292
I xiv Aprendiendo UML en 24 horas
HORA 21 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
Diagramas UML para el diseiio de la GUI ...299
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 ..................
HORA22 N O C I ~DE
N LOS PATRONES DE DISENO 309
Parametrizacih ......... .................................................................................... 310
Patrones de diseiio .................................... ................ ...... 312
Cadena de responsabilidad ................................................................................ 313
Cadena de responsabilidad: dominio Restaurante .......... ...314
Cadena de responsabilidad: Modelos de eventos de 10s exploradores Web 3 15
Nuestros propios patrones de diseiio ........
Ventajas de 10s patrones de diseiio .................................................................... 319
Resumen ....................................................
Preguntas y respuestas ..............................
Taller ...........................................................
Cuestionario .................................................................................... 320
Ejercicios ...................................................................................................... 320
PARTE 111 VISION DEL FUTURO 321

HORA 23 MODEIADO DE SISTEMAS INCRUSTADOS 323
.......................................................... 324
......................................................... .325
iQuC es un sistema incrustado? ....
.......................................................... 328
Subprocesos .................................................................................................. 328

Intermpciones ............. ...329
Sistema operativo .......................................................................................... 330
Contenido xv
Modelado de TecnoApreth ........ ................................

Clases ............................................................................................................ 332
Casos de us0 ............................
Interacciones .................................................................................................. 335
Cambios de estado generales ..................
Distribucidn ............................................
Flexiones en sus mfisculos ............................
....................................................................................... 339
Preguntas y respuestas ................................... ..339
........................................................................................ 340
....................................................... ,340
....................................................................................... 340
HORA 24 EL FUTURO DEL UML 341
Extensiones para 10s negocios ........................................ ........ ,342
Lecciones de las extensiones de negocios .......................................................... 343
Interfaces grhficas de usuario ........................................
Conexiones a casos de us0 ..................................................... .344
Modelado de la GUI ..................................................
Sistemas expertos ..................................................................... .346
Componentes de un sistema experto .........................................
..................................................... ,348
ientos ...........................
Eso es todo, amigos ....... ...................................................................... 352
Resumen ...................................................................................................
Preguntas y respuestas ...... .......................................................... 353
Taller .................................................................................................................. 353
Cuestionario ......... ....................................................................... 353
PARTE IV APENDICES 355

AP~NDICE
A RESPUESTAS
A LOS CUESTIONARIOS 357
B HERRAMIENTAS
AP~NDICE DE MODELADO PARA EL UML 369
Rational Rose . ............................................................................ 370

1 xvi Aprendiendo UML en 24 horas
AP~NDICE
C UN RESUMEN GRAFICO 377
Diagrama de actividades ................................. ........................... 378
Diagrama de clases ..... .................................................. 380
Diagrama de colaboraciones ........................... ............................... 382
Diagrama de component ......................................................... 382
Diagrama de distribuci6n ............................. ...................................... 383
Diagrama de secuencias .......................................................
Diagrama de estados .......................... ................................................ 384
Diagrama de casos de us0 .............................................................
~NDICE 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 experien-
cia 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 des-
gracia 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 vecinda-
rio 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
Pearson Educacion Latinoamerica
El personal de Pearson Educacidn LatinoamCrica esth cornprometido en presentarle lo
I 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 tele-
fdnico 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.
1
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 diagra-
mas. Cada diagrama tiene fines distintos dentro del proceso de desarrollo.
El objetivo de este libro es darle, en 24 horas de estudio, las bases sobre el UML. Cada
hora le presentara ejemplos para mejorar la comprensidn e incluiri ejercicios que le per-
mitiran 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 diagra-
macidn 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 dia-
gramas 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 diagra-
mas 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
I Modeler, un subconjunto de Rational Rose. No obstante, en este libro todo lo que necesi-
tarti sera un lapiz y papel para dibujar 10s diagramas y una sana curiosidad respecto a1
estado actual del diseiio de sistemas.
iIniciemos !
t
Aprendiendo UML en 24 horas
12
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 esen-

ciales. El vocablo, en si, aparecera en cursiva.
PARTEI
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 sis-
temas 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 programa-
dores 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, engorro-
sos y dificiles de utilizar?
Por que es necesario el UML

En 10s principios de la computacidn, 10s programadores no realizaban anilisis muy pro-
fundos sobre el problema por resolver. Si acaso, garabateaban algo en una servilleta.
Con frecuencia comenzaban a escribir el programa desde el principio, y el c6digo nece-
sario 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 compren-
der 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 resul-
tad0 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 pre-
dominaron 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 reac-
ciones resultantes trajeron consigo considerables modificaciones. Conforme diversos cor-
porativos 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 consi-
deraci6n 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 confor-
mar 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 conju-
gacion 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 edi-
ficio. 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 diagra-
mas con mayor detenimiento. Recuerde que es posible generar hibridos de estos dia-
gramas y que el UML otorga formas de organizarlos y extenderlos.
Diagrama de clases
Piense en las cosas que le rodean (una idea demasiado amplia, 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 cate-
gorias (autom6viles, mobiliario, lavadoras ...). A tales categorias las llamare-
mos 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 atribu-
tos 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 rnarca
de una clase. 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 interac-
tuar 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 especifi-
cos 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 sim-
bolo 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 reque-
rimientos del sistema desde el punto de vista del usuario. Esto es importante si la finali-
dad es crear un sistema que pueda ser utilizado por la gente en general (no s610 por
expertos en computaci6n).
Posteriormente trataremos este tema con mayor detalle; por ahora, le mostrark un ejem-
plo 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.
K-
Usuario de la lavadora
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 reali-
dad. 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 1
FIGURA 1.4 t
Diagrarna de estados
UML.
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 com-
plet6 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. La manguera dejari de abastecer agua.
4. El tambor girari de un lado a otro durante quince minutos.
5. El agua jabonosa saldrh por el drenaje.
6. Comenzarh nuevamente el abastecimiento de agua.
7. 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 (re-
presentados como rectingulos en la parte superior del diagrama). En este diagrama el
tiempo se da de arriba hacia abajo.
FIGURA1.5 Drenaje
Diagrama de
secuencias UML.
- 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
Girar el tambor de un lado a otro 15 rninutos
Diagrama de
actividades UML. I.
Vaciar el agua jabonosa 3
Reiniciar el abastecimientode agua
Diagrama de colaboraciones
Los elementos de un sistema trabajan en conjunto para cumplir con 10s objetivos del sis-
tema, 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
Cronometro interno
Diagrama de
colaboraciones UML.
2: Girar de un lado a otm Manguera de agua
r -T
Diagrama de componentes
Este diagrama y el siguiente dejarfin el mundo de las lavadoras, dado que estin intima-
mente ligados con 10s sistemas informfiticos.
El modern0 desarrollo de software se realiza mediante componentes, lo que es particular-
mente 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 Componente

Diagrama de
componentes UML. GI I
I '4 Hora 1
Diagrama de distribucion
El diagrama de distribuci6n UML muestra la arquitectura fisica de un sistema infor-
mhtico. 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
"Procesador"
Diagrarna de
Pequefio servidor Qube 2700WG
distribucidn UML. de Cobalt Networks
Vectra VL Serie 7 Dell Dimension XPS R450
Otras caracteristicas
Anteriormente, mencionC que el UML proporciona caracten'sticas que le permiten orga-
nizar y extender 10s diagramas.
Paquetes
En algunas ocasiones se encontrari con la necesidad de organizar 10s elemen-
tos 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.I0 1
El paquete UML le Paquete 1
permite agrupar 10s
elementos de un
diagrama. 0Clase 1
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 adhe-
sivo. 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 respecto a la Clase 1
I I
diagrama, podra
0
agregar comentarios
aclaratorios mediante
Clase 1
una nota.
Estereotipos
El UML otorga varios elementos de utilidad, pero no es un conjunto minu-
cioso 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 completa-
mente 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 correcta-
mente.
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
n
pemzite crear nuevos
elementos a partir de
otros existentes. U
116 Hora 1
Para que tantos diagramas

Como puede ver, 10s diagramas del UML le penniten examinar un sistema desde distin-
tos 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 dia-
grama 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?
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 desa-
rrollo). 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 oca-
siones, el cliente dicta esto; en otras, el cliente desea una recomendacibn del
equipo de desarrollo. Ciertamente, un arquitecto de sistemas encontrari dtil a1 dia-
grama 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, mues-
tran 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 formulm’a
a un usuario potencial y por quC las hm’a.
3RA 2
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.
EIn 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 ven-
ta.jas. 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 obje-

tos, 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 sus-
tancialmente 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 princi-
pios 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 seg-
mento de Cl), y 10s programas, por lo general, imitan a 10s objetos del mundo. Si com-
prende 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 incorpo-
rkamos 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 alegm’an que esto es lo mismo
que la categorizacibn, pero evitemos dicho debate).
Orientacion a objetos 21 I
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 pala-
bras 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 orien-
taci6n a objetos si sabe que las clases en 10s programas orientados a objetos pueden
crear nuevas instancias.
FIGURA2.1 Lavadora
La clase Lavadora
marca
(modelo original) modelo
es una plantilla numeroserie
para generar capacidad
nuevas instancias
agregarRopa0
de Lavadoras. 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 Lavadora
La adicidn de
rnarca
atributos y acciones rnodelo
a1 modelo lo acerca numeroserie
a la realidad. 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.
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 pro-
viene. 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 Electrodo-
mestico 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 microon-
das 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 Electrodomestico
heredan 10s atributos
y acciones de la clase
Electrodomestico.
Cada electrodomkstico
es una subclase de
la clase Electro-
domestico. La clase
Electrodomestico es
una superclase de
cada subclase.
I24 Hora 2
La herencia no tiene por quC terminar aqui. Por ejemplo, Electrodomestico es una sub-
clase 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 Articulos del hogar
tambih pueden ser
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 polimor-
fismo (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 desarrolla-
dores 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
tener mhs de un significado. El polimorfismo permite a1 modelador mantener tal terrni-

nologia 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 ahorra-
rian 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 gene-
ral, la mayoria de la gente que ve la televisi6n no sabe o no se preocupa de la compleji-
dad 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 electrodomCs-
ticos funcionan asi.
FIGIJRA 2.6
La television oculta
LO5 objetos encapsu- sus operaekmes
lan ,lo que hacen; es de la persona
que la ve.
deci < ocultan la fun-
cionialidad interna de
sus ,operaciones,
de oitros obietos
Y de
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 encapsula-
miento 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 pre-
senta (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 tele-
visidn, ella no le devolver6 el favor. Hay otras asociaciones que son en dos direcciones,
como “casamiento”.
Orientacidn a objetos 27 1
FIG^IRA 2.7
Ejennplo de un mensaje
enviado de un objeto
a ot ro: el objeto
“COIttrol remoto ”
envia un mensaje a1
objc’to “televisidn”
p a nz encenderse.
El olbjeto “televisidn”
recibe el mensaje
mea!ante su interfaz,
un raceptor infrarrojo.
FIGURA 2.8
Corzfrecuencia 10s
a
obj,etos se relacionan
ent,re sf de alguna
fonna. Cuando usted Encender
P
enc,iende su televisidn,
ten,drd una asociacidn
en una sola direccidn
cori ella.
En ocasiones, un objeto podn’a 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.
FICium 2.9
En ocasiones, 10s
ob,ietos pueden
as1xiarse en ma’s
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 asociacio-

nes 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.
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 extremada-
mente comunes, y ello ayuda a que Cree modelos que se asemejen considerablemente
a la realidad.
I 30 Hora 2
FIGURA2.12
En una composicidn,
un componente puede
morir antes que el
objeto compuesto.
Si destruye a1 objeto
compuesto, destruira'
tambiin a 10s
componentes.
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 ayu-
darle 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 fundamen-
tales. 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.
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.
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 orien-
tadas 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. iQu6 es un objeto?
2. iC6mo trabajan 10s objetos en conjunto?
3. iQuC establece la multiplicidad?
4. 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 3
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 pa-
labra 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 l----l
La representacidn
U M L de una clase.
I Lavadoralndustrial
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.
Electrodornesticos
Si la clase “Lavadora” es parte de un paquete llamado “Electrodomesticos”, po-

dri 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 dia-
grarnas que se presentan a lo largo de este libro, de igual rnanera, evitare-
rnos 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.
At ributos
i__l Electrodornesticos::Lavadora
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 Lavadora

Una clase y sus
marca
atributos. modelo
I numeroserie
capacidad
Todo objeto de la clase tiene un valor especifico en cada atributo. La figura 3.5 le mues-
tra 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 miLavadora:Lavadora

Un objeto cuenta con
marca = "Laundatorium"
un valor especljCco modelo = "Washrneister"
en cada uno de 10s numeroserie = "GL57774"
atributos que lo capacidad = 16
cornponen.
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 boolea-
no (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 prede-
terminado 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
FIGURA3.6 Lavadora I
Un atributo puede
rnarca: string = "Laundatoriurn"
mostrar su tipo modelo: string
asi como su valor nurneroserie: string
predeterminado. 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 excep-
tuando 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 Lavadora
La lista de opera-
rnarca
ciones de una clase rnodelo
aparece debajo de nurneroserie
una linea que las capacidad
separa de 10s atributos
de la clase. agregarRopa()
sacarRopa()
agregarDetergente0
activar()
Asi como es posible establecer informaci6n adicional de 10s atributos, tam-

biCn lo es en lo concerniente a las operaciones. En 10s parkntesis que prece-
den 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 II Lavadora

Lafirma de una
rnarca
operacidn. rnodelo
nurneroserie
capacidad
I
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 sus-
pensivos. 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 suspen-
sivos indican atributos
I
...
Lavadora
rnarca
u operaciones que
no se encuentran en
I
todo el conjunto.
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 sub-
conjunto de atributos, como en la figura 3.1 1.
FIGURA3.1 1 Lavadora
Podrd usar un 4nfo identificacion.
estereotipo para marca
modelo
organizur una lista
numeroserie
de atributos u .info maquinan
operaciones. capacidad
agregarRopa0
sacarRopa()
agregarDetergente0
<<relacionadocon
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 Lavadora
En un sirnbolo de 4nfo identificacion,,
clase, que ira debajo marca
de la lista de opera- modelo
numeroserie
ciones, escribira las 4nfo maquina,,
responsabilidades de capacidad
I
la clase. -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 restriccio’n, 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 Lava-
dora. La figura 3.13 le muestra c6mo hacerlo.
FIGURA3.13
La regla entre llaves
rnarca
restringe a1 atributo modelo
capacidad para numeroserie
contener uno de tres (capacidad = 7, 8 o 9 Kg)
posibles valores.
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 avan-
zada 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 ma-
nera en que se generan 10s ndmeros de serie para 10s objetos de la clase Lavadora.
FIGURA 3.14
Una nota adjunta
rnarca
proporciona mayor
4
rnodelo
informacidn respecto nurneroserie --------- Vease la norrna
gubernarnental EV5-2241
a la clase. capacidad
de 10s Estados Unidos
para la generacion
agregarRopa0 de nurneros de serie
sacarRopa()
agregarDetergente0
activar()
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 ha-
ble 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 4’ I
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 intema-
cional, 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: ‘‘~QuChay 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 atribu-
tos 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 Balon
Un diagrama inicial
1
estatura
para modelar el juego
de baloncesto. driblarBalon()
pasarBalon() la mayor
tirarBalon() parte del
avanzar() rebotaro drible y pase
infraccionarODonente0
w +m u
Delantero
realiza
Centro
I
lnfraccion
perrnanece
la mayor parte cerca del cesto, DeTresPuntos
de 10s tiros tirade una
de media distancia distancia cercana
(profesional = 24 segs.
colegial = 35 segs.
internacional = 30 segs.)
U TiroLibre
E l
CronometroDeJuego
(profesional= 4 cuartos
de 12 mins. colegial e
internacional = 2 mitades
de 20 mins.)
I Linea
DeTiroLibre
I
I I I I
Duracion (profesional = 48 mins. Cancha
colegial e internacional =
40 mins.)
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 atri-
butos 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.
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 rela-
cionada tenga a la mano. Pregunte a sus entrevistados respecto a documentos o
manuales que hayan escrito. Cuando haya terminado de leer, tendri cierto conoci-
miento 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 desarrolla-
dores 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. iC6mo representa una clase en el UML?
2. iQut informacidn puede mostrar en un simbolo de clase?
3. iQuC es una restriccibn?
4. 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 informa-
ci6n 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 4
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 confor-
man 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 re-
presentacibn.
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 aso-
ciaci6n (“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 aso-
ciacidn. 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
lJugadorl Participa en,
Por lo general, en una Empleado Empleador
asociacion cada clase
juega un papel. Puede
representar tales pape-
les en el diagrarna.
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 Jugador Participa en b Equipo
Pueden aparecer dos 4 Emplea

r
asociaciones entre U
clases en el mismo
diagrama.
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 discon-
tinua 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 Estudiante de educacion I
Elige b I Academic0 I
dos asociaciones en
una restriccidn.
media superior
I&
I Elige b 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 usociacio’n.
Puede concebir a una clase de asociacidn de la misma forma en que lo hm’a 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 mues-
tra 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 me-
diante una linea dis-
continua, 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 Participa en b
un,,inculo es la
instan- gustavo naiera :Jugador nacional : Equipo
cia de una asociacidn.

Conecta a 10s objetos
en lugar de las clases.
Debera subrayar el
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 repre-
sentar 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
iJugador 5 Participa en,
relacionarse con un
objeto de una clase
asociada.
La multiplicidad de este ejemplo no es la iinica que existe. Hay varios tipos de multipli-
cidades (una multiplicidad de multiplicidades, por decirlo asi). Una clase puede rela-
cionarse 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 ma‘s y para repre-
sentar 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 1 Esposa
1 Esta casado con b
Posibles multiplici- uno a uno
dudes y cdmo repre-
Casa 1 Tiene b 0 , ~Chimenea

uno a ninguno o uno
Itiempo 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 pre-
senta un reto muy particular: la bdsqueda. Cuando un objeto de una clase tiene que selec-
cionar 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 ade-
cuado. 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 reser-
vacidn, deberi proporcionar el ndmero de confirmacidn.
En el UML la informacidn de identidad se conoce como cal$cador. Su sim-
bolo 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.
FIGURA4.11 Recepcionista 1 Localizab * Reservacion

Nurnero de confirrnacion
Un calcficador en una
asociacidn resuelve el
problema de la
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 Conduce
incluir 10s papeles, v
nombre de la asocia-
cidn y su direccidn, asi
como su multiplicidad.
Herencia y generalizacion
Uno de 10s sellos distintivos de la orientacidn a objetos es que captura uno de 10s ma-
yores 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 cate-
gorias. Si usted sabe que algo es un electrodomkstico, ya sabra que contar5 con un in-
tenuptor, 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 secun-
darias 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 triingu-
los, 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
T
Animal
Una jerarquia de
herencia en el reino
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 for-
mas. 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 agre-
garin 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 colo-
car 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 con-
trola 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.
i
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 Jugador
Dos jerarquias de nombre
herencia con clases tamaiio
abstractas en el velocidadAlCorrer
modelo de baloncesto. saltovertical
correrAlFrente0
quitarBalon()
CronometroDelJuego LapsoDeTiro
Dependencias
__
En otro tipo de relacibn, una clase utiliza a otra. A esto se llama LLpenden-
cia. 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 formula-
rio 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 triin-
gulo sin relleno que apunta a la clase de la que depende, como muestra la figura 4.15.
FIGURA4.15
Unaflecha represen-
tada por una linea
discontinua con una
punta de flecha en
U
forma de tria’ngulo sin
relleno simboliza una
dependencia.
Resumen
Sin las relaciones, un modelo de clases seria poco menos que una lista de cosas que repre-
sentm’an 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 secun-
daria 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 secun-
daria, 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.
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 balon-
cesto, 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 5
Agregacion,
cornposicion,
interfaces
y realizacion
Continuaremos con las relaciones entre clases y comprenderA nuevos con-
ceptos 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
. * 0
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 repre- '?
senta por una linea
entre el componente y
el todo con un rombo
sin relleno que con- I I
forma 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 1
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, utilizm’a 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 agre-
gacidn para mostrar
que un componente u
LJ
Comida
otro es parte del todo.
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 sim-
bolo de una cornposicion es el mismo que el de una agregacidn, except0 que el rombo
esth relleno (vea la figura 5.3).
I
FIGURA 5.3
,
MesaDeCafe
En una composicidn,
cada componente
pertenece solamente
a un todo. Un rombo
I),
relleno representa
esta relacio’n. SuperficieDeLaMesa Pata
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 agru-
pamiento o en otro, y el diagrama de contexto le proporciona la caracteristica de mode-
laje 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 I Camisa
Un diagrama de con-
tento de composicidn
le muestra 10s compo-
nentes de una clase
esta cosida en
como un diagrama
v
1 5,6
anidado dentro de un
enorme recta'ngulo de I Botonadura
clase.
7-
Boton Ojal
El diagrama de contexto de composicidn enfoca la atencidn en la camisa y sus compo-

nentes. 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 Guardarropa
Un diagrama de
contexto del sistema
le muestra 10s com-
ponentes de una
clase y la forma
L$
en que la clase se
relaciona con las
otras que hay en
el sistema.
fIAtuendo
Agregacion, cornposicion, interfaces y realizacion
61 I
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 opera-
ciones 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 con-
junto 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 comuni-
carse 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 encon-
trarh en una mhquina de escribir: Control, Alt, RePhg, AvPhg y otras. Asi pues, la inter-
faz puede establecer un subconjunto de las operaciones de una clase y no necesariamente
todas ellas.
Puede modelar una interfaz del mismo mod0 en que modelm’a una clase, con un sim-
bolo 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 “hm’a 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 con-
junto de operaciones cantidadDeTeclas DeEscribir
que realiza una clase.
Esta Lltima se relaciona TeclazoO
con una interfaz me-
diante 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.
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 reali-
zacibn. La visibilidad se aplica a atributos u operaciones, y establece la pro-
porcidn 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 publi-
cos, protegidos y privados tanto en una televisi6n como en un autom6vil.
Agregacion, cornposicion, interfaces y realizacion 63 I
FIGURA5.8 ITelevision I IAutornovil I

Los atributos -y opera-
. + rnarca + fabricante I
ciones pu’blicos y pri-
vados, 1tanto de una
1’ ...
I+ rnodificarVolurnen() I I + acelerar() 13) I
tezevisidrz como de un + frenar()
- colorearlrnagenEnPantalla() #actualizarKilornetraje()
automdvil.
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 frecuen-
cia 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 com-
prender algunas relaciones adicionales. Una agregaci6n establece una asociacidn para
conformar un todo: una clase “todo” se genera de clases que la componen. Un compo-
nente 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 compo-
nente 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 sis-
tema. 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 opera-
ciones 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 reali-
zacidn 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 atribu-
tos 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.
P ;Se considera transitiva a la agregacidn? Es decir, si la clase 3 es un compo-
nente 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 dia-
grama de contexto del sistema que muestre a la revista junto con el suscriptor y el
comprador en el puesto de revistas.
E
l 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 ele-
mentos 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 necesitm’a una funcidn de marcado rippido? LQuem’a 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 ana’lisis 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 resul-
tad0 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 I
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 preten-
den utilizar un sistema. Puesto que el desarrollo tradicional de 10s sistemas era, con fre-
cuencia, 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 utilizm’an.
La idea es involucrar a 10s usuarios en las etapas iniciales del anflisis y diseiio del sis-
tema. 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 adqui-
rir una lata de gaseosa, probablemente las personas le dirin que se enfrentari a diversos
escenarios -un caso de USO, en otras palabras- que podria etiquetar como “Comprar
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 esta-
blece un conjunto
de escenarios para
n
realizar algo u’tilpara
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 selec-
ci6n; 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 cues-
tiones que saltm’an 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 posterior-
mente hace una selecci6n. La miquina no cuenta con ninguna lata de la gaseosa sele-
ccionada, 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 per-
maneceria 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 in-
dica 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 den-
tro 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 condi-
cidn 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 “Reabas-
tecer” 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 imple-
mentarlo. 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 confor-
mar 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” inicim’a 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 finalizm’a 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 inclusio’n
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 con-
fusion 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 oca-
siones 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 llama-
riamos “Reabastecer de acuerdo a las ventas”. Este nuevo caso de us0 es una extensih
del original, accidn a la que se le conoce como extensio’n 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 hm’an 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
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 compren-
der 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 cues-
tionarios”.
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 7
Diagramas de casos de us0
El caso de us0 es un poderoso concept0 que ayuda a un analista a compren-
der 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 nece-
sariamente) 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 aso-
ciativa 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 sis-
tema 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.
FIGURA7.1
En un modelo de caso
de USO, unafigura
agregada representa a
un actor; una elipse Actor Actor
a un caso de us0 y una
linea asociativa repre-
senta la comunicacidn
entre el actor y el caso
de USO.
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
us0 provenientede la
maquina de gaseosas
de la hora 6.
Cliente Cliente
O K
Reabastecer del
Representante
proveedor
x
Representante
del proveedor
. . . .
Recolector 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 hm’a 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).
79 I
FIGURA7.3
K- -K
Maquina de gaseosas
El modelo de caso de
us0 en la maquina
de gaseosas con
la inclusio’n.
Cliente
Cliente
?-
A
Representante
del proveedor
-
,
el interior
-K
Representante
del proveedor
Extension
K-
Recolector
3 Recolector
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 reabas-
tecer 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 dm’an 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
FIGURA7.4
Un diagrama de casos
10s compartimientos
de us0 que muestra
la extensidn y la
inclusidn. I -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 secun-
dario 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,
Y Agente proveedor
10s actores pueden

estar en una relacidn
de generalizacidn.
A A
Reabastecedor Recolector
Diagramas de casos de us0 8’ I
Ag rupamiento
En ciertos diagramas de casos de uso, podria tener varios casos de us0 que querri organi-
zar. 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.

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 compren-
si6n 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 empezm’a?
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 I
’ sirve
de la consultoria. * Y
1 ..
Cliente 1 lee I..* Propuesta
’A 1A
.,* se presenta a * apareceen
1..
1 4 aparece en 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, entrevistm’a 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 generaliza-
cidn, 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 seguri-
dad”, “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
de datos”, “Indizar las propuestas”, “Utilizar propuestas previas” y “Compartir impreso-

ras”. De acuerdo con esta informacibn, la figura 7.9 le muestra el diagrama de casos de
us0 de alto nivel que hemos generado.
K
FIGURA7.8
La jerarquia de
usuarios que
interactuarbn
con la LAN. EmDleado
Funcionario Administrador Consultor Oficinista
Adrninistrador Administrador Administrador

de oficina de proyectos 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 revi-
sores 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.
x AN
x
Funcionario
corporativo
Adrninistrador
0 Crear
propuestas
x
de oficina
Adrninistrador
x
de proyecto
base de datos
Consultor
0 Utilizar
propuestas
previas
x
Adrninistrador
de red
Conectar
OO a Internet
Cornpartir
impresoras
Oficinista
85 I
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 propues-
tas 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 , de- oficina
a
I
.
<<extender,)’,,ccincIuir,,
Crear una propuesta la sesion de la red
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 imple-
mentacidn. 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 avan-
zado 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 Agregaciones
Objetos Composiciones
Interfaces Estereotipos
Casos de us0 Restricciones
Actores Notas
Asociaciones Paquetes
Generalizaciones Extensiones
Realizaciones 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 es-
tructurales 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 oelemento 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.
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 exten-
siones, 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 esquema-
tiza 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 Elernentos estructurales
La organizacidn del
UML, en te‘rrninos de
10s elernentos clue ha
utilizado hasta ahora.
0Caso de us0
Relaciones
Asociacion
D
-- Generalizacion
- - - - - - - -> Dependencia
- - - - - - - 5> Realizacion
Agrupacion Extension
c( Estereotipo>>
Paquete (Restriccion}
(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 here-
da 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 dia-
gramas 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 pano-
rama 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.
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 entre-
vistas con 10s usuarios. En este punto, esto es mas o menos un ejercicio de recopi-
lacidn 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.
89 1
P ;Por quC es importante tener en cuenta tal ”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 agrupm’a
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 al-
macCn 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 8
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.
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 tratm’a una nueva cate-
goria 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 1
diagrama de estados.
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 tran-
sicibn. 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 repre-
senta 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 li‘nea
continua y una punta
de Jecha. Un circulo
relleno se interpreta
como el punto inicial de
una secuencia de esta-
dos, y una diana repre-
senta 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
f-LL-1
simbolo del estado Variables de estado
en areas que muestren
el nombre, variables y Actividades
actividades del estado.
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 varia-
bles 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 tele-
f 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 f Envio de fax

La rndquina de fax Fecha = Fecha en curso
es un buen ejemplo de Hora = Hora de inicio del fax
Telefono = Numero telefonico del propietario
un estado con variables
Propietario = Nombre del propietario
y actividades.
entradaharcar el numero de fax
salida/finalizar transmision
hacedagregar impresion de fecha
1 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 dia-
gonal 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
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 transi-

ciones de una inte$az
ncender la
.
pc
I
lnicializacion
>
Operacion
Apagado
>
Apagar
+@I
grafica del usuario 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
FIGIJRA
El 8.5
diagrama
de estados para
la GUI, con el estado
I-{ 0 [-k
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
hacer/Arrancar
Operacion
v
Apagado
Protector de pantalla
y la condicidn
de seguridad. [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 bambali-
nas, 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 secuencia-
les dentro del estado
Operacidn de la GUI. A la espera
de la accion
del usuario del usuario 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 secuen-
cia 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 Operacion
Los subestados con-
currentes suceden
a1 mismo tiempo. de la accion
Una linea discontinua del usuario del usuario del usuario
10s separa.
........................................
Actualizar
cronometro
despliegue
del sistema
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 concu-
rrentes 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 ini-
cia1 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 A la espera Registro de Representacion
compuesto recuerdu
su subestado uctivo
de accion
del usuario
Action
’una accion
del usuario
de la accion
del usuario
cuundo el objeto
trasciende fuera de
tal estudo compuesto. Verificar el [Lapso transcurrido]
cronornetro
> Actualizar
despliegue
del sisterna <
[Lapso transcurrido] I J I
I
I
f
Teclazo o
novirniento
del raton
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).
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 com-
portamiento del objeto, aumenta la probabilidad de que el equipo de desarrollo produzca
un sistema que cumpla con 10s requerimientos.
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
-I
Elernentos de comportamiento
[ Estado
un elemento de com- I
portarniento: el dia-
grams de estados.
La organizacidn del
0Caso de us0
UML, en te'nnirios Relaciones

de 10s elementos
Asociacion
que ha utilizado
hasta ahora. -D Generalizacion
_------>
_ Dependencia
-_----- Realizacion
Estereotipon
Paquete (Restriccion}
[valor etiquetado}
Anotacion
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 redon-
deados 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 desen-
cadenada. Finalmente, una transici6n puede ocurrir cuando se cumple una condici6n
particular, o condicidn de seguridad.
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 com-
puesto. 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.
I
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 desarrolla-
dores, 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.
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. LQUCes 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 transmi-
tido. 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 subesta-
dos 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.
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 conti-
nuas 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 co-
nocida 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 eje-
cuci6n 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 trans-
ferencia del control de un objeto a otro. Si un objeto envia un mensaje sincr6nico, espe-
rari 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 sin-
cr6nico 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 >- Simple

Sirnbolos para 10s -b Sincronico
rnensajes en un dia- i ~ ~ i ~ ~ ~ ~ ~ i
grarna de secuencias.
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 supe-
rior 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
R?! [3
;I,
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 dia-
grarna de secuencias.
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 interac-
tividades 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. La GUI notifica a1 sistema operativo que se oprimi6 una tecla.
2. El sistema operativo le notifica a la CPU.
3. El sistema operativo actualiza la GUI.
4. La CPU notifica a la tarjeta de video.
5. La tarjeta de video envia un mensaje a1 monitor.
6. El monitor presenta el 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 traba-
jar 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 correspon-
diente 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 se-
cuencias que rnuestra
la forrna en que la
GUI interacciona
con otros objetos.
x Teclazo
-1
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
0
1
x
secuencias puede lnicializacion
rnostrar 10s estados
de un objeto.
Operativo
.
.'
:retroalimentacioi
f
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.
x
FIGURA9.6
El caso de uso repre-
sentado grbjicamente
por el diagrama Ejecutar la opresion
de secuencias de de una tecla
lajigura 9.4.
Usuario Usuario
I 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 regis-
trador 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. 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 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 instan-
cia) 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 h
V lnsercion
I:Fachadal I :Registrador I (:Dispe;sadorl
Este diagrama de se-
(Alimentacion) ’
cuencias modela tan
sdlo el mejor esce-
?n
A E l e c c i o n (Selj ’ Enviar
nario del caso de us0

“Comprargaseosa ”.
Por lo tanto, es un
diagrama de secuen-
I1 Despachar
(Seleccion)
(l
cias de instancias.
Un diagrama de secuencias generic0

Como recordari, el caso de us0 “Comprar gaseosa” tenia dos escenarios alternos. Uno
de ellos se refen’a 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 tratm’a
de un diagrama de secuencias gene‘rico.
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 aguar-
de 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 men-
saje 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
c
Diagramas de secuencias 111 1
FIGURA9.8 0 [:Fachadal
El diagrama de lnsercion
.,.’.
:I,
(Alirnentacion) I
. ’
secuencias luego
de agregar el ,I I
:Enviar (altmentacion)
I
..
,I I
I.
I
I
I
’.
.
,
: :
II
escenario de “Monto II IAlirnentacion = Preciol
.
):
I !. \ I
incorrecto ” a1 caso
: Despachar (Seleccion) [Alirnentacion >Prec6 :
Verificar carnbio
de us0 “Comprar
[Carnbio en reserva]
gaseosa ”. , Regresar carnbio [Carnbio en reserva] 1
[No hay carnbio en reserva] :

Devolver (Alimentacion)
Transaccionfinalizada”
Despachar (Seleccion) :
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 esce-
nario 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 0 I:fachadal
Insertion
El diagram de
secuencias gene‘rico
[Alimentaclon = Precio]
de la ma’quina de Verificar (Selection)
gaseosas luego [Seieccion en existencia]
de agregarle
[Selection agatada]
el escenario I ’ Mostrar (mensale)
“Sin marca” I -
a la figura 9.8.
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 representm’a 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 consul-
tor 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 inte-
grado 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 secuen-
cia 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 corn-
plejidad 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 E
El diagrama de
secuencias del caso
de us0 "Crear una
. ...
I.
propuesta ". [iocaiizado] ;

abrir farchwo) I I
I .
_I I I
, ,
?' .' :,
a- .0
'[trabajar]
war aplicaciones m
..
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 I:Calculladora I
Cdmo reuresentar
InteresO
la recursividad
en un diagrama
de secuencias.
I
I
Ahora podri agregar otro diagrama a su panorama del UML. Dado que se refiere a1 com-
portamiento de 10s objetos, el diagrama de secuencias iria bajo la categoria “Elementos
de comportamiento”. La figura 9.12 actualiza su creciente panorama.
FIGURA9.12 Elementos estructurales Elementos de comportamiento

El panorama del
UML con la adicidn
del diagrama de
E l o
‘lase tnterfaz
I Estado I
U
secuencias.
0Caso de us0
Relaciones
Asociacion
D
-, Generalizacion
- - - - - - - - + Dependencia
- - - - - - - - D Realizacion Secuencia
’ Estereotipo”
Paquete (Restriccion)
{valor etiquetado)
Anotacion
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 mo-
mento 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.
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 recthn-
gulo 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.
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 dia-
gramas de secuencias. Encontrarh las respuestas en el ApCndice A, “Respuestas a 10s
cuestionarios”.
Cuestionario
1. Defina mensaje sincro’nico y mensaje asincrdnico.
2. En un diagrama de secuencias genCrico jc6mo representm’a el control de flujo
implicito en una instrucci6n condicional?
3. iC6mo representm’a 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 I
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
I
i 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 colabo-
raci6n 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 rela-
ciones 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 colabo-
raciones 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 concep-
tos 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. La GUI notifica a1 sistema operativo que se oprimi6 una tecla.
2. El sistema operativo le notifica a la CPU.
3. El sistema operativo actualiza la GUI.
4. La CPU notifica a la tarjeta de video.
5. La tarjeta de video envia un mensaje a1 monitor.
6. El monitor presenta el 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) t 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 1
FIGURA10.4
El diugramu de colubo-
raciones para el
+ insertar(alimentacion, seleccion)
mejor cuso de
“Comprur gaseosa ”.
i:agregar(alimentacion, seleccion)
:Despachador :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 dia-
grama 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. Empe-
zaremos 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. Numera-
rh 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 fi-
nalizada” en este mensaje, y otro en el mensaje que despacha la gaseosa. La figura 10.6
presentarh la situacidn.
I 124 Hora 10
FIGURA10.5
El diagrarna de insertar(a1irnentacion.seleccion)
colaboraciones con
parte de la situacidn
“rnontode dinero 1 .agregar(alirnentacion,seleccion)
inadecuado ”.
(alimentacion= precio] 2.1: despachar(selecci0n) [alirnentacion > precio] 2.2: veriilcar

[hay precio de entrada] 3.1: despachar(selecc1on) Cambio(alimentacion,precio)
FIGURA10.6
El diagrama de
colaboraciones
“Cornprargaseosa”
con toda la situaci6n 4:despachar
“montode dinero
-
inadecuado ”.
:Reqistrador
[alirnentacion= precio] 2.1: despachar(se1eccion) [alirnentacion> precio] 2.2: verifica

[hay precio de entradal3.1: despachar(selecci0n) 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 pro-
puesta 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 1
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 1:iniciarBusqueda()
colaboruciones [encontrado] 4.1: abrir(archiv0)
[no encontrado] 4.2: nuevo(archivo)
“Creur unu propuestu ”. ‘[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 ejem-
plo: 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 F l
Un objeto que envia
’[todos] 1: atender(tarea)
un mensaje a diversos
objetos de una clase.
B :Estudiante
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
*[position en la fila = 1...n] l:atender()
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.
FIGURA 10.10
Un diagrama de
1: precio total := calcular(precioElernento, irnpuestos)
colaboraciones que
incluye la sintaxis
de un resultado.
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 biblio-
tecario 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 con-
currencia.
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 recta‘ngulo 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 ven-
tas 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 ante-
ceder5 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 F r ( c a r n p a r i a , producto)
colaboraciones.
:Gerente ventas
3: vender(campaiia. producto)
Vendedor
lientes asignados] 4 IlamadaVentas(carnpaia, producto)
Ciiente
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
Clase
lnterfaz
-
I I
Elementos de cornportarniento
Estado
colaboraciones.
0Caso de us0
I :Nombrell
I I
Relaciones
o-n
I I
Asociacion
-D Generalizacion
- - - - - _ _ +_ Dependencia
- - - - - - - - D Realizacion
@ Secuencia
<<Estereotipo>>
Paquete {Restriccion}
(valor etiquetado) I:Nombre2 I
Colaboracion
Anotacion
17
Resumen
Un diagrama de colaboraciones es otra forma de presentar la informacidn en un dia-
grama 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 repre-
senta 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.
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 colabo-
racidn, 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 mostrm’a informacidn secuencial en un diagrama de colaboraciones?
3. iC6mo mostrm’a 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 colabora-
ciones 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.
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 secuen-
cia 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.

Aprendiendo Uml en 24 Horas

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Aprendiendo Uml en 24 Horas

Cargado por

Copyright:

Formatos disponibles

/ Datos de catalogacion bibliografica

APRENDIENDO UML EN 24 HORAS

Formato: 18.5 x 23.5 cm Pbginas: 448

EDICIdN EN ESPANOL EDITOR EJECUTIVO

APRENDIENDO UML EN 24 HORAS EDITOR DE DESARROLLO

Primera edici6n CORRECTORES DE PRUEBAS

53370 Naucalpan de Jufirez, Edo. de MCxico Bill Rowe

PARTE I PARA INlClAR 3

PARTE11 ESTUDIO DE UN CASO 203

PARTE IV APENDICES 355

PARTE I PARA INICIAR 3

Para quC tantos diagramas .......................................

HORA 2 ORIENTAC16N A OBJETOS 19

Resumen .................. ....................... 30

HORA 5 AGREGACl6N. COMPOSlCl6N, INTERFACES Y REALlZACl6N 57

Interfaces y realizaciones ...................................................................................... 61

HORA6 lNTRODUCC16N A LOS CASOS DE U S 0 67

Subestados concurrentes ................................................ .96

Preguntas y respuestas ....................... 101

Adiciones a1 panorama ............................ ................................................ 1 15

HORA 13 DIAGRAMAS DE DlSTRlBUCl6N 163

HOW DE LOS FUNDAMENTOS DEL UML

Estereotipos ........................................................................................................ 179

Componente .................................................................................................. 182

Preguntas y respuestas ........................................................................................ 185

HORA 15 ADAPTACldN DEL UML EN UN PROCESO DE DESARROLLO 187

PARTE II ESTUDIODE UN CASO

Aplicaci6n de GRAPPLE a1 problema ................................ 206

Resumen. .............................................................. 220

HORA 17 ELABORACldN DE UN ANALISIS DE DOMlNlO 223

HORA 18 RECOPlLACldN DE LAS NECESIDADES DEL SISTEMA 247

HORA 21 DISENO DEL ASPECTO, SENSACldN Y DlSTR!BUCl6N 293

PARTE 111 VISION DEL FUTURO 321

Subprocesos .................................................................................................. 328

Modelado de TecnoApreth ........ ................................

PARTE IV APENDICES 355

Rational Rose . ............................................................................ 370

Convenciones utilizadas en este libro

Una Nota presenta interesantes secciones de inforrnacion relacionadas con el

El icono TCrmino Nuevo resalta las definiciones de vocablos nuevos y esen-

La comunicacidn de la idea es de suma importancia. Antes del advenimiento del UML, el

Por que es necesario el UML

es que asi como un arquitecto le muestra un anteproyecto a la persona que lo contrat6,

La concepcion del UML

Las horas 2, "orientacion a objetos", y 4, "Us0 de relaciones", tratan de la

En 1994 Rumbaugh ingres6 a Rational Software Corporation, donde ya trabajaba Booch.

Diagramas del UML

Este enfoque es similar a aprender un idiorna extranjero rnediante el us0 del

La finalidad de 10s diagramas es presentar diversas perspectivas de un sistema,

Diagrama de casos de us0

A la figura correspondiente a1 Usuario de la lavadora se le conoce como actor.

8. El abastecimiento de agua se detendri.

FIGURA 1.8 Componente

Vectra VL Serie 7 Dell Dimension XPS R450

Para que tantos diagramas

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

Ya se ha iniciado en el UML. Ahora deberi reafirmar su conocimiento de esta gran

de software, de manera que primer0 se genera un sistema mediante un conjunto de obje-

Objetos, objetos por doquier

Regresemos a1 ejemplo de la lavadora. Si en la clase Lavadora se indica la marca, el

En la hora 3, "Us0 de la orientacion a objetos", Vera que 10s nornbres de las

Esto es particularmente importante en el desarrollo de software orientado a objetos.

Es importante que recuerde que el prop6sito de la orientaci6n a objetos es desarrollar

tener mhs de un significado. El polimorfismo permite a1 modelador mantener tal terrni-