ISW512 Act 04 GM 04 UML v1.2

Consorcio de Universidades©
Guía Metodológica de UML
Versión 1.2
2008/06/18
Adaptado de:
Learning UML, Sinan Si Alhir, O'Reilly & Associates.
Cimat © Guía Metodológica de UML – v. 1.2
Control De Versiones Sección Introducción a UML
Nombre del Archivo Versión Fecha Autor Comentarios

GM_06_UML 0.1 2005/02/21 ESF Versión inicial
del Documento
GM_06_UML 0.2 2005/02/26 ESF Reestructuración
del documento
GM_06_UML 0.3 2005/03/09 ESF Dividir el archivo
por capítulos
para su
traducción en
paralelo.
GM_1.0_UML 1.0 2005/06/12 ESF Unión de los
documentos
traducidos,
revisión y
corrección
GM_1.1_UML 1.1 2007/06/04 ESF Modificación de
la Portada,
corregir formato
del texto de las
fuentes de las
imgs.
ISW512_CU_ 1.2 2008/06/18 ESF Modificación de
GM_04_UML la Portada, se
corriguieron
algunas
referencias a
figuras que
estaban rotas.
2008/06/18 2/195
Índice del Documento

1
0 Introducción.................................................................................................... 10
265H
1.1
1H Propósito....................................................................................................... 10
26H
1.2
2H Alcance ......................................................................................................... 10
267H
1.3
3H Acrónimos..................................................................................................... 10
268H
1.4
4H Referencias................................................................................................... 10
269H
1.5
5H Definiciones .................................................................................................. 10
270H
Parte I.- Fundamentos........................................................................................... 12

6H 271H
2 Introducción a UML ........................................................................................ 12

7H 27H
2.1 Que es UML?................................................................................................ 12

8H 273H
2.1.1 Los tres aspectos de UML ......................................................................... 12

9H 274H
2.1.2 Metas y Alcances....................................................................................... 14

10H 275H
2.1.3 Historia....................................................................................................... 15
1H 276H
2.2 UML y los Procesos ...................................................................................... 16

12H 27H
2.2.1 Aplicando un Ciclo de Vida en Cascada .................................................... 17

13H 278H
2.2.2 Aplicando un Ciclo de Vida Iterativo .......................................................... 17

14H 279H
2.3 Aprendiendo UML......................................................................................... 18

15H 280H
3 Modelado Orientado a Objetos ...................................................................... 20

16H 281H
3.1 Requerimientos para el manejo del sistema. ................................................ 20

17H 28H
3.2 Alfabetos, Palabras y Sentencias ................................................................. 21

18H 283H
3.2.1 Alfabeto...................................................................................................... 21
19H 284H
3.2.2 Palabras..................................................................................................... 21
20H 285H
3.2.3 Sentencias ................................................................................................. 22

21H 286H
3.3 El Paradigma de la Orientación a Objetos .................................................... 24

2H 287H
3.3.1 Conceptos.................................................................................................. 24
23H 28H
3.3.2 Principios ................................................................................................... 29

24H 289H
3.4 Párrafos ........................................................................................................ 31

25H 290H
3.4.1 Modelado de Estructura............................................................................. 32

26H 291H
3.4.2 Modelado de Comportamiento................................................................... 39

27H 29H
3.4.3 Otros elementos ........................................................................................ 47

28H 293H
3.5 Secciones ..................................................................................................... 48

29H 294H
3.6 Documentos.................................................................................................. 49
30H 295H
Parte II.- Modelado de la Estructura...................................................................... 51

31H 296H
4 Diagramas de Clase y Objetos....................................................................... 51

32H 297H
4.1 Clases y objetos ........................................................................................... 51

3H 298H
4.1.1 Clases........................................................................................................ 52
34H 29H
4.1.2 Objetos ...................................................................................................... 64

35H 30H
4.2 Asociaciones y ligas ..................................................................................... 67

36H 301H
4.2.1 Asociaciones.............................................................................................. 67
37H 302H
4.2.2 Clases de la Asociación............................................................................. 69

38H 30H
4.2.3 Extremos De la Asociación ........................................................................ 70

39H 304H
2008/06/18 3/195
4.2.4 Vínculos ..................................................................................................... 78

40H 305H
4.2.5 Objetos Del Vinculo ................................................................................... 80

41H 306H
4.2.6 Extremos Del Vínculo ................................................................................ 80

42H 307H
4.3 Tipos, Clases e Interfaces de Implementación ............................................. 85

43H 308H
4.3.1 Tipos .......................................................................................................... 85

4H 309H
4.3.2 Clases de Implementación......................................................................... 86

45H 310H
4.3.3 Interfaces ................................................................................................... 87

46H 31H
4.4 Generalizaciones, Realizaciones y Dependencias ....................................... 89

47H 312H
4.4.1 Generalizaciones ....................................................................................... 89

48H 31H
4.4.2 clases indiferenciadas................................................................................ 90

49H 314H
4.4.3 Realizaciones ............................................................................................ 93

50H 315H
4.4.4 Dependencias............................................................................................ 97
51H 316H
4.5 Paquetes y Subsistemas .............................................................................. 99

52H 317H
4.5.1 Paquetes.................................................................................................... 99
53H 318H
4.5.2 Subsistemas ............................................................................................ 102

54H 319H
5 Diagramas de Caso de Uso ......................................................................... 107

5H 320H
5.1 Actores........................................................................................................ 108

56H 321H
5.2 Casos de uso.............................................................................................. 110

57H 32H
5.3 Asociaciones de Comunicación .................................................................. 114

58H 32H
5.4 Dependencias............................................................................................. 116

59H 324H
5.4.1 Dependencias incluidas ........................................................................... 116

60H 325H
5.4.2 Dependencias Extendidas ....................................................................... 118

61H 326H
5.5 Generalizaciones ........................................................................................ 122

62H 327H
5.5.1 Generalizaciones de actores ................................................................... 122

63H 328H
5.5.2 Generalizaciones de Caso-uso................................................................ 124

64H 329H
6 Diagramas de Componentes y de Deployment............................................ 127

65H 30H
6.1 Componentes ............................................................................................. 127

6H 31H
6.2 Nodos ......................................................................................................... 130

67H 32H
6.3 Dependencias............................................................................................. 132

68H 3H
6.3.1 Dependencias Residentes ....................................................................... 132

69H 34H
6.3.2 Dependencias de Uso.............................................................................. 134

70H 35H
6.3.3 Dependencias de Despliegue .................................................................. 135

71H 36H
6.4 Asociaciones de Comunicación .................................................................. 136

72H 37H
Parte III.- Modelando del Comportamiento.......................................................... 139

73H 38H
7 Diagramas de Secuencia y de Colaboración ............................................... 139

74H 39H
7.1 Roles........................................................................................................... 140

75H 340H
7.1.1 Clases y Objetos...................................................................................... 144

76H 341H
7.1.2 Asociaciones y Vínculos .......................................................................... 145

7H 342H
7.2 Mensajes y estímulos ................................................................................. 147

78H 34H
7.3 Interacciones y Colaboraciones.................................................................. 147

79H 34H
7.4 Diagramas de Secuencia............................................................................ 149

80H 345H
7.4.1 Elementos................................................................................................ 149

81H 346H
7.4.2 Comunicación .......................................................................................... 151

82H 347H
2008/06/18 4/195
7.4.3 Repetición................................................................................................ 155

83H 348H
7.4.4 Condicionamientos .................................................................................. 159

84H 349H
7.5 Diagramas de Colaboración ....................................................................... 160

85H 350H
7.5.1 Elementos................................................................................................ 160

86H 351H
7.5.2 Comunicación .......................................................................................... 162

87H 352H
7.5.3 Repetición................................................................................................ 163

8H 35H
7.5.4 Condicionar.............................................................................................. 165

89H 354H
8 Diagramas de Estado................................................................................... 167

90H 35H
8.1 Estados....................................................................................................... 167

91H 356H
8.1.1 Estados Simple........................................................................................ 168

92H 357H
8.1.2 Estados Inicial y Final .............................................................................. 169

93H 358H
8.2 Transiciones ............................................................................................... 169

94H 359H
8.2.1 Eventos.................................................................................................... 170

95H 360H
8.2.2 Acciones .................................................................................................. 172

96H 361H
8.3 Diagramas De Estado Avanzados .............................................................. 173

97H 362H
9 Diagramas de Actividad ............................................................................... 176

98H 36H
9.1 Estados....................................................................................................... 176

9H 364H
9.1.1 Estados Simples de Acción (Acciones).................................................... 176

10H 365H
9.1.2 Estados de la acción inicial y final ........................................................... 177

10H 36H
9.2 Flujo de transiciones ................................................................................... 178

102H 367H
9.2.1 Transiciones de flujo de control ............................................................... 178

103H 368H
9.2.2 Flujo de control de objetos....................................................................... 179

104H 369H
9.3 Swimlanes .................................................................................................. 182

105H 370H
9.4 Decisiones .................................................................................................. 183

106H 371H
9.5 Concurrencia .............................................................................................. 184

107H 372H
Parte IV.- Mas allá de UML ................................................................................. 186

108H 37H
10 Mecanismos de Extensión ........................................................................... 186

109H 374H
10.1 Lenguaje de Arquitectura.......................................................................... 186

10H 375H
10.2 Estereotipos.............................................................................................. 188

1H 376H
10.2.1 Definiendo Estereotipos......................................................................... 189

12H 37H
10.2.2 Aplicando Estereotipos .......................................................................... 190

13H 378H
10.3 Propiedades.............................................................................................. 191

14H 379H
10.3.1 Etiquetas(Tags) ..................................................................................... 191

15H 380H
10.3.2 Restricciones ......................................................................................... 193

16H 381H
10.4 Perfiles...................................................................................................... 194

17H 382H
Índice de Figuras
Figura 2-1. Administradores, proyectos y equipos. ............................................... 12
18H 38H
Figura 2-2. La cantidad cinco en dos “lenguajes”.................................................. 13

19H 384H
Figura 3-1. Conceptos ........................................................................................... 22

120H 385H
Figura 3-2. Relaciones .......................................................................................... 22

12H 386H
2008/06/18 5/195
Figura 3-3. Un equipo desarrollara un proyecto .................................................... 23

12H 387H
Figura 3-4. Un Administrador maneja un proyecto y dirige un equipo (versión 1) . 23

123H 38H
Figura 3-5. Un Administrador maneja un proyecto y dirige un equipo (versión 2) . 24

124H 389H
Figura 3-6. Juan Maneja el proyecto Águila y dirige un equipo anónimo .............. 25
125H 390H
Figura 3-7. Clases sin atributos............................................................................. 25

126H 391H
Figura 3-8. Clases con valores en los atributos..................................................... 26

127H 392H
Figura 3-9. Clases con operaciones...................................................................... 27

128H 39H
Figura 3-10. Clases con operaciones y atributos .................................................. 27

129H 394H
Figura 3-11. Interacción General........................................................................... 28

130H 395H
Figura 3-12. Interacción Específica ....................................................................... 28

13H 396H
Figura 3-13. Requerimientos del Proyecto y los Sistemas .................................... 30

132H 397H
Figura 3-14. Productos de Trabajo del Proyecto, Requerimientos y Sistemas...... 31

13H 398H
Figura 3-15. Diagrama de Clases.......................................................................... 34

134H 39H
Figura 3-16. Diagrama de Objetos ........................................................................ 36

135H 40H
Figura 3-17. Diagrama de Caso de Uso................................................................ 37

136H 401H
Figura 3-18. Diagrama de Componentes .............................................................. 38

137H 402H
Figura 3-19. Diagrama de Deployment ................................................................. 39

138H 403H
Figura 3-20. Diagrama de Secuencia.................................................................... 41

139H 40H
Figura 3-21. Diagrama de Colaboración ............................................................... 42

140H 405H
Figura 3-22. Diagrama de Estado ......................................................................... 44

14H 406H
Figura 3-23. Diagrama de Actividad ...................................................................... 46

142H 407H
Figura 3-24. Notas, estereotipos y propiedades.................................................... 47

143H 408H
Figura 4-1. Clases ................................................................................................. 52

14H 409H
Figura 4-2. Clase del trabajador con sus atributos ............................................... 55

145H 410H
Figura 4-3. Clase unidad de trabajo con sus atributos .......................................... 55

146H 41H
Figura 4-4. Clase ProductoDeTrabajo con sus atributos....................................... 55

147H 412H
Figura 4-5. Clase trabajador con sus operaciones ................................................ 60

148H 413H
Figura 4-6. Clase UnidadDeTrabajo con sus operaciones .................................... 61

149H 41H
Figura 4-7. Clase ProductoDeTrabajo con sus operaciones ................................. 61

150H 415H
Figura 4-8. Objetos................................................................................................ 66

15H 416H
Figura 4-9. Asociaciones Binarias ......................................................................... 68

152H 417H
Figura 4-10. Asociaciones N-arios ....................................................................... 69

153H 418H
Figura 4-11. Clases de asociación Binarias .......................................................... 70

154H 419H
Figura 4-12. Clase de asociación N-arios ............................................................ 70

15H 420H
Figura 4-13. Extremos binarios de la asociación................................................... 71

156H 421H
Figura 4-14. Extremos de la asociación N-arios.................................................... 72

157H 42H
Figura 4-15. Agregación y composición para las asociaciones ............................. 74

158H 423H
Figura 4-16. Forma alterna de composición para las asociaciones....................... 76

159H 42H
Figura 4-17. Composición doble jerarquizada para las asociaciones.................... 76

160H 425H
Figura 4-18. Calificadores para asociaciones........................................................ 77

16H 426H
Figura 4-19. Vínculos Binarios .............................................................................. 79

162H 427H
Figura 4-20. Vínculos de N-arios........................................................................... 80

163H 428H
Figura 4-21. Agregación y composición para los vínculos .................................... 82

164H 429H
Figura 4-22. Forma alterna de composición para los vínculos .............................. 83

165H 430H
Figura 4-23. Composición doble jerarquizada para los vínculos ........................... 84

16H 431H
Figura 4-24. Valores de los calificadores para los vínculos................................... 84

167H 432H
2008/06/18 6/195
Figura 4-25. Tipos ................................................................................................. 85

168H 43H
Figura 4-26. Tipos con asociaciones terminadas .................................................. 86

169H 43H
Figura 4-27. Clases de Implementación ................................................................ 87

170H 435H
Figura 4-28. Interfaces .......................................................................................... 88

17H 436H
Figura 4-29. Interfaces con asociaciones finales................................................... 89

172H 437H
Figura 4-30. Generalizaciones entre tipos............................................................. 90

173H 438H
Figura 4-31. Generalizaciones entre clases .......................................................... 91

174H 439H
Figura 4-32. Generalizaciones entre clases de implementación ........................... 92

175H 40H
Figura 4-33. Generalizaciones entre interfaces..................................................... 93

176H 41H
Figura 4-34. Realizaciones para las clases de Trabajador.................................... 94

17H 42H
Figura 4-35. Realización para la clase Producto de Trabajo................................. 95

178H 43H
Figura 4-36. Realizaciones de clases indiferenciadas por clases de

179H
implementación .............................................................................................. 96 4H
Figura 4-37. Realizaciones para la clase de implementación Empleado .............. 96

180H 45H
Figura 4-38. Realizaciones para la clase de implementación de el Artifact........... 97

18H 46H
Figura 4-39. Realizaciones y dependencias.......................................................... 98

182H 47H
Figura 4-40. Dependencias entre interfaces y tipos de retorno ............................. 99

183H 48H
Figura 4-41. Paquetes......................................................................................... 101

184H 49H
Figura 4-42. Una representación de subsistema en el UML ............................... 103

185H 450H
Figura 4-43. Subsistemas ................................................................................... 105

186H 451H
Figura 5-1. Actores.............................................................................................. 109

187H 452H
Figura 5-2. Instancias de actores ........................................................................ 110

18H 453H
Figura 5-3. Casos de uso .................................................................................... 111

189H 45H
Figura 5-4. Actores y casos de uso ..................................................................... 115

190H 45H
Figura 5-5. Casos de uso con un común comportamiento .................................. 116

19H 456H
Figura 5-6. Dependencias incluidas .................................................................... 117

192H 457H
Figura 5-7. Casos de uso con un comportamiento opcional ............................... 118

193H 458H
Figura 5-8. Dependencias extendidas simples.................................................... 119

194H 459H
Figura 5-9. Puntos de extensión y dependencias extendidas ............................. 120

195H 460H
Figura 5-10. Actores similares............................................................................. 123

196H 461H
Figura 5-11. Generalizaciones de actores........................................................... 124

197H 462H
Figura 5-12. Casos de uso similares ................................................................... 125

198H 463H
Figura 5-13. Generalizaciones de Caso-Uso....................................................... 126

19H 46H
Figura 6-14. Componentes del sistema de administración del proyecto ............. 128
20H 465H
Figura 6-15. Instancias de componentes en el sistema de administración del

201H
proyecto ....................................................................................................... 129

46H
Figura 6-16. Nodos usados por el sistema de administración de proyectos ....... 131
20H 467H
Figura 6-17. Instancias de nodo .......................................................................... 132

203H 468H
Figura 6-18. Paquetes para las dependencias residentes .................................. 133

204H 469H
Figura 6-19. Dependencias residentes para subsistemas................................... 133

205H 470H
Figura 6-20. Dependencias residentes usando anidamientos............................. 134

206H 471H
Figura 6-21. Dependencias de uso ..................................................................... 135

207H 472H
Figura 6-22. Dependencias de despliegue .......................................................... 135

208H 473H
Figura 6-23. Dependencias de deploy para un subsistema. ............................... 136

209H 47H
Figura 6-24. Dependencias de deploy usando jerarquías ................................... 136

210H 475H
Figura 6-25. Asociaciones de comunicación ....................................................... 137

21H 476H
2008/06/18 7/195
Figura 6-26. Asociaciones de comunicación ....................................................... 138

21H 47H
Figura 7-1. Generar el Reporte del Estado del Proyecto..................................... 140

213H 478H
Figura 7-2. Organizaciones y proyectos.............................................................. 141

214H 479H
Figura 7-3. Interacción y colaboración realizan un caso de uso.......................... 142

215H 480H
Figura 7-4. Interacción y colaboración usan clases............................................. 144

216H 481H
Figura 7-5. Interacción y colaboración usan objetos ........................................... 145

217H 482H
Figura 7-6. Interacción y colaboración usan asociaciones .................................. 146

218H 483H
Figura 7-7. Interacción y colaboración usan vínculos.......................................... 147

219H 48H
Figura 7-8. Un rol de clase y dos clases ............................................................. 149

20H 485H
Figura 7-9. Un objeto conforma el rol de una clase............................................. 150

21H 486H
Figura 7-10. Líneas de Vida ................................................................................ 150

2H 487H
Figura 7-11. Activaciones .................................................................................... 151

23H 48H
Figura 7-12. Diagrama de Secuencia Comunicaciones ...................................... 152

24H 489H
Figura 7-13. Diagrama de Secuencia comunicaciones reflexivas ....................... 154

25H 490H
Figura 7-14. Diagrama de Secuencia Crear y Destruir Comunicaciones ............ 155

26H 491H
Figura 7-15. Diagrama de Secuencia Repetir usando una iteración en la forma

27H
general de una interacción. .......................................................................... 156 492H
Figura 7-16. Diagrama de Secuencia que usa una condición guardián en la forma
28H
general de una interacción. .......................................................................... 156 493H
Figura 7-17. Diagrama de Secuencia Repetición en la forma instancia de la

29H
interacción.................................................................................................... 158
49H
Figura 7-18. Diagrama de Secuencia Condicionar en la forma general de una

230H
interacción.................................................................................................... 159
495H
Figura 7-19. Diagrama de Secuencia Condicionar en la forma instancia de la

231H
interacción.................................................................................................... 160
496H
Figura 7-20. Roles de Asociación........................................................................ 161

23H 497H
Figura 7-21. Vínculos que conforman roles de asociación................................. 162

23H 498H
Figura 7-22. Diagrama de Colaboración Comunicaciones .................................. 162

234H 49H
Figura 7-23. Diagrama de Colaboración Comunicación Reflexiva ...................... 163

235H 50H
Figura 7-24. Diagrama de Colaboración Crear y destruir comunicaciones ......... 163

236H 501H
Figura 7-25. Diagrama de Colaboración Repetición usando una iteración en una

237H
forma general de una interacción................................................................. 164 502H
Figura 7-26. Diagrama de Colaboración Repetición usando una condición guardián

238H
en la forma general para una interacción ..................................................... 164 503H
Figura 7-27. Diagrama de Colaboración Repetición en la forma instancia de la

239H
interacción.................................................................................................... 165
504H
Figura 7-28. Diagrama de Colaboración Condicionar en la forma general de una

240H
interacción.................................................................................................... 166
50H

241H
interacción.................................................................................................... 167
506H
Figura 8-1. Estados simple................................................................................. 168

24H 507H
Figura 8-2. Estados simple, inicial y final. ........................................................... 169

243H 508H
Figura 8-3. Transiciones con eventos. ............................................................... 171

24H 509H
Figura 8-4. Transiciones con eventos y acciones................................................ 173

245H 510H
Figura 8-5. Diagramas de estado avanzado ...................................................... 175

246H 51H
Figura 9.1. Estados simples de la acción ............................................................ 177

247H 512H
2008/06/18 8/195
Figura 9.2. Estados de Acción simples, iniciales y finales................................... 178

248H 513H
Figura 9.3. Transiciones Control - Flujo .............................................................. 179

249H 514H
Figura 9.4. Transiciones objeto – flujo y control - flujo ........................................ 181

250H 51H
Figura 9.5. Transiciones de flujo-de-objeto y de flujo-de-control sin las innecesarias

251H
transiciones de flujo-de-control .................................................................... 182 516H
Figura 9.6. Swimlanes ......................................................................................... 183

25H 517H
Figura 9.7. Decisiones......................................................................................... 184

253H 518H
Figura 9.8. Concurrencia .................................................................................... 185

254H 519H
Figura 10-1. Definiendo estereotipos .................................................................. 189

25H 520H
Figura 10-2. Aplicando estereotipos usando diagramas de clase ....................... 190

256H 521H
Figura 10-3. Aplicación de estereotipos usando diagramas de objetos .............. 191

257H 52H
Figura 10-4. Definiendo estereotipos y tags ........................................................ 192

258H 523H
Figura 10-5. Aplicando estereotipos y tags ......................................................... 193

259H 524H
Figura 10-6. Definiendo estereotipos, etiquetas y restricciones .......................... 194

260H 52H
Figura 10-7. Perfiles ............................................................................................ 195

261H 526H
Índice de Tablas
Ninguna.
2008/06/18 9/195
1 Introducción
1.1 Propósito
Describir los diagramas que conforman la notación de UML.
1.2 Alcance
Este documento aplica a todos los proyectos generados en la licenciatura en
Sistemas Computacionales plan 04, y en la licenciatura de Ingeniería en
Computación plan 03, a partir de la liberación de la línea base.
1.3 Acrónimos
Acrónimo Descripción
UML Unified Modeling Language
OMG Object Managment Group
OCL Object Constraint Language
PAS Publicly Available Specification
ISO International Organization for Standardization
XML Extensible Markup Language
SQL Structured Query Language
OMT Object Modeling Technique
OOSE Object-Oriented Software Engineering
1.4 Referencias
Núm. Descripción
[1] Sinan Si Alhir, Learning UML, O'Reilly, ISBN : 0-596-00344-7, 2003
1.5 Definiciones
Palabra Definición
UML UML es un lenguaje para el modelado y
comunicación de diversos sistemas, para el cual se
usan diagramas y texto.
Lenguaje Es el que nos permite la comunicación acerca de un
determinado tema.
2008/06/18 10/195
Proceso Conjunto de pasos descritos por una metodología

para resolver un problema
Modelo Captura un conjunto de ideas conocidas como
abstracciones
Caso de Uso Es un requerimiento funcional descrito desde la
perspectiva del usuario del sistema
Riesgo Es cualquier obstáculo que puede hacernos
fracasar
Los enunciados Son fragmentos de diagramas o diagramas muy
UML simples.
Polimorfismo Es la capacidad de tener múltiples métodos para una
sola operación.
Atributo Es todo aquello que un objeto conoce,
2008/06/18 11/195
Parte I.- Fundamentos

2 Introducción a UML
2.1 Que es UML?

Muy simple, UML es un lenguaje para modelar y comunicar información sobre
sistemas, para lo cual se usan diagramas y texto. Por ejemplo la Figura 2-1
527H
comunica lo siguiente:
• Un administrador dirige un equipo que trabaja en un proyecto.
• Cada administrador tiene un nombre y un número de teléfono, además

puede iniciar o terminar un proyecto.
• Cada proyecto tiene un nombre, una fecha de inicio y una fecha de fin.
• Cada equipo tiene una descripción, y eso es todo lo que nos interesa con
respecto al equipo.
Figura 2-1. Administradores, proyectos y equipos.
Administrador
Nombre
Telefono
IniciarProyecto() Administra
TerminarProyecto()
Dirige
Equipo Proyecto
Ejecuta
Descripcion Nombre
FerchaDeInicio
FichaDeFin
Fuente: O`Reilly 2003
2.1.1 Los tres aspectos de UML

UML es una abreviación de Unified Modeling Language (Lenguaje de Modelado
Unificado). Cada una de estas tres palabras habla de un aspecto importante de
UML, las próximas secciones hablaran de estos tres aspectos.
2.1.1.1 Language (Lenguaje)
2008/06/18 12/195
Un lenguaje nos permite la comunicación sobre un tema o concepto determinado.

En el desarrollo de un sistema, los temas que se incluyen son los requerimientos y
el sistema. Sin un lenguaje seria difícil para los miembros de un equipo
comunicase y colaborar para el desarrollo exitoso de un sistema.
Los lenguajes, no siempre se componen de palabras escritas. Por ejemplo,

comúnmente usamos lenguajes de conteo para enseñar a los niños a contar en
las clases de aritmética. Los niños usan entonces objetos como son, peras o
manzanas, para representar algún número.
Ahora considere estos dos lenguajes para comunicar algún número en específico
o días que dura un proyecto. Para representar el número cinco, un lenguaje de
conteo utiliza cinco objetos, mientras que un lenguaje aritmético se utiliza la
cadena "5".
Figura 2-2. La cantidad cinco en dos “lenguajes”
UML es un lenguaje para especificar, visualizar construir y documentar los artifacts

del sistema intensivo de procesos.
UML en si no es un proceso, un proceso implica un conjunto de pasos descritos

por una metodología para resolver un problema y desarrollar un sistema que
satisfaga los requerimientos de un usuario.
2.1.1.2 Modelo
Un modelo es una representación de un tema, éste captura un conjunto de ideas
conocidas como abstracciones. Sin un modelo, es muy difícil para los miembros
del equipo tener un entendimiento común de los requerimientos del sistema, así
como del impacto de los cambios mientras se desarrolla el sistema.
Cuando se crea el modelo, si tratamos de representar todo al mismo tiempo,

fácilmente tendremos una sobrecarga de información, es por eso que hay que
2008/06/18 13/195
concentrarse en capturar solo la información relevante para entender el problema,

resolverlo, e implementar la solución, mientras se excluye cualquier información
que sea irrelevante que pudiera dificultar el progreso del desarrollo.
2.1.1.3 Unificado
Este término se refiere al hecho de que el Grupo de Administración de Objetos
(Object Management Group - OMG) y el Rational Software Corporation, crearon
UML para traer las mejores prácticas de ingeniería a la industria de tecnología y
de los sistemas de información. Sin un lenguaje en común, es difícil para los
nuevos miembros de un equipo volverse productivos rápidamente y contribuir en el
desarrollo de un sistema.
2.1.2 Metas y Alcances

Para entender las metas y los alcances de la OMG para UML, es mejor empezar
por las motivaciones detrás de UML. Las metas de los OMG’s que hicieron UML
son:
• Listo para usarse
• Expresivo
• Simple
• Preciso
• Extensible
• Independiente de la implementación
• Independiente del proceso
Estando listo para usarse, siendo expresivo, simple y preciso, UML puede
inmediatamente ser aplicado para el desarrollo de proyectos. Para habilitar el
desarrollo de modelos precisos, la OMG presenta el Lenguaje de Restricciones de
Objetos (Object Constraint Language - OCL), un sublenguaje para adherir
condiciones que los elementos del modelo deben satisfacer para que el mismo
modelo sea considerado correcto.
En cuanto a los alcances de la OMG al momento de la creación de UML fue incluir

un lenguaje de modelado que combina tres de los más importantes métodos de
desarrollo de sistemas:
• El Método Booch `93 de Grady Booch.
2008/06/18 14/195
• La Técnica de Modelado de Objetos (Object Modeling Technique - OMT) de

James Rumbaugh.
• El método de Ingeniería de Software Orientado a Objetos (Object-Oriented

Software Engineering - OOSE) de and Ivar Jacobson.
En conjunto con las mejores prácticas de la industria de tecnología y de sistemas

de información. De manera separada son sólo eso, métodos, pero al unirlos
conforman una metodología.
2.1.3 Historia
La historia de UML consiste de cinco Períodos distintos. Al entender esos
Períodos se puede entender como surgió UML y como esta evolucionando en
estos momentos.
2.1.3.1 El Período de Fragmentación

Entre la mitad de 1970 y la mitad de 1990, las organizaciones comenzaron a
entender el valor del software para los negocios, pero solo tenía una colección
fragmentada de técnicas para desarrollar y dar mantenimiento al software. Tres
métodos sobresalieron:
• El Método Booch `93 de Grady Booch, que hace énfasis en el diseño y

construcción de sistemas de software.
• La Técnica de Modelado de Objetos (Object Modeling Technique - OMT) de

James Rumbaugh, que hace énfasis en el análisis de los sistemas de
software.
• El método de Ingeniería de Software Orientado a Objetos (Object-Oriented

Software Engineering - OOSE) de and Ivar Jacobson, que hace énfasis en
la ingeniería del negocio y el análisis de los requerimientos.
Conforme los métodos orientados a objetos comenzaron a evolucionar desde los

métodos estructurales, la industria se fue fragmentando principalmente alrededor
de estos tres métodos. Los practicantes de un método no podían fácilmente
entender los artifacts producidos por un método diferente. Además estas personas
tenían problemas al pasar de una organización hacia la siguiente debido a que
dicho movimiento implicaba el aprendizaje de un nuevo método.
2.1.3.2 El Período de Unificación

Entre la mitad de 1990 y la mitad de 1997, surgió la versión 1.0 de UML. James
Rumbaugh y posteriormente Ivar Jacobson, se unieron a Grady Booch en la
2008/06/18 15/195
Corporación Rational Software para unificar sus métodos. Por sus esfuerzos de
unión, se les empezo a llamar “Los Tres Amigos”. Conforme las organizaciones
comenzaron a ver el valor de UML, el grupo de trabajo de Diseño y Análisis de
Objetos de la OMG elaboro una Solicitud para una Propuesta (Request for
Proposal - RFP) para establecer un estándar que definiera el significado de los
conceptos de la tecnología orientada a objetos para las herramientas que
soportarían el diseño y el análisis orientado a objetos. En conjunto con varias
organizaciones, la Corporación Rational Software forma un Consorcio de Socios
de UML, y estos socios son los que envían la versión 1.0 de UML a la OMG en
respuesta a uno de los varios RFPs iniciales.
2.1.3.3 El Período de Estandarización

Hacia finales de 1997 se libera la versión 1.1 de UML, todas las replicas a los RFP
fueron combinadas en la versión 1.1 de UML. La OMG adopto UML y asumió la
responsabilidad del desarrollo de la estandarización en noviembre de 1997.
2.1.3.4 El Período de Revisión

Después de la adopción de UML en 1997, varias versiones surgieron. La OMG
realizo un diagrama de las revisiones del grupo de trabajo (revision task force -
RTF) para aceptar comentarios públicos de UML y realizar la menor cantidad de
trabajo editorial y de actualizaciones técnicas al estándar. Varios vendedores
empezaron a dar soporte y promoción de UML con herramientas, consultoría y
libros. La versión actual de UML es la 1.4 y la OMG esta actualmente trabajando
en versión 2.0 de UML.
2.1.3.5 El Período de Industrialización

A la par del período de revisión, los OMG están proponiendo que el estándar de
UML se convierta en una estandarización internacional a través de una
Especificación de Disposición Pública (Publicly Available Specification - PAS) a
través de la Organización Internacional de Estándares(Organization for
Standardization - ISO).
2.2 UML y los Procesos

Aunque UML es independiente del proceso, sus creadores promueven un proceso
que sea dirigido por Casos de Uso (use-case driven), iterativo e incremental. Para
entender como UML esta relacionado con los procesos y los tipos de procesos
que sus creadores proponen, se debe tener un mejor entendimiento acerca de
cuál es la mejor técnica para aprender UML. Sin embargo cualquier tipo de
proceso – incluso aquellos que no tienen estas características – pueden utilizar
UML.
2008/06/18 16/195
Generalmente cada proceso de ciclo de vida en el desarrollo de un sistema,

involucra los siguientes tipos de actividades:
• Requerimientos.
• Actividades de análisis para entender los requerimientos.
• Actividades de diseño para determinar como el sistema va a satisfacer los

requerimientos.
• Actividades de Implementación para la construcción del sistema.
• Actividades de Prueba para verificar que el sistema satisface los

requerimientos.
• Actividades de Deployment para hacer que el sistema sea accesible para

sus usuarios.
2.2.1 Aplicando un Ciclo de Vida en Cascada

Cuando se aplica el ciclo de vida de cascada, las actividades son realizadas de
una manera simple y linear para todos los requerimientos. Esto a veces resulta en
el descubrimiento de problemas relacionados con la calidad, estos problemas se
mantienen escondidos durante las actividades de diseño e implementación.
2.2.2 Aplicando un Ciclo de Vida Iterativo

Cuando se aplica el Ciclo de Vida Iterativo, cada una de las actividades del ciclo
de vida son realizadas varias veces para un mejor entendimiento de los
requerimientos y desarrollar gradualmente un sistema más robusto.
2.2.2.1 Casos de Uso

Un caso de uso es un requerimiento funcional descrito desde la perspectiva del
usuario del sistema. Por ejemplo, un requerimiento funcional para la mayoría de
los sistemas incluye una funcionabilidad de seguridad que les permita a los
usuarios entrar y salir del sistema, agregar datos, procesar datos, generar
reportes, etc.
2.2.2.2 Arquitectura
La arquitectura abarca los elementos que se necesitan para elaborar un sistema y
la manera en que estos trabajan juntos para proveer de funcionabilidad del
sistema. Los elementos y sus relaciones son conocidos como la estructura del
2008/06/18 17/195
sistema. El modelado de la estructura del sistema se conoce como Modelado de la

Estructura. Los elementos y la manera en que estos interactúan y colaboran son
conocidos como el comportamiento del sistema. El modelado del comportamiento
del sistema es conocido como Modelado del Comportamiento. Los distintos tipos
de elementos que constituyen la arquitectura del sistema, estructura y
comportamiento están determinados por el paradigma orientado a objetos.
2.2.2.3 Riesgo
Un riesgo es cualquier obstáculo o incógnita que puede impedir nuestro éxito.
Para determinar que casos de uso deben ser tomados en cuenta para la
realización de una iteración y en que partes de la arquitectura nos tenemos que
concentrar en una iteración en particular, lo primero que se tiene que hacer es
identificar los riesgos del proyecto. Una vez hecho esto se relacionan los riesgos
más importantes con los casos de uso y los elementos de arquitectura que
resolverían dichos riesgos.
2.3 Aprendiendo UML

Aprender UML puede ser un poco abrumador, debido a la amplitud y profundidad
del lenguaje así como a la ausencia de un proceso, si no se sabe sobre que partes
de UML enfocarse. Para poder entender como UML se relaciona con los procesos,
uno se debe concentrar en:
• El paradigma orientado a objetos, porque este establece las bases para

UML.
• El Modelado de la Estructural y el Modelado del Comportamiento, porque

ellos permiten entender los requerimientos y la arquitectura.
• Otras capacidades de UML.
Cuando se aprende UML es importante concentrarse en lo esencial y entender

cómo aplicar UML de manera efectiva y exitosa al modelado de sistemas, en vez
de atascarse en tratar de aprender cada aspecto del lenguaje.
Para lo que resta de los capítulos, se utilizará un caso de uso de un sistema de

administración de proyectos para ayudar a aprender como leer, entender, escribir
y poder aplicar efectiva y exitosamente UML. El objetivo no es crear un modelo
completo o demasiado extenso para la implementación de un sistema, pero si
explorar ese caso de uso y aprender como aplicar efectiva y exitosamente UML
para comunicar en el desarrollo de un sistema del mundo real.
2008/06/18 18/195
Generalmente, en el caso de estudio un sistema de administración de proyectos

provee funcionalidad para manejar proyectos, recursos y administrar el sistema, se
definen los siguientes roles:
• Administrador del Proyecto (Project Manager)

o Es el responsable de asegurar la entrega de un proyecto con calidad,
dentro del tiempo especificado, costo y recursos.
• Administrador de Recursos (Resource Manager)

o Es el responsable de asegurar que el personal disponible en el
proyecto este entrenado y con las habilidades necesarias.
• Recursos Humanos (Human Resource)

o Es el responsable de asegurar que las habilidades se mantienen y
que la calidad del trabajo esta completa para un proyecto.
• Administrador del Sistema (System Administrator)

o Es el responsable de asegurar que un sistema de administración de
proyectos esta disponible para un proyecto.
Conforme se vaya avanzando en los capítulos se ira proveyendo de mas detalle

sobre el caso de estudio donde sea necesario.
2008/06/18 19/195
3 Modelado Orientado a Objetos
3.1 Requerimientos para el manejo del sistema.

Para esta sección se va a utilizar la siguiente descripción parcial de
requerimientos, que abarca una parte muy pequeña del caso de estudio del
sistema de administración de proyectos que se va a utilizar como ejemplo:
• El administrador del proyecto utiliza el sistema de administración de

proyectos para manejar un proyecto. El administrador del proyecto dirige al
equipo para que lleve a cabo el proyecto dentro de las fechas de inicio y fin
de dicho proyecto, una vez que el proyecto es creado en el sistema de
administración de proyectos, el administrador puede iniciarlo, y
posteriormente terminarlo, una vez que se haya completado o por cualquier
otra razón.
• Como entrada un proyecto recibe requerimientos, y como salida, un

proyecto produce un sistema. Tanto los requerimientos como el sistema son
productos de trabajo, es decir productos que son creados, usados,
optimizados y elaborados durante el proyecto. Cada uno de estos productos
tienen una descripción, un porcentaje de completado (que se mide a través
de un esfuerzo) y pueden ser validados. Sin embargo la validación depende
del tipo de producto de trabajo. Por ejemplo los requerimientos son
validados por los usuarios en juntas de trabajo y el sistema es validado a
través de pruebas que comparan el sistema versus los requerimientos.
Adicionalmente, los requerimientos pueden ser publicados utilizando
diferentes tipos de medios, por ejemplo a través de una intranet o en papel;
los sistemas pueden ser colocados en plataformas específicas.
• El sistema de administración de proyectos debe manejar el siguiente

escenario. Juan quien es un administrador de proyectos, maneja tres
proyectos, que se llaman, Águila, Halcón, y Cóndor. Todos los proyectos
involucran equipos anónimos o sin nombre. El proyecto Águila esta
desarrollando un sistema de administración de proyectos, similar al que se
esta utilizando de ejemplo. El proyecto Halcón esta utilizando la plataforma
Java para producir otro tipo de sistema, que esta dirigido hacia un amplio
mercado. El proyecto Cóndor esta utilizando la plataforma Microsoft .Net
para producir un sistema similar al del proyecto Halcón, pero este tiene
requerimientos específicos de organización adicionales. Por consiguiente
los proyectos Halcón y Cóndor comparten requerimientos comunes.
• Cuando se crea un proyecto, el administrador de proyectos utiliza un

interfaz de usuario para ingresar sus datos para poder ser contactado
(como mínimo su nombre y tu número de teléfono), el nombre del proyecto,
la fecha de inicio y de fin, y una descripción de los requerimientos y del
sistema, así como una descripción del equipo. Una vez que la información
2008/06/18 20/195
requerida es ingresada, el sistema procesa adecuadamente la solicitud

guardando la información y confirmando la operación. Inicialmente, el
proyecto se encuentra inactivo. Este se activa cuando los recursos
humanos son asignados al proyecto, y puede volverse inactiva nuevamente
si los recursos humanos son retirados de dicho proyecto, y es removido del
sistema una vez que es completado.
• Para propósitos de auditoria y seguridad el sistema, el sistema de

administración de proyectos esta conformado por dos partes, una interfaz
de usuario y una base de datos. La base de datos del sistema de
administración de proyectos se ejecuta en un servidor central. La interfaz de
usuario del sistema de administración de proyectos se ejecuta en
computadoras de escritorio (clientes), dichas computadoras tienen acceso a
una impresora y utilizan la base de datos para guardar información
relacionada con el proyecto.
3.2 Alfabetos, Palabras y Sentencias

Debido a que las tecnologías de requerimientos y de implementación son
complejas y están en constante cambio, un lenguaje no solo nos facilita la
comunicación sino que además nos hace capaces de una mejor administración de
los cambios y la complejidad. Un lenguaje esta basado en un paradigma, una
manera de ver al sujeto, que define los tipos de conceptos que pueden ser usados
en el lenguaje y los principios para entender porque son útiles. La sintaxis de UML
incluye diagramas y su semántica esta basada en el paradigma de la orientación a
objetos.
3.2.1 Alfabeto
Un alfabeto define las partes más simples de un lenguaje: letras, caracteres,
signos y etiquetas. El alfabeto de UML esta conformado por fragmentos de
símbolos (rectángulos, líneas y otros elementos gráficos) y cadenas de caracteres.
Estos no tienen significado por si mismos, las unidades mas pequeñas que tienen
un significado en un lenguaje son las “Palabras”.
3.2.2 Palabras
Una palabra es una agrupación de elementos del alfabeto del lenguaje que
definen una unidad con significado. En UML las palabras se agrupan en dos
categorías o tipos:
• Conceptos:
o Son mostrados en rectángulos cuyas líneas externas son continuas o
símbolos etiquetados con un nombre.
2008/06/18 21/195
• Relaciones entre conceptos:

o Son mostrados como líneas unen símbolos etiquetados con un
nombre.
Adicionalmente a los nombres, conceptos y relaciones, se pueden tener otras

cadenas de caracteres relacionados con estos para especificar más información.
La Figura 3-1 muestra varios conceptos que fueron identificados en los

528H
requerimientos del sistema de administración de proyectos, al analizar los

sustantivos, se incluyen Proyecto, Administrador, Equipo, ProductoDeTrabajo,
Requerimiento y Sistema.
Figura 3-1. Conceptos
ProductoDeTrabajo
Requerimiento Sistema
Proyecto
Equipo Administrador
Así mismo la Figura 3-2 muestra varias de las relaciones que fueron identificadas
529H
en los requerimientos del sistema de administración de proyectos, al analizar los

verbos, se incluyen Administrar, Dirigir, Ejecutar, Entrada y Salida.
Figura 3-2. Relaciones
Usualmente ni las relaciones ni los conceptos son mostrados de manera

separada, cuando se combinan, es cuando se generan las palabras y sentencias
de UML.
3.2.3 Sentencias
Una sentencia es una agrupación de palabras del vocabulario del lenguaje que
define una unidad gramatical que contiene significado y una expresión sobre el
2008/06/18 22/195
tema. La gramática de un lenguaje especifica las reglas para poder combinar las
palabras y formar sentencias. Las sentencias en UML son fragmentos de
diagramas o diagramas muy simples.
La Figura 3-3 muestra una sentencia de UML que comunica que un equipo
530H
desarrollara un proyecto como es indicado en los requerimientos del sistema de

administración de proyectos. Equipo y Proyecto son conceptos (sustantivos), y
Desarrollar es una relación (verbo) entre dos conceptos.
Figura 3-3. Un equipo desarrollara un proyecto
Equipo
Ejecuta
Proyecto
La Figura 3-4 muestra una sentencia de UML un poco mas elaborada en la un

531H
Administrador administra un Proyecto y dirige un Equipo.
Figura 3-4. Un Administrador maneja un proyecto y dirige un equipo (versión 1)
Administrador
Dirige Administra
Equipo Proyecto
La ubicación de los conceptos y de las relaciones no tiene ningún significado

especial, así como que los símbolos sean colocados uno dentro de otro.
Usualmente una relación se lee de izquierda a derecha y de arriba hacia abajo,
aunque a una relación se le puede agregar un pequeño triángulo a manera de
flecha, de tal manera que la punta de la flecha indica la dirección en la que se
debe leer el nombre, esta flecha se coloca sólo para propósitos descriptivos, y el
nombre de la relación debería ser entendido a través del significado de los
conceptos relacionados.
2008/06/18 23/195
Figura 3-5. Un Administrador maneja un proyecto y dirige un equipo (versión 2)
Equipo Dirige Administrador Administra Proyecto
3.3 El Paradigma de la Orientación a Objetos
3.3.1 Conceptos
El paradigma Orientado a Objetos se basa en algunos conceptos que nos
permiten observar el mundo a nuestro alrededor, en las siguientes secciones se
detallan esos conceptos.
3.3.1.1 Clases, Asociaciones, Objetos y Ligas

La Figura 3-3 y la Figura 3-5 representan sentencias generales, debido a que no
532H 53H
identifican a ningún proyecto, administrador o equipo en particular. Los conceptos

generales mostrados en las sentencias son conocidos como clases y las
relaciones generales como asociaciones. De manera similar a los lenguajes
naturales, se puede comunicar en UML utilizando sentencias que involucran
proyectos, administradores y equipos específicos, los conceptos específicos son
conocidos como objetos y las relaciones específicas son conocidas como ligas.
Una clase define el tipo de objeto y las características de dicho objeto, y un objeto
es la instancia de una clase. La Figura 3-4 y la Figura 3-5 muestran tres clases,
534H 53H
que incluyen Administrador, Equipo y Proyecto. Se pueden tener numerosos

administradores, equipos, y proyectos y cada administrador, equipo, y proyecto
específico es una instancia u objeto para su clase. En UML un concepto específico
es mostrado utilizando el mismo símbolo que el concepto general. El símbolo es
etiquetado con un nombre específico seguido por dos puntos y el nombre de su
concepto general. La cadena completa (el nombre específico, los dos puntos, y el
nombre general) son subrayados. La Figura 3-6 muestra una clase específica para
536H
cada uno de los objetos que fueron mostrados en la Figura 3-4 y la Figura 3-5. 537H 538H
Una asociación define un tipo específico de liga, las características de la misma y

una liga es una instancia de una asociación. Una relación específica se muestra
como una línea sólida y puede estar etiquetada con el nombre de su relación
general subrayado. La Figura 3-6 muestra ligas específicas de las asociaciones
539H
mostradas en la Figura 3-4 y la Figura 3-5.

540H 541H
2008/06/18 24/195
Figura 3-6. Juan Maneja el proyecto Águila y dirige un equipo anónimo
Juan : Administrador
Dirige Administra
: Equipo Águila : Proyecto
El Paradigma Orientado a Objetos ve el mundo como una colección de objetos

únicos, usualmente referenciado como sociedad de objetos. Cada objeto tiene su
ciclo de vida en el cual conoce algo, realiza algo y se comunica con otros objetos.
Lo que un objeto sabe y realiza se conoce como características. Las
características se dividen en dos tipos o categorías: atributos y operaciones.
3.3.1.2 Atributos
Aquello que un objeto conoce es llamado Atributo, que esencialmente
representada datos. Una clase define los atributos y los objetos tienen valores
para estos atributos, aún si dos objetos tienen los mismos valores para sus
atributos estos son únicos y tienen su propia identidad. Las asociaciones y los
atributos son conocidos como características estructurales.
La Figura 3-7 elaborada a partir de la Figura 3-4, muestra que un Administrador

542H 543H
tiene un nombre, un equipo tiene una descripción y un proyecto tiene un nombre,

FechaDeInicio, y FechaDeFin.
Figura 3-7. Clases sin atributos
Administrador
Nombre
Dirige Administra
Proyecto
Equipo Nombre
Descripción FechaDeInicio
FechaDeFin
La Figura 3-8 elaborada a partir de la Figura 3-6, muestra varios objetos con
54H 54H
valores en sus atributos.
2008/06/18 25/195
Figura 3-8. Clases con valores en los atributos
- Nombre = "Juan Castillo Salómon"
Dirige Administra

- Descripción = "Equipo que incluye análistas, usuarios - FechaDeFin = Enero 1, 2003
finales, arquitectos, diseñadores, - FechaDeInicio = Enero 1, 2002
desarrolladores y examinadores" - Nombre = "Eagle"
3.3.1.3 Operaciones y métodos

Aquello que el objeto puede realizar es llamado operación o especificación y
esencialmente representa un proceso. La manera en que un objeto lleva a cabo el
proceso para una operación en particular es conocida como implementación o
método. Una clase define operaciones y métodos que aplican a sus objetos. Una
clase puede mostrarse con un tercer compartimiento que lista estas operaciones
como texto. Los métodos de una clase (el código que implementa las operaciones)
no es mostrada en una clase, pero puede ser descrito utilizando otras técnicas de
modelado de UML. Los objetos carecen de ese tercer compartimiento, debido a
que todos los objetos de una clase tienen las mismas operaciones y comparten
sus métodos de clase. Los métodos y las operaciones son conocidos como
características de comportamiento.
Para mostrar dos operaciones, IniciarProyecto y TerminarProyecto, la Figura 3-9 546H
muestra que un administrador puede iniciar o terminar un proyecto. El

compartimiento de atributos esta vació debido a que ese diagrama se enfoca sólo
en las operaciones.
2008/06/18 26/195
Figura 3-9. Clases con operaciones
Administrador
IniciarProyecto()
TerminarProyecto()
Dirige Administra
Equipo Proyecto
La Figura 3-10 muestra atributos y operaciones para cada clase en el mismo

547H
diagrama.
Figura 3-10. Clases con operaciones y atributos
Administrador
Nombre
IniciarProyecto()
TerminarProyecto()
Dirige Administra
Proyecto
Equipo Nombre
Descripción FechaDeInicio
FechaDeFin
3.3.1.4 Mensajes y Estímulos

En el Paradigma Orientado a Objetos, la comunicación de un objeto emisor hacia
un objeto receptor se utiliza para transmitir información o solicitar un proceso. El
envío de una petición y de una recepción de una solicitud se conoce como evento
u ocurrencias. La comunicación entre objetos mediante sus ligas es conocido
como un estimulo, y la comunicación entre clases a través de sus asociaciones es
conocido como mensaje. Un estímulo es una instancia de un mensaje de manera
similar en que un objeto es una instancia de una clase y una liga es una instancia
2008/06/18 27/195
de una asociación. El transmisor se le conoce como cliente, y el receptor es

conocido como proveedor. El mensaje o estimulo es representado a través de una
flecha relacionada con una asociación o a una liga que apunta del transmisor
hacia el receptor y etiquetado con un número secuencial que muestra el orden en
el que el mensaje o estímulo es enviado, seguido de dos puntos, seguidos del
nombre de la operación que es invocada.
La Figura 3-11 muestra a un administrador asignando actividades y tareas a un

548H
equipo basado en los requerimientos de un proyecto.
Figura 3-11. Interacción General
Administrador
2: asignarActividades 1: obtenerRequerimientos
3: asignarTareas
Equipo Proyecto
La Figura 3-12 muestra la interacción específica entre Juan (quien es el

549H
Administrador), el proyecto Águila y el equipo.
Figura 3-12. Interacción Específica
2: asignarActividades
1: obtenerRequerimientos
3: asignarTareas
2008/06/18 28/195
3.3.2 Principios
El paradigma Orientado a Objetos se basa en cuatro principios que nos permiten
un mejor manejo del cambio y la complejidad. En las siguientes secciones se
hablan de ellos.
3.3.2.1 Abstracciones
Los conceptos y las relaciones son conocidos como abstracciones. Las clases y
las asociaciones son abstracciones generales, mientras que los objetos y las ligas
son abstracciones especificas. Una buena abstracción esta bien definida e incluye
información esencial para entenderla, pero excluye cualquier información
irrelevante o eventual. Al utilizar abstracciones bien definidas, se puede manejar
mejor la complejidad al enfocarse sobre lo que es esencial y no distraerse con lo
que es irrelevante.
3.3.2.2 Encapsulación
Combinar los atributos y operaciones para formar clases y objetos escondiendo
los métodos detrás de las operaciones es conocido como encapsulación.
Combinar los atributos y las operaciones para formar clases y objetos también es
conocido como localización. Al combinar atributos y operaciones en unidades
independientes, se puede administrar mucho mejor el cambio y la complejidad al
reducir el número de lugares que se tienen que considerar cuando un cambio
ocurre.
Cuando las clases o los objetos se comunican, el cliente usualmente sólo se

interesa en los resultados de la operación y no en el método que él proveedor
utiliza para realizar la operación; de esa manera un método puede ser escondido
de sus clientes. Un atributo también puede ocultarse o volverse inaccesible para
sus clientes, de tal manera que sólo pueda ser accesado a través de las
operaciones, llamados sets y gets, estos recuperan y asignan el valor de un
atributo.
Esconder un método detrás de una operación se le conoce como ocultar

Información. Hacer esto nos permite un mejor manejo del cambio y la complejidad,
debido a que es posible modificar el método de una clase sin impactar a sus
clientes, aquellos que utilizan la implementación de la operación a través del
método.
3.3.2.3 Generalización
2008/06/18 29/195
La Figura 3-13 muestra las clases que representan los requerimientos y los
50H
sistemas basados en los requerimientos del caso de estudio del sistema de

administración de proyectos. Hay que destacar que tanto los requerimientos como
los sistemas son productos de trabajo con algunos atributos y operaciones en
común pero con diferentes métodos para su validación, y varios atributos únicos
para sus clases. Se puede utilizar la generalización para capturar y reutilizar lo que
es común en ambas clases. Una Generalización es utilizada entre una clase
general y una clase específica para indicar que la clase específica recibe los
atributos, las relaciones, operaciones y métodos de la clase general. Una
generalización es mostrada por una línea continua que va de la clase específica
hacia la clase general, con un triángulo largo y vacío al final de la línea que
conecta con la clase general.
Figura 3-13. Requerimientos del Proyecto y los Sistemas
PorcentajeCompletado PorcentajeCompletado
Descripción Descripción
Media Plataforma
Validar() Validar()
Publicar() Deploy()
La Figura 3-14 muestra como se utiliza una generalización para comunicar que
51H
tanto los requerimientos como los sistemas son productos de trabajo, que tienen
una descripción, un porcentaje de avance y que pueden ser validados.
2008/06/18 30/195
Figura 3-14. Productos de Trabajo del Proyecto, Requerimientos y Sistemas
ProductoDeTrabajo
PorcentajeCompletado
Descripción
Validar()
PorcentajeCompletado PorcentajeCompletado
Descripción Descripción
Media Plataforma
Validar() Validar()
Publicar() Deploy()
3.3.2.4 Polimorfismo
En la Figura 3-14 se muestra la operación Validación, ésta aparece en todas las
52H
clases, esta operación es definida en la clase Producto de Trabajo, quizás con un

método por defecto, y las clases de Requerimiento y Sistema tienen sus propios
métodos para la validación. La habilidad de tener varios métodos para una sola
operación es conocida como poliformismo.
3.4 Párrafos
Un párrafo es un grupo de sentencias con un tema en común, los párrafos de UML
son los diagramas, un diagrama es una colección de sentencias de UML. Los
elementos que conforman un diagrama son conocidos como elementos de
diagrama.
El tema principal sobre el que se quiere comunicar un sistema que reside en un

dominio. Al domino también se le conoce como contexto, es un área amplia de
interés que tiene una colección generalmente aceptada de conceptos y relaciones.
Los conceptos son clases y sus relaciones con asociaciones, ambos son
conocidos como elementos del dominio.
Un sistema es una colección de elementos organizados para un propósito

específico, estos son conocidos como elementos de un sistema. Para entender un
sistema, tenemos que enfocarnos en su arquitectura. La arquitectura de un
2008/06/18 31/195
sistema incluye a todos los elementos que conforman dicho sistema y la manera
en que estos trabajan juntos para proveer la funcionalidad. Los elementos más
importantes que componen un sistema son conocidos como elementos de
arquitectura. Los elementos de un sistema y sus relaciones definen la estructura
del sistema, la manera en que interactúan y colaboran define el comportamiento
del sistema.
Los sistemas pueden descomponerse recursivamente en sistemas más pequeños,

llamados subsistemas y elementos primitivos. Cada subsistema a su vez se puede
descomponer en subsistemas y elementos primitivos, cuando ya no se pueden
descomponer más, tenemos únicamente elementos primitivos. Los elementos
primitivos no se pueden descomponer más.
Cuando los elementos primitivos de un sistema o subsistema son objetos, el

sistema es considerado un sistema orientado a objetos. Cuando los elementos
primitivos son simples datos, funciones o procedimientos, el sistema es
considerado no orientado a objetos.
En UML los diagramas se agrupan en dos categorías o tipos: de estructura o de

comportamiento.
3.4.1 Modelado de Estructura

El modelado de estructura nos ayuda a entender y comunicar los elementos que
conforman un sistema y la funcionalidad que éste sistema provee.
3.4.1.1 Diagramas de Clases

Describen la estructura de un sistema en general, están conformados por los
siguientes elementos:
• Una clase
o Esta representado a través de un rectángulo cuyas líneas externas
son continuas, etiquetado con un nombre, éste representa un
concepto general.
• Una asociación
o Esta representada por una línea continua, etiquetada con un nombre,
ésta representa una relación entre las clases.
• Un atributo
o Esta representado como una cadena de texto en el segundo
compartimiento de una clase, éste representa los que los objetos de
una clase conocen.
• Una operación
2008/06/18 32/195
o Esta representada como una cadena de texto en el tercer

compartimiento de una clase, ésta representa lo que los objetos de la
clase se pueden hacer.
La Figura 3-15 esta basada en el siguiente párrafo de la descripción de

53H
requerimientos proveída al inicio de este capítulo (ver sección 3.1), y combina

54H
muchas de las sentencias discutidas en las secciones anteriores:
• El administrador del proyecto utiliza el sistema de administración de

proyectos para manejar un proyecto. El administrador del proyecto dirige al
equipo para que lleve a cabo el proyecto dentro de las fechas de inicio y fin
de dicho proyecto, una vez que el proyecto es creado en el sistema de
administración de proyectos, el administrador puede iniciarlo, y
posteriormente terminarlo, una vez que se haya completado o por cualquier
otra razón.
• Como entrada un proyecto recibe requerimientos, y como salida, un

proyecto produce un sistema. Tanto los requerimientos como el sistema son
productos de trabajo, es decir productos que son creados, usados,
optimizados y elaborados durante el proyecto. Cada uno de estos productos
tienen una descripción, un porcentaje de completado (que se mide a través
de un esfuerzo) y pueden ser validados. Sin embargo la validación depende
del tipo de producto de trabajo. Por ejemplo los requerimientos son
validados por los usuarios en juntas de trabajo y el sistema es validado a
través de pruebas que comparan el sistema versus los requerimientos.
Adicionalmente, los requerimientos pueden ser publicados utilizando
diferentes tipos de medios, por ejemplo a través de una intranet o en papel;
los sistemas pueden ser colocados en plataformas específicas.
Estos párrafos (ver sección 3.1), describen algunas de las clases que conforman
5H
el sistema de administración de proyectos. Se puede comunicar esta información

en un único diagrama que se muestra en la Figura 3-15, o a través de múltiples
56H
diagramas, tal como se hizo al inicio de éste capítulo.
2008/06/18 33/195
Figura 3-15. Diagrama de Clases
ProductoDeTrabajo
Descripción
Validar()
Sistema
Requerimiento
Descripción
Descripción
Plataforma
Media
Validar()
Validar()
Deploy()
Publicar()
Entrada Proyecto Salida

Nombre
FechaDeInicio
FechaDeFin
Ejecuta
Administrar
Administrador Equipo
Nombre Dirige Descripción
Telefono
IniciarProyecto()
TerminarProyecto()
3.4.1.2 Diagrama de Objetos

Describen la estructura del sistema en un punto en el tiempo en particular, están
conformados por los siguientes elementos:
• Un objeto:
o Está representado por un rectángulo cuyas líneas externas son
continuas, etiquetado con un nombre seguido por dos puntos, que a
su vez son seguidos por el nombre de su clase, todo lo anterior
subrayado, éste representa un concepto específico. Ambos nombres
son opcionales, y los dos puntos están presentes sólo si la clase es
especificada.
2008/06/18 34/195
• Una liga:
o Esta representada por una línea continua, etiquetada con un nombre
de su asociación subrayado, ésta representa una relación específica
entre los objetos.
• Un valor de atributo:
o Esta representado por una cadena de texto seguida por un símbolo
de igual y su valor en el segundo compartimiento de un objeto, esto
representa lo que un objeto sabe.
La Figura 3-16 se basa en el siguiente párrafo de la descripción de los

57H
requerimientos que fue proporcionado al inicio de este capítulo (ver sección 3.1): 58H
• El sistema de administración de proyectos debe manejar el siguiente

escenario. Juan quien es un administrador de proyectos, maneja tres
proyectos, que se llaman, Águila, Halcón, y Cóndor. Todos los proyectos
involucran equipos anónimos o sin nombre. El proyecto Águila esta
desarrollando un sistema de administración de proyectos, similar al que se
esta utilizando de ejemplo. El proyecto Halcón esta utilizando la plataforma
Java para producir otro tipo de sistema, que esta dirigido hacia un amplio
mercado. El proyecto Cóndor esta utilizando la plataforma Microsoft .Net
para producir un sistema similar al del proyecto Halcón, pero este tiene
requerimientos específicos de organización adicionales. Por consiguiente
los proyectos Halcón y Cóndor comparten requerimientos comunes.
El párrafo anterior describe una situación específica que el sistema de

administración de proyectos debe ser capaz de manejar utilizando las diferentes
clases que componen el sistema.
2008/06/18 35/195
Figura 3-16. Diagrama de Objetos

Entrada Salida
Cliente-Req: Proyecto:Condor Solución Dot-Net:
Requerimientos Sistema
Administra Entrada
Ejecuta
:Equipo
RequerimientosEnComun:
Maneja Requerimiento
:Equipo
Maneja
Ejecuta Entrada
Solución
Administra Halcon:Proyecto Java:Sistema
Salida
Maneja
Juan:Administrador :Equipo
Nombre = “Juan Castillo Salomón ” Descripción = “Este es el equipo del proyecto Águila”
Ejecuta
Maneja Proyecto:Águila
Nombre = “Águila”
FechaDeInicio = Enero 1, 2002
Entrada FechaDeFin = Enero 1, 2003
:Requerimientos Salida
Porcentaje Completado = 50
Descripción = “Este es el requerimiento :Sistema
Para el proyecto de administración de sistema”
Media = “Paper” Porcentaje Completado = 50
Descripción = “Este es el proyecto
de administración de sistema”
3.4.1.3 Diagramas de Caso de Uso

Describen la funcionalidad de un sistema, esta conformado por los siguientes
elementos:
• Un Actor
o Esta representado por un icono de una figura de madera, éste
representa usuarios y a los sistemas externos con que los que el
sistema que se va a desarrollar va a interactuar.
• Un caso de uso
o Esta representado por una elipse, este representa un requerimiento
funcional que es descrito desde la perspectiva de los usuarios de un
sistema.
• Una asociación de comunicación

o Esta representado por una línea continua entre un actor y un caso de
uso, ésta representa que el actor utiliza el caso del uso.
2008/06/18 36/195
La Figura 3-17 se basa en el siguiente fragmento del párrafo de la descripción de

59H
los requerimientos que fue proporcionado al inicio de este capítulo (ver sección
3.1):
560H
• Un administrador del proyecto utiliza el sistema de administración de

proyectos para administrar un proyecto.
Lo anterior identifica funcionalidad específica que el sistema de administración de

proyectos debe proveer a sus usuarios.
Figura 3-17. Diagrama de Caso de Uso
AdministradorDel AdministrarProyecto
Proyecto
3.4.1.4 Diagramas de Componentes

Son conocidos también como diagramas de implementación, estos describen la
implementación de un sistema, están conformados por los siguientes elementos:
• Un componente
o Esta representado como rectángulo con dos rectángulos pequeños
que resalen de uno de sus lados, éste representa una parte del
sistema que existe mientras que el sistema se está ejecutando.
• Una relación de dependencia

o Esta representado por flecha punteada que une un componente
cliente con un componente proveedor, éste representa que un
componente cliente utiliza o depende de un componente proveedor.

561H
3.1):
562H
• Para propósitos de auditoria y seguridad, el sistema de administración de

proyectos esta conformado por dos partes, una interfaz de usuario y una
base de datos.
El párrafo anterior describe como el sistema de administración de proyectos es

implementado cuando éste es ejecutado.
2008/06/18 37/195
Figura 3-18. Diagrama de Componentes
Sistema
DeAdministración
DeProyectos
BaseDeDatos
Mientras que el paradigma orientado a objetos se enfoca en el uso de objetos, el

paradigma basado en componentes, se enfoca en el uso de componentes. Ambos
paradigmas se basan en los principios de abstracción, encapsulación,
generalización y poliformismo.
3.4.1.5 Diagramas de Deployment

Son conocidos también como diagramas de implementación, estos describen el
ambiente de implementación de un sistema. Se debe observar que tanto los
diagramas de componentes como de deployment son tipos específicos de
diagramas de implementación, están conformados por los siguientes elementos:
• Un nodo
o Esta representado por rectángulo tridimensional, éste representa un
recurso que se encuentra disponible durante tiempo de ejecución. Un
componente que reside en un nodo es anidado dentro de dicho
nodo.
• Una asociación de comunicación

o Esta representada por una línea continua, entre dos nodos, ésta
representa un camino de comunicación entre los nodos.

563H
3.1):
564H
2008/06/18 38/195
• La base de datos del sistema de administración de proyectos se ejecuta en

un servidor central. La interfaz de usuario del sistema de administración de
proyectos se ejecuta en computadoras de escritorio (clientes), dichas
computadoras tienen acceso a una impresora y utilizan la base de datos
para guardar información relacionada con el proyecto.
Figura 3-19. Diagrama de Deployment
3.4.2 Modelado de Comportamiento

Ayuda a entender y a comunicar como interactúan y colaboran los elementos para
proveer funcionalidad al un sistema. UML soporta varios diagramas que se utilizan
para el modelado del comportamiento, en las siguientes secciones se detalla esa
información.
3.4.2.1 Diagramas de Secuencia

Son conocidos también como diagramas de interacción, estos describen como los
elementos interactúan a través del tiempo, están conformados por los siguientes
elementos:
• Clases y objetos
o Las clases son mostradas de manera muy similar a la que son
presentadas en los diagramas de clase. Los objetos también pueden
ser presentados de igual manera en la que son presentados en los
diagramas de objetos.
• Una línea de vida
2008/06/18 39/195
o Esta representada por una línea vertical punteada que se origina en

un elemento, ésta representa la existencia de un elemento a través
del tiempo.
• Una comunicación
o Esta representada como una flecha continua que se dibuja desde la
línea de vida del emisor hacia la línea de vida del receptor, se
etiqueta con el nombre de la operación que es invocada, ésta que el
mensaje o estímulo que envía el emisor hacia el receptor.

56H
3.1):
56H
• Cuando se crea un proyecto, el administrador de proyectos utiliza un

interfaz de usuario para ingresar sus datos para poder ser contactado
(como mínimo su nombre y tu número de teléfono), el nombre del proyecto,
la fecha de inicio y de fin, y una descripción de los requerimientos y del
sistema, así como una descripción del equipo. Una vez que la información
requerida es ingresada, el sistema procesa adecuadamente la solicitud
guardando la información y confirmando la operación.
El párrafo anterior describe un escenario específico de las clases y los objetos que
conforman el sistema de administración de proyectos y que a su vez debe ser
capaz de manejar.
2008/06/18 40/195
Figura 3-20. Diagrama de Secuencia
3.4.2.2 Diagramas de Colaboración

Son conocidos también como diagramas de interacción, estos describen como los
elementos interactúan a través del tiempo y como es que están relacionados. Se
debe observar que tanto los diagramas de secuencia y colaboración son tipos
específicos de diagramas de interacción, están conformados por los siguientes
elementos:
• Clases y objetos
o Las clases son mostradas de manera muy similar a la que son
presentadas en los diagramas de clase. Los objetos también pueden
ser presentados de igual manera en la que son presentados en los
diagramas de objetos.
• Asociaciones
2008/06/18 41/195
o Estas son mostradas de la misma manera a la que son mostradas en

los diagramas de clase. Las ligas también pueden ser mostradas de
la misma manera en que son mostradas en los diagramas de
objetos.
• Una Comunicación
o Esta es representada por una flecha que se dibuja cerca de la
relación apuntando del emisor hacia el receptor. Se etiqueta con un
número secuencial que muestra el orden en el cual la comunicación
se realiza, seguido de dos puntos, que a su vez son seguidos por el
nombre de la operación que se invoca. Ésta representa el mensaje
que es enviado del emisor hacia el receptor.
La Figura 3-21 se basa en el mismo fragmento del párrafo de la descripción de los

567H
requerimientos que fue proporcionado al inicio de este capítulo (ver sección 3.1) 568H
que la Figura 3-20, pero incluye relaciones adicionales.

569H
Figura 3-21. Diagrama de Colaboración
InterfazDe
Usuario Equipo
1: IngresarNombre
Administrador 2: IngresarTelefono
DelProyecto 3: IngresarNomAdministrador
4: IngresarFechaInicio 10: PeticiónDel
5: IngresarFechaFin Proceso
6: IngresaDscReq 18: asignar
7: IngresarDscSistema DscEquipo
8: IngresarDscEquipo
9: Enviar 19: Confirmar
ParaTerminar
Manejador
AdministradorDelProyecto 17: asignar
DscSistema
Sistema
11: asignarNom 13: asinar

Administrador NomProyecto
16: asignar
14: asignar DscReq
FechaInicio
12: asignar
Telefono
15: asignar
FechaFin
Administrador Proyecto Requerimiento
2008/06/18 42/195
3.4.2.3 Diagramas de Estado

Son conocidos también como diagramas de diagrama de transición de estados,
estos describen el ciclo de vida de un elemento, están conformados por los
siguientes elementos:
• Un estado
o Esta representado por un rectángulo con esquinas redondeadas,
éste representa una condición o situación de un elemento.
• Un evento
o Es un acontecimiento al recibir un mensaje.
• Una transición
o Esta representada por una línea sólida que se dibuja desde el estado
fuente hacia el estado destino etiquetado con un evento, ésta
representa que si un elemento que se encuentra en el estado fuente
y ocurre el evento, dicho estado pasara al estado destino.
• Un estado inicial
o Es cuando un elemento es creado, este ingresa en su estado inicial,
es representado por un círculo pequeño y sólido. La transición que
se origina desde el estado inicial puede ser etiquetada con el evento
que crea el elemento.
• Un estado final
o Es cuando un elemento ingresa a su estado final y es destruido, es
representado por un círculo que rodea a otro círculo pequeño y
sólido. La transición hacia el estado final puede ser etiquetada con el
evento que destruye al elemento.

570H
3.1):
571H
• Inicialmente, el proyecto se encuentra inactivo. Este se activa cuando los

recursos humanos son asignados al proyecto, y puede volverse inactiva
nuevamente si los recursos humanos son retirados de dicho proyecto, y es
removido del sistema una vez que es completado.
Aquí se describe el ciclo de vida de un objeto proyecto que conforma el sistema

de administración de proyectos.
2008/06/18 43/195
Figura 3-22. Diagrama de Estado
AsignarRecursos
Crear Activo Completar

Inactivo
DesasignarRecursos
3.4.2.4 Diagramas de Actividad

Describen las actividades y responsabilidades de los elementos, esta conformado
por los siguientes elementos:
• Una estado
o Esta representado por una figura de líneas rectas arriba y abajo, y
dos arcos a los lados, éste representa procesamiento.
• Una transición de control de flujo

o Esta representado por una línea sólida que se dibuja desde estado
fuente hacia el estado destino, ésta representa que una vez que el
estado fuente ha completado su procesamiento el estado destino
comienza su procesamiento.
• Una estado inicial

o Esta representado por un círculo pequeño y sólido, ésta representa
cual es el primer estado a través de una transición de flujo de control
que se origina desde el estado inicial hacia dicho estado.
• Una estado final

o Esta representado por un círculo que rodea a otro círculo pequeño y
sólido, ésta representa cual es el estado final a través de una
transición de flujo de control desde dicho estado.
• Un flujo de objeto
o Esta representado por una flecha punteada entre un estado y un
objeto, ésta representa que estado es el que recibe o envía dicho
objeto. Un flujo de objeto de entrada, el cual apunta hacia un estado
y representa lo que dicho estado esta recibiendo un objeto. Un flujo
2008/06/18 44/195
de objeto de salida, el cual apunta hacia un estado y representa lo

que dicho estado esta enviando un objeto.
• A swimlane
o Esta representada por una línea vertical continua a cada lado con
una etiqueta en la parte superior del elemento responsable de los
estados que se muestran dentro de dicho swimlane, lo anterior
delimita una región que separa este swimlane de sus vecinos, ésta
representa responsabilidad.
La Figura 3-23 se basa en el mismo fragmento del párrafo de la descripción de los

572H
requerimientos que fue proporcionado al inicio de este capítulo (ver sección 3.1) 573H
que la Figura 3-20 y la Figura 3-21, pero enfatiza las actividades y las
574H 57H
responsabilidades del administrador de proyectos y del sistema administrador de

proyectos.
2008/06/18 45/195
Figura 3-23. Diagrama de Actividad
2008/06/18 46/195
3.4.3 Otros elementos

Un lenguaje usualmente contiene elementos meramente de notación y otros
elementos que permiten extender dicho lenguaje. UML no es diferente. UML
provee también elementos de notación como son las notas. Los estereotipos y las
propiedades que permiten extender el lenguaje.
3.4.3.1 Notas
Están representadas por un rectángulo con un doblez en su esquina superior
derecha y pueden ser ligadas a otros elementos utilizando una línea punteada,
éstas representan un comentario muy similar a los comentarios usados en
lenguajes de programación.
La Figura 3-24 muestra un comentario ligado a la clase Proyecto.

576H
Figura 3-24. Notas, estereotipos y propiedades
<<Tabla>>
Proyecto {Versión = 1.5
FechaInicio <= FechaFin}
Nombre
FechaInicio
FechaFin Usa la Versión 1.5 de la
tabla del Proyecto y
aplica una regla del
negocio a las fechas
3.4.3.2 Estereotipos
Están representado por una cadena de texto acotada por signos de mayor que y
menor que dobles(<< >>), que se muestra en la parte superior o inferior del
nombre de un elemento, éstos representan un significado especial asociado con el
elemento.
La Figura 3-24 muestra un estereotipo ligado a la clase Proyecto, indicando que la

57H
clase representa una tabla de base de datos.
3.4.3.3 Propiedades
Están representadas por cadenas de texto delimitadas por comas dentro de llaves
({ }), que se muestran antes o después del nombre del elemento, y expresadas en
cualquier lenguaje ya sea natural o de computadora, éstas representan las
características de un elemento. Las cadenas de texto que representan a las
propiedades pueden agruparse en dos categorías o tipos:
2008/06/18 47/195
• Una cadena de texto que puede tener un valor asignado (Tagged Value),
se muestra como un par palabra-valor (una palabra seguida por un signo
de igual y seguido a su vez por su valor), éstos representan una
característica de un elemento y su valor.
• Una cadena de texto que puede ser una constante, se muestra como una
cadena de texto que puede ser expresada en el Lenguaje de Restricciones
de Objetos (Object Constraint Language - OCL), éstos representan una
condición que el elemento debe satisfacer.
La Figura 3-24 muestra las propiedades de la clase Proyecto, que incluyen la

578H
versión que se esta utilizando, así como una regla del negocio concerniente a las
fechas de inicio y fin del proyecto.
3.5 Secciones
Una sección es un grupo de párrafos con un tema en común. Las secciones de
UML son las vistas de arquitectura, éstas son categorías de diagramas que
agrupan un conjunto específico de conceptos. Las diferentes vistas de arquitectura
determinan las diferentes maneras en las que uno puede entender un sistema. Por
ejemplo los diagramas mostrados en esta sección se pueden agrupar en
diferentes vistas, vistas para agrupar la funcionalidad, la estructura y el
comportamiento. Los elementos que componen una vista son conocidos como
elementos de la vista.
Debido a que UML es un lenguaje y no una metodología, éste no prescribe de

manera explicita ninguna vista de arquitectura, sin embargo los diagramas de UML
generalmente pueden ser agrupados en las siguientes vistas de arquitectura:
• De Casos de Uso o de Usuario:

o Se enfoca a la funcionalidad del sistema, utilizando los diagramas de
casos de uso para comunicar la funcionalidad el sistema provee a los
usuarios
• Estructural o Estática
o Se enfoca a la estructura del sistema, usando diagramas de clase y
objeto para comunicar que elementos y relaciones conforman el
sistema
• De Comportamiento o Dinámica
o Se enfoca al comportamiento del sistema, utilizando diagramas de
secuencia, colaboración, estado y actividad, para comunicar las
interacciones y colaboraciones de los elementos que conforman el
sistema
2008/06/18 48/195
• De Componentes o Implementación
o Se enfoca en la implementación del sistema, utilizando diagramas de
componentes para comunicar como es implementado el sistema
• De Deployment o de Modelo del Ambiente

o Se enfoca en la implementación del ambiente, usando diagramas de
desarrollo para comunicar como es implementado el sistema que
abarca el ambiente
Aún cuando cada tipo de diagrama es organizado alrededor de un solo tipo de

vista, cada diagrama puede ser utilizado en cualquier vista de arquitectura.
Además, UML nos permite definir nuestras propias vistas de arquitectura, según
nuestras necesidades.
3.6 Documentos
Un documento de UML es un grupo de secciones sobre un tema común,
incluyendo cualquier diagrama que no sea de UML, documentos textuales, y
cualquier información de soporte. Los documentos de UML son modelos. Por
ejemplo, en el lenguaje Español se agrupan secciones en documentos, tales como
un libro. Un modelo es una representación de un sistema. Por ejemplo, todas las
figuras en esta sección y su documentación textual de soporte son un modelo del
sistema de administración de proyectos. Los elementos que componen un modelo
se conocen como elementos del modelo. Por ejemplo, cualquier elemento usado
en los diagramas en esta sección, con cualquier documentación de soporte
necesario para comunicarse sobre ese elemento, forman un elemento del modelo.
Las relaciones entre los modelos, las vistas de arquitectura, y diagramas es similar
a las relaciones entre las bases de datos, las vistas, y las consultas. Una base de
datos contiene datos, las vistas organizan subconjuntos de datos dentro de
unidades significativas de información, y las consultas extraen subconjuntos de
esa información. Un elemento modelo es similar a un elemento de datos en la
base de datos, los elementos de las vistas son similares a los elementos de datos
usados utilizados en las vistas, y los elementos de los diagramas son similares a
los elementos de datos usados dentro de las consultas. Esto establece un
esquema general o aproximación a la manera en que se organiza UML y cómo
éste nos permite comunicarnos.
Debido a que UML es un lenguaje y no una metodología, no prescribe pasos

explícitos para aplicar dichos modelos al desarrollo un sistema partiendo de sus
requerimientos, pero cualquier metodología podrá de manera general asociar los
modelos con estas vistas de arquitectura.
Los modelos y los diagramas nos ayudan a capturar y a comunicar nuestra

comprensión de los requerimientos y del sistema durante el proceso de ciclo de
2008/06/18 49/195
vida de desarrollo del sistema. No solamente nos ayudan con la administración del
cambio y la complejidad, también evalúan nuestra comprensión antes de invertir
recursos en la producción de un sistema que es inaceptable o no satisface a
cabalidad los requerimientos. Los modelos capturan todos los detalles al cruzar el
abismo entre los requerimientos y los sistemas; seguramente no se capturan los
detalles del diseño y de la implementación en los requerimientos, y seguramente
no se capturan detalladamente los requerimientos en la implementación del
sistema. Sin embargo, se capturan tal detalle en un modelo que madura durante
un proceso como nuestra comprensión de los requerimientos además de la
madurez del sistema.
2008/06/18 50/195
Parte II.- Modelado de la Estructura

4 Diagramas de Clase y Objetos
Este capítulo se centra en los diagramas de la clase y objetos, que representan la
estructura de un sistema en general y en un punto particular del tiempo,
respectivamente. Primero, se presentan los diagramas de clase y de objeto, y
cómo éstos se utilizan. Después, se discuten las clases, objetos, y sus detalles
para modelar los elementos que construyen un sistema. Luego, se discuten a las
asociaciones, vínculos y sus detalles para modelar las relaciones entre los
elementos que conforman un sistema. Finalmente, se discuten varios tipos de
elementos y de relaciones. Muchos de los detalles que no se discutieron en el
Capítulo 3 son profundizados completamente aquí, y a través del capítulo se
incluyen sugerencias relacionadas con los diagramas de clase y de objeto.
El modelado de clases es un tipo especializado de modelado que concierne a la

estructura general de un sistema. El modelado de objetos es un tipo especializado
de modelado que concierne a la estructura de un sistema en un punto particular de
tiempo. A menudo se aplica el modelado de clases y de objetos durante las
actividades del análisis y de diseño, para entender los requerimientos y para
determinarse cómo un sistema satisface sus requerimientos. El modelado de
objetos se utiliza generalmente en conjunto con el modelado de clases para
explorar y para refinar los diagramas de clase. El modelado de clases y objetos
generalmente comienza después de que los requerimientos hayan madurado lo
suficiente (según como lo haya determinado su proceso del desarrollo del
sistema) y continúa en paralelo con el modelado de la interacción y de la
colaboración (Capítulo 7) a través del proceso de desarrollo del sistema, mientras
se centra en los elementos que integran el sistema y sus relaciones.
Como un proceso de arquitectura-céntrico se enfoca en la arquitectura de un

sistema a través de iteraciones, es importante entender qué elementos integran el
sistema y cómo se relacionan uno con otro. Dado que cada proyecto tiene
recursos limitados, se puede utilizar esta información para determinar cómo
desarrollar mejor un sistema. Esto permite que los arquitectos, diseñadores, y
desarrolladores consideren compensaciones técnicas con respecto al sistema al
sistema, incluyendo qué elementos se pueden desarrollar en paralelo, cuáles
elementos pueden ser comprados en lugar de construirlos, y cuáles elementos
pueden ser reutilizados.
4.1 Clases y objetos

Los diagramas de clase muestran las clases que representan conceptos, mientras
que los diagramas de objeto muestran los objetos que representan instancias
específicas de esos conceptos. Las secciones siguientes hablan detalladamente
sobre la representación de clases y objetos en los diagramas de clases y de
objetos.
2008/06/18 51/195
4.1.1 Clases
Según lo planteado en el Capítulo 3, una clase es un concepto general. Por
ejemplo, el sistema de administración de proyectos envuelve varios conceptos
generales, incluyendo proyectos, administradores, equipos, productos de trabajo,
requerimientos, y sistemas.
Una clase define un tipo de objeto y sus características, incluyendo características

estructurales y características del comportamiento. Las características
estructurales definen los objetos de la clase conocida, y las características del
comportamiento definen lo qué pueden hacer los objetos de la clase. Por ejemplo,
en el Capítulo 3 se puede ver que los individuos de la clase Administrador tienen
nombres (algo que se sabe), y puede iniciar y terminar los proyectos (cosas que
hacen). Las características estructurales incluyen atributos y asociaciones. Las
características del comportamiento incluyen operaciones y métodos.
El aspecto más crucial de una clase es que tiene semántica: un cierto significado
convenido entre quien se intenta comunicar con él. Por ejemplo, cuando se
discute un proyecto, ¿qué significa un proyecto para mi audiencia? ¿Es un
esfuerzo que dura una semana o un año? ¿Es un esfuerzo que requiere un
administrador y otros recursos humanos? Y así sucesivamente. Tal significado es
muy específico para la audiencia y el dominio en los cuales la clase se emplea.
En un diagrama de clase de UML, se muestra una clase como el contorno de un

rectángulo sólido con tres compartimientos estándar separados por líneas
horizontales. En el compartimiento superior es requerido y se muestra el nombre
de la clase, en el segundo compartimiento es opcional y muestra una lista de
atributos, y en el tercer compartimiento también opcional muestra una lista de
operaciones. Los segundos y terceros compartimientos necesitan solamente
mostrar la información específica que se requiera comunicar usando el diagrama
dado. No necesita mostrar todos los atributos de una clase y operaciones en todo
momento.
La Figura 4-1 muestra varias clases fundamentales asociadas al sistema de

579H
administración de proyectos en este caso de estudio, se incluyen trabajador,

unidad de trabajo, y producto de trabajo , usando la notación más básica para las
clases.
Figura 4-1. Clases
Trabajador UnidadDeTrabajo ProductoDeTrabajo
Fuente: Sinan Si Alhir, 2003
Un trabajador es una persona o un grupo de personas que realizan un trabajo,

incluyendo administradores del proyecto, administradores de recurso, recursos
2008/06/18 52/195
humanos, y administradores de sistema. Una unidad del trabajo es una unidad del
esfuerzo, que incluye asignar y analizar requerimientos, así como diseñar,
implementar, probar o destacar un sistema. Un producto de trabajo es cualquier
cosa producida y usada dentro de un proyecto, incluyendo los requerimientos y el
sistema. Se observa que una clase se debe nombrar usando una oración nominal.
Las clases, como se debe recordar del Capítulo 3, representan conceptos que se
descubren centrándose en los sustantivos.
4.1.1.1 Atributos
Un atributo es lo que un objeto conoce de una clase. Es un elemento de los datos
mantenidos por el objeto. Por ejemplo, cada objeto de la clase trabajador del
sistema de administración de proyecto puede tener un nombre, descripción, y así
sucesivamente. Todos estos son atributos.
EmailAddress
En un diagrama de clase, se listan los atributos en el segundo compartimiento en

una clase. La manera más simple es solo listar los nombres de atributos, pero
UML permite que se haga mucho más que eso. Se considera un atributo para
mantener la dirección de correo electrónico de un trabajador. Se puede comenzar
definiéndolo usando la sintaxis básica siguiente:
Mientras se avanza en el proceso del desarrollo, se puede agregar detalle a esta

definición en cada iteración haciendo varias preguntas y capturando más detalles
sobre el atributo basado en las respuestas.
EmailAddress [1..5]
Por ejemplo, se puede preguntar cuántas direcciones de email tiene un trabajador.

Presumiendo que un trabajador puede tener hasta cinco direcciones de email, se
puede poner al día la definición de atributo como sigue:
EmailAddress [1..5 desordenado]
Después, se puede preguntar si estas direcciones de email están ordenadas,

quizás por prioridad. Presumiendo que las direcciones de email no están
ordenadas, se puede actualizar la definición de atributo como sigue:
Se puede decidir preguntar qué tipo de dato se necesita para mantener el atributo
de email. Se descubre que un email es una cadena de caracteres, y se actualiza la
definición de atributo para indicar esto:
EmailAddress [1..5 desordenado] : String
2008/06/18 53/195
Se puede que entonces pregunte si hay un valor fijo para el email de un

trabajador. El cliente sugiere usar un valor fijo de "ningún email ", así se actualiza
tal definición de atributo como sigue:
EmailAddress [1..5 desordenado] : String = "Sin email"
Finalmente, se puede preguntar si otros objetos pueden tener acceso al e-mail del
objeto del trabajador. Asumiendo la respuesta es que el email del objeto
trabajador no es accesible por otros objetos, se puede poner al día la definición de
atributo una última vez precediéndola con el signo de menos (-), como sigue:
- EmailAddress [1..5 desordenado] : String = "Sin email"
Para resumir, esta definición de atributo final comunica la información siguiente:
• El símbolo -
o Indica que el atributo del email es privado para el objeto y así
inaccesible por otros objetos.
• 1..5
o Indica que el atributo del email puede tener a partir de uno a cinco
valores.
• desordenado
o Indica que los valores del atributo del email no están ordenados
basados en un criterio específico.
• String
o Indica que las direcciones del email son cadenas de caracteres.
• "Sin email "

o Es el valor inicial de cada email.
La Figura 4-2 muestra la clase Trabajador de la Figura 4-1 con sus atributos. Un
580H 581H
trabajador tiene un número de identificación (Id), un número de identificación

siguiente (SiguienteId), un nombre, hasta cinco direcciones de email que están
desordenadas, cualquier número de los números telefónicos que se piden, y una
contraseña. SiguienteId se subraya para indicar que es un valor, definido en el
nivel de la clase, compartido por todos los objetos de la clase. El sistema utiliza
este valor compartido para asegurarse de que cada objeto del trabajador tiene un
número único de identificación.
2008/06/18 54/195
Figura 4-2. Clase del trabajador con sus atributos
Trabajador
- SiguienteId : Integer = 1
-Id : Integer
-Nombre : String
+Direcciondecorreoelectronico(1..5Desordenado) : String = SinEmail
- NumeroTelefonico(1..*ordenado) : String
# Contraseña : String
En la Figura 4-2, se ve cierta sintaxis que no se ha descrito todavía: un signo de

582H
número (#) en el frente del atributo contraseña y de la palabra clave ordenados en

el atributo número telefónico. Esta sintaxis se describe en la siguiente sección,
sección 4.1.1.2.
583H
En la Figura 4-3 se muestra la clase UnidadDeTabajo de la Figura 4-1con sus

584H 58H
atributos. Una unidad de trabajo tiene un nombre y una descripción.
Figura 4-3. Clase unidad de trabajo con sus atributos
UnidadDeTrabajo
- Nombre : String
- Descripcion : String
En la Figura 4-3 se muestra la clase ProductoDeTrabajo de la Figura 4-1 con sus

586H 587H
atributos. Un producto de trabajo tiene un nombre, descripción, y un porcentaje

final.
Figura 4-4. Clase ProductoDeTrabajo con sus atributos
ProductoDeTrabajo
- Nombre : String
- PorcentajeCompleto : Real = 0
4.1.1.2 Sintaxis de Atributo

En UML, un atributo se describe en el segundo compartimiento de una clase este
se expresa utilizando la siguiente sintaxis de UML:
visibibilidad nombre [multiplicidad ordenada] : tipo = valor

inicial
2008/06/18 55/195
En la cuál:
• visibilidad
o Es opcional, no tiene ningún valor fijo, e indica si el atributo es
accesible fuera de la clase. Puede ser de la siguiente manera:
+
• Visibilidad pública; el atributo es accesible fuera de su
clase.
-
• Visibilidad privada; el atributo es inaccesible fuera de
su clase.
#
• Visibilidad protegida; el atributo es accesible por las
clases que tienen una relación de la generalización
(según lo visto en capítulo 3) a su clase, pero es de
otra manera inaccesible fuera de su clase.
La Figura 4-2 a través de la Figura 4-4 muestra que la mayoría de

58H 589H
los atributos son privados, a menos que se proteja la contraseña de

un trabajador de modo que tipos más específicos de trabajadores
puedan utilizarla de cualquier manera en la cual ellos manejar la
seguridad.
• nombre
o Es el nombre del atributo que se está describiendo.
• multiplicidad
o Es opcional, tiene un valor fijo de 1, e indica el número de valores
que un atributo puede llevar a cabo. Si un atributo tiene solamente
un valor, la multiplicidad, el ordenamiento, y los corchetes no se
muestran. De otro modo, la multiplicidad es mostrada como una
cadena límite-inferior .. límite-superior, en la cual un
asterisco indica un rango ilimitado; por ejemplo 0..* permite a partir
del cero hasta un número infinito de valores. Figura 4-2 a través de la
590H
Figura 4-4se muestra que todos los atributos a excepción de Email y

591H
de numero telefónico tienen solamente un valor. Un trabajador

puede tener hasta cinco direcciones de email y cualquier número de
los números de teléfono.
• ordenamiento
2008/06/18 56/195
o Es opcional, tiene un defecto de valor desordenado, y se utiliza

donde la multiplicidad es mayor que uno para indicar si los valores
de un atributo son ordenados o desordenados. Se utiliza una de las
palabras claves siguientes:
desordenado
• Indica que los valores están desordenados.
ordenado
• Indica que los valores están ordenados.
La Figura 4-2 muestra que las cinco direcciones de email de un

592H
trabajador están desordenadas y que los números telefónicos de un

trabajador están ordenados.
• tipo
o Es opcional, no tiene ningún valor fijo, e indica el tipo de dato que un
atributo puede llevar a cabo. Si no se muestra un tipo para un
atributo, se deben omitir los dos puntos. El tipo de un atributo puede
ser otra clase. Además, UML proporciona los tipos de datos
siguientes:
Boolean
• Un valor verdadero o falso
Entero
• Un número entero
Real
• Un número real
Cadena
• Una cadena de caracteres
Figura 4-2 a través de la Figura 4-4 se muestra que la mayoría de los

593H 594H
atributos son secuencias mientras que el número de identificación de

un trabajador (Id) y el número de identificación siguiente
(SiguienteId) son números enteros, y los atributos de porcentaje de
completado de un producto de trabajo es un número real.
• valor_inicial
o Es opcional, e indica el valor inicial de un atributo. Por defecto, un
atributo no tiene ningún valor inicial. Si no se muestra un valor
inicial, se debe omitir el símbolo de igual (=). Figura 4-2 basada de la
59H
Figura 4-4 se muestra que la mayoría de los atributos no tienen

596H
2008/06/18 57/195
ningún valor inicial. Sin embargo, el número de identificación

siguiente de un trabajador (SiguienteId) tiene un valor inicial de 1, los
porcentajes de completado de un producto de trabajo tiene un valor
inicial de 0, y las direcciones de email tienen un valor inicial de "Sin
email".
Si se prefiere, UML también permite que se muestre un atributo usando seudo

código u otro lenguaje. Por ejemplo, se puede utilizar la sintaxis de Java, de C++,
de C #, o algún otro lenguaje de programación.
Si el valor de un atributo es específico para un objeto, se conoce como instancia

scoped o el objeto scoped. Si un atributo es compartido por todos los objetos de
una clase, se conoce como la clase scoped. Se puede indicar que un atributo es
clase scoped, subrayándolo. La Figura 4-2 basada de la Figura 4-4 muestra que
597H 598H
todos los atributos son objeto scoped, a excepción del número de identificación
siguiente del trabajador (SiguienteId), que es clase scoped.
4.1.1.3 Operaciones
Recordemos del Capítulo 3 que una operación es lo que un objeto de una clase
puede hacer. Es una especificación de un servicio proporcionado por el objeto.
Recordemos también que un método es cómo un objeto de una clase realiza su
proceso. Es una implementación de un servicio proporcionado por el objeto. Por
ejemplo, cada clase del proyecto del sistema de administración puede
proporcionar las operaciones de obtener y asignar para sus atributos. Estas
operaciones de obtener y asignar, recuperan y fijan los valores para los atributos
de un trabajador, unidad de trabajo, producto de trabajo, y así sucesivamente.
Consideremos una operación para agregar un email a un trabajador. Se puede

comenzar definiendo la sintaxis básica siguiente:
agregarEmailAddress
Mientras se desarrollan las iteraciones del proceso de desarrollo, se puede

agregar detalle para esta definición haciendo preguntas y capturando el detalle
adicional sobre la operación de las respuestas a esas preguntas.
Por ejemplo, se puede preguntar si la operación de agregarEmailAddress requiere

cualesquiera parámetros: datos de entrada o salida de la operación. Presumiendo
que la operación requiere un email como entrada, se puede actualizar la
definición de la operación como sigue:
agregarEmailAddress (EmailAddress)
2008/06/18 58/195
Después, se puede preguntar ¿qué tipo de datos puede contener el email?

Presumiendo que el email es una cadena de caracteres, se puede actualizar la
definición de la operación como sigue:
agregarEmailAddress (Email Address: String)
Después, se puede preguntar si hay un valor fijo para el email. Presumiendo que
el email tiene un valor fijo de una cadena vacía, o ningún carácter, se puede
actualizar la definición de la operación como sigue:
agregarEmailAddress (Email Address: String = "")
Puede que entonces se pregunte si el email es simplemente una entrada a la

operación, una salida de la operación, o ambas. Presumiendo que el email es
solo la entrada a la operación, y de ese modo no ser modificado por la operación,
se puede agregar la palabra clave in que precede del nombre del parámetro:
agregarEmailAddress (in EmailAddress: String = "")
Se puede entonces preguntar si la operación devuelve algún tipo de dato.

Presumiendo que la operación devuelve un verdadero o falso indicando si la
operación fue exitosa en la agregación del email al trabajador, se puede actualizar
la definición de la operación como sigue:
agregarEmailAddress (in EmailAddress: String = "") : Boolean
Finalmente, se puede preguntar si otros objetos están permitidos para tener

acceso a la operación de agregarEmailAddress de un objeto. Presumiendo que la
operación de agregarEmailAddress de un objeto es accesible por otros objetos, se
puede preceder el nombre de la operación en la definición con un signo de más
(+):
+ AgregarEmailAddress (en el EmailAddress: String = "") :

Boolean
Para resumir, esta definición de la operación comunica lo siguiente:
• El símbolo +
o Indica que la operación de AgregarEmailAddress es pública y es
accesible por otros objetos. La expresión dentro de paréntesis indica
los parámetros que llevan a cabo los valores pasados a la operación.
• La palabra clave
o Indica que el parámetro entra y no se puede modificar por la
operación.
2008/06/18 59/195
• El EmailAddress : String = ""

o Indica que un email, es una cadena con un valor fijo de una cadena
vacía, está aprobado para la operación.
• La palabra clave Boolean

o Indica que la operación de AgregarEmailAddress devuelve un valor
de verdad o de falsedad, posiblemente indicando si hay sitio para
que el email sea agregado al atributo de email (que contiene un
máximo de cinco direcciones de email).
La Figura 4-5 muestra la clase trabajador de la Figura 4-1 y la Figura 4-2 con sus
59H 60H 601H
diferentes atributos de las operaciones de obtener y asignar. Note que las

operaciones de obtener y asignar para números telefónicos están basadas en la
prioridad del número telefónico tales como en la que se especifico en las
operaciones de asignación y obtención del número telefónico correspondiente.
Además, se nota que la operación de obtener para las direcciones de email
recupera todas las direcciones de email de un trabajador, mientras que la
operación de asignar para las direcciones del email agrega simplemente un email.
Las operaciones crear y destruir de los objetos del trabajador, crean y destruyen
objetos trabajador, respectivamente.
Figura 4-5. Clase trabajador con sus operaciones
En la Figura 4-6 se muestra la clase de UnidadDeTrabajo de la Figura 4-1 con sus

602H 603H
distintas operaciones de obtener y asignar para fijar y para recuperar valores del
atributo, y con operaciones para crear y para destruir los objetos de
UnidadDeTrabajo.
2008/06/18 60/195
Figura 4-6. Clase UnidadDeTrabajo con sus operaciones
UnidadDeTrabajo
+ crear() : trabajo
+ obtenerNombre() : String
+ asignarNombre(Elnombre : String)
+ obtenerDescripcion() : String
+ asignarDescripcion(LaDescripcion : String)
+ destruir()
+ obtenerNombreyDescripcion(Elnombre : String, Ladescripcion : String)
+ asignarNombreyDescripcion(Elnombre : String, Ladescripcion : String)
+ nombre()
La Figura 4-7 muestra la clase ProductoDeTrabajo de la Figura 4-1 y la Figura 4-4

604H 605H 60H
con sus varias operaciones de obtener y asignar para sus atributos y las
operaciones para crear y para destruir objetos de trabajo. Notar que la Figura 4-7 607H
también muestra los atributos de la clase.
Figura 4-7. Clase ProductoDeTrabajo con sus operaciones
ProductoDeTrabajo
- Nombre : String
- PorcentajeCompleto : Real = 0
+ crear() : ProductoDeTrabajo
+ crear(Elnombre : String, ElPorcentajeCompleto : Real = 0, Ladescripcion : String)
+ obtenerNombre() : String
+ asignarNombre(Elnombre : String)
+ obtenerPorcentajeCompleto() : Real
+ asignarPorcentajeCompleto(ElporcentajeCompleto : Real)
+ obtenerDescripcion() : String
+ asignarDescripcion(LaDescripcion : String)
+ destruir()
4.1.1.4 Sintaxis de la operación

En UML, una operación se describe en la tercera división de una clase usando la
siguiente sintaxis de UML:
visibilidad nombre_de_la_operación (lista_de_parámetros)

valor_de_retorno
En la cuál:
• visibilidad
2008/06/18 61/195
o Es opcional, no tiene ningún valor fijo, e indica si la operación es

accesible fuera de la clase.
Puede ser uno de los siguientes:
+
• Visibilidad pública; la operación es accesible fuera de
su clase.
-
• Visibilidad privada; la operación es inaccesible fuera
de su clase.
#
• Visibilidad protegida; la operación es accesible por las
clases que tienen una relación de la generalización
(según lo discutido en capítulo 3) a su clase, pero es de
otra manera inaccesible fuera de su clase.
En la Figura 4-5, Figura 4-6, y la Figura 4-7 se muestra que todas las
608H 609H 610H
operaciones son públicas, excepto que la operación para fijar la

contraseña de un trabajador está protegida de modo que tipos más
específicos de trabajadores o de subclases de la clase del trabajador
puedan utilizarla en cualquier manera de la cual manejan seguridad.
• nombre _ de_la_operación
o Es el nombre de la operación que se está describiendo.
• lista _ de _ parámetros
o Es opcional, no tiene ningún valor fijo, y es una lista separada que
indica los parámetros a los cuales lleva a cabo los valores pasados o
recibidos de la operación. Cada parámetro se muestra como cadena
de texto que tiene siguiente sintaxis :
tipo de nombre: tipo = valor_fijo
tipo
• Es opcional, tiene un valor fijo adentro, y puede ser uno
de los siguientes:
o in
Indica que el parámetro es solamente
entrada y que no se puede modificar por
la operación.
o out
2008/06/18 62/195
Indica que el parámetro solamente salida,

y que se puede modificar por la operación
para comunicar la información al cliente
que invocó la operación.
o inout
Indica que el parámetro está dentro y se
puede alternadamente modificar por la
operación para comunicar la información
al cliente que invocó la operación.
El tipo y el valor fijo son igual que el tipo y el valor inicial de un

atributo, descrito en la sección anterior.
tipo
• Es opcional, no tiene ningún valor fijo, e indica el tipo
de dato que un parámetro puede llevar a cabo. Si no
se muestra un tipo para un parámetro, se deben omitir
los dos puntos. El tipo de un parámetro puede ser otra
clase. Además, UML proporciona los siguientes tipos
de datos:
o Boolean
Un valor verdadero o falso.
o Integer
En número entero
o Real
Un número real
o String
Una cadena de caracteres
o Valor por defecto

Es opcional, e indica el valor inicial de un
parámetro. Por defecto, un parámetro no
tiene ningún valor inicial. Si no se
muestra un valor inicial, se debe omitir el
símbolo igual (=).
En la Figura 4-5 se muestra un valor inicial para el

61H
parámetro al método de agregarEmailAddress.
Tipo de retorno
• Es opcional, no tiene ningún valor fijo, e indica el tipo
de datos que la operación devuelve a su llamador. Si
2008/06/18 63/195
se elige no demostrar el tipo de retorno de una

operación, se deben también omitir los dos puntos. Sus
opciones para el tipo de retorno son iguales que para
un tipo del parámetro. Muchas de las operaciones
demostradas en la Figura 4-5 a través de la Figura 4-7
612H 613H
muestran un tipo de retorno.
UML también permite que se muestre una operación usando seudo código u otra
lengua. Por ejemplo, se puede utilizar la sintaxis de Java, de C++, de C #, o de un
otro lenguaje de programación.
Si una operación se aplica a un objeto específico, se conoce como instancia

scoped o el objeto scoped. Si una operación se aplica así misma a la clase, se
conoce como la clase scoped. En la Figura 4-5 basada de la Figura 4-7 se
614H 615H
muestra que la mayoría de las operaciones son objeto scoped. Las excepciones
son las operaciones de crear, que son de la clase scoped. Las operaciones de
crear se utilizan para crear objetos de una clase y se conocen como constructores.
Las operaciones de destruir se utilizan para destruir objetos de una clase y se
conocen como destructores. Las operaciones de crear son clase scoped, porque
una clase se utiliza para crear los objetos de la clase; si se creara una instancia
scoped, se necesitaría crear de alguna manera un objeto antes de invocar su
operación para crearla, que no tiene ningún sentido. La operación de destruir, por
otra parte, es objeto scoped, porque se aplica a un objeto específico que seria
destruido.
Podemos combinar la Figura 4-2 y la Figura 4-5 o la Figura 4-3 y la Figura 4-6 de
61H 617H 618H 619H
manera que la Figura 4-7 combina los atributos que se muestran en la Figura 4-4
620H 621H
con las operaciones de la clase. De esta manera, podemos demostrar cualquier

combinación de los atributos y de las operaciones basadas sobre lo que
deseamos comunicar.
Los métodos, la implementación actual de operaciones, no se muestran en una

clase, pero se pueden describir usando otras técnicas de modelado de UML.
4.1.2 Objetos
Según lo discutido en el Capítulo 3, un objeto es un concepto específico, o
instancia de una clase, teniendo las características definidas por su clase,
incluyendo características estructurales y características del comportamiento. Por
ejemplo, el sistema de administración de proyectos implica varios conceptos
específicos, incluyendo proyectos específicos, administradores, equipos,
productos de trabajo, requerimientos, sistemas, y así sucesivamente. Recuerde
que las características estructurales definen lo que conoce el objeto, y que las
características del comportamiento definen lo que puede hacer el objeto. Las
características estructurales incluyen valores para los atributos y vínculos. Las
características del comportamiento incluyen las operaciones y los métodos, que
2008/06/18 64/195
son compartidos por todos los objetos de una clase. El aspecto más crucial de un
objeto es que tiene su propia identidad. No hay dos objetos iguales, incluso si
tienen los mismos valores para sus características estructurales. Por ejemplo, si
dos objetos del trabajador tienen los mismos valores para sus atributos, los
objetos son únicos y tienen sus propias identidades.
En un diagrama de clase de UML, se muestra una clase como el contorno de un

rectángulo sólido con tres compartimientos estándar separados por líneas
horizontales. El compartimiento superior es requerido y muestra el nombre del
objeto seguido por dos puntos seguidos por el nombre de la clase del objeto, y la
cadena entera se subraya completamente. Ambos nombres son opcionales, y los
dos puntos deben solamente estar presentes si se especifica el nombre de la
clase. El segundo compartimiento que es opcional, muestra una lista de atributos.
El segundo compartimiento necesita solamente la información específica que se
desea comunicar con un diagrama dado; no se necesita demostrar todos los
valores del atributo de un objeto en todo momento.
En la Figura 4-8 se muestran varios objetos asociados a las clases mostradas en

62H
las figuras anteriores. Estos objetos incluyen lo siguiente:
• Nora y Felipe que son trabajadores
• La prueba de eso es una unidad de trabajo
• Prueba que es un producto de trabajo
• Una unidad anónima de trabajo con el atributo conocido, Implementación
• Un producto anónimo de trabajo con el atributo conocido, Sistema
• XYZ es un objeto sin especificar.
En la Figura 4-8 introduce la notación que no se ha visto antes: algunos objetos no

623H
tienen ningún nombre y otros no tienen ninguna clase especificada. Los Objetos
en un diagrama de UML que no tienen nombres se refieren como objetos
anónimos. Los Objetos para los cuales una clase no se ha especificado se refieren
como objetos sin especificar. Se puede encontrar tal notación dependiendo de la
metodología específica que es utilizada para un proyecto.
Observar que los nombres del objeto en la Figura 4-8 son todos subrayados
624H
completamente. También se ven valores específicos de los atributos. Se plantean

valores del atributo futuros en la siguiente sección.
2008/06/18 65/195
Figura 4-8. Objetos
Felipe: Trabajador
:UnidadDeTrabajo
Nora:Trabajador ID = 2
Nombre : String Nombre = "Fel ipe"
Descripcion : String Email [1] = "Phi @myorg.org"
Email [2] = ""
Prueba:Uni dadDeTrabaj o Email [3] = "p.h@m yorg.org"
Descri pcion = "verificar que el sistema satisfaga los requerimi entos" Email [4] = ""
Email [5] = "Feli pe@myorg.org"
:ProductoDeT rabajo
XYZ
nombre = "Sistema"
Porcentaj eCompl eto : Real = 80
Prueba:ProductoDeT rabaj o
name : String = prueba 0015*
Descri pcion = probar que el usuari o pueda accesar con el nombre de usuari o y contraseña correctos
4.1.2.1 Valores de Atributo

Un valor de atributo es el valor que un objeto de una clase conoce para un
atributo. En UML, un valor de atributo se describe en la división de un segundo
objeto. Por ejemplo, cada objeto Trabajador del proyecto de administración del
sistema puede tener un valor para su nombre.
Considerando un valor de atributo para mantener las direcciones de email de un

trabajador. Se puede definir usando la sintaxis siguiente:
- EmailAddress [1]: String = "ph@myorg.org"
Esta definición expresa lo siguiente:
• El símbolo -
o Indica que el atributo de email es privado y accesible solamente por
el objeto.
• [1]
o Indica que éste es el primer valor de email, porque hay valores
múltiples del email.
• String
o Indica que el email es una cadena de caracteres.
• "ph@myorg.org"
o Indica el valor del atributo de email.
Lo que sigue es la sintaxis general a utilizar para definir valores de los atributos:
2008/06/18 66/195
visibilidad nombre [índice]: tipo = valor
Los elementos de la sintaxis son iguales que para los atributos de una clase.
4.1.2.2 Operaciones
Puesto que las operaciones y los métodos de una clase son compartidos por todos
los objetos de la clase, las operaciones no se muestran en cada objeto. Por
ejemplo, en la Figura 4-8 se muestra que Nora y Felipe son trabajadores, y por lo
625H
tanto comparten las operaciones y los métodos del trabajador. No hay necesidad
de demostrar las operaciones en cada objeto, pues las operaciones serán
repetidas innecesariamente cada vez. Para determinar las operaciones de un
objeto, se hace referencia a la clase de ese objeto.
4.2 Asociaciones y ligas

Los diagramas de la clase contienen asociaciones, y los diagramas del objeto
contienen vínculos. Las asociaciones y los vínculos representan relaciones. Las
asociaciones representan relaciones entre las clases; los vínculos representan
relaciones entre los objetos. Las secciones próximas abordan las
representaciones de UML de asociaciones y de vínculos detalladamente.
4.2.1 Asociaciones
Según lo discutido en el Capítulo 3, una asociación define un tipo de vínculo y es
una relación general entre las clases. Por ejemplo, el proyecto de administración
del sistema implica varias relaciones generales, incluyendo administrar, dirigir,
ejecutar, entrada y salida entre los proyectos, los administradores, los equipos, los
productos de trabajo, los requerimientos, y los sistemas. Considerando, por
ejemplo, cómo un administrador de proyecto conduce a equipo.
4.2.1.1 Asociaciones binarias

Una asociación binaria relaciona dos clases. Por ejemplo, una relación binaria en
el sistema de administración del proyecto está entre los trabajadores individuales y
sus unidades del trabajo, y otra relación binaria está entre los trabajadores
individuales y sus productos de trabajo.
En un diagrama de clase de UML, una asociación binaria se muestra como

trayectoria de una línea recta que conecta las dos clases relacionadas. Una
asociación binaria se puede etiquetar con un nombre. El nombre se lee
generalmente de izquierda a derecha; si no, puede tener un triángulo sólido negro
pequeño al lado de él, donde el punto del triángulo indica la dirección en la cual
leer el nombre, pero la flecha es puramente descriptiva, y el nombre de la
asociación se debe entender por las clases que se relacionan.
2008/06/18 67/195
En la Figura 4-9 se muestran varias asociaciones dentro del sistema de

62H
administración de proyectos usando la notación más básica para las asociaciones

binarias. Las asociaciones en la figura son como sigue:
o Un trabajador es responsable del producto de trabajo y realiza unidades de

trabajo
o Las unidades de trabajo consumen productos de trabajo como

entrada y producen productos del trabajo como salida.
Observe que una asociación binaria se debe nombrar usando una frase del verbo.
Recuerde del Capítulo 3 que se describen asociaciones centrándose en los
verbos.
Figura 4-9. Asociaciones Binarias
ResponsableDe
ProductoDeTrabajo
Trabajador
ConsumoDeEntrada ProductoDeSalida
UnidadDeTrabajo
Realizar
4.2.1.2 Asociaciones de N-arias

Una asociación n-aria relaciona tres o más clases. Por ejemplo, en el sistema de
administración de proyectos, el uso de un trabajador incluye el trabajador, sus
unidades de trabajo, y en ella asoció productos del trabajo.
En un diagrama de clase de UML, una asociación n-aria se muestra como

diamante grande con las trayectorias de una línea recta que conecta el diamante a
cada clase. Una asociación n-aria se puede etiquetar con un nombre. El nombre
se lee de manera semejante a las asociaciones binarias, descrito en la sección
anterior.
En la Figura 4-10 se muestra una asociación n-aria asociada al sistema de

627H
administración de proyecto usando la notación más básica para las asociaciones

n-arios. Esta asociación indica que la Utilización implica a trabajadores, unidades
de trabajo, y de los productos de trabajo. Como con una asociación binaria, una
asociación n-aria también se nombra comúnmente usando una frase del verbo.
2008/06/18 68/195
Sin embargo, éste no es siempre el caso -- por ejemplo, la asociación n-aria de la

Utilización mostrada en la Figura 4-10 se describe usando un sustantivo en lugar
628H
de un verbo, porque se nombra de nuestra perspectiva en lugar de la perspectiva

de una de las clases. Es decir, em nuestra perspectiva, deseamos entender la
utilización de un trabajador concerniente a las otras clases. De la perspectiva del
trabajador, un trabajador es responsable de productos de trabajo y realiza
unidades de trabajo.
Figura 4-10. Asociaciones N-arios
4.2.2 Clases de la Asociación

Las clases de la asociación se pueden aplicar a las asociaciones binarias y n-aria.
Similar a cómo una clase define las características de sus objetos, incluyendo sus
características estructurales y las características del comportamiento, una clase de
la asociación se puede utilizar para definir las características de sus vínculos,
incluyendo sus características estructurales y las características del
comportamiento. Estos tipos de clases se utilizan cuando se necesita mantener la
información sobre la relación de sí mismo.
En un diagrama de clase de UML, se muestra una asociación de una clase como

una clase unida por una trayectoria de línea discontinua a la trayectoria de la
asociación en una asociación binaria o a su diamante de la asociación en una
asociación n-aria. El nombre de la clase de la asociación debe corresponder al
nombre de la asociación.
En la Figura 4-11 se muestran la asociación de clases para las asociaciones

629H
binarias en la Figura 4-9 usando la notación más básica para la asociación binaria
630H
de clases. La asociación de clase clasifica la información siguiente:
• La razón un trabajador es responsable de un producto de trabajo
• La razón un trabajador realiza una unidad de trabajo
• Una descripción de cómo una unidad de trabajo consume un producto de

trabajo
2008/06/18 69/195
• Una descripción de cómo una unidad de trabajo produce un producto de

trabajo.
Figura 4-11. Clases de asociación Binarias
ResponsableDe ProductoDeTrabajo
ResponsableDe
-----------
+Razon : String
ConsumodeEntrada ProductodeSalida
Trabajador
Realizar ConsumodeEntrada ProductodeSalida

+Razon : String + Descripcion : String +Descripcion : String
UnidadDeTrabajo
Realizar
En la Figura 4-12 se muestra una clase de la asociación para la asociación n-aria

631H
en la Figura 4-10 se utiliza la notación más básica para las asociaciones de clase
632H
n-aria. La clase de la asociación sigue un porcentaje de la utilización para los

trabajadores, sus unidades del trabajo, y sus productos asociados del trabajo.
Figura 4-12. Clase de asociación N-arios
4.2.3 Extremos De la Asociación

Un extremo de la asociación es un punto final de la línea dibujada para una
asociación, y conecta la asociación con una clase. Un extremo de la asociación
puede incluir cualquiera de los puntos siguientes para expresar más a detalle
cómo la clase se relaciona con la otra clase o clases en la asociación:
• Nombre del rol
2008/06/18 70/195
• Flecha de navegación
• Especificación de la multiplicidad
• Símbolo de la agregación o de la composición
• Calificador
4.2.3.1 Nombre del rol

Un nombre del rol es opcional e indica el papel que una clase desempeña
relacionado a las otras clases en una asociación, y cómo las otras clases
"consideran" la clase o la "cara" que la clase proyecta a las otras clases en la
relación. Un nombre del rol se muestra cerca del final de una asociación unida a
una clase.
Por ejemplo, un producto de trabajo es visto como entrada por una unidad de
trabajo, donde la unidad de trabajo es considerada como consumidor por el
producto de trabajo; un producto de trabajo es visto como salida por una unidad
del trabajo donde la unidad de trabajo es considerada como productor por el
producto de trabajo, según lo mostrado en la Figura 4-13 Se continuará
63H
discutiendo esta figura en las secciones siguientes. Se captura particularmente el

detalle significativo en una figura, de modo que se pueda ver cuánto le permite el
UMC comunicarse en una figura tal como esto.
Figura 4-13. Extremos binarios de la asociación
ReaponsableDe 0..n
ProductoDeTrabajo
elProductoDeTrabajo
0..n 0..n
1 Entrada Salida
Trabajador
1
Consumidor Productor
0..n 0..n
Realizar 0..n
UnidadDeTrabajo
elTrabajo
4.2.3.2 Navegación
2008/06/18 71/195
La navegación es opcional e indica si una clase se puede referenciar de otras

clases a una asociación. La navegación se muestra como flecha unida a un
extremo de la asociación que señala hacia la clase en cuestión. Si no hay flechas
presentes, las asociaciones se asumen navegables en todas las direcciones, y
todas clasifican implicadas en la asociación pueden referirse a una a la otra.
Por ejemplo, dado un trabajador, se puede determinar sus productos de trabajo y

unidades de trabajo. Así, en la Figura 4-13 se muestran las flechas que señalan
634H
hacia producto de trabajo y unidades de trabajo. Dado una unidad de trabajo, se

puede determinar sus productos de trabajo de entrada y salida; pero dado un
producto del trabajo, no se puede identificar qué trabajador es responsable de él o
qué unidades del trabajo se refieren a él como entrada o salida (según lo mostrado
en la Figura 4-13 por la carencia de las flechas que señalan a la clase del
635H
Trabajador). En la Figura 4-14 se muestran las flechas de la navegación aplicadas

63H
a una asociación n-aria. Dado un trabajador, se puede referir sus productos de

trabajo y unidades de trabajo para determinar su utilización, pero dado un
producto de trabajo o una unidad de trabajo, no se puede determinar su utilización
de un trabajador.
Figura 4-14. Extremos de la asociación N-arios
4.2.3.3 Multiplicidad
La multiplicidad (que es opcional) indica cuántos objetos de una clase pueden
relacionarse con otras clases en una asociación. La multiplicidad se muestra
como secuencia coma-separada como el siguiente:
• Intervalos de número entero
• Valores literales de número entero
Se muestran los intervalos como un límite inferior… limite superior de cadena de

caracteres, en la cual un asterisco indica un rango ilimitado. Si no se muestra un
2008/06/18 72/195
asterisco, el rango es cerrado. Por ejemplo, 1 significa un, 1..5 significa de uno a
5, 1, 4 significa uno o cuatro, 0.. * y * significan cero o más (o muchos), y 0..1 y 0,
1 significan cero o uno. No hay multiplicidad por defecto para los extremos de la
asociación. La multiplicidad simplemente no está definida, a menos que se la
especifique. Por ejemplo:
• Un solo trabajador es responsable de cero o más los productos del trabajo.
• Un solo producto de trabajo es la responsabilidad de exactamente un

trabajador.
• Un solo trabajador realiza cero o más unidad de trabajo.
• Una unidad de trabajo es realizada por exactamente un trabajador.
• Una unidad del trabajo puede tener cero o mas productos de trabajo como
entrada y salida.
• Un producto del trabajo puede ser consumido como entrada por cero o más
unidad de trabajo y ser producido como hecho salir por cero o más unidad
de trabajo.
Todo esto se muestra en la Figura 4-13 Continuando el ejemplo, la utilización se

637H
puede determinar para un solo trabajador que deba tener de tres a cinco unidades
de trabajo y cero o más productos de trabajo, según lo demostrado en la Figura
638H
4-14.
Para determinar la multiplicidad de una clase, se pregunta cuántos objetos pueden

relacionarse con un solo objeto de la clase. La respuesta determina la multiplicidad
en el otro objeto al final de la asociación. Por ejemplo, usando la Figura 4-13, si se
639H
tiene un solo objeto del trabajador, ¿de cuántos productos de trabajo puede ser
responsable un solo objeto del trabajador? La respuesta es cero o más, y ésa es
la multiplicidad mostrada en el diagrama al lado de la clase ProductoDeTrabajo.
Usando la Figura 4-14 si se tiene un solo trabajador, ¿con cuántos productos de
640H
trabajo puede solamente el trabajador estar relacionado para determinar la

utilización del trabajador? La respuesta es cero o más, y ésa es la multiplicidad
mostrada en el diagrama al lado de la clase de ProductoDeTrabajo.
Otra manera de determinar multiplicidad es preguntar cuántos objetos de una

clase pueden relacionarse con un solo objeto de la clase con otra al final de una
asociación, o un objeto de la clase con otros al final de una asociación n-aria. La
respuesta determina la multiplicidad para la clase. Por ejemplo, usando la Figura 641H
4-13, ¿cuántos productos del trabajo es responsable un solo trabajador? La

respuesta es cero o más; ésa es la multiplicidad mostrada en el diagrama al lado
de la clase de ProductoDeTrabajo. También, usando la Figura 4-14, ¿cuántos
642H
2008/06/18 73/195
productos de trabajo se relacionan con solo trabajador y una sola unidad detrabajo
para determinar la utilización del trabajador? La respuesta es cero o más; ésa es
la multiplicidad mostrada en el diagrama al lado de la clase de producto de trabajo.
4.2.3.4 Agregación
La agregación es la relación conjunto-parte entre un agregado, el conjunto, y sus
partes. Esta relación frecuentemente conocida como tiene-una relación, porque el
conjunto tiene sus piezas. Por ejemplo, cuando se piensa en los trabajadores que
integran un equipo, se puede decir que un equipo tiene trabajadores. Se muestra
la agregación usando un diamante hueco unido a la clase que representa el
conjunto. Esta relación que se acaba de mencionar entre un equipo y sus
trabajadores se muestra en la Figura 4-15. Busque el diamante hueco a la derecha
643H
de la clase del equipo. Los diamantes llenos representan la composición, que se

discutirá después. Como una regla de UML, la agregación se utiliza solamente con
asociaciones binarias.
Figura 4-15. Agregación y composición para las asociaciones
1 1
Organizacion
0..20 elEquipo elTrabajador

0..1000
1 0..2
Equipo 2..5 Trabajador
miembro
0..3
subequipo
Note en la Figura 4-15 que se ha hecho algo diferente con el equipo. Se ha creado
64H
una relación circular para tener en cuenta subequipos. Una relación circular se
conoce como relación reflexiva, porque relaciona dos objetos de la misma clase.
4.2.3.5 Composición
La composición, también conocida como agregación compuesta, es una relación
conjunto-parte entre un compuesto (el conjunto) y sus partes, en las cuales las
partes deben pertenecer solamente a una parte entera y al conjunto que son
responsables de crear y de destruir sus partes cuando son creadas y destruidas.
Esta relación es frecuentemente conocida como contiene-una relación, porque el
conjunto contiene sus partes. Por ejemplo, una organización contiene a los
equipos y a trabajadores, y si la organización deja de existir, sus equipos y
trabajadores también dejan de existir. Los individuos específicos que representan
a los trabajadores existirán aún, solamente que no serán más trabajadores de la
2008/06/18 74/195
organización, porque no existirá más la organización. Se muestra la composición

usando un diamante lleno unido a la clase que representa el conjunto. Las
relaciones entre un equipo, sus trabajadores, y una organización se muestran en
la Figura 4-15. Llenar el diamante en la punta final de la relación de subequipos en
645H
la Figura 4-15 indica que los equipos contienen sus subequipos. Como una regla
64H
de UML, la composición se utiliza solamente con asociaciones binarias.
Note cuánta información se está comunicando en la Figura 4-15, se muestra que

647H
una organización puede contener de 0 a 20 equipos y de 0 a 1.000 trabajadores.

Además, cada equipo tiene de 2 a 5 trabajadores y cada trabajador puede ser un
miembro de 0 a 2 equipos. Además un equipo puede contener de 0 a 3
subequipos.
Para determinar si se utiliza una agregación o una composición, hágase algunas

preguntas. Primero, si las clases se relacionan con una con otra, utilice una
asociación. Después, si una clase es parte de otra clase, que es el conjunto, use
una agregación; si no, utilice una asociación. Por ejemplo, en la Figura 4-15 se
648H
muestra que los trabajadores son parte de un equipo y de una organización, los
equipos son parte de una organización, y los subequipos son parte de los equipos.
Finalmente, si la parte debe pertenecer a una parte entera solamente, y el
conjunto es responsable de crear y de destruir sus piezas, use una composición; si
no, utilice simplemente la agregación. Por ejemplo, en la Figura 4-15 se muestra
649H
que un equipo y un trabajador deben pertenecer a una organización solamente, y

la organización es responsable de determinar (o de crear y de des) a sus equipos
y trabajadores. También se muestra que un subequipo debe pertenecer a un
equipo solamente, y el equipo es responsable de determinar (o de crear y de
destruir) sus subequipos. Si esto es confuso, mantenga las cosas simples y utilice
las asociaciones sin la agregación o la composición.
La composición también puede ser mostrada gráficamente jerarquizando las

clases, en las cuales la multiplicidad de una clase jerarquizada se muestra en su
esquina superior derecha y su nombre de su rol se indica delante de su nombre de
la clase. Separe el nombre del rol del nombre de la clase usando dos puntos. En la
Figura 4-16 utiliza el anidamiento gráfico de equipos y de trabajadores en
650H
organizaciones para comunicar la misma información según lo demostrado en la

Figura 4-15.
651H
2008/06/18 75/195
Figura 4-16. Forma alterna de composición para las asociaciones
Organizacion
1 0..2 2..5
elEquipo:Equipo elTrabajador:Trabajador
0..20 miembro 0..1000
0..3 subequipo
En la Figura 4-17 utiliza el anidamiento gráfico de subequipos dentro de los

652H
equipos para comunicar la misma información que en la Figura 4-15 y en la Figura

653H 654H
4-16 El resultado es una clase jerarquizada dentro de una clase jerarquizada.
Figura 4-17. Composición doble jerarquizada para las asociaciones
Organizacion
elEquipo:Equipo 0..2 2..5 elTrabajador:Trabajador

0..20 miembro 0..1000
subEquipo:Equipo
0..3
4.2.3.6 Calificadores
Un calificador es un atributo de una clase de la asociación que reduzca la
multiplicidad a través de una asociación. Por ejemplo, en la Figura 4-13 se 65H
muestra que la multiplicidad entre los productos del trabajo y las unidades del
trabajo es cero o más para ambas asociaciones; es decir, puede haber muchos
productos del trabajo asociados a una sola unidad del trabajo y puede haber
muchas unidades del trabajo asociadas a un solo producto del trabajo. En lugar de
decir simplemente que hay "muchos" objetos implicados en la relación, se puede
comunicar un número más finito.
2008/06/18 76/195
Se puede reducir la multiplicidad entre los productos del trabajo y las unidades del
trabajo si se pregunta qué se necesita saber sobre una unidad del trabajo de modo
que se pueda definir una multiplicidad más específica - una que no sea ilimitado.
Asimismo, se puede hacer la misma pregunta acerca de la asociación entre el
producto de trabajo y las unidades de trabajo. Si se tiene un producto del trabajo y
el nombre de una unidad del trabajo, se puede determinarse si existe una relación
entre los dos; asimismo, si se tiene una unidad del trabajo y del nombre de un
producto del trabajo, se puede determinarse si una relación existe entre esos dos.
El truco es documentar exactamente la información necesaria que necesita el
objeto al final de la relación. Aquí es a donde el calificador entra en juego.
Esencialmente, un calificador es un pedazo de información usado como índice

para encontrar los objetos en otro final de una asociación. Un calificador se
muestra como rectángulo pequeño unido a una clase donde un objeto de la clase,
junto con un valor para el calificador, reduce la multiplicidad en el otro objeto al
final de la asociación. Los calificadores tienen la misma notación que atributo, no
tienen ningún valor inicial, y deben ser atributo de la asociación o de la clase en el
otro final de la asociación.
Las relaciones entre los productos del trabajo, las unidades del trabajo y sus
calificadores se muestran en la Figura 4-18. Los calificadores indican que un
65H
producto del trabajo con el nombre de una unidad del trabajo puede identificar una
unidad del trabajo, y que una unidad del trabajo con el nombre de un producto del
trabajo puede identificar un producto del trabajo. Note que se ha reducido la
multiplicidad de 0.. * mostrada en la Figura 4-13 a 0..1 en Figura 4-18. El
657H 658H
calificador permite hacer esto. Como una regla de UML, calificadores se utiliza
solamente con asociaciones binarias.
Figura 4-18. Calificadores para asociaciones
2008/06/18 77/195
4.2.4 Vínculos
Según lo discutido en el Capítulo 3, un vínculo es una relación específica entre los
objetos. Por ejemplo, el sistema de administración de proyectos implica varias
relaciones específicas, incluyendo maneja, conduce, ejecuta, entrada, salida, y
otras relaciones entre los proyectos, encargados, equipos, productos de trabajo,
requerimientos, sistemas, y así sucesivamente. Un vínculo instancia de una
asociación, y UML soporta diversos tipos de vínculos que correspondan a los
diversos tipos de asociaciones.
Las reglas generales para representar vínculos en un diagrama de UML son como
sigue:
• Etiquete los vínculos con sus nombres de la asociación, y subraye los
nombres para demostrar que son casos específicos de sus asociaciones
respectivas.
• Asegúrese de que los extremos del vínculo sean constantes con sus
extremos correspondientes de la asociación.
• Traduzca la multiplicidad de la asociación a unos o más vínculos

específicos entre los objetos específicos.
En las siguientes secciones se muestra cómo aplicar estas reglas a los varios
tipos del vínculo.
4.2.4.1 Vínculos Binarios

Un vínculo binario, que es una relación específica entre dos objetos, mientras que
una trayectoria de línea llena que conecta los dos objetos en un UML se opone el
diagrama. Por ejemplo, relacionan a un trabajador específico con las unidades
específicas del trabajo y de los productos del trabajo en el sistema de gerencia de
proyecto. Un vínculo puede tener su nombre de la asociación demostrado cerca
de la trayectoria (subrayada completamente), pero los vínculos no tienen nombres
del caso.
En la Figura 4-19 se muestra los varios objetos asociados a las clases mostradas
659H
en la Figura 4-13 y a las asociaciones de las clases mostradas en la Figura 4-11

60H 61H
Además, en la Figura 4-19 se incluye varios objetos vínculo. En la Figura 4-19 se

62H 63H
describe a un trabajador anónimo que realiza un proyecto -- una unidad de trabajo

- que consume un producto de trabajo Declaración del Problema y produce un
producto de trabajo del sistema. ResponsableDe y Realizar dos vínculos que
están en la Figura 4-19.64H
2008/06/18 78/195
Figura 4-19. Vínculos Binarios
:ResponsableDe
DeclaraciondelProblema: ProductodeTrabajo
ResponsableDe
Entrada
:Realizar
Consumidor
--------------------------------- :ConsumodeEntrada
Proyecto:UnidadDeTrabajo
:Trabajador
Realizar
Productor :ProductodeSalida
---------------------------------
Salida
ResponsableDe Systema: ProductodeTrabajo
|
|
|
:ResponsableDe
La única diferencia entre un vínculo binario y una asociación binaria es que el

vínculo binario es específico, y tiene su nombre de la asociación subrayado.
4.2.4.2 Vínculos de N-arios

Un vínculo n-aria, una relación entre tres o más objetos, se muestra como
diamante grande con las trayectorias de una línea recta conectadas al diamante
para cada objeto en un diagrama del objeto de UML. Por ejemplo, la utilización de
un trabajador específico implica el trabajador, las unidades específicas del
trabajador del trabajo, y los productos específicos del trabajo del trabajador en el
sistema de gerencia de proyecto. Un vínculo puede tener el nombre de su
asociación mostrado cerca de la trayectoria, y porque un vínculo es específico, el
nombre de su asociación debe ser subrayado completamente. Sin embargo, los
vínculos no tienen nombres de instancia. Pues como una regla de UML, la
agregación, la composición, y los calificadores de UML no se pueden utilizar con
vínculos n-arios.
En la Figura 4-20 se muestran varios objetos asociados a las clases mostradas en

65H
la Figura 4-14 y a las asociaciones de las clases mostradas en la Figura 4-12

6H 67H
Además, la Figura 4-20 incluye un objeto vínculo llamado Utilización. La Figura

68H 69H
4-20 describe la utilización de un equipo anónimo, su trabajo, y de sus productos

del trabajo.
2008/06/18 79/195
Figura 4-20. Vínculos de N-arios

Proyecto:UnidadDeTrabajo
-el
Tr *
-elTrabajo
jo
ab
ba
aja
* eTra
do
r
toD
uc
rod
P
-el
-elProductoDeTrabajo
*
4.2.5 Objetos Del Vinculo

Un vínculo de un objeto es un caso específico de una asociación de una clase, y
tiene así todas las características, incluyendo las características estructurales y del
comportamiento, definidas por la asociación de la clase. Las características
estructurales incluyen valores del atributo y quizás otros vínculos. Las
características del comportamiento incluyen las operaciones y los métodos, que
son compartidos por todos los vínculos de la asociación de una clase. Siempre
que una asociación tenga relación con una asociación de una clase, cada uno de
sus vínculos tiene un objeto vínculo correspondiente. Este objeto vinculo define los
valores de los atributos para las características estructurales del vinculo. Además,
las características del comportamiento definidas por la asociación de la clase del
vínculo se aplican a los objetos del vínculo. En un diagrama de objetos de UML, se
muestra un objeto vínculo como un rectángulo del objeto unido por una trayectoria
de línea discontinua a la trayectoria del vínculo en un vínculo binario, o unido a un
diamante que representa un vínculo n-aria. Como con todos los elementos de
UML que representan objetos o vínculos específicos, los nombres del objeto
vínculo deben estar subrayados completamente.
En la Figura 4-19 se muestran los objetos vinculo para las asociaciones binarias
670H
de la Figura 4-13, y la Figura 4-20 muestra un objeto vínculo para la asociación n-

671H 672H
aria en la Figura 4-14.

673H
4.2.6 Extremos Del Vínculo

Un extremo de un vínculo, similar a un extremo de una asociación, es un punto
final de un vínculo y conecta el vínculo con un objeto. Un extremo del vínculo
puede mostrar el rol del extremo de su asociación, la flecha de navegación, la
2008/06/18 80/195
agregación o el símbolo de la composición, y los valores para los calificadores en

el extremo de su asociación.
4.2.6.1 Nombre Del rol

El nombre del rol en un extremo del vínculo debe coincidir con el nombre del rol
del extremo de su asociación. Por ejemplo, la Figura 4-13 muestra que un
674H
Trabajador es responsable de un ProductoDeTrabajo. La asociación específica

usada es ResponsableDe; este mismo nombre de la asociación se utiliza otra vez
en la Figura 4-19 para describir los vínculos específicos entre un Trabajador
675H
específico y los dos productos específicos del trabajo: DeclaraciónDelProblema y

Sistema.
4.2.6.2 Navegación
Asimismo, la navegación de un extremo del vínculo debe coincidir con la
navegación de su extremo de la asociación. Por ejemplo, las flechas en los dos
vínculos de ResponsableDe en la Figura 4-19 ambos apuntan a la instancia
67H
ProductoDeTrabajo. Esto es consistente con la Figura 4-13, que muestra la flecha

67H
para la asociación de ResponsableDe que señala a la clase de

ProductoDeTrabajo.
4.2.6.3 Multiplicidad
La multiplicidad se muestra solamente en los extremos de la asociación. Esto es,
debido a que una asociación describe la multiplicidad entre dos o más clases de
objetos. Un vínculo sin embargo, está entre objetos específicos. Así, en un
diagrama del objeto, la multiplicidad se manifiesta en términos de un número
específico de vínculos que señalan a un número específico de objetos discretos.
Por ejemplo, la multiplicidad mostrada en el Figura 4-13 indica que un objeto
678H
Trabajador puede ser responsable de cero a muchos (0.. *) objetos

ProductoDeTrabajo. En la Figura 4-19 se muestran dos objetos específicos
679H
ProductoDeTrabajo. La Figura 4-19 es específica, y la multiplicidad específica en

680H
este caso son dos: el objeto específico Trabajador es responsable de dos objetos
específicos ProductoDeTrabajo.
4.2.6.4 Agregación
La agregación usando un diamante hueco, según lo mostrado en la Figura 4-21 a 681H
través de la Figura 4-23. La Figura 4-21 muestra a tres equipos nombrados Águila,
682H 683H
Halcón, y Cóndor. Jonathan, Juan, Nora, y Felipe están en el equipo Águila,

mientras que Nora y Felipe están en el equipo del Halcón.
2008/06/18 81/195
Figura 4-21. Agregación y composición para los vínculos
Organizacion
Halcon:Equipo
subequipo miembro Jonathan:Trabajador
Aguila:Equipo miembro
Juan:Trabajador
miembro
Nora:Trabajador
subequipo
miembro
Condor:Equipo
miembro
Felipe:Trabajador
4.2.6.5 Composición
La composición se puede mostrar usando un diamante llenado o un anidamiento
gráfico, como en la Figura 4-21. La Figura 4-21 muestra que los dos equipos,
684H 685H
Halcón y Cóndor, son subequipos del equipo del Águila. Además, llenar el
diamante al lado de la clase de la Organización indica que todos los individuos en
estos equipos pertenecen a la misma organización, y que el equipo Águila así
mismo pertenece a la organización.
La Figura 4-22 utiliza el anidamiento gráfico de equipos y de trabajadores en las

68H
organizaciones para comunicar la misma información que la Figura 4-21. 687H
2008/06/18 82/195
Figura 4-22. Forma alterna de composición para los vínculos
:Organización
Halcon:Equipo
subequipo
miembro Jonathan:Trabajador
Aguila:Equipo miembro
Juan:Trabajador
miembro
subequipo Nora:Trabajador
miembro
Condor:Equipo
miembro
Felipe:Trabajador
miembro
La Figura 4-23 utiliza el anidamiento gráfico de subequipos para comunicar la

68H
misma información que en la Figura 4-21 y la Figura 4-22.

689H 690H
2008/06/18 83/195
Figura 4-23. Composición doble jerarquizada para los vínculos
:Organización
miembro
Jonathan:Trabajador
Halcon:Equipo
miembro
Juan:Trabajador
Aguila:Equipo
miembro
Nora:Trabajador
miembro
Condor:Equipo
miembro
Felipe:Trabajador
miembro
4.2.6.6 Calificador
Los valores para los calificadores del vínculo tienen la misma notación que para
los valores del atributo del objeto. En la Figura 4-24 se muestra cómo los valores
691H
de los calificadores asocian un proyecto a su declaración del problema (nombrada

DeclaraciónDelProblema) y al sistema (nombrado PM-Sistema).
Figura 4-24. Valores de los calificadores para los vínculos
2008/06/18 84/195
4.3 Tipos, Clases e Interfaces de Implementación

Los tipos de clases discutidas hasta el momento se conocen como clases no
diferenciadas, y se utilizan comúnmente durante actividades de diseño dentro de
un proceso del desarrollo. Se pueden también distinguir entre tres diversos tipos
de clases, llamadas las clases diferenciadas. Éstos incluyen:
• Tipos
• Clases de Implementación
• Interfaces
Estas clases diferenciadas se relacionan fuertemente con diversas actividades del

proceso de desarrollo. En las siguientes secciones se discuten estas clases
diferenciadas.
4.3.1 Tipos
Un tipo es una clase que puede tener atributos, asociaciones, y operaciones, pero
no tiene ningún método. Un tipo define el rol que un objeto puede jugar con
respecto a otros objetos, de igual manera que el nombre de un rol indica el rol que
una clase juega con respecto a otras clases en una asociación. Por ejemplo, un
objeto Trabajador puede desempeñar el rol de un administrador del proyecto, de
un administrador de recursos, de un recurso humano, o de un administrador de
sistema. Un tipo se muestra como una clase marcada con la palabra clave del tipo.
Estos tipos de trabajadores se muestran en la Figura 4-25.
692H
Figura 4-25. Tipos
<<type>>
TAdministradorDelProyecto
<<type>> <<type>>
TRecursoHumano TAdministradorDelSistema
<<type>>
TAdministradorDeRecursos
2008/06/18 85/195
Los tipos se utilizan comúnmente durante las actividades de análisis dentro de un

proceso del desarrollo para identificar los tipos de objetos que un sistema puede
requerir. Se puede pensar en tipos como clases conceptuales, porque representan
las ideas para las posibles clases. También, debido a que los tipos no tienen
métodos y sólo representan roles, no tienen instancias.
Los tipos pueden ser utilizados junto con asociaciones binarias, asociaciones n-
aria y vínculos. Una lista separada por comas de uno o más tipos se pueden
colocar después del nombre de rol, para indicar el rol que juega una clase u objeto
dentro de la relación. Se separa el nombre del rol de la lista, usando dos puntos.
Si no es utilizado ningún nombre de rol, los tipos se colocan después de los dos
puntos.
La Figura 4-26 utiliza los tipos de la Figura 4-25 para actualizar la Figura 4-13.
693H 694H 695H
Esta figura muestra los diferentes roles que puede desempeñar un trabajador con
respecto a los productos de trabajo y las unidades de trabajo. Un trabajador
puede ser el administrador del proyecto, el administrador de recursos, un recurso
humano, o el administrador del sistema.
Figura 4-26. Tipos con asociaciones terminadas
ResponsableDe 0..*
ProductoDeTrabajo
:TAdministradorDelProyecto,
elProductoDeTrabajo
TAdministradorDeRecursos, 0..* 0..*
TRecursoHumano,
Entrada Salida
TAdministradorDelSistema 1
Trabajador
:TAdministradorDelProyecto, 1
TAdministradorDeRecursos,
0..* 0..*
TRecursoHumano, 0..*
TAdministradorDelSistema UnidadDeTrabajo
Desempeña elTrabajo
4.3.2 Clases de Implementación

Una clase de implementación es una clase que puede tener atributos,
asociaciones, operaciones y métodos. Una clase de implementación define la
implementación física de los objetos de una clase. Por ejemplo, si se fuera a
implementar las clases para un sistema de administración de base de datos, la
clase Trabajador puede ser implementada en una tabla empleado, la clase
ProductoDeTrabajo se puede implementar en una tabla de artifact, y la clase de
UnidadDeTrabajo se puede implementar en una tabla orden de trabajo. Una clase
de implementación se representa como una clase marcada con la palabra clave
2008/06/18 86/195
implementationClass (clase de implementación). Las tres clases de

implementación antes mencionadas se muestran en la Figura 4-27.
69H
Figura 4-27. Clases de Implementación
<<ImplementationClass>>
Empleado
OrdenDeTrabajo
Arifact
Las clases de implementación se utilizan comúnmente durante la última parte del

diseño y durante las actividades de implementación, dentro del proceso de
desarrollo, para identificar cómo los objetos serán implementados dentro del
sistema. Se puede pensar en clases de implementación como las clases físicas
de "código", debido a que son las implementaciones físicas de clases.
4.3.3 Interfaces
Una interfaz es una clase que puede tener operaciones pero no puede tener
atributos, asociaciones o métodos. Una interfaz define un servicio o contrato
como un conjunto de operaciones públicas. Por ejemplo, un administrador del
proyecto debe poder iniciar y terminar un proyecto, planear y administrar un
proyecto mientras que maneja un equipo, etc. Un administrador de recursos debe
poder asignar o no asignar recursos humanos a un equipo y desde un equipo. Un
producto de trabajo debe ser producido y consumido; es producido cuando es
creado o escrito, y es consumido cuando es leído o destruido. Las interfaces se
pueden utilizar para definir éstos conjuntos de operaciones.
Una interfaz se representa como una clase marcada con la palabra clave
“interface”, y debido a que las interfaces no tienen atributos, el segundo
compartimiento se encuentra siempre vacío, y por lo tanto, no se muestra. Una
interfaz también se puede representar con un círculo pequeño con el nombre del
interfaz puesto cerca del símbolo y las operaciones de la interfaz no se muestran.
Los ejemplos de ambas representaciones de la interfaz se muestran en la Figura
697H
4-28.
2008/06/18 87/195
Figura 4-28. Interfaces
<< interface >>

IAdministradorDelProyecto
<< interface >> << interface >>
iniciarProyecto(elProyecto : Proyecto) IConsumible IProducible
terminarProyecto(elProyecto : Proyecto)
planearProyecto(elProyecto : Proyecto) leer() crear()
administrarProyecto(elProyecto : Proyecto) destruir() escribir()
dirigirEquipo(elEquipo : Equipo)
IRecursoHumano IAdministradorDelSistema
<< interface >>

IAdministradorDeRecursos
asignar(elRecursoHumano : RecursoHumano, elEquipo : Equipo) : Resultado
desasignar(elRecursoHumano : RecursoHumano, elEquipo : Equipo) : Resultado
Las interfaces se utilizan comúnmente durante las actividades de análisis y de

diseño, dentro del proceso de desarrollo, para identificar los servicios que las
clases y sus objetos proporcionan. Se puede pensar en interfaces como las
Interfaces para la Programación de Aplicación (APIs), porque definen un conjunto
de operaciones, que se utilizan comúnmente juntas y se define así un servicio
más general. Debido a que las interfaces no tienen métodos, si no que
representan simplemente servicios, no tienen instancias.
Las interfaces se pueden utilizar junto con asociaciones binarias, n-aria y vínculos
para indicar los servicios (o interfaces) que una clase proporciona en la relación.
Se comienza con un nombre de rol seguido por dos puntos, después se agrega
una lista separada por comas de uno o más nombres de la interfaz, según se
muestra en la Figura 4-29.
698H
La Figura 4-29 utiliza las interfaces de la Figura 4-28 para actualizar la Figura
69H 70H 701H
4-26. Muestra como un producto del trabajo proporciona varios servicios a las
unidades de trabajo, incluyendo una interfaz para el consumo del producto de
trabajo y una interfaz para la producción del producto de trabajo. También
muestra las diversas interfaces, que un trabajador proporciona en la asociación
con los productos de trabajo y las unidades de trabajo. Las interfaces y los tipos
se pueden listar juntos, pero los tipos se utilizan comúnmente durante actividades
de análisis, mientras que las interfaces se utilizan comúnmente durante
actividades de análisis y de diseño. Las interfaces y los tipos se pueden utilizar
durante análisis y diseño, es muy importante tener una convención estándar de
nomenclatura. Por ejemplo, una convención es que las interfaces tengan el prefijo
‘I’ y los tipos el prefijo ‘T’.
2008/06/18 88/195
Figura 4-29. Interfaces con asociaciones finales
TAdministradorDeRecursos, 0..*
ResponsableDe ProductoDeTrabajo
TRecursoHumano,
TAdministradorDelSistema elProductoDeTrabajo
IAdministradorDelProyecto 0..* 0..*
IAdministradorDeRecursos Entrada : IConsumible Salida : IProducible
IRecursoHumano
IAdministradorDelSistema 1
Trabajador
1
TAdministradorDeRecursos,
TRecursoHumano, Consumidor Productor
TAdministradorDelSistema 0..* 0..*
IAdministradorDelProyecto 0..* UnidadDeTrabajo
Desempeña elTrabajo
IRecursoHumano
IAdministradorDelSistema
4.4 Generalizaciones, Realizaciones y Dependencias

Mientras que es común el uso de tipos durante las actividades de análisis,
interfaces durante las actividades de análisis y diseño, clases no diferenciadas
durante las actividades de diseño, y clases de implementación durante la última
parte de diseño y durante las actividades de implementación, ¿cómo se relacionan
todos estos elementos? Las generalizaciones, realizaciones, y las dependencias,
llamadas relaciones especializadas, tratan la cuestión de cómo clases no
diferenciadas y diferenciadas se relacionan. En las siguientes secciones se
discuten estas relaciones.
4.4.1 Generalizaciones
Una generalización entre un elemento más general y un elemento más específico
de la misma clase, indica que el elemento más específico recibe los atributos,
asociaciones y otras relaciones, operaciones, y métodos del elemento más
general. Los dos elementos deben ser de la misma clase. Por ejemplo, una
relación de generalización puede estar entre dos tipos pero no entre un tipo y una
interfaz. Pueden existir relaciones de generalización para las siguientes clases de
elementos:
• Tipos
• Clases no diferenciadas
• Clases de implementación
• Interfaces
2008/06/18 89/195
Una generalización se representa con una línea del elemento más específico al
elemento más general, con un triángulo hueco grande en el extremo de la
trayectoria conectada con el elemento más general. Se verán ejemplos de esto,
como cuando se discuta cada tipo específico de una generalización en las
siguientes secciones.
4.4.1.1 Tipos
El administrador del proyecto, el recurso humano, y los tipos de administrador del
sistema mostrados anteriormente en la Figura 4-25 son tipos específicos de
702H
recursos humanos. Se puede modelar una generalización de estos tres tipos,

para mostrar la estructura y comportamiento común de éstos. Una generalización
entre los tipos permite reutilizar las cualidades, las asociaciones, y las operaciones
de un tipo para definir un nuevo tipo. La Figura 4-30 muestra que el tipo
703H
TRecursoHumano es una generalización de TAdministradorDelProyecto, de

TAdministradorDelSistema, y de TAdministradorDeRecursos.
Figura 4-30. Generalizaciones entre tipos
<<type>>
<<type>> <<type>>
TRecursoHumano TAdministradorDelSistema
<<type>>
Debido a que una generalización entre un tipo más general y un tipo más
específico, indica que el tipo más específico es una forma especializada del tipo
más general, estas clases pueden desempeñar los roles del tipo más específico,
así como también pueden desempeñar los roles del tipo más general. Por lo
tanto, la Figura 4-30 muestra esos objetos que desempeñan los roles específicos
704H
del administrador del proyecto, del administrador de recursos, y el administrador

del sistema, que también desempeñan un rol más general de un recurso humano.
4.4.2 clases indiferenciadas

La clase Trabajador mostrada en la Figura 4-26 pueden tener una clase
705H
especializada no diferenciada de recurso humano, que a su vez tiene clases
2008/06/18 90/195
especializadas no diferenciadas, incluyendo administradores del proyecto,

administradores de recursos, y administradores del sistema. Se pueden jerarquizar
las relaciones de la generalización para clases no diferenciadas así como los
tipos, interfaces y clases diferenciadas. Por ejemplo, los administradores del
proyecto, los administradores de recursos y los administradores del sistema,
podrían ser especializaciones de un recurso humano. Un recurso humano, por
otra parte, podría ser una especialización de un trabajador, o un trabajador podría
ser una generalización de un recurso humano. Una generalización entre clases no
diferenciadas permite que se reutilicen los atributos de una clase, asociaciones,
operaciones y los métodos para definir una nueva clase no diferenciada. Las
relaciones entre las clases no diferenciadas antes mencionadas se muestran en la
Figura 4-31.
706H
Figura 4-31. Generalizaciones entre clases
Trabajador
RecursoHumano
AdministradrorDelProyecto AdministradorDeRecursos AdministradorDelSistema
Trabajo ProductoDeTrabajo
La Figura 4-30 muestra tres generalizaciones, mientras que la Figura 4-31

70H 708H
combina las generalizaciones de las clases de AdministradordelProyecto,

AdministradordeRecursos, AdministracidordelSistema conectadas de la clase
RecurosHumanos. Siempre que varias trayectorias de la misma clase conecten
con un solo elemento, UML permite que se combinen estas trayectorias en una
sola trayectoria según lo mostrado en esta figura. También, cuando se cruzan las
trayectorias pero no se conectan, UML lo muestra con una pequeña curva
semicircular por encima de las trayectorias, según se muestra para las
asociaciones entre la clase del trabajador y las clases UnidadDeTrabajo y
ProductoDeTrabajo. Indica que la línea con la curva no conecta de ninguna
manera con la otra línea que pasa a través de la curva.
Dada una clase específica, cualesquiera de las clases inmediatamente más

generales son llamadas clases padre o súper clases. Las clases más específicas
2008/06/18 91/195
se llaman clases hijo o subclases. Las clases generales que no son padres (es
decir, no inmediatamente la más general) se llaman clases primitivas. Las clases
más específicas que no son hijos (es decir, no inmediatamente la más específica)
se llaman clases descendientes. Por lo tanto, la Figura 4-31 muestra que la clase
709H
Trabajador es el padre de la clase RecursoHumano, y las clases de

AdministradordelProyecto, AdministradordeRecursos, y AdministradordeSistema
son los hijos de la clase de RecursoHumano. También muestra que la clase
Trabajador es una clase primitiva de la clase de AdministradorDelProyecto, de
AdministradorDeRecursos, y de AdministradorDelSistema, y que estas clases son
descendientes de la clase Trabajador.
Debido a que una generalización entre dos clases no diferenciadas, indica que los
objetos de una clase más específica no diferenciada son los objetos
especializados de una clase más general no diferenciada, los objetos más
específicos de la clase no diferenciada se pueden sustituir por objetos de una
clase no diferenciada. Por lo tanto, la Figura 4-31 muestra que los objetos
710H
administrador del proyecto, el administrador de recursos, y administrador del

sistema pueden ser sustituidos por los objetos recurso humano.
4.4.2.1 Clases de implementación

Una generalización entre las clases de implementación permite reutilizar los
atributos de una clase de implementación, asociaciones, las operaciones y los
métodos para definir una nueva clase de implementación. Anteriormente se
manejó la posibilidad de poner las clases de implementación mostradas en la
Figura 4-27 como tablas de la base de datos. En tal caso, las tres clases de
71H
implementación en la Figura 4-27 podían ser clases especializadas de una clase

712H
de una tabla de la base de datos. La Figura 4-32 muestra esto haciendo las
713H
especializaciones de las clases Empleado, OrdenDeTrabajo , y Artifact en de una

clase más general TablaBaseDeDatos .
Figura 4-32. Generalizaciones entre clases de implementación
Empleado
<<ImplementationClass>> <<ImplementationClass>>
TablaBaseDeDatos OrdenDeTrabajo
Arifact
2008/06/18 92/195
Debido a que una generalización entre una clase más general de implementación
y una clase más específica de implementación, indica que los objetos de la clase
más específica son objetos especializados de la clase general, los objetos de la
clase específica de implementación se pueden sustituir por los objetos de la clase
general de implementación. Por lo tanto, la Figura 4-32 muestra que el empleado,
714H
la orden de trabajo, y los objetos artifact pueden ser sustituidos por los objetos de
la tabla de la base de datos.
4.4.2.2 Interfaces
El administrador del proyecto, el recurso humano, y las interfaces del
administrador del sistema mostrados en la Figura 4-28 son versiones más
715H
específicas de la interfaz del recurso humano. Una generalización entre las

interfaces permite que se reutilicen operaciones de una interface para definir una
nueva interfaz. Las relaciones entre las interfaces antes mencionadas se
muestran en la Figura 4-33.
716H
Figura 4-33. Generalizaciones entre interfaces
<< interface >>


IRecursoHumano IAdministradorDelSistema
<< interface >>

Debido a que una generalización entre una interfaz más general y una interfaz
más específica, indica que la interfaz más específica es una forma especializada
de la interfaz más general, esas clases que proporcionan el servicio definido por la
interfaz más específica, pueden también proporcionar el servicio definido por la
interfaz más general. Por lo tanto, la Figura 4-33 muestra que esos objetos que
71H
proporcionan las interfaces para el administrador del proyecto, el recurso humano,

y el administrador del sistema también proporcionan la interfaz del recurso
humano.
4.4.3 Realizaciones
Una realización de un elemento fuente (llamado el elemento de realización) a un
elemento destino (llamado el elemento de especificación) indica que el elemento
fuente respalda todas las operaciones del elemento destino, sin tener que
2008/06/18 93/195
respaldar ningún atributo o asociación del elemento destino. Por ejemplo, la clase
no diferenciada o la clase de implementación, pueden desempeñar el rol definido
por un tipo y puede proporcionar el servicio definido por una interfaz, si la clase
respalda las operaciones definidas el tipo e interfaz. Una realización permite que
reutilicemos las operaciones de tipos y de las interfaces donde un elemento de la
realización se dice realiza sus elementos de especificación.
Una realización se muestra como una línea punteada que va desde el elemento
fuente al elemento destino, con un triángulo hueco en el extremo de la trayectoria
conectada con el elemento destino. Cuando el elemento destino es una interfaz
representada como un círculo pequeño, la realización se muestra como una línea
que conecta al elemento fuente con la interfaz.
4.4.3.1 Clases indiferenciadas

La Figura 4-29 muestra una lista de tipos y de interfaces que provienen de la clase
718H
Trabajador. De acuerdo con la Figura 4-29, la Figura 4-34 muestra que la clase
719H 720H
Trabajador toma en cuenta esos tipos e interfaces. El elemento fuente es la clase

Trabajador, y los otros elementos son los destinos. La Figura 4-29 muestra cómo
721H
las interfaces y los tipos se utilizan con varias asociaciones entre la clase
Trabajador y otras clases, mientras que la Figura 4-34 muestra que la clase
72H
Trabajador realiza explícitamente estas interfaces y los tipos independientes, y

como éstos se utilizan en las relaciones.
Figura 4-34. Realizaciones para las clases de Trabajador
<<type>>
IRecursoHumano
TRecursoHumano
<< interface >>

<<type>>
Trabajador
<<type>>
TAdministradorDeRecursos << interface >>
<<type>>
TAdministradorDelSistema
2008/06/18 94/195
Basándose en la Figura 4-29, la Figura 4-35. muestra las interfaces de los

723H 724H
productos de trabajo que se realizan. El elemento de la fuente es la clase

ProductoDeTrabajo y los otros elementos son los destinos.
Figura 4-35. Realización para la clase Producto de Trabajo
<< interface >>

IProducible
crear()
escribir()
ProductoDeTrabajo
<< interface >>

IConsumible
leer()
destruir()
Debido a que la realización de una clase fuente a un elemento destino, indica que
los objetos de la clase fuente respaldan todas las operaciones del elemento
destino, los objetos de la clase fuente se pueden sustituir por objetos de otras
clases, que también respaldan al mismo elemento destino. Por lo tanto, la Figura 725H
4-34 muestra que un objeto trabajador se puede sustituir por objetos de otras
clases que realicen los mismos tipos e interfaces que el objeto trabajador, y los
objetos de otras clases que realizan los mismos tipos e interfaces que el objeto
trabajador, se pueden sustituir por los objetos trabajador. Es decir, si dos objetos
realizan el mismo tipo o interfaz, pueden ser sustituidos por otro. La Figura 4-35
726H
ilustra esto.
4.4.3.2 Clases de implementación

De acuerdo con la Figura 4-27, la Figura 4-36 muestra que la clase Trabajador
72H 728H
puede ser implementada en una tabla de empleados, la clase de

ProductoDeTrabajo puede ser implementada en una tabla de artifacts, y la clase
UnidadDeTrabajo puede ser implementada en una tabla orden de trabajo, si se
implementan dentro de un sistema de administración de base de datos. Esto se
indica con las relaciones entre la clase de implementación Empleado realizando la
clase Trabajador, la clase de implementación OrdenDeTrabajo realizando la clase
UnidadDeTrabajo y la clase de implementación Artifact realizando la clase
ProductoDeTrabajo.
2008/06/18 95/195
Figura 4-36. Realizaciones de clases indiferenciadas por clases de implementación
<<ImplementationClass>> Trabajador
Empleado
<<ImplementationClass>> <<ImplementationClass>> ProductoDeTrabajo

TablaBaseDeDatos OrdenDeTrabajo
<<ImplementationClass>> UnidadDeTrabajo
Arifact
Cuando una clase de implementación realiza una clase no diferenciada, debe

también tomar en cuenta los tipos y las interfaces que la clase no diferenciada
realiza; esto es, no podría desempeñar los roles definidos por los tipos de la clase
no diferenciada, ni proporcionar los servicios definidos por las interfaces de las
instancias de las clases no diferenciadas.
De acuerdo con la Figura 4-36 y la Figura 4-34, la Figura 4-37 muestra los tipos e
729H 730H 731H
interfaces que la clase de implementación Empleado toma en cuenta.
Figura 4-37. Realizaciones para la clase de implementación Empleado
IRecursoHumano
<<type>>
TRecursoHumano
<<type>> << interface >>

TAdministradorDelProyecto IAdministradorDelProyecto
Empleado
<<type>>
<< interface >>
TAdministradorDelSistema
<<type>>
De acuerdo con la Figura 4-36 y la Figura 4-35, la Figura 4-38 muestra las
732H 73H 734H
interfaces que la clase de implementación Artifact toma en cuenta.
2008/06/18 96/195
Figura 4-38. Realizaciones para la clase de implementación de el Artifact
<< interface >>

IProducible
crear()
escribir()
Arifact
<< interface >>

IConsumible
leer()
destruir()
Debido a que una realización de una clase fuente a un elemento destino, indica
que los objetos de la clase fuente respaldan todas las operaciones del elemento
destino, los objetos de la clase fuente se pueden sustituir por los objetos de otras
clases que también tomen en cuenta el mismo elemento destino. Por lo tanto, la
Figura 4-37 muestra que un objeto empleado se puede sustituir por los objetos de
735H
otras clases que tomen en cuenta los mismos tipos e interfaces que el objeto
empleado, y los objetos de otras clases que tomen en cuenta los mismos tipos e
interfaces que el objeto del empleado se puede sustituir por los objetos del
empleado. La Figura 4-38 muestra lo mismo para un objeto artifact.
736H
4.4.4 Dependencias
Una dependencia de un elemento fuente (llamado cliente) a un elemento destino
(llamado proveedor) indica que las aplicaciones del elemento fuente usa o
depende del elemento destino; si el elemento destino cambia, el elemento fuente
puede requerir un cambio. Por ejemplo, una UnidadDeTrabajo utiliza la interfaz de
IConsumible como consumidor y utiliza la interfaz de IProducible como productor;
si cualquier interfaz cambia, la UnidadDeTrabajo puede requerir un cambio. La
Figura 4-39 muestra las interfaces usadas por UnidadDeTrabajo.
73H
Una dependencia se representa como una línea discontinua del elemento fuente al
elemento destino. La dependencia se puede resaltar con el uso de una palabra
clave; sin embargo, la palabra clave se omite a menudo porque el significado es
evidente de cómo se utiliza la dependencia. También, se nota que una
dependencia no tiene un triángulo hueco grande en el extremo de la trayectoria,
pero tiene una flecha abierta.
2008/06/18 97/195
De acuerdo con la Figura 4-29, la Figura 4-39 muestra las dependencias entre las
738H 739H
unidades del trabajo y de los productos del trabajo. Note que una realización se
puede mostrar como dependencia marcada con la palabra clave realiza, según lo
mostrado en la Figura 4-39 entre la clase de ProductoDeTrabajo y el interfaz de
740H
IProducible.
Figura 4-39. Realizaciones y dependencias
ProductoDeTrabajo <<realiza>>
0..* 0..*
Entrada : IConsumible Salida : IProducible

IConsumible IProducible
leer() crear()
destruir() escribir()
0..* 0..*
UnidadDeTrabajo
<<usa>>
La Figura 4-40 muestra las dependencias entre las interfaces discutidas en este
741H
capítulo, el parámetro y los tipos de retorno de sus operaciones. Por ejemplo,

IAdministradorDelProyecto debe depender de Proyecto, porque muchas de sus
operaciones toman un objeto Proyecto como parámetro.
2008/06/18 98/195
Figura 4-40. Dependencias entre interfaces y tipos de retorno
<< interface >>

iniciarProyecto(elProyecto : Proyecto) Proyecto
terminarProyecto(elProyecto : Proyecto)
planearProyecto(elProyecto : Proyecto)
administrarProyecto(elProyecto : Proyecto)
Equipo
dirigirEquipo(elEquipo : Equipo)
Resultado RecursoHumano
<< interface >>

asignar(elRecursoHumano : RecursoHumano, elEquipo : Equipo) : Resultado
desasignar(elRecursoHumano : RecursoHumano, elEquipo : Equipo) : Resultado
4.5 Paquetes y Subsistemas

Como un modelo puede tener centenares (si no es que millares) de elementos,
¿cómo se pueden organizan los elementos que integran un sistema y sus
relaciones? ¿Y cómo se utiliza esta información para determinar cómo desarrollar
el sistema lo mejor posible, mientras se consideran las vistas técnicas
concernientes del sistema, incluyendo qué elementos se pueden desarrollar en
paralelo, cuáles pueden ser comprados y cuáles tienen que ser construidos, y qué
elementos pueden ser reutilizados? Los paquetes y los subsistemas, conocidos
también como el modelo de administración de elementos, dan respuesta a estas
preguntas.
4.5.1 Paquetes
Un paquete es una agrupación organizada de elementos, en donde éstos residen,

los cuales deben tener un nombre único. En UML, los paquetes se utilizan de una
manera similar a los directorios y las carpetas, que en un sistema operativo
agrupan y organizan archivos. Por ejemplo, el sistema de administración del
proyecto se puede descomponer en una colección de clases organizadas en los
paquetes de la siguiente manera:
• Utilidades
o Fecha, tiempo y otras clases de utilidad.
• Trabajadores
2008/06/18 99/195
o La clases Trabajador y cualquier otra clase relacionada con el

trabajador, en la cual la clase Trabajador esta contenida dentro de un
paquete llamado Genérico.
• Genérico
o Las clases genéricas tales como la clase Trabajador y cualquier otra
clase relacionada con el trabajador.
• Unidad de Trabajo
o La clase UnidadDeTrabajo y cualquier otra clase relacionada con el
trabajador.
• Producto de Trabajo
o La clase de ProductoDeTrabajo y cualquier otra clase relacionada
con el producto de trabajo.
• Interfaz de Usuario
o Un paquete que contiene las clases responsables para proveer una
interfaz de usuario a través de la cual, los usuarios pueden
interactuar con el sistema.
• Procesos del Negocio

o Un paquete que contiene las clases responsables para la
implementación de la funcionalidad del negocio.
• Datos
o Un paquete que contiene las clases responsables para
implementación del almacenamiento de los datos.
Los paquetes permiten la partición de un sistema en grupos lógicos y después

relacionar estos grupos lógicos; ya que, podría llegar a ser abrumador trabajar
con cada clase y su relación a la vez. Un paquete es representado como
rectángulo grande con un rectángulo o una "lengüeta pequeña" unida en su lado
superior izquierdo. Los paquetes listados anteriormente, junto con sus relaciones,
se muestran en la Figura 4-41.
742H
2008/06/18 100/195
Figura 4-41. Paquetes
Datos
Productos de Trabajo::
ProductoDeTrabajo
Trabajadores::Genérico::
Trabajador
Unidades de Trabajo::
UnidadDeTrabajo
Trabajadores
Unidades de Prodcutos de
+ Genérico Trabajo Trabajo
+ Trabajador
+ UnidadDeTrabajo + ProductoDeTrabajo
Se puede mostrar el nombre de un paquete dentro de su rectángulo grande,

cuando su contenido no se muestra; de lo contrario, cuando el contenido del
paquete se muestra en el rectángulo grande, se debe mostrar el nombre del
paquete dentro de su lengüeta. En la Figura 4-41, se muestra que los paquetes
743H
Interfaz de Usuario, Utilidades, y Procesos del Negocio no muestran su contenido,

mientras que el resto de paquetes algunos de sus elementos. De esa manera, los
paquetes Interfaz de Usuario, Utilidades, y Procesos del Negocio tienen sus
nombres dentro del rectángulo grande, mientras que los otros paquetes tienen sus
nombres en sus respectivas lengüetas. Cada elemento dentro de un paquete
puede tener un símbolo de visibilidad para indicar si el elemento es accesible fuera
de su paquete (es decir, es público). La Figura 4-41 muestra que las clases del
74H
Trabajador, de UnidadDeTrabajo, y ProductoDeTrabajo son públicas. El paquete

Genérico situado dentro del paquete de Trabajadores es también público.
Una dependencia de un paquete fuente a un paquete destino, indica que el

contenido del paquete fuente utiliza el contenido del paquete destino. La Figura 745H
4-41 muestra que el paquete de Datos utiliza los paquetes Trabajadores, Unidades
de Trabajo y Productos del Trabajo. También muestra que los paquetes de
2008/06/18 101/195
Interfaz de Usuario, Procesos del Negocio, y Datos utilizan el paquete Utilidades,

mientras que el paquete de Interfaz de Usuario utiliza el paquete Procesos del
Negocio, que alternadamente utiliza el paquete Datos.
Un paquete define un espacio para los nombres, una parte de un modelo en el

cual un nombre debe ser único. Un elemento mostrado dentro de un paquete
probablemente esté definido en ese paquete, si se nombra simplemente. Por
ejemplo, el paquete de las Unidades del Trabajo en la Figura 4-41 define una
746H
clase pública llamada UnidadDeTrabajo. Se puede mostrar la clase

UnidadDeTrabajo en otros paquetes para indicar que esos paquetes, utilizan la
clase, en el caso de que se reserve el nombre de la clase con la trayectoria al
paquete el cual se define la clase. Un nombre completamente reservado se refiere
a un nombre de trayectoria. El nombre de trayectoria de un elemento es una
secuencia de los nombres del paquete vinculados entre sí y separados por dos
puntos dobles (::), seguidos por el nombre del elemento. La secuencia de los
nombres de paquete empieza con el nivel exterior del paquete y continuando con
el siguiente nivel interior del paquete que contiene el elemento en cuestión. La
Figura 4-41 muestra que el paquete de Datos utiliza lo siguiente:
74H
Trabajadores::Genérico:Trabajador
La clase del trabajador situada dentro del paquete Genérico, que se jerarquiza
dentro del paquete Trabajadores.
Unidades de Trabajo:: UnidadDeTrabajo
La clase UnidadDeTrabajo localizada dentro del paquete Unidades de Trabajo
Productos de Trabajo:: ProductoDeTrabajo
La clase ProductoDeTrabajo localizada dentro del paquete Productos de Trabajo.
4.5.2 Subsistemas
Recuerde que un sistema es una colección organizada de los elementos que se
pueden descomponer recursivamente en subsistemas más pequeños y
eventualmente en elementos primitivos, que no pueden descomponerse en más
elementos. Por ejemplo, el sistema de administración del proyecto se puede
descomponer como sigue:
• Un subsistema de interfaz de usuario responsable de proporcionar una
interfaz de usuario a través de la cual, los usuarios pueden interactuar con
el sistema.
• Un subsistema de los procesos del negocio responsable de implementar la

funcionalidad del negocio.
2008/06/18 102/195
• Un subsistema de datos responsable de implementar el almacenamiento

de los datos.
Los elementos primitivos son las diversas clases que se utilizan en estos
subsistemas y a fin de cuentas en el sistema entero. Mientras que un paquete
agrupa simplemente elementos, los elementos agrupados en un subsistema
proporcionan en conjunto, servicios para que otros elementos puedan tener
acceso solo a estos servicios y ningún otro elemento más. Y mientras que los
paquetes permiten descomponer el sistema en grupos lógicos y relacionar estos
grupos lógicos, los subsistemas permiten considerar qué servicios proporcionan
estos grupos lógicos a otro.
Un sistema es representado como un paquete marcado con la palabra clave del

subsistema. El rectángulo grande del paquete puede tener tres compartimientos
estándares, que se muestran dividiendo el rectángulo con una línea vertical y
después dividiendo el área a la izquierda de esta línea en dos compartimientos
con una línea horizontal. La Figura 4-42 muestra cómo un subsistema Datos debe
748H
lucir, para nuestro ejemplo de un sistema administración del proyecto. Las

operaciones del subsistema, los elementos de especificación, y las interfaces
describen los servicios que el subsistema proporciona, y son los únicos servicios
accesibles para otros elementos fuera del subsistema.
Figura 4-42. Una representación de subsistema en el UML

<<subsystem>>
Datos
leer Realización de Elementos

destruir
hacerTrabajo(elTrabajo:Trabajo) Productos de Trabajo::
ProductoDeTrabajo
Trabajadores::Genérico:
:Trabajador
Especificación de Elementos
Unidades de Trabajo::
UnidadDeTrabajo
Administrador del Administrador del Proyecto
Proyecto Negociador
El compartimiento superior izquierdo muestra una lista de las operaciones que el

subsistema realiza. El compartimiento inferior izquierdo se puede etiquetar
"Especificación de Elementos" y muestra la especificación de elementos que el
subsistema toma en cuenta. Por ejemplo, cualquier caso de uso que el
subsistema proporciona la especificación de elementos que el sistema debe tomar
en cuenta. El compartimiento derecho se puede etiquetar "Realización de
Elementos" y muestra los elementos dentro del subsistema que realizan las
operaciones del subsistema y la especificación de elementos, así como también
2008/06/18 103/195
cualquier interfaz que el subsistema proporciona. Se puede modificar esta

notación general cambiando los compartimientos, combinando los
compartimientos, o quitando uno o más compartimientos. Cualquier elemento se
puede utilizar como elemento de la especificación o de la realización, debido a que
una realización indica simplemente el elemento de la realización da soporte por lo
menos todas las operaciones del elemento de la especificación sin tener que
necesariamente dar soporte a cualesquier cualidad o asociación del elemento de
la especificación.
La Figura 4-43 utiliza subsistemas para refinar la Figura 4-41. Los paquetes del
749H 750H
Procesos del Negocio y Datos de la Figura 4-41 ahora son subsistemas. El

751H
subsistema del Procesos del Negocio proporciona una interfaz que es utilizada por
el paquete Interfaz de Usuario. El subsistema Procesos del Negocio utiliza el
subsistema Datos y la interfaz IProducible proporcionada por el subsistema Datos.
El subsistema Datos toma en cuenta la interfaz IProducible que se encuentra fuera
del subsistema, diferentes operaciones y un caso de uso Administrador del
Proyecto que se discutió en el Capítulo 2. El caso del uso es el óvalo en el
compartimiento del elemento de la especificación. Los elementos de la realización
del subsistema Datos realizan las operaciones leer, destruir, y hacerTrabajo, el
caso del uso, y las operaciones de la interfaz IProducible.
2008/06/18 104/195
Figura 4-43. Subsistemas
Note en la Figura 4-43 que el paquete de la Interfaz de Usuario no utiliza el

752H
paquete del Procesos del Negocio según lo mostrado en la Figura 4-41, por el
753H
contrario, utiliza la interfaz IProcesosDelNegocio proporcionado por el subsistema

Procesos del Negocio. Este último, usa una interfaz que permite centrarse en el
servicio que el paquete Interfaz de Usuario utiliza, mejor dicho el paquete que le
proporciona el servicio. Al centrarse en el hecho de que el paquete de Interfaz de
Usuario utiliza el paquete Procesos del Negocio, no es posible determinar las
operaciones exactas que el paquete Interfaz de Usuario requiere del paquete
Procesos del Negocio; si hay un cambio al paquete Procesos del Negocio, se
tendría que hacer un esfuerzo significativo para determinar si el cambio requiere la
modificación del paquete Interfaz de Usuario. Centrándose en el servicio que el
paquete Interfaz de Usuario utiliza o mejor dicho el paquete que le proporciona el
servicio, se pueden determinar las operaciones usadas por el paquete que
proporciona el servicio; solamente si hay un cambio en el servicio o en esas
operaciones, se tiene que realizar un esfuerzo para determinar si el cambio
requiere la modificación del paquete Interfaz de Usuario. Más bien, hay que
considerar todas las operaciones disponibles dentro del paquete Procesos del
2008/06/18 105/195
Negocio para determinar si los cambios en ese paquete afectan el paquete

Interfaz de Usuario, se necesita solamente observar un subconjunto de esas
operaciones: el subconjunto definido por la interfaz IProcesoNegocio. De manera
similar, note cómo el paquete Procesos del Negocio utiliza el paquete Datos en la
Figura 4-41, pero el subsistema Procesos del Negocio utiliza sólo las operaciones,
754H
los elementos especificados, y la interfaz IProducible proporcionado por el

subsistema Datos en la Figura 4-43.
75H
En la Figura 4-43, se muestran los elementos principales que integran el sistema

756H
de administración del proyecto y las relaciones entre ellos. Usando los paquetes,
subsistemas, interfaces, y sus relaciones, se puede considerar más fácilmente qué
elementos se pueden desarrollar en paralelo, qué elementos pueden ser
comprados y cuáles tienen que ser construidos, y cuáles pueden ser reutilizados.
Es posible tratar a estos elementos como clases y sus relaciones, pero debido a
que un sistema puede tener muchas clases, puede llegar a ser fácilmente
abrumador trabajar con tanta diversidad. Se puede también tratar a estos
elementos usando los paquetes y sus dependencias, pero los paquetes no ofrecen
servicios. Los paquetes capturan simplemente los elementos principales que
integran el sistema y no los servicios que se utilizan dentro del paquete. Así que
se debe de centrar en todo el contenido de un paquete, o más bien, en los
servicios usados por los elementos que dependen del paquete. Sin embargo,
usando los paquetes, los subsistemas, las interfaces, y sus relaciones, se puede
tratar más fácilmente los elementos mencionados anteriormente, debido a que se
puede capturar los elementos principales que integran el sistema, así como
también los servicios que se proporcionan y se requieren para que estos
elementos puedan trabajar en conjunto, para proporcionar la funcionalidad del
sistema.
Debido a que las operaciones de un subsistema, los elementos especificados, y

las interfaces describen los servicios que el subsistema proporciona, así como
cuáles son los únicos servicios accesibles por otros elementos fuera del
subsistema, qué colección de subsistemas se puede desarrollar en paralelo,
proporcionan las interdependencias entre ellos que se basan solamente en sus
servicios. Por ejemplo, se puede desarrollar el subsistema de Datos y el
subsistema de los Procesos del Negocio en paralelo, porque cualquier elemento
que utilice estos subsistemas utiliza siempre los servicios ya definidos.
Debido a que los servicios de un subsistema se especifican completamente, se

procura comprar (o construir) un subsistema que proporcione los mismos
servicios. Por ejemplo, no se puede tener bastante financiamiento para construir
el subsistema de Datos, sino que, debido a que se conocen los servicios del
subsistema, se puede buscar y comprar un subsistema similar que ofrezca los
mismos servicios.
Debido a que los servicios de un subsistema se especifican completamente, se

puede reutilizar el subsistema siempre que se requieran servicios similares. Por
2008/06/18 106/195
ejemplo, siempre que se requieran los servicios definidos por la interfaz de

IProcesoNegocio, se puede reutilizar cualquier subsistema que proporcione la
interfaz; cuando se requieran los servicios definidos por la interfaz IProducible
como las operaciones leer, destruir, hacerTrabajo, o el caso de uso Administración
del Proyecto, se puede reutilizar cualquier subsistema que proporcione alguno de
estos servicios.
5 Diagramas de Caso de Uso

Este capítulo se centra en los diagramas de caso de uso, que representan la
funcionalidad de un sistema. Primero, se introducen los diagramas de caso de uso
y se observa como se utilizan. Después, se habla sobre los actores y casos de
uso. Finalmente, se pasan varias relaciones referentes a los actores y casos de
uso. Muchos detalles que no fueron mostrados en el capítulo 3 se elaboran más
completamente aquí, y a través del capítulo se incluye sugerencias referentes a
los diagramas de caso de uso.
El modelado de caso de uso es un tipo especializado de modelado estructural

referido al modelado de la funcionalidad de un sistema. Se aplica generalmente el
modelado de caso de uso durante las actividades requeridas a los requisitos de la
captura que definen lo que debe hacer un sistema. El modelado de caso de uso
típicamente comienza rápidamente en un proyecto y continúa a través de un
proceso de desarrollo de sistema. Esto es usualmente hecho como una serie de
talleres entre los usuarios y analistas de un sistema en el cual las ideas puedan
ser exploradas y los requisitos pueden ser mostradas en un cierto plazo.
Así como un caso de uso dirige las aplicaciones de proceso que usa casos para
planear y para realizar las iteraciones, es importante entender cómo los casos de
uso se relacionan el uno con el otro, incluyendo los casos de uso que tienen en
común, los cuales sean opciones de otros casos de uso, y cada caso de uso son
similares el uno al otro. Dado que cada proyecto ha limitado recursos, se puede
usar esta información acerca de casos de uso para determinar cómo mejorar la
ejecución del proyecto. Los casos de uso que son comunes a dos o más de otros
casos de uso necesitan solo ser implementados una sola vez, y entonces pueden
ser reutilizados. Casos de uso que son opciones de otros casos de uso se pueden
poner en ejecución después, y casos de uso son similares y nos permite
implementar un caso de uso que puede que sea rehusado. Una comprensión de
cómo casos de uso son relacionados permite que los usuarios y los analistas
negocien y que alcancen el acuerdo referente al alcance y los requisitos de un
sistema.
Un diagrama de caso de uso se puede considerar un "tabla de contenido" para los

requisitos funcionales de un sistema. Los detalles detrás de cada elemento en el
diagrama de caso de uso pueden ser capturados en forma textual o usando el otro
modelado técnico de UML. Todos los diagramas de caso de uso y sus detalles
asociados para un sistema específico forman los requisitos funcionales del
2008/06/18 107/195
sistema. Sin embargo, UML no proporciona ninguna dirección explícita en cómo

capturar los detalles textuales, sino se centra más en la notación.
5.1 Actores
Según lo discutido en el capítulo 3, un actor es un usuario o un sistema externo
con el cual un sistema modelado interactúa. Por ejemplo, nuestro sistema de
administración de proyecto implica varios tipos de usuarios, incluyendo
administradores de proyecto, administradores de recurso, recursos humanos, y
administradores de sistema. Estos usuarios son todos los actores.
Los actores siguen la dicotomía del tipo de instancia primeramente discutido en el

capítulo 3 y aplicada a las clases y objetos en el capítulo 4. Se puede utilizar UML
para hablar de clases de actores, así como actores específicos de una clase. Al
hablar de una clase de actores, se acostumbra a utilizar los términos actores o
clase de actor. Así, mientras que se puede pensar en un actor como una cosa
específica, en UML, un actor realmente representa una clase de cosas. Al hablar
de un actor específico de una clase, se usa el termino actor de casos.
Un actor es externo a un sistema, interactuando con el sistema, puede ser un

usuario humano u otro sistema, y tiene metas y responsabilidades para satisfacer
en la interacción con el sistema. Los actores tratan la cuestión de quién y de qué
influenciar con un sistema. En UML, muestran un actor como una "figura de
palitos" icono, o como clase marcada con la palabra clave del actor y etiquetada
con el nombre de la clase del actor.
La Figura 5-1 muestra a varios actores asociados con el proyecto de sistemas de

75H
administración:
• Administrador de proyecto
o Responsable de asegurarse de que un proyecto entregue un
producto de calidad dentro de un tiempo y costo especificado, y
adentrado a una limitación de recursos específicos.
• Administrador de recursos
o Responsable de asegurar que se entrene y especialice a los
recursos humanos para que estos estén disponibles para los
proyectos
• Recursos humanos
o Responsable de asegurarse de que las habilidades del trabajador
estén mantenidas, y de que el trabajo de la calidad sea completado
para un proyecto
• Administrador de sistema
2008/06/18 108/195
o Responsable de asegurarse que un proyecto de sistema de

administración este disponible para un proyecto
• Sistema de reserva
o Responsable de la cubierta de datos de reserva para el proyecto de
sistema administrativo
Figura 5-1. Actores
: Administrador de Sistemas
: Administrador de Proyecto
: Recursoso Humanos
<<Actor>>
Sistema de
: Administrador de Recursos Respaldo
Un caso de actor es un usuario o un sistema en específico. Por ejemplo, los

usuarios específicos de un proyecto de sistema administrativo incluyen a
Jonathan, Juan, Simón, Felipe, Nora, y así sucesivamente. Un caso del actor se
muestra similar a una clase del actor, pero se etiqueta con el nombre de caso de
actor seguido por dos puntos seguidos por el nombre de la clase del actor, todo
subrayado completamente. Ambos nombres son opcionales, y los dos puntos
están solamente presentes si se especifica el nombre de la clase del actor. Los
casos del actor tratan la cuestión de quién y de qué obra recíprocamente
específicamente con un sistema.
La Figura 5-2 muestra los variados casos de actor de las clases de actor en la
758H
Figura 5-1, incluyendo a Jonathan y Juan que son los administradores del
759H
proyecto, Simón que es un recurso humano, Felipe que es el administrador de

sistema, Nora que es un tipo sin especificar de caso de actor, un sistema de
reserva llamado BackupSys1.0, y de otros casos del actor. Apenas pues es
posible tener un actor de un tipo sin especificar, tal como Nora, es posible que se
tengan actores tales como Recursos Humanos para el cual se especifique un tipo,
pero no un nombre.
2008/06/18 109/195
Figura 5-2. Instancias de actores
: Jonathan: Administrador de : Felipe: Administrador de

: Simon: Recursoso Humanos : Nora
Proyecto Sistema
: Juan: Administrador de
: Recursos Humanos
Proyecto
BackSis: Sistema de Respaldo :

Sistema de Respaldo
: Administrador de Recursos : Recursos Humanos
El porque de que los actores son externos a un sistema e interactúan con este
sistema, es porque definen el límite o el alcance del sistema. Por ejemplo, dado
los actores demostrados en la Figura 5-1 , sabemos exactamente quién y qué
760H
interactuara con el proyecto de sistema. Si no definimos a nuestros actores,

podemos caer en una trampa sin fin de discutir si hemos identificado a todos los
usuarios del sistema y del resto de los sistemas que interactúan con el sistema.
Consecuencialmente, el porque de cada requisito funcional debe ser de interés por
lo menos a un usuario (de otra manera, ¿porqué debemos construir el sistema
para proporcionar la funcionalidad?), sin identificar a actores, no tenemos ninguna
manera de saber si hemos identificado todos los requisitos funcionales del
sistema. Un actor puede también representar un recurso poseído por otro proyecto
o comprado más bien que construido. Por ejemplo, el sistema de reserva se debe
proporcionar por otro proyecto, y puede ser comprado de un vendedor o ser
construido más bien que ser comprado. Independientemente de cómo sea
desarrollado, estamos interesados en interactuar con este como recurso.
5.2 Casos de uso

Según se discutió en el capítulo 3, un caso de uso es un requisito funcional que se
describe de la perspectiva de los usuarios de un sistema. Por ejemplo, los
requisitos funcionales para el proyecto de sistema administrativo incluyen:
funcionalidad de la seguridad (tal como permitir que los usuarios abran una sesión
y fuera del sistema), entrada de datos, proceso de datos, generación de informes,
y así sucesivamente.
Casos de uso siguen la dicotomía del tipo-caso primero discutida en el capítulo 3 y

aplicada a las clases y se oponen en el capítulo 4. Se puede utilizar UML para
2008/06/18 110/195
hablar de clases de casos de uso, y se puede utilizar UML para hablar de casos
específicos de uso de una clase. Al hablar de una clase de casos de uso, se
acostumbra utilizar el termino de casos de uso o clase de casos de uso. Así,
mientras que puede ser que se piense en un caso de uso como una cosa
específica, en UML, un caso de uso realmente representa una clase de cosas. Al
hablar de un caso específico de uso de una clase, se usa el termino de clase de
casos de uso.
Un caso de uso define un requisito funcional que se describa como secuencia de

pasos, que incluyen las acciones realizadas por un sistema e interacciones entre
el sistema y los actores. Casos de uso tratan la cuestión de cómo los actores
interactúan con un sistema, y describen las acciones que el sistema se realiza.
En UML, un caso de uso se muestra como una elipse y se etiqueta con el nombre
de la clase de caso-uso. Los casos de uso se pueden incluir por un rectángulo que
represente el límite del sistema que proporciona la funcionalidad. La Figura 5-3
761H
muestra los varios casos de uso asociados al proyecto de sistema administrativo,

incluyendo funcionalidad para manejar proyectos, para manejar recursos, y para
administrar el sistema.
Figura 5-3. Casos de uso
Administrador de proyecto
Administrador de Recursos Administrador de sistemas
Una instancia de caso-uso, a menudo llamado un panorama, es el funcionamiento

de una secuencia específica de acciones y de interacciones. Por ejemplo, un caso
específico del actor que utiliza funcionalidad de seguridad para abrirse una sesión
o fuera del proyecto de sistema administrativo representa un panorama. Otros
panoramas posibles pudieron incluir a un usuario que inscribe datos, a un usuario
que solicite el proceso que se hará en los datos, o a un usuario que solicita que el
sistema genere un informe.
Una instancia de caso-uso se muestra semejantemente a un caso de uso pero se

etiqueta con el nombre de instancia de caso-uso seguido por dos puntos seguidos
por el nombre de caso-uso, todo subrayado completamente. Ambos nombres son
opcionales, y los dos puntos son presentables solamente si se especifica el
nombre de la clase de caso-uso. Las instancias de caso-uso tratan las cuestiones
2008/06/18 111/195
de cómo los casos del actor interactúan específicamente con un sistema y de qué
acciones específicas realiza el sistema en vuelta. Las instancias de caso-uso no
se muestran comúnmente en diagramas de caso de uso sino se discuten
simplemente con los usuarios para entender mejor sus requisitos.
El porque de que los casos de uso son realizados por un sistema, es porque
definen los requisitos funcionales del sistema. Por ejemplo, dado casos de uso
demostrados en la Figura 5-3 , sabemos generalmente qué tipo de funcionalidad
762H
se debe proporcionar por el proyecto de sistema administrativo. Otros diagramas

de caso de uso pueden refinar y descomponer estas cajas de uso. Si no definimos
nuestros casos de uso, podemos caer en la trampa sin fin de discutir si hemos
identificado toda la funcionalidad del sistema.
Cada caso de uso se compone de una o más secuencias de comportamiento. Una

secuencia de comportamiento es una secuencia de pasos en los cuales cada paso
especifica una acción o una interacción. Cada acción especifica el proceso
realizado por el sistema. Cada interacción especifica una cierta comunicación
entre el sistema y el que esta de los actores que participan en el caso de uso. Por
ejemplo, un caso de uso de la conexión puede tener la secuencia del siguiente
comportamiento:
1. El sistema provee una interfaz de usuario para capturar la información de

entrada.
2. El usuario entra con su nombre de usuario.
3. El usuario introduce su contraseña.
4. El sistema valida el nombre de usuario y la contraseña.
5. El sistema responde apropiadamente permitiendo que el usuario continúe, o

rechazando al usuario, dependiendo de si su nombre de usuario y
contraseña son válidos.
Pasos 1, 4, y 5 son las acciones que el sistema realiza, y los pasos 2 y 3 son
interacciones entre el sistema y el usuario. Es bastante simple ver que el paso 4
es una acción, pero se puede preguntarse porqué los pasos 1 y 5 son acciones
más bien que interacciones, cuando el sistema está interactuando con el usuario
por la presentación de la interfaz de usuario o respondiendo apropiadamente con
una ventana de mensaje o algo similar. Los pasos 1 y 5 son acciones más bien
que interacciones porque el sistema simplemente está llevando a acción la
demostración de la interfaz de usuario o una ventana de mensaje que el usuario
pueda elegir fácilmente para ignorar. Sin embargo, si éste no fuera un usuario
humano sino otro sistema que recibiría una cierta comunicación a la cual debe
contestar, éstas serían interacciones más bien que acciones. Absolutamente a
menudo, no es necesario el intentar clasificar cada paso como una acción o
2008/06/18 112/195
interacción; algo, es más importante considerar un caso de uso como diálogo

entre los actores y el sistema, entender cómo los actores interactúan con el
sistema, y entender qué acciones son la responsabilidad del sistema.
Las acciones y las interacciones se pueden repetir también, condicional, u

opcional. Por ejemplo, el caso de uso del proyecto de manejo puede tener una
secuencia de comportamiento para encontrar un proyecto en el cual trabajar, y las
tres secuencias siguientes del comportamiento que tienen éxito:
• Uno para los proyectos de administración que implican a empleados

solamente.
• Uno para los proyectos de manejo que implican a consultores solamente
• Uno para manejar proyectos de la participación de empleados y de

consultores
Una instancia de caso de uso del proyecto de manejo implica casos del actor y
encontrar un proyecto y el manejo de él que usa una de las tres secuencias
disponibles del comportamiento basadas sobre el tipo de proyecto seleccionado.
Las secuencias del comportamiento, tales como la que esta demostrada
anteriormente para el caso de uso de la conexión, se capturan comúnmente en
forma textual, pero se pueden también capturar usando técnicas que modelan del
comportamiento, según lo discutido en la parte III. Sin embargo, UML no
proporciona ninguna dirección explícita en cómo capturar secuencias del
comportamiento.
Porque el uso encajona resultado en un cierto valor observable a unos o más

actores, deben permitir que los actores alcancen sus metas. Después de todo,
cada actor tiene metas para interactuar con un sistema. Los casos de uso no
representan las metas del actor, sino que por el contrario representan
funcionalidad que permite a los actores alcanzar sus metas. Por ejemplo, casos de
uso demostrados en la Figura 5-3 permiten a los actores demostrados en la Figura
763H 764H
5-1 para alcanzar sus metas de las siguientes maneras:
• Para asegurarse de que un proyecto entregue un producto de calidad

dentro del tiempo especificado, del costo, y de las limitaciones
especificadas del recurso, un administrador de proyecto puede utilizar el
caso de uso del proyecto de manejo.
• Para asegurarse que el entrenamiento y la experiencia de los recursos

humanos estén disponibles para los proyectos, un administrador de recurso
puede utilizar el caso de uso del recurso del manejo.
2008/06/18 113/195
• Para asegurarse de que un sistema de gerencia de proyecto esté disponible

para un proyecto, un administrador de sistema puede utilizar el caso de uso
del sistema del administrar, que puede implicar un sistema de reserva.
El proyecto de sistema administrativo no ofrece ninguna funcionalidad para

permitir a recursos humanos alcanzar sus metas. Observe que tal funcionalidad
está fuera del alcance del sistema.
5.3 Asociaciones de Comunicación

La Figura 5-1 muestra que los actores asociados al proyecto de sistema
765H
administrativo y la Figura 5-3 muestra los casos de uso asociados al proyecto de

76H
sistema administrativo, pero ¿cómo los actores y casos de uso están

relacionados? Un tipo especializado de asociación, llamado una asociación
comunicativa, trata la cuestión de cómo los actores y casos de uso son
relacionados y de que participan dentro o inician los actores casos de uso. (Las
asociaciones se discuten en el capítulo 4.)
Según lo discutido en el capítulo 3, una asociación comunicativa entre un actor y

un caso de uso indica que el actor utiliza el caso de uso; es decir, indica que el
actor se comunica con el sistema y participa en el caso de uso. Un caso de uso
puede tener asociaciones con los actores múltiples, y un actor puede tener
asociaciones con los casos múltiples de uso. Una asociación del comunicar se
muestra como de línea llena entre un actor y un caso de uso.
La Figura 5-4 muestra que un administrador de proyecto participa en proyectos de

76H
manejo, un administrador de recursos participa en recursos de manejo, y un

sistema del administrador de sistema y de reserva participa en administrar el
sistema.
2008/06/18 114/195
Figura 5-4. Actores y casos de uso
Sistema De Administracion De Proyecto
Administrador de Proyecto Administracion_de _Proyecto Administrador de Sistemas
Administrador de Sistema
<<Actor>>
Sistema de Respaldo
Administracion_de_Recursos
Administrador de Recursos
Una flecha de navegación en una asociación que señala hacia un caso de uso
indica que el actor inicia la interacción con el sistema. La Figura 5-4 muestra que
768H
un administrador de proyecto inicia la interacción con el proyecto de sistema

administrativo para manejar proyectos, y un administrador de recursos inicia la
interacción con el proyecto de sistema administrativo para manejar recursos.
Una flecha de la navegación en una asociación que señala hacia un caso de uso
indica que el actor inicia la interacción con el sistema. La Figura 5-4 muestra que
769H
un administrador de proyecto inicia la interacción con el proyecto de sistema

administrativo para manejar proyectos, y un administrador de recurso inicia la
interacción con el proyecto de sistema administrativo para manejar recursos.
Más bien se usaran dos flechas cuando el sistema o el actor pueda iniciar una
interacción, las flechas de navegación en ambos finales de dicha asociación se
caen. La Figura 5-4 muestra que un administrador de sistema o el sistema puede
70H
iniciar una interacción para administrar el sistema. El administrador de sistema

pudo iniciar una interacción con el sistema para sostener los datos, o, por ejemplo,
el sistema pudo iniciar una interacción con el administrador de sistema que
informaba al actor que los recursos de sistema son bajos.
Esté enterado, sin embargo, que una carencia de las flechas de la navegación
puede resultar simplemente de un modelador que elige no especificar cualquier
cosa sobre la iniciación de una interacción. Así, con respecto a la Figura 5-4, no se 71H
puede estar absolutamente seguro que cualquier actor puede iniciar una
interacción de la administración del sistema. Podría ser que el administrador de
2008/06/18 115/195
sistema puede iniciar solamente la interacción, y el modelador que UML eligió

simplemente no especificar la iniciación en este un caso. Depende simplemente
de las pautas que modelan que el modelador está utilizando.
5.4 Dependencias
Un modelo puede tener muchos casos de uso, así que ¿cómo organizamos casos
de uso que definen lo que debe hacer un sistema? Y cómo utilizamos esta
información sobre casos de uso para determinarnos cómo lo más mejor posible
ejecutar un proyecto mientras que consideran cómo casos de uso se relacionan
uno con otro, incluyendo ¿qué algunos casos de uso pudieron tener en campo
común, y también consideran casos de uso que son opciones de otros casos de
uso? Los tipos especializados de dependencias, llamados dependencias incluidas
y extendidas, tratan estas preguntas; las dependencias se discuten en el capítulo
4. Las próximas secciones discuten estos tipos especializados de dependencias.
5.4.1 Dependencias incluidas

Quizás deseamos registrar las actividades de los administradores de proyecto, de
los administradores de recursos, y de los administradores de sistema mientras que
interactúan con el proyecto de sistema administrativo. La Figura 5-5 elabora casos
72H
de uso, en la Figura 5-4 para demostrar que las actividades del administrador de
73H
proyecto, de los administradores de recurso, y de los administradores de sistema

están registradas cuando están realizando casos de uso demostrados en el
diagrama. Así, las actividades de registro son comunes a estos casos de tres
usos. Podemos utilizar una dependencia del incluido para tratar este tipo de
situación descomponiendo en factores fuera y reutilizando comportamiento común
de casos múltiples de uso.
Figura 5-5. Casos de uso con un común comportamiento
Administracion del proyecto y

Administrador de Proyecto Administrador de Sistema
Actividad del Registro
Administrador del Sistema y

<<Actor>>
Sistema de Respaldo
Adminstrador de recursos Administracion de Recursos y

2008/06/18 116/195
Una dependencia incluida a partir de un caso de uso (llamado la base de casos de

uso) a otro caso de uso (llamado el caso de uso de la inclusión) indica que la base
de casos de uso incluirá o llamará el caso de uso de la inclusión. Un caso de uso
puede incluir casos múltiples de uso, y puede ser incluido en casos múltiples de
uso. Se muestra una dependencia del incluido como una flecha rayada de base de
casos de uso al caso de uso de la inclusión marcado con la palabra clave del
incluido. Está responsable la base de casos de uso de identificar donde en su
secuencia del comportamiento o en qué paso para incluir el caso de uso de la
inclusión. Esta identificación no se hace en el diagrama de UML, sino algo en la
descripción textual de base de casos de uso.
La Figura 5-6 refina la Figura 5-5 que usa dependencias incluidas. La actividad del
74H 75H
registro de casos de uso es común al proyecto del manejo, maneja el recurso, y

administra casos de uso del sistema, así que se descompone en factores hacia
fuera y es incluido por estos casos de uso.
Figura 5-6. Dependencias incluidas
Administracion de Proyecto
Administrador de Projecto
Administrador de Sistemas
<<include>>
<<include>>
Actividad de Registro Administrador de Sistemas
<<include>> <<Actor>>
Sistema de
Respaldo
Administracion de Recursos
Administrador de Recursos
Se puede utilizar una dependencia del incluido cuando un caso de uso puede ser
común al múltiplo otros casos de uso y por lo tanto se descompone en factores
fuera de los diversos casos de uso para poderlo reutilizar. El caso de uso de la
actividad del registro en la Figura 5-6 se incluye en el proyecto del manejo, maneja
76H
el recurso, y administra casos de uso del sistema. Por lo tanto, se debe analizar y
2008/06/18 117/195
convertirse que caso de uso antes de que se desarrolle los tres casos de uso que
dependen de él.
5.4.2 Dependencias Extendidas

Los proyectos se hacen de actividades, y las actividades se hacen de tareas. La
Figura 5-7 elabora el caso de uso del proyecto del manejo en la Figura 5-4, y
7H 78H
muestra que un administrador de proyecto puede manejar proyectos manteniendo

el proyecto sí mismo, sus actividades, o sus tareas. Así, manteniendo el proyecto,
sus actividades, y sus tareas son opciones de manejar un proyecto. Se puede
utilizar una dependencia del extender para tratar esta situación descomponiendo
en factores fuera de comportamiento opcional de un caso de uso.
Figura 5-7. Casos de uso con un comportamiento opcional
Administracion del Proyecto

por si mismo
Administracion del Proyecto

Administrador de Proyecto por Actividad
Administrar Proyecto
por Tarea
Una dependencia del extender a partir de un caso de uso (llamado el caso de uso
de la extensión) a otro caso de uso (llamado la base de casos de uso) indica que
el caso de uso de la extensión extenderá (o ser insertado en) y aumentará la base
de casos de uso. Un caso de uso puede extender casos múltiples de uso, y un
caso de uso se puede ampliar por los casos múltiples de uso. Una dependencia
del extender se muestra como flecha rayada de caso de uso de la extensión a la
base de casos de uso marcado con la palabra clave del extender. La base de
casos de uso es responsable de identificar en qué pasos en su secuencia del
comportamiento pueden ser insertados casos de uso que extienden.
La Figura 5-8 refina la Figura 5-7 que usa amplía dependencias. El proyecto del
79H 780H
mantener, mantiene actividad, y mantiene casos de uso de la tarea es opciones de

caso de uso del proyecto del manejo, así que maneje el proyecto se descompone
en factores hacia fuera y extiende esos casos de tres usos.
2008/06/18 118/195
Figura 5-8. Dependencias extendidas simples
Mantener Proyecto
<<extender>>
<<extender>>
<<extender>>
Administacion de Proyecto Mantener Actividad
Administrador de Proyecto
Mantener Tarea
La localización en una base de casos de uso en el cual otra secuencia del

comportamiento pueda ser insertada se llama un punto de la extensión. Los
puntos de la extensión para un caso de uso se pueden enumerar en un
compartimiento etiquetado "extensión señalada" donde cada punto de la extensión
se muestra dentro del compartimiento con un nombre del extensión-punto seguido
por dos puntos seguidos por una descripción conveniente de la localización del
punto de la extensión en la secuencia del comportamiento de caso de uso. Las
localizaciones se pueden describir como estando antes, después, o en-el-lugar- de
un paso en la secuencia del comportamiento de base de casos de uso. Por
ejemplo, el caso de uso del proyecto del manejo puede tener una secuencia del
comportamiento para encontrar un proyecto en el cual al trabajo siguió por un
punto de la extensión nombrado Project Selected seguido por otro
comportamiento. El punto seleccionado proyecto de la extensión se puede
describir como ocurriendo después de que se encuentre un proyecto pero antes
de que se trabaja realmente encendido.
Una dependencia del extender es responsable de definir cuando un caso de uso

de la extensión es insertado en la base de casos de uso especificando una
condición que se deba satisfacer para que ocurra la inserción. La condición se
puede demostrar después de la palabra clave del extender incluida dentro de los
corchetes seguidos por el nombre del punto de la extensión incluido en paréntesis.
Por ejemplo, otros casos de uso se pueden insertar en el punto seleccionado
proyecto de la extensión apenas descrito para el caso de uso del proyecto del
manejo. Tales secuencias del comportamiento pueden incluir el repaso y la
puesta al día de la información del proyecto, o seleccionar una versión específica
de un proyecto antes de manejar los detalles del proyecto en las secuencias del
comportamiento que tienen éxito.
2008/06/18 119/195
La Figura 5-9 elabora en el caso de uso del sistema del administrar en la Figura
781H 782H
5-4 que usa amplía dependencias. Muestra un administrador de sistema ofrece

dos opciones -- encender el sistema o cerrar el sistema -- en el punto de la
extensión nombrado Funciones Administrativas, que se describe como estando
disponible en el menú de administración del interfaz utilizador. La Figura 5-9 783H
muestra a más profundidad el procedimiento:
Figura 5-9. Puntos de extensión y dependencias extendidas
Puntos de Extencion:
Funciones de
Administracion:
Menu de Administracion
Administrador del Sistema

Administrador de sistema
<<extend>> <<extend>>
[Opcion Apagar]
[Opcion Empezar]
Funciones Administrativas
Funciones Administrativas
Puntos de Extencion
Puntos de Extencion Antes: Antes de
Antes: Antes de Apagar
empezar Despues:Despues
Despues: Despues de Apagar
de Empezar Empezar Sistema Apagar Sistema
<<extend>> <<extend>>
[Opcion de Respaldo]
[Opcion Restaurar]
(Despues)
(Antes)
Restaurar Datos Respaldo de Datos
• El caso de lanzamiento de uso del sistema está disponible pues una opción
en el punto de la extensión de las funciones de la administración de caso de
uso del sistema del administrar. El caso de lanzamiento de uso del sistema
tiene dos puntos de la extensión nombrados antes y después. Antes de
que el punto de la extensión se describa como ocurriendo antes de que la
funcionalidad de lanzamiento sea realizada por el sistema, y después de
que el punto de la extensión se describa como ocurriendo después de que
la funcionalidad de lanzamiento sea realizada por el sistema. Se utilizan
estos puntos de la extensión como a continuación se dice:
o El caso de uso la restauración de datos está disponible pues una

opción en antes del punto de la extensión de caso de lanzamiento de
2008/06/18 120/195
uso del sistema. Antes de comenzar encima del sistema, el

administrador de sistema puede restaurar datos del sistema de
reserva a la base de datos del proyecto de sistema administrativo
que fue archivada previamente.
o No hay opciones descritas para después de que punto de la

extensión de caso de lanzamiento de uso del sistema.
• El caso de uso del sistema de parada está disponible pues una opción en el
punto de la extensión de las funciones de la administración de caso de uso
del sistema del administrar. El caso de uso del sistema de parada tiene dos
puntos de la extensión, nombrados antes y después. Antes de que el punto
de la extensión se describa como ocurriendo antes de que la funcionalidad
de la parada sea realizada por el sistema, y después de que el punto de la
extensión se describa como ocurriendo después de que la funcionalidad de
la parada sea realizada por el sistema. Se utilizan estos puntos de la
extensión como sigue:
o Los casos de uso de reserva de datos está disponible como una

opción que después del punto de la extensión de caso de uso del
sistema de parada. Después de cerrar abajo del sistema, el
administrador de sistema puede sostener datos de la base de datos
del proyecto de sistema administrativo al sistema de reserva para
una recuperación más última.
o No hay opciones descritas para antes de que punto de la extensión

de caso de uso del sistema de parada.
Los puntos de la extensión apenas descritos permiten que insertemos

comportamiento en los casos de lanzamiento de uso del sistema y del sistema de
parada antes o después de que realizan el arranque o la parada que procesa para
el proyecto de sistema administrativo. Las dependencias del extender se refieren
a estos puntos de la extensión para indicar donde casos de uso pueden ser el
interior insertado uno otro, y también para indicar las condiciones que se deben
satisfacer para que ocurra tal inserción. Naturalmente, se restauran los datos
antes de que el sistema se comience para arriba y se sostienen los datos después
de que se cierre el sistema.
Utilice una dependencia del extender cuando un caso de uso es opcional a otro
caso de uso. Porque el proyecto del mantener, mantiene actividad, y mantiene
casos de uso de la tarea extiende el caso de uso del proyecto del manejo, el caso
de uso del proyecto del manejo se debe desarrollar antes de los otros; si no, los
otros casos de uso no tendrán un caso de uso a extender. Asimismo, el caso de
uso del sistema del administrar se debe desarrollar antes de los casos de
lanzamiento de uso del sistema y del sistema de parada, el sistema de
lanzamiento se debe desarrollar antes de datos del restore, y el sistema de parada
2008/06/18 121/195
se debe desarrollar antes de datos de reserva. Sin embargo, administre una vez
el sistema se convierte, el sistema de lanzamiento y el sistema de parada se
pueden desarrollar en paralelo o concurrentemente, porque no se relacionan
directamente.
5.5 Generalizaciones
Los actores pueden ser similares en cómo utilizan un sistema; por ejemplo, los
administradores de proyecto, los administradores de recurso, y los
administradores de sistema pueden abrirse una sesión y fuera de nuestro proyecto
de sistema administrativo. Casos de uso pueden ser similares en la funcionalidad
proporcionada a los usuarios; por ejemplo, un administrador de proyecto puede
publicar el estado de un proyecto de dos maneras: generando un informe a una
impresora o generando un Web site en un Web Server del proyecto.
Dado que puede haber semejanzas entre los actores y casos de uso, ¿cómo
organizamos a los casos de uso que definen lo que debe hacer un sistema? ¿Y
cómo utilizamos la información sobre semejanzas entre los actores y utilizamos
casos para determinarnos cómo lo más mejor posible ejecutar un proyecto? Los
tipos especializados de generalizaciones, llamados actor y las generalizaciones de
caso de uso, tratan estas preguntas. Las generalizaciones se introducen y se
discuten en el capítulo 4. Las dos secciones siguientes discuten estos tipos
especializados de generalizaciones.
5.5.1 Generalizaciones de actores

La Figura 5-10 muestra que los administradores de proyecto, los administradores
784H
de recurso, y los administradores de sistema pueden abrirse una sesión y fuera

del proyecto de sistema administrativo. Así, el entrar y hacia fuera es común a
estos actores. Las generalizaciones del actor tratan tales situaciones
descomponiendo en factores hacia fuera y reutilizando semejanzas entre los
actores.
2008/06/18 122/195
Figura 5-10. Actores similares
Log In
Administrador Administrador Administrador

de Recursos de Proyecto de Sistema
Log out
Una generalización del actor de un más específico, o especializado, actor a un

más general, o generalizado, actor indica que los casos del actor más específico
se pueden sustituir para los casos del actor más general. Un actor puede
especializar a actores múltiples, y un actor puede ser especializado por los actores
múltiples. Una generalización del actor entre los actores se muestra como
trayectoria de línea llena del actor más específico al actor más general, con un
triángulo hueco grande en el extremo de la trayectoria conectada con el actor más
general.
La Figura 5-11 refina la Figura 5-10 usando generalizaciones del actor entre los
785H 786H
actores. Un recurso humano inicia casos de uso de la conexión y del registro de

estado de la máquina. Los administradores de proyecto, los administradores de
recurso, y los administradores de sistema son recursos humanos.
2008/06/18 123/195
Figura 5-11. Generalizaciones de actores
Administrador Log in
de Proyecto
Recursoso Humanos Administrador de Sistemas
Administrador
de Recursos
Log Out
Utilice una generalización del actor entre los actores cuando un actor es similar a
otro, pero tiene interacciones específicas en las cuales participe o inicie. Por
ejemplo, cualquier recurso humano puede abrirse una sesión y hacia fuera, pero
los administradores de proyecto, los administradores de recursos, y los
administradores de sistema hacen el uso especializado del proyecto de sistema
administrativo. Porque el administrador de proyecto, el administrador de recurso,
y los actores del administrador de sistema son actores especializados del recurso
humano, benefician de casos de uso en los cuales el actor del recurso humano
está implicado. Por lo tanto, desarrollando casos de uso de la conexión y del
registro de estado de la máquina, proporcionamos la funcionalidad descrita por
esos casos de uso para todos los actores de nuestro sistema.
5.5.2 Generalizaciones de Caso-uso

La Figura 5-12 muestra que un administrador de proyecto puede publicar el estado
78H
de un proyecto de dos maneras: imprimir un informe o generando un Web site en

un web server del proyecto. Así, publicar el estado de un proyecto y todo el
proceso implicado en recoger y elaborar los datos para la publicación es común a
estos casos de uso. Se puede utilizar una generalización de caso-uso para tratar
esta situación descomponiendo en factores hacia fuera y reutilizando
comportamiento similar de casos múltiples de uso.
2008/06/18 124/195
Figura 5-12. Casos de uso similares
Publicar el estado generando un

Impresora
reporte
Servidor del Web

del Proyecto
Publicar el estado generando un
sitio web
Una generalización de caso-uso de un caso más específico, o especializada, de

uso a un más general, o generalizado, caso de uso indica que el caso de uso más
específico recibe o hereda los actores, las secuencias del comportamiento, y los
puntos de la extensión de caso de uso más generales, y que las instancias de
caso más específico de uso se pueden sustituir para las instancias de caso de uso
más generales. El caso específico de uso puede incluir a otros actores, definir
nuevos secuencias del comportamiento y puntos de la extensión, y modificar o
especializar las secuencias del comportamiento que recibe o que hereda. Un caso
de uso puede especializar casos múltiples de uso, y un caso de uso se puede
especializar por los casos múltiples de uso. Una generalización de caso-uso entre
casos de uso se muestra como trayectoria de línea llena de caso más específico
de uso al caso de un uso más general, con un triángulo hueco grande en el
extremo de la trayectoria conectada con el caso de un uso más general.
La Figura 5-13 refina la Figura 5-12 usando la generalización de caso-uso entre

78H 789H
casos de uso. El informe de generación y generación de Website de casos de uso

recibe a un actor administrador de proyecto, secuencias del comportamiento, y los
puntos de la extensión del estado publicado.
2008/06/18 125/195
Figura 5-13. Generalizaciones de Caso-Uso
Generar Reporte
Impresora
Publicar Estado
Servidor del
Generar Sitio Web
proyecto web
Se puede utilizar una generalización de caso-uso entre casos de uso cuando un

caso más específico de uso es similar a un caso de un uso más general pero
implica a otros actores o ha especializado comportamiento. Por ejemplo, un
administrador de proyecto puede publicar el estado de un proyecto usando un
informe o un Web site, pero una impresora está implicada solamente si se genera
un informe, y un web server del proyecto está implicado solamente si se genera un
Web site. Porque el informe de la generación y genera casos de uso del Web site
especializa el caso de uso del estado del publicar, publica estado se debe
convertir antes de los otros casos de uso; si no, los otros casos de uso no tendrán
un caso de uso a especializarse.
Es importante entender que la diferencia entre incluir y ampliar las dependencias y

generalización de caso de uso. Un caso de uso de inclusión no tiene conocimiento
de la base de casos de uso que lo incluye, un caso de uso de extensión no tiene
conocimiento de la base de casos de uso que lo extiende, y la actividad de
mantenimiento de casos de uso en la Figura 5-8 no tiene ningún conocimiento de
790H
casos de uso que la extienden, así que no se pueden implicar a los actores de la
base de casos de uso en sus secuencias del comportamiento. Por ejemplo, la
actividad de registro de casos de uso en la Figura 5-6 no tiene ningún
791H
conocimiento de casos de uso que lo incluyen. Sin embargo, un caso más

específico de uso recibe o hereda los actores, las secuencias del comportamiento,
y los puntos de extensión de estos casos de uso más generales, así que puede
implicar a los actores de caso de uso más general en su secuencia del
comportamiento. Por ejemplo, el caso de uso del informe de la generación en la
Figura 5-13 tiene conocimiento de caso de uso de estado a publicar y puede
792H
implicar al actor del administrador de proyecto en su secuencia del
2008/06/18 126/195
comportamiento. Una inclusión de caso de uso debe ser desarrollada antes de

esta base de casos de uso, una extensión de casos de uso debe ser desarrollada
después de esta base de casos de uso, y un caso más específico de uso se debe
desarrollar después de sus casos de un uso más general.
6 Diagramas de Componentes y de Deployment

Este capitulo se centra en los diagramas de componentes y deployment, los
cuales representan la implementación y el entorno de un sistema,
respectivamente. Primero, se presentaran los diagramas de componentes y
deployment y como estos son usados. Después, se discutirá sobre componentes y
nodos, que son elementos representados en esos diagramas. Finalmente, se
discutirán varias relaciones entre componentes y nodos. Muchos detalles del
sistema de administración de proyectos que no fueron comentados en el Capitulo
2 serán detallados a continuación y a lo largo del capítulo, se incluirán sugerencias
relacionadas con los diagramas de componentes y deployment.
El modelado de componentes es un tipo especializado de modelado estructural

basado en la implementación de un sistema. Usando UML, se puede comunicar la
implementación de un sistema usando diagramas de componentes. Usualmente
uno aplica el modelado de componentes durante las actividades de diseño para
determinar de qué manera las actividades de implementación construirán el
sistema; esto es, para determinar los elementos del sistema sobre los cuales las
actividades de implementación se enfocarán. EL modelado de componentes
típicamente comienza después de que el diseño del sistema esta casi completo,
como lo determine el proceso de desarrollo del sistema.
El modelado de deployment es un tipo especializado del modelado estructural

basado en el entorno de implementación de un sistema. En contraste con el
modelado de componentes de un sistema, un modelo de deployment nos muestra
los recursos externos que aquellos componentes requieren. Normalmente se
aplica el modelado de deployment durante las actividades de diseño para
determinar las actividades de deployment que harán disponible el sistema a todos
sus usuarios, esto es, para determinar los elementos del sistema para las cuales
se centrara las actividades de deployment. Al igual que el modelado de
componentes, el modelado de deployment usualmente empieza después de que el
diseño del sistema esta casi terminado, determinado por el proceso de desarrollo
del sistema.
6.1 Componentes
Como se menciono en el Capitulo 3, un componente es una parte del sistema que
existe cuando este se esta ejecutando. Por ejemplo, el sistema de administración
de proyectos puede ser descompuesto en los siguientes componentes:
• Un componente de interfaz de usuario
2008/06/18 127/195
o Responsable de proveer una interfaz de usuario a través del cual los

usuarios pueden interactuar con el sistema
• Un componente de procesos de negocio

o Responsable de implementar funcionalidad de negocios, incluyendo
toda la funcionalidad de la administración del proyecto proporcionada
por el sistema de administración del proyecto
• Un componente de datos
o Para implementar funcionalidad del almacenamiento de los datos.
• Un componente de seguridad
o Provee varias formas de funciones de seguridad para los procesos
de negocio y componentes de los datos, incluyendo autentificación
de usuario y verificación de privilegios a la hora de acceder los
datos.
Un componente existe durante el tiempo de ejecución y requiere un recurso con el

cual ejecutarse, de lo que se hablara en la próxima sección, la Sección 6.2. En
UML, un componente es mostrado como un rectángulo con dos rectángulos más
pequeños que sobresalen de sus lados. El rectángulo esta etiquetado con el
nombre de la clase del componente.
La Figura 6-14 muestra varios componentes asociados con el sistema de

793H
administración de proyectos, incluida la interfaz de usuario, procesos de negocio,

datos, y componentes de seguridad.
Figura 6-14. Componentes del sistema de administración del proyecto
Interfaz de Procesos del

Usuario Negocio
Datos Seguridad
Una instancia del componente es un componente específico. Por ejemplo,

componentes específicos del sistema de administración de proyectos incluye:
• Una instancia del componente de interfaz de usuario Web

o Permite a los usuarios acceder al sistema de administración de
proyectos vía Web
2008/06/18 128/195
• Una instancia del componente de interfaz de usuario cliente/servidor

o Permite a los usuarios acceder al sistema de administración de
proyectos en un entorno cliente/servidor
• Una instancia de componente de datos locales

o Almacena datos de la administración del proyecto para un usuario o
grupo especifico
• Una instancia de componente de datos empresariales

o Almacena datos de la administración del proyecto para toda una
organización
Una instancia de componente se muestra parecida a una clase de componente,

pero esta etiquetada con el nombre de la instancia seguida de dos puntos y
seguida del nombre de la clase del componente, con todas las partes del nombre
subrayado. Ambos nombres son opcionales, y los dos puntos se ponen solo si el
nombre de la clase esta especificado
La Figura 6-15 muestra varias instancias de componentes de la clase de

794H
componentes de la Figura 6-14, incluyendo dos instancias de interfaz de usuario,

795H
llamados Web y ClienteServidor, dos instancias de datos, llamados DatosLocales

y DatosEmpresariales, una instancia de proceso del negocio sin nombre y una
instancia de seguridad también sin nombre.
Figura 6-15. Instancias de componentes en el sistema de administración del

proyecto
Web: Interfaz de : Procesos del

Usuario Negocio
ClienteServidor:
Interfaz de Usuario
DatosEmpresariales:
Datos
: Seguridad
DatosLocales : Datos
2008/06/18 129/195
6.2 Nodos
Un nodo es un recurso que esta disponible durante el tiempo de ejecución. (Los
nodos fueron mencionados en el Capitulo 3). Tradicionalmente, los nodos se
refieren a las computadoras en una red, pero en UML un nodo puede ser una
computadora, impresora, servidor, Internet u otro tipo de recurso disponible. Por
ejemplo, el sistema de administración de proyectos puede desplegar los siguientes
nodos:
• Una computadora personal

o En el cual el componente de interfaz de usuario se ejecuta
• Una impresora
o La cual usa el sistema de administración de proyectos para imprimir
reportes
• Un servidor de procesos del negocio

o En el cual el componente del proceso del negocio se ejecuta
• Un servidor de base de datos

o En el cual un componente de datos se ejecuta y donde la
información del proyecto es almacenada
Los nodos siguen la dicotomía (división de dos partes), tipo-instancia discutida

anteriormente en el Capitulo 2 y aplicada a las clases y objetos en el Capitulo 4.
Se puede usar UML para hablar acerca de clases y nodos, como también de
nodos y clases específicos. Entonces, mientras se piensa en un nodo como una
cosa especifica, en UML, un nodo en realidad representa a una clase de nodos.
Cuando se habla de componentes específicos de una clase, se usa el término
instancia del nodo.
Un nodo esta disponible durante el tiempo de ejecución y es un recurso en los

cuales se pueden ejecutar los componentes. En UML, un nodo es mostrado como
un rectángulo de tres dimensiones etiquetado con el nombre del nodo.
La Figura 6-16 muestra varios nodos asociados con el sistema de administración

796H
de proyectos incluyendo una computadora personal, un servidor de procesos del

negocio, un servidor de base de datos, y un nodo de impresión.
2008/06/18 130/195
Figura 6-16. Nodos usados por el sistema de administración de proyectos
Una instancia de nodo es un nodo específico. Por ejemplo, nodos específicos

usados por el sistema de administración de proyectos incluyen:
• Una instancia del nodo a una computadora personal

o Usado por Jonathan para acceder el sistema de administración de
proyectos
• Una instancia del nodo a una computadora personal

o Usado por Juan para acceder el sistema de administración de
proyectos
• Un grupo de instancias del nodo servidor de procesos del negocio

o Usado por un grupo de usuarios para administrar proyectos
• Una instancia del nodo servidor de procesos del negocio empresarial

o Usado por una organización completa para administrar proyectos
Una instancia de nodo es similar una clase de nodo pero esta etiquetada con el
nombre de la instancia seguido de dos puntos seguidos por el nombre de la clase
del nodo y completamente subrayadas. Ambos nombres son opcionales, y los dos
puntos se colocan solo si el nombre de la clase esta especificado.
La Figura 6-17 muestra varias instancias de nodos de las clases del nodo en la
79H
Figura 6-16, incluyendo dos instancias del nodo de una computadora personal,
798H
llamado ComputadoraDeJonathan y ComputadoraDeJuan, dos instancias del nodo

procesos del negocio, llamado ServidorDeGrupo y ServidorEmpresarial, una
instancia del nodo de una impresora, llamada ImpresoraDeGrupo, y una instancia
del nodo servidor de base de datos.
2008/06/18 131/195
Figura 6-17. Instancias de nodo
6.3 Dependencias
La Figura 6-14 muestra componentes asociados con el sistema de administración
79H
de proyectos, y la Figura 6-16 muestra los nodos asociados con el sistema de

80H
administración de proyectos, pero ¿Cómo están los componentes relacionados

con las clases diferenciadas y no diferenciadas, paquetes, subsistemas, y otros
componentes y nodos? Tipos especializados de dependencias – llamadas
dependencias residentes, de uso y de deploy – responden estas preguntas. Las
próximas secciones en este capitulo plantea estos tipos especializados de
dependencias. Las dependencias en general son discutidas en el Capitulo 3.
6.3.1 Dependencias Residentes

Una dependencia reside desde un componente hasta cualquier elemento de UML
indicando que el componente es un cliente del elemento, el cual es considerado
un proveedor, y que el elemento reside en el componente. El elemento puede ser
una clase diferenciada o no diferenciada, paquete, o subsistema. Un elemento
puede residir en cualquier número de componentes, y un componente puede tener
cualquier número de elementos que residen en él.
Una dependencia residente se muestra como una flecha punteada desde el cliente
hasta el elemento proveedor marcado con la palabra clave reside. La Figura 6-18
801H
muestra que la interfaz de usuario los paquetes de utilidades residen en el

componente de la interfaz de usuario. Por el hecho de que el paquete de Interfaz
de Usuario dependa del paquete de Utilidades, los paquetes Interfaz de Usuario y
Utilidades deben residir en el mismo componente, de otra forma, el paquete
Interfaz de Usuario no estaría habilitado para usar el paquete de Utilidades.
2008/06/18 132/195
Figura 6-18. Paquetes para las dependencias residentes
«reside»
«reside»
La Figura 6-19 muestra que el subsistema de Procesos del Negocio y el Paquete

802H
de Utilidades reside en el componente de ProcesosDelNegocio. El hecho de que

el subsistema Procesos del Negocio provea la interfaz de IProcesosDelNegocio, el
componente de Procesos del Negocio también provee la interfaz. De nuevo, el
hecho de que subsistema Procesos del Negocio depende del paquete de
Utilidades, el subsistema Procesos del Negocio y el paquete de Utilidades deben
residir en el mismo componente, de otra forma, el subsistema Procesos del
Negocio no podría estar habilitado para que el paquete de Utilidades lo use. Debe
recordarse que, es perfectamente correcto para un elemento residir en más de un
componente. Por ejemplo, el paquete de Utilidades reside en ambos componentes
la Interfaz de Usuario y Procesos del Negocio, y, como se vera pronto, en el
componente Datos.
Figura 6-19. Dependencias residentes para subsistemas
2008/06/18 133/195
Alternativamente, un elemento que reside dentro de un componente puede ser

mostrado desde cualquier componente. La Figura 6-20 muestra que el subsistema
803H
Datos y el paquete Utilidades residen dentro del componente Datos. El subsistema

Datos es dibujado dentro del componente Datos, mientras la dependencia
residente a Utilidades sigue dibujada en la misma manera como en las figuras
Figura 6-18 y Figura 6-19.
804H 805H
Figura 6-20. Dependencias residentes usando anidamientos
Datos
Note que el paquete de Utilidades reside en todos los componentes en las Figura 806H
6-18, Figura 6-19, y Figura 6-20, porque cada componente descrito en esas
807H 80H
figuras tiene un paquete que usa el paquete de Utilidades. Los detalles del
paquete de Utilidades son discutidos en el Capitulo 3.
6.3.2 Dependencias de Uso

Una dependencia de uso de un componente cliente hasta un componente
proveedor indica que el componente de cliente usa o depende del componente
proveedor. Una dependencia de uso desde un componente cliente hasta una
interfaz del componente proveedor indica que el componente cliente usa o
depende de la interfaz dada por el componente proveedor. Una dependencia de
uso es mostrada como una flecha punteada desde el componente cliente hasta la
interfaz del componente proveedor. La dependencia puede ser marcada con la
palabra clave usa, sin embargo, la palabra clave es rara vez omitida porque se
coloca por default, y el significado evidente de como la dependencia es usada.
La Figura 6-21 muestra como varios de los componentes del sistema de

809H
administración de proyectos están compuestos:
• El componente de una Interfaz de Usuario
2008/06/18 134/195
o Usa el componente de Seguridad y la interfaz IProcesosDelNegocio

dadas por el componente de Procesos del Negocio
• El componente de los Procesos del Negocio

o Usa el componente de Seguridad y las interfaces IProducible e
IConsumible dadas por el componente de Datos
• El componente de los Datos

o Usa el componente de Seguridad
Figura 6-21. Dependencias de uso
6.3.3 Dependencias de Despliegue

Una dependencia de deploy de un componente cliente hasta un nodo proveedor
indica que el componente del cliente hace un deployment en el nodo proveedor.
Una dependencia de deploy es mostrada como una flecha punteada desde el

componente cliente hasta un nodo proveedor marcada con la palabra clave
deploy. La Figura 6-22 muestra que la Interfaz de Usuario esta desplegada en el
810H
nodo de la computadora personal.
Figura 6-22. Dependencias de despliegue
«deploy»
Computadora
Interfaz de Usuario
Personal
2008/06/18 135/195
La Figura 6-23 muestra que el componente de Procesos del Negocio esta

81H
desplegado en el nodo servidor de Procesos del Negocio
Figura 6-23. Dependencias de deploy para un subsistema.
Alternativamente, un componente que hace un deployment en un nodo se puede

mostrar jerarquizado dentro del nodo. La Figura 6-24 muestra que el componente
812H
de los datos está desplegado en el nodo del servidor de la Base de Datos.
Figura 6-24. Dependencias de deploy usando jerarquías
IProducible
IConsumible
6.4 Asociaciones de Comunicación

La Figura 6-16 muestra los nodos asociados al sistema de administración de
813H
proyectos, pero ¿Cómo se relacionan esos nodos? Un tipo especializado de

asociación, llamado una asociación de comunicación, trata la cuestión de cómo los
nodos están relacionados. (Las asociaciones se discuten en el Capítulo 3.)
Una asociación de comunicación entre los nodos indica una trayectoria de

comunicación entre los nodos que permita que los componentes en los nodos se
comuniquen el uno con el otro. Una asociación de comunicación se muestra como
una línea llena entre los nodos. La Figura 6-25 muestra que el servidor Procesos
814H
del Negocio tiene una asociación de la comunicación con los nodos de una
Computadora Personal, Impresora, y del servidor de Base de Datos.
2008/06/18 136/195
Figura 6-25. Asociaciones de comunicación
La Figura 6-26 combina la Figura 6-21 y la Figura 6-25 para mostrar como los
815H 816H 817H
componentes están relacionados a los nodos. Note que si dos componentes están
relacionados y residen en nodos distintos, los nodos deben tener una asociación
de comunicación entre ellos para permitir la comunicación de los componentes, de
otra forma, los componentes no están habilitados para comunicar y estar
relacionado con otros. Por ejemplo, si la asociación de comunicación entre el nodo
de la Computadora Personal y los nodos del servidor Procesos del Negocio
fuesen removidos, el componente de Interfaz de Usuario podría no estar
relacionada con la interfaz IProcesosDelNegocio y el componente de Seguridad.
Si la asociación de comunicación entre los nodos del servidor Procesos del
Negocio y del servidor Base de Datos fuesen removidos, el componente Datos no
podría estar relacionado al componente de Seguridad, y el componente Procesos
del Negocio no podría estar relacionado con las interfaces IProducible e
IConsumible.
2008/06/18 137/195
Figura 6-26. Asociaciones de comunicación
2008/06/18 138/195
Parte III.- Modelando del Comportamiento

7 Diagramas de Secuencia y de Colaboración
Este capítulo se centra en los diagramas de secuencia y colaboración. Los
diagramas de secuencia describen el comportamiento dinámico de los elementos
que integran un sistema y como éstos interactúan en un tiempo determinado. Los
diagramas de colaboración describen el comportamiento de los elementos y como
éstos interactúan y se relacionan, en un tiempo y espacio determinados. Como un
proceso de arquitectura centrada se enfoca en la arquitectura de un sistema a
través de las iteraciones, es importante comprender como interactúan y colaboran
los elementos que integran el sistema, uno con el otro para proveer de
funcionalidad al sistema. Se puede usar esta información para determinar cual es
la mejor manera para desarrollar un sistema. Esto permite a los arquitectos,
diseñadores y desarrolladores asegurarse de que el sistema, cuando es
implementado, satisfaga los requerimientos.
Hay una cierta redundancia entre los diagramas de secuencia y de colaboración, y

es que ambos, muestran como los elementos interactúan en un tiempo
determinado. Sin embargo, el énfasis en cada diagrama es diferente. Los
diagramas de secuencia permiten enfocarse en mayor medida en la línea de
tiempo en el que los eventos ocurren, mientras que los diagramas de colaboración
hacen más fácil mostrar las relaciones entre los objetos.
Primero, se dará una introducción a los diagramas de secuencia y colaboración, y

como son utilizados. Posteriormente, se discutirán los roles que las clases, los
objetos, las asociaciones y los vínculos juegan en una interacción y una
colaboración. Más tarde, se abordarán las comunicaciones que éstos intercambian
cuando desempeñan dichos roles. Finalmente, se discutirá como se capturan las
interacciones y las colaboraciones. Muchos de los detalles que no fueron descritos
en el Capítulo 3 son desarrollados ampliamente a lo largo de este capítulo,
además se incluyen sugerencias relacionadas a los diagramas de secuencia y
colaboración.
El modelado de interacción es un tipo especial de modelado de comportamiento

en donde se muestra como los elementos interactúan en un tiempo determinado.
El modelado de colaboración es un tipo especial de modelado de comportamiento
en donde se muestra como los elementos se relacionan unos con otros y cómo
éstos interactúan en un tiempo determinado. Usando UML, se puede expresar
como los elementos interactúan en un tiempo determinado y como éstos se
relacionan usando diagramas de colaboración. Usualmente, se usa el modelado
de interacción y colaboración durante las actividades de análisis y diseño para
entender los requerimientos y determinar como el sistema podrá satisfacerlos. El
modelado de interacción y colaboración generalmente comienza después de que
los requerimientos hayan madurado lo suficiente, según lo determine el proceso
del desarrollo del sistema, y continúa en paralelo con el modelado de las clases y
objetos (Capítulo 4) a lo largo del proceso de desarrollo del sistema.
2008/06/18 139/195
7.1 Roles
Según lo discutido en el Capítulo 3, el paradigma orientado a objetos ve el mundo
como una colección única de elementos (objetos, clases, subsistemas, etc.),
frecuentemente se refiere a ellos como una sociedad de objetos, que se
comunican el uno con el otro. La comunicación de un elemento emisor a un
elemento receptor es utilizada para trasmitir información o para solicitar un
proceso. La palabra “objetos” es utilizada en la frase “sociedad de objetos”, en
lugar de “clases”, “subsistemas” o cualquier otra palabra, porque los objetos son
las partes más fundamentales o primitivas del paradigma orientado a objetos. Es
también común usar la frase “sociedad de elementos”.
Por ejemplo, la Figura 7-1, un diagrama de caso de uso, muestra como un

81H
administrador del proyecto solicita al sistema de administración de proyectos que

genere un reporte del estado del proyecto que es enviado a la impresora. El caso
de uso Generar el Reporte del Estado del Proyecto involucra a un actor
Administrador del Proyecto quién inicia la generación del reporte y un actor
Impresora a través del cual el reporte se imprime, como lo discutido en el Capítulo
5.
Figura 7-1. Generar el Reporte del Estado del Proyecto
Generar el Reporte del Estado del

Administrador del Proyecto Impresora
Proyecto
El caso de uso Generar el Reporte del Estado del Proyecto se describe a

continuación:
1. El administrador del proyecto ingresa el nombre del proyecto de

interés.
2. El sistema genera el reporte.
3. El sistema envía el reporte a la impresora.
4. La impresora imprime el reporte.
Note como todos los actores y el sistema están se ven envueltos en esta
descripción. La descripción indica que el sistema generará un reporte, pero no
menciona cómo.
2008/06/18 140/195
Para proveer de funcionalidad al reporte, una sociedad de objetos debe trabajar

junta en mucho más de la manera que lo hacen las clases en la Figura 7-2. La 819H
Figura 7-2 muestra que una organización puede ejecutar varios proyectos. Un
820H
objeto de la clase Organización puede contener cero o más objetos de la clase

Proyecto, y cada objeto de la clase Proyecto debe contener no más de un objeto
de la clase Organización, según lo discutido en el Capítulo 4. Además, estas
clases y otras pueden ser usadas para formar una sociedad de objetos que
trabajan en conjunto para proveer de funcionalidad al caso de uso Generar el
Reporte del Estado del Proyecto.
Figura 7-2. Organizaciones y proyectos
Organización Proyecto
1 Ejecutar *
Como las clases en la Figura 7-2 pueden interactuar y colaborar con otras clases
821H
para proveer de funcionalidad a la Figura 7-1, cada clase o asociación pueden

82H
jugar un rol dentro de esa interacción y colaboración. Un rol es un símbolo que

puede ser remplazado por un objeto o vínculo que juega un papel dentro de una
interacción y colaboración. Por ejemplo, los elementos participantes en el caso de
uso Generar el Reporte del Estado del Proyecto pueden desempeñar los
siguientes roles:
• Iniciador
o Interpretado por un administrador del proyecto; responsable de
iniciar el caso de uso.
• Dispositivo de Salida
o Interpretado por la impresora; responsable de imprimir el reporte
generado.
• La Organización del proyecto

o Interpretado por un objeto de la clase Organización; responsable de
contener el proyecto que es el tema del reporte.
• Una Referencia del proyecto

o Interpretado por un vínculo de la asociación Ejecutar; responsable de
referir al proyecto que es el tema del reporte.
• El Proyecto
o Interpretado por un objeto de la clase Proyecto, tema del reporte.
Para generar el reporte en una interacción y colaboración, se puede usar un objeto

de la clase Proyecto para acceder directamente a la información del proyecto, o se
2008/06/18 141/195
puede usar un vínculo de la asociación Ejecutar como un medio para acceder a un

objeto de la clase Proyecto. Debido a que se quiere demostrar como se usan las
clases y objetos, así como las asociaciones y vínculos en los diagramas de
interacción y colaboración, nos enfocaremos más en la clase Organización y en la
asociación Ejecutar que en las clases Organización y Proyecto.
En UML, el uso de una interacción y colaboración es representada por una elipse

de contorno entrecortado que contiene el nombre de la interacción y la
colaboración. La interacción y colaboración se pueden unir al caso de uso que las
realizan por medio de una relación, como la descrita en el Capítulo 4. Figura 7-3,
823H
un diagrama de caso de uso, muestra que la interacción y colaboración Generar el

Reporte del Estado del Proyecto lleva a acabo un caso de uso Generar el Reporte
del Estado del Proyecto. Es común usar el mismo tanto para el nombre de la
interacción y la colaboración como para el caso de uso que las lleva a acabo.
Figura 7-3. Interacción y colaboración realizan un caso de uso

Proyecto

Proyecto
La interacción y colaboración Generar el Reporte del Estado del Proyecto puede

tener la siguiente descripción utilizando los siguientes roles: un iniciador, un
dispositivo de salida, una organización del proyecto y una referencia al proyecto
que a continuación se describen:
1. El rol del iniciador ingresa el nombre del proyecto para que el reporte sea
generado y envía esta información al sistema.
2. La petición generar el reporte de estado del proyecto es recibido por un

elemento que lo trata y es el responsable de manejar la generación total del
reporte.
2008/06/18 142/195
3. El elemento responsable de generar el reporte, crea un elemento reporte

que es una abstracción del reporte generado. Esto es, el elemento reporte
representa dentro del sistema el reporte que es generado.
4. El elemento responsable de generar el reporte recupera la información de la

organización del rol organización del proyecto y del proyecto usando el rol
referencia, da formato a la información y envía ésta al elemento reporte.
5. Si el proyecto fue creado recientemente o está sin especificar y no tiene

información (esto es, aún no se definen a los trabajadores, unidades de
trabajo, ni productos de trabajo), el elemento responsable de generar el
reporte requiere que el elemento organización del proyecto indique lo
anterior al elemento reporte.
6. Si el proyecto no contiene información, el elemento generador del reporte

requiere que el elemento organización del proyecto continúe generando
información para el elemento reporte.
a. El rol organización del proyecto recupera los datos de los

trabajadores del proyecto y solicita al proyecto la salida de la
información para cada trabajador usando un rol referencia del
proyecto. El rol organización del proyecto no aplica ningún formato a
está salida.
b. Para cada trabajador, el rol organización del proyecto recupera las

unidades de trabajo y los productos de trabajo usando el rol de
referencia del proyecto, dando formato a esta información y
enviándola al elemento reporte. El rol organización del proyecto
realiza todo el formato a esta información.
7. El elemento generador del reporte imprime el elemento reporte.
8. El elemento generador del reporte destruye el elemento reporte. Esto es, el

destruye el elemento que dentro del sistema representa el reporte que es
generado.
9. El rol del dispositivo de salida imprime el reporte recibido del sistema.
Note como todos los roles y otros elementos se involucran en esta descripción. La
descripción elabora un caso de uso Generar el Reporte del Estado del Proyecto e
indica como el sistema genera el reporte:
• El paso 1 de la descripción del paso 1 es equivalente al paso 1 de la

descripción de la interacción y colaboración.
2008/06/18 143/195
• Los pasos 2 y 3 de la descripción del caso de uso se definen también en los

pasos del 2 al 8 en la descripción de la interacción y colaboración.
• El paso 4 de la descripción del caso de uso es equivalente al paso 9 en la

descripción de interacción y colaboración.
Los roles en la interacción y colaboración Generar el Reporte del Estado del

Proyecto pueden ser clasificados como roles de clases y asociaciones.
7.1.1 Clases y Objetos

El rol de una clase define un uso específico del objeto de la clase; se dice que los
objetos de la clase conforman un rol de la clase. Por ejemplo, un administrador del
proyecto interpreta el role de iniciador, una impresora interpreta el rol de un
dispositivo de salida y una organización juega el rol de la organización que
contiene el proyecto que es el tema del reporte del estado del proyecto.
Para mostrar que los objetos de una clase conforman un rol de la clase, una línea
punteada se dibuja desde el símbolo de la interacción y la colaboración hacia la
clase, etiquetada con el nombre del rol del objeto de la clase que juega dentro de
la interacción y la colaboración. Por ejemplo, Figura 7-4 un diagrama que usa los 824H
elementos de un caso de uso y un diagrama de clase, combina la Figura 7-1 a la 825H
Figura 7-3 para mostrar los roles de las clases iniciador, dispositivo de Salida y
826H
Organización del proyecto.
Figura 7-4. Interacción y colaboración usan clases
/ Iniciador: Administrador del Proyecto Generar el Reporte del Estado del / Dispositivo de salida : Impresora
Proyecto
iniciador Dispositivo de salida
Organización del proyecto

Proyecto
/ Organización del proyecto :
Organización
Además, la Figura 7-4 muestra dos métodos para identificar un rol. El primer
827H
método involucra etiquetar la línea punteada para indicar que los objetos de la
clase conforman un rol. También se muestra una clase usando la notación para
las clases definida en el Capítulo 4, pero con el nombre de la clase es precedida
2008/06/18 144/195
por una diagonal inversa seguida del nombre del rol separados por dos puntos por
ejemplo, / Organización del proyecto : Organización. La diagonal inversa indica
que el nombre es el nombre de un rol. Que va seguido de dos puntos y,
finalmente, el nombre de la clase, que en este caso es Organización. Usualmente,
se usa alguno de estos métodos.
Para mostrar que un objeto específico de una clase conforma el rol de la clase,
una línea punteada es dibujada desde el símbolo de interacción y colaboración
hacia el objeto, etiquetado con el rol del objeto específico de la clase que participa
dentro de la interacción y colaboración. Como con una clase, más que etiquetar la
línea punteada, se puede denotar a un objeto usando la notación definida en el
Capítulo 4, pero el nombre del objeto es seguido de una diagonal inversa y del
nombre del rol, posteriormente se escriben dos puntos seguidos del nombre de la
clase y todo lo anterior subrayado.
Por ejemplo, la Figura 7-5, un diagrama que usa los elementos de los diagramas
82H
de caso de uso y objeto, puesta que Juan interpreta el rol del iniciador, la
impresora de Juan interpreta el rol de dispositivo de salida y la organización de
Juan interpreta el rol de una organización que contiene el proyecto que es el tema
para el reporte.
Figura 7-5. Interacción y colaboración usan objetos
Juan / Iniciador: Generar el Reporte del Estado del Impresora de Juan / Dispositivo
Administrador del Proyecto Proyecto de salida : Impresora

Proyecto
Organización de Juan / Organización del proyecto :
Organización
7.1.2 Asociaciones y Vínculos

El rol de una asociación define un uso específico de un vínculo de una asociación.
Se dice que los vínculos de una asociación conforma el rol de la asociación. Por
ejemplo, una relación ejecutar juega el rol de una referencia a un proyecto que es
un tema de un reporte del estado del proyecto.
2008/06/18 145/195
Para mostrar que el vínculo de una asociación conforma un rol de la asociación,

una línea punteada es dibujada desde símbolo de la interacción y colaboración
hacia la asociación, etiquetada con el rol del vínculo de la asociación que participa
dentro de la interacción y colaboración. También, más que etiquetar la línea
punteada, se puede mostrar la asociación usando una notación similar a la
utilizada en la Figura 7-4: el nombre de la asociación es precedido de una diagonal
829H
inversa seguida del nombre del role y separados por dos puntos.
Por ejemplo, la Figura 7-6 actualiza la Figura 7-4 y muestra que la Referencia del
830H 831H
proyecto como un rol de asociación.
Figura 7-6. Interacción y colaboración usan asociaciones
/ Iniciador: Administrador Generar el Reporte del Estado del / Dispositivo de

del Proyecto Proyecto salida : Impresora

Proyecto
|
|
/ Organización del proyecto : | Proyecto
Organización
1 / Referencia del proyecto : Ejecutar *
Para mostrar que un vínculo específico de una asociación conforma un rol de la

asociación, una línea punteada es dibujada desde el símbolo de interacción y
colaboración hacia el vínculo, etiquetada con el vínculo específico de la asociación
que dentro de la interacción y colaboración. También, mas que etiquetar la línea
punteada, se puede mostrar el vínculo utilizando una notación similar a la de los
objetos en la Figura 7-5: el nombre de la asociación es precedida de una diagonal
832H
inversa seguida del rol separados por dos puntos. Recuerde del Capítulo 4, que un
vínculo puede tener el nombre de su asociación mostrada cerca de la trayectoria y
subrayada, pero el vínculo no tiene el nombre de la instancia.
Por ejemplo, la Figura 7-7 actualiza la Figura 7-5 y muestra el rol del vínculo
83H 834H
Referencia del proyecto.
2008/06/18 146/195
Figura 7-7. Interacción y colaboración usan vínculos
Juan / Iniciador: Impresora de Juan / Dispositivo

Administrador del Proyecto de salida : Impresora
Proyecto

Proyecto
|
| Referencia del proyecto
Organización de Juan / Organización del proyecto : Proyecto de Juan :
|
Organización Proyecto
1 / Referencia del proyecto : Ejecutar
*
7.2 Mensajes y estímulos

Según lo discutido en el Capítulo 3, la comunicación de un objeto emisor hacia un
objeto receptor por medio de un vínculo es llamado estímulo, y la comunicación de
una clase emisor hacia una clase receptor por medio de una asociación es
llamada mensaje. Un estímulo es una instancia de un mensaje, así como un objeto
es una instancia de una clase y un vínculo es una instancia de una asociación. Por
ejemplo, los objetos de la Figura 7-5 y Figura 7-7 intercambiarían estímulos y las
835H 836H
clases de la Figura 7-4 y Figura 7-6 intercambiarían mensajes. El objeto emisor (o

837H 83H
clase) es llamado cliente y el objeto receptor (o clase) es llamado proveedor.
Dentro de una interacción y colaboración, los mensajes son intercambiados entre

un rol de la clase emisor y un rol de la clase receptor por medio del rol de una
asociación, y los estímulos son intercambiados entre un objeto receptor que juega
el rol de la clase emisor y un objeto receptor que juega el rol de la clase receptor
por medio de un vínculo que juega el rol de una asociación. Por ejemplo, Figura 839H
7-4 y la Figura 7-6 muestran que los roles de las clases intercambian mensajes
840H
por medio de un rol de asociación, la Figura 7-5 y la Figura 7-7 muestra que los
841H 842H
objetos juegan los roles de las clases que intercambian estímulos por medio de
vínculos que juegan roles de asociación. Según lo discutido en el Capítulo 3, en el
paradigma orientado a objetos, la comunicación de un emisor a un receptor es se
usa para trasportar información o solicitar un proceso.
7.3 Interacciones y Colaboraciones

Formalmente, una colección de clases, sus mensajes y sus asociaciones es
llamada una colaboración. Una colección de determinados objetos que juegan
roles de clases, sus estímulos y sus vínculos específicos que juegan roles de
asociación, es llamada una instancia de colaboración. Una colección de mensajes
es llamada una interacción y colección de estímulos es llamada una instancia de
una interacción. Una interacción se dice que puede ocurrir dentro de un contesto
2008/06/18 147/195
de una colaboración porque una interacción es un subconjunto del contenido de

una colaboración; y una instancia de una interacción se dice que puede ocurrir
dentro de un contexto de una instancia de colaboración porque una instancia de
una interacción es un subconjunto del contenido de una instancia de colaboración.
Se puede representar una interacción usando alguna de las dos formas siguientes:
• Forma general de una interacción

o Muestra dos o más posibles secuencias para que los mensajes o
estímulos sean intercambiados usando la repetición y el condicionar.
Repetición
• Involucra repetir de una serie de mensajes o estímulos,
por ejemplo repetir el conjunto de mensajes o estímulos
en los pasos 6a y 6b en la descripción de la interacción
y colaboración que genera un reporte del estado del
proyecto.
Condicionar
• Involucra realizar la comunicación de una serie de
mensajes o estímulos en lugar de otros mensajes o
estímulos, por ejemplo condicionar la ejecución de los
pasos 5 o 6 en la descripción de la interacción y
colaboración que genera un reporte del estado del
proyecto.
• Forma instancia de la interacción

o Muestra una secuencia tangible del intercambio de los mensajes o
estímulos sin ninguna repetición o condición. Por ejemplo, generar
un determinado reporte del estado del proyecto que contiene
exactamente tres trabajadores, con dos unidades de trabajo un
producto de trabajo. Más que mostrar una repetición y condición
como una forma general de una interacción, la forma instancia de la
interacción muestra el conjunto actual de los mensajes o estímulos
que son repetidos y el conjunto de mensajes o estímulos que se
comunican para determinadas condiciones.
Se puede representar una colaboración usando uno de los dos niveles siguientes:
• Nivel de especificación de la colaboración

o Muestra los roles de clase, los roles de asociación y sus mensajes.
Por ejemplo, se pueden usar los roles de clase, los roles de
asociación y sus mensajes para expresarlos en forma general o en la
forma instancia de la interacción.
2008/06/18 148/195
• Nivel de la instancia de colaboración

o Muestra determinados objetos, vínculos y sus estímulos. Por
ejemplo, se puede usar los objetos, vínculos y sus estímulos para
expresarlos en forma general o en la forma instancia de la
interacción.
En UML, los diagramas de secuencia y colaboración, más que una descripción

textual, son usados para capturar los detalles de las interacciones, colaboraciones
y sus instancias. Las formas de interacción y los niveles de colaboración descritos
hacen a UML más expresivo.
7.4 Diagramas de Secuencia

Un diagrama de secuencia muestra como los elementos interactúan en un tiempo
determinado, mostrando una interacción o una instancia de la interacción. Los
diagramas de secuencia se organizan a lo largo de dos ejes: el eje horizontal
donde se muestran los elementos involucrados en la interacción y un eje vertical
que representa el tiempo y se extiende hacia abajo de la pagina. Los elementos en
el eje horizontal pueden aparecer en cualquier orden.
7.4.1 Elementos
Los diagramas de secuencia están constituidos por un numero de elementos,
incluyendo los roles de las clases, los objetos, las líneas de vida y las
activaciones. Todos ellos se describen a continuación en los apartados siguientes.
7.4.1.1 Roles de clase

En un diagrama de secuencia, el rol de una clase es representado usando la
notación para la clase descrita en el Capítulo 4, pero el nombre de la clase es
precedido por una diagonal inversa seguida del nombre del rol de los objetos que
deben conformarse para participar dentro del rol, separados por dos puntos. Otras
clases también se pueden mostrar si es necesario, usando la notación de para las
clases descrita in el Capítulo 4.
Los roles de clase y otras clases son usadas para expresar el nivel de
especificación de la colaboración usando diagramas de secuencia. La Figura 7-8 843H
muestra el rol de la clase Organización del proyecto así como también las clases
Proyecto e Reporte.
Figura 7-8. Un rol de clase y dos clases
/ Organización del proyecto : Proyecto Reporte
Organización
2008/06/18 149/195
7.4.1.2 Objetos Específicos

En un diagrama de secuencia, un objeto específico de una clase conforma el rol
de la clase que es representado usando la notación para objetos descrita en el
Capítulo 4, pero el nombre del objeto es seguido de una diagonal inversa seguida
del nombre del rol, separado por dos puntos y enseguida el nombre de la clase, y
subrayado. Otros objetos también se pueden mostrar si es necesario usando la
notación para objetos, descrita en el Capítulo 4.
Los objetos específicos que conforman los roles de clase y otras objetos son
usados para expresar un nivel de instancia de colaboración usando diagramas de
secuencia. La Figura 7-9 muestra que la organización de Juan interpreta el rol de
84H
una organización que contiene el proyecto que es el tema del reporte. La Figura 845H
7-9 también muestra los objetos Proyecto e Reporte anónimos.
Figura 7-9. Un objeto conforma el rol de una clase

Organización de Juan / Organización : Proyecto : Reporte
del proyecto : Organización
7.4.1.3 Líneas de Vida

Una línea de vida, representada por una línea vertical punteada de un elemento,
representa la existencia del elemento en un tiempo determinado. La Figura 7-10 846H
muestra las líneas de vida para los roles de clase (Organización del proyecto) y las
clases (Proyecto e Reporte) en la Figura 7-8. Las líneas de vida también se
847H
pueden mostrar para los objetos de Figura 7-9. 84H
Figura 7-10. Líneas de Vida

Organización
7.4.1.4 Activaciones
Una activación opcional, representada por un rectángulo delgado y alargado sobre
la línea de vida, representa el periodo en el que un elemento ejecuta una
operación. El borde superior se alinea con el tiempo de inicialización y el borde
superior con el tiempo de culminación. La Figura 7-11 muestra las activaciones
849H
2008/06/18 150/195
para los roles de clase de la Figura 7-8, donde todos los elementos están
850H
ejecutando operaciones de manera simultanea. Las activaciones también se

pueden mostrar para los objetos de la Figura 7-9. 851H
Figura 7-11. Activaciones

Organización
7.4.2 Comunicación
En un diagrama de secuencia, una comunicación, mensaje o estímulo es
representada por una flecha que va desde la línea de vida o activación de un
emisor a la línea de vida o activación de un receptor. En UML, la comunicación se
describe usando la siguiente sintaxis:
[guardián] * [ iteración] número_de_secuencia :

variable_devuelta : = nombre_de_la_operación
(lista_de_argumentos)
En donde:
guardián
• Es opcional e indica una condición que se debe satisfacer para la
comunicación sea enviada u ocurra. Se también se omiten los
corchetes cuando no se específica un guardián.
iteración
• Es opcional e indica el número de veces que la comunicación ocurre
o es enviada. También se omiten el asterisco y los corchetes cuando
no se específica una iteración.
número_de_secuencias
• Es un número entero opcional, que indica el orden de la
comunicación. También se omiten los dos puntos cuando no se
específica un número de secuencia. Debido a que el eje vertical
2008/06/18 151/195
representa el tiempo y se extiende hacia abajo de la pagina en un

diagrama de secuencia, el número de secuencia es opcional.
variable_devuelta
• Es opcional e indica el nombre del valor regresado por la operación.
Si se elije no mostrar la variable de retorno, o la operación no
regresa ningún valor, también se deben omitir los dos puntos y el
signo de igual.
nombre_de_la_operación
• Es el nombre de la operación que será invocada.
lista_de_argumentos
• Es opcional y es una lista separada por comas que indica los
argumentos pasados a la operación. Cada parámetro puede ser
explícitamente un valor o una variable devuelta de una comunicación
previa. Si una comunicación no requiere de argumentos, los
paréntesis van vacíos.
La Figura 7-12 muestra la comunicación que ocurre entre el encargado de

852H
Generar el Reporte del Estado del Proyecto, que es una clase (quien es
responsable de manejar la generación total del reporte del estado del proyecto) y
el rol de clase Organización del proyecto.
Figura 7-12. Diagrama de Secuencia Comunicaciones
GenerarProyecto-Manejador / Organización del proyecto :

DelEstadoDelReporte Organización
[Si el proyecto está Activo] *[Para cada Trabajador]

6:1: DatoDeSalida : = DarFormatoInfoTrabajador
(UnidadesDeTrabajo,ProductosDeTrabajo )
Echemos una mirada a como se realiza la notación para la comunicación en la

Figura 7-12. Para comenzar, la comunicación invoca una operación
853H
DarFormatoInfoTrabajador que da formato a la información de un trabajador:
DarFormatoInfoTrabajador
2008/06/18 152/195
Esta operación requiere de las unidades de trabajo y los productos de trabajo, así
que actualizaremos la comunicación como sigue:
DarFormatoInfoTrabajador (UnidadesdeTrabajo, ProductosdeTrabajo)
La operación también regresa un dato de salida que es una cadena de texto

formateado, así que actualizaremos la comunicación para reflejar esto:
DatoDeSalida : = DarFormatoInfoTrabajador (UnidadesDeTrabajo,

ProductosDeTrabajo)
En la descripción anterior de esta interacción y colaboración, esta operación

ocurre en la sexta comunicación dentro de toda la secuencia de comunicaciones:
6: DatoDeSalida : = DarFormatoInfoTrabajador (UnidadesDeTrabajo,

ProductosDeTrabajo)
Un proyecto puede involucrar a más de un empleado, así que la operación debe

ocurrir para cada trabajador se indica esto usando la notación para la repetición:
* [Para cada Trabajador] 6 : DatoDeSalida : =

DarFormatoInfoTrabajador (UnidadesDeTrabajo, ProductosDeTrabajo)
Finalmente, esta operación ocurre solo si el proyecto esta activo y se indica esto
con una notación de una condición guardián:
[Si el proyecto esta Activo] * [Para cada Trabajador] 6 :

DatoDeSalida : = DarFormatoInfoTrabajador (UnidadesDeTrabajo,
ProductosDeTrabajo)
UML también permite mostrar la comunicación usando pseudocódigo u otro

lenguaje. Por ejemplo, se puede usar la sintaxis de Java, C++, C#, o algún otro
lenguaje de programación. Una comunicación también puede ser descrita en el
margen izquierdo del diagrama de secuencia.
7.4.2.1 Comunicación Reflexiva

Similar a la asociación reflexiva o de vínculos, descrita en el Capítulo 4, un
elemento puede comunicarse consigo mismo cuando la comunicación es enviada
del elemento a él mismo. En UML, una comunicación reflexiva es representada
por una fecha horizontal desde la línea de vida o activación de un elemento que
gira hacia la misma línea de vida o activación del mismo elemento.
La Figura 7-13 muestra una comunicación reflexiva para el paso 6 de la

854H
descripción para la interacción y colaboración Generar el Reporte del Estado del

Proyecto donde el encargado de generar el reporte del estado del proyecto, que
es una clase, da formato a la información de la organización y el proyecto.
2008/06/18 153/195
Figura 7-13. Diagrama de Secuencia comunicaciones reflexivas
GenerarProyecto-Manejador
DelEstadoDelReporte
1: DatoDeSalida : = DarFormato (InfoOrg,InfoProy)
7.4.2.2 Crear y destruir un elemento

Cuando un elemento es creado durante una interacción, la comunicación que crea
el elemento es representada con una flecha dirigida hacia el elemento. Cuando un
elemento es destruido durante una interacción, la comunicación que destruye el
elemento es representada por una fecha dirigida a la línea de vida del elemento
donde la destrucción es representada por una “X”.
La Figura 7-14 muestra una comunicación para el paso 3 de la descripción para la

85H
interacción y colaboración Generar el Reporte del Estado del Proyecto en donde el

encargado de generar el reporte, que es una clase, genera el reporte. Esta figura
también muestra la comunicación para el paso 8 para la descripción antes
mencionada en donde la clase encargada de generar el reporte destruye el
reporte.
2008/06/18 154/195
Figura 7-14. Diagrama de Secuencia Crear y Destruir Comunicaciones
DelEstadoDelReporte
1: Crear() Reporte
2: Destruir()
7.4.3 Repetición
En un diagrama de secuencia, una repetición (que involucra repetir una serie de
mensajes o estímulos) en la forma general de una interacción es mostrada como
una serie de comunicaciones encerradas en un rectángulo.
Una iteración puede estar en la parte superior o inferior dentro del rectángulo
indicando el número de veces que las comunicaciones dentro del rectángulo
deben ocurrir. La Figura 7-15 muestra el paso 6b de la descripción para la
856H
interacción y colaboración Generar el Reporte del Estado del Proyecto usando una
iteración en la que el la clase encargada de generar el reporte, recupera la
información de la unidades de trabajo y los productos de trabajo, da formato a esta
información y la información formateada es enviada al elemento reporte. Note el
uso de *[Para cada trabajador] en la parte superior izquierda, que indica que la
comunicación ocurrirá por cada trabajador involucrado dentro del proyecto.
2008/06/18 155/195
Figura 7-15. Diagrama de Secuencia Repetir usando una iteración en la forma

general de una interacción.
/ Organización del proyecto : Projecto Reporte

Organización
*[Para cada Trabajador]

1: UnidadesDeTrabajo : =
ObtenerUnidadesDeTrabajo()
2: ProductosDeTrabajo : =
ObtenerProductosDeTrabajo()
3: DatoDeSalida : = DarFormatoInfoTrabajador (UnidadesDeTrabajo,ProductosDeTrabajo)

4: Salida(DatoDeSalida)
De forma alternativa, una condición guardián estar dentro de la parte inferior o

superior dentro del rectángulo indicando la condición que se debe satisfacer para
poder dar por terminada la repetición. La Figura 7-16 muestra la Figura 7-15
857H 85H
usando una condición guardián para expresar la misma iteración que en la Figura 859H
7-15. Más que especificar una repetición de una serie de comunicaciones para
cada trabajador, la condición guardián específica que las comunicaciones serán
repetidas mientras no haya más trabajadores para procesar.
Figura 7-16. Diagrama de Secuencia que usa una condición guardián en la forma
general de una interacción.

Organización
2: ProductoDeTrabajo : =
3: DatoDeSalida : = DarFormatoInfoTrabajador (UnidadesDeTrabajo,ProductosDeTrabajo )
[No hay más trabajadores]
2008/06/18 156/195
La repetición en la forma instancia de la interacción involucra el mostrar los

estímulos y mensajes actuales que serán repetidos. La Figura 7-17 muestra el
860H
paso 6b de la descripción para la interacción y colaboración Generar el Reporte

del Estado del Proyecto (Figura 7-15 y Figura 7-16) para un proyecto que contiene
861H 862H
exactamente tres trabajadores, cada uno con dos unidades de trabajo y un

producto de trabajo. Note que también se ha descrito la interacción en el margen
izquierdo para hacer el diagrama más legible.
2008/06/18 157/195
Figura 7-17. Diagrama de Secuencia Repetición en la forma instancia de la

interacción
/ Organización del proyecto : Project Report

Organización
Manejador Primer
Trabajador 2: UnidadesDeTrabajo : =
Manejador Segundo
Trabajador 7: UnidadesDeTrabajo : =
Manejador Tercer 12: UnidadesDeTrabajo : =
Trabajador ObtenerUnidadesDeTrabajo()
14: DatoDeSalida : = DarFormatoInfoTrabajador(UnidadesDeTrabajo,ProductosDeTrabajo)
2008/06/18 158/195
7.4.4 Condicionamientos
En un diagrama de secuencia, el condicionar (involucra repetir de una serie de
mensajes o estímulos en lugar de otra serie de mensajes o estímulos) en una
forma general de una interacción es representada como varias comunicaciones
desde la línea de vida o activación que tienen mutuamente expresiones guardián.
Una línea de vida se puede partir también en dos o más líneas de vida para
mostrar como un elemento puede manejar comunicaciones entrantes múltiples, y
las líneas de vida se combinarían nuevamente.
La Figura 7-18 muestra los pasos 5 y 6 de la descripción para la interacción y

863H
colaboración Generar el Reporte del Estado del Proyecto en donde la clase

encargada de generar el reporte requiere que el rol de clase Organización del
proyecto indique si es un proyecto vacío, recientemente creado o está sin
especificar, y la clase encargada de generar el reporte requiere que el rol de clase
del Organización del proyecto continúe generando información para el elemento
reporte si el proyecto no fue recientemente creado o está sin especificar. En esta
figura, solo se muestra la primera comunicación que realmente genera el reporte
actual. Si no hay más comunicaciones para generar el reporte actual, la
comunicación Generar Reporte puede ir de la misma línea de vida como una
comunicación de Proyecto Vacío. Se usan diferentes líneas de vida en la figura
porque cada línea de vida representa un diferente camino a ejecutar.
Figura 7-18. Diagrama de Secuencia Condicionar en la forma general de una

interacción
GenerarProyecto-Manejador / Organización del proyecto : Proyecto

1: [Proyecto no Especificado] SalidaProyectoVacío( )
2: [Proyecto Especificado] GenerarReporte( )
3: Trabajadores : = ObtenerTrabajadores( )
El condicionar en la forma instancia de la interacción involucra una serie de

mensajes o estímulos que serán comunicados a una condición específica. La
Figura 7-19 muestra la Figura 7-18 con un proyecto especificado.
864H 865H
2008/06/18 159/195

interacción
GenerarProyecto-Manejador / Organización del proyecto : Proyecto

1: GenerarReporte( )
2: Trabajadores : = ObtenerTrabajadores( )
7.5 Diagramas de Colaboración

Un diagrama de colaboración muestra como los elementos que interactúan en un
tiempo determinado y como éstos se relacionan. Esto es, muestra una
colaboración o una instancia de colaboración. Mientras los diagramas de
secuencia están orientados al tiempo y enfatiza todo el flujo de una interacción, los
diagramas de colaboración están orientados al tiempo y al espacio, enfatiza la
interacción de los elementos involucrados y sus relaciones. Los diagramas de
secuencia son más útiles para interacciones complejas, porque se pueden leer de
arriba hacia abajo. Los diagramas de colaboración son más útiles para observar el
impacto de una interacción en varios elementos, porque se puede colocar un
elemento en el diagrama e inmediatamente ver todos los demás elementos con los
que interactúan.
7.5.1 Elementos
Los diagramas de colaboración están integrados de un número de elementos,
incluyendo los roles de clase, los objetos específicos, los roles de asociación y los
vínculos específicos. Todos estos elementos se describen en los siguientes
apartados.
7.5.1.1 Roles de clase y asociación

En un diagrama de colaboración, los roles de clase y otras clases son
representadas usando la misma notación que en los diagramas de secuencia. Un
rol de asociación es representado usando la notación para las asociaciones como
se describió en el Capítulo 4, pero el nombre de la asociación es precedido de un
diagonal inversa seguida del nombre del rol separado por dos puntos para indicar
que la vínculo conforma el rol en el que participa. Otras asociaciones se pueden
mostrar si es necesario usando la notación para las asociaciones descrita en el
Capítulo 4
2008/06/18 160/195
Los roles de clase y asociación, otras clases y otras asociaciones son usadas en
el nivel de especificación de las colaboraciones expresadas utilizando diagramas
de colaboración. La Figura 7-20 muestra el rol de clase de la Figura 7-8 con un rol
86H 867H
de asociación Referencia del proyecto, las clases Reporte y Sección, y la

asociación Tiene.
Figura 7-20. Roles de Asociación
/ Organización del proyecto : Proyecto

Organización
1 /Referencia del proyecto : Ejecutar *
Reporte Sección
* Tiene *
7.5.1.2 Objetos específicos y vínculos

En un diagrama de colaboración, los objetos específicos que conforman los roles
de clase y otras objetos son representados usando la misma notación que en los
diagramas de secuencia. Un vínculo específico de una asociación que conforma
un rol de asociación es representado usando la notación descrita en el Capítulo 4,
pero el nombre de la asociación es precedido de la diagonal inversa seguida del
nombre del rol separado por dos puntos de el nombre de la asociación y además
todo subrayado. Recuerde del Capítulo 4 que un vínculo puede tener el nombre de
su asociación representado cerca de la línea y todo subrayado, pero recuerde que
los vínculos no tienen nombres de instancia. Otros vínculos se pueden también
representar si es necesario usando la notación para vínculos descrita en el
Capítulo 4.
Los objetos específicos conforman los roles de clase, los vínculos específicos
conforman los roles de asociación, y los vínculos específicos son usados en el
nivel de la instancia de colaboración expresado usando diagramas de
colaboración. La Figura 7-21 muestra los objetos de la Figura 7-9 con un vínculo
86H 869H
Referencia del proyecto, un objeto Reporte anónimo conformado por los objetos
Introducción, Cuerpo, y Conclusión, y sus tres vínculos Tiene.
2008/06/18 161/195
Figura 7-21. Vínculos que conforman roles de asociación
Organización de Juan / Organización : Proyect

del proyecto : Organización
/Referencia del proyecto : Ejecutar
Introducción : Sección Cuerpo : Sección
Tiene
Conclusión : Sección
: Reporte
Tiene
Tiene
7.5.2 Comunicación
En un diagrama de colaboración, una comunicación, un mensaje o un estímulo es
representada con una fecha para una relación desde un emisor hacia un receptor.
Una comunicación es etiquetada usando la misma notación que en los diagramas
de secuencia, pero el número de secuencia es requerido y expresado usando un
esquema numerado especial conocido como notación dot o de punto decimal, que
se usa entre los diferentes niveles de comunicación. Por ejemplo, entre el
elemento A y el B, la comunicación 1 es seguida de la comunicación 2; entre el
elemento B y C, la comunicación 1,1 es seguida de la 1.2; y toda la secuencia de
comunicación es 1, 1.1, 1.2 y 2.
La Figura 7-22 es similar a la Figura 7-12, pero usando un diagrama de

870H 871H
colaboración para mostrar la comunicación que ocurre entre la clase encargada de

generar el reporte del estado del proyecto (que es la responsable de manejar toda
la generación del reporte) y de el rol de clase Organización del proyecto.
Figura 7-22. Diagrama de Colaboración Comunicaciones

[Si el proyecto está Activo] *[Para cada Trabajador]
1: DatoDeSalida : = DarFormatoInfoTrabajador
(UnidadesDeTrabajo,ProductosDeTrabajo)
GenerarProyecto-Manejador / Organización del proyecto :
7.5.2.1 Comunicación Reflexiva

La Figura 7-23, similar a la Figura 7-13 pero usando un diagrama de colaboración
872H 873H
para mostrar la comunicación reflexiva del paso 6 de la descripción para la

interacción y colaboración Generar el Reporte del Estado del Proyecto, en el que
2008/06/18 162/195
una clase encargada de generar el reporte da formato a la información de la

organización y el proyecto. Note como una comunicación reflexiva es
representada usando una relación reflexiva.
Figura 7-23. Diagrama de Colaboración Comunicación Reflexiva

DelEstadoDelReporte
1: DatoDeSalida : = DarFormato (InfoOrg,InfoProy)
7.5.2.2 Crear y destruir elementos

La Figura 7-24, similar a la Figura 7-14 pero usando un diagrama de colaboración,
874H 875H
muestra la comunicación del paso 3 de la descripción para la interacción y

colaboración Generar el Reporte del Estado del Proyecto en el que una clase
encargada de generar el reporte destruye el reporte. Note que una comunicación
que crea un elemento y una comunicación que lo destruye son representados
simplemente como otra comunicación.
Figura 7-24. Diagrama de Colaboración Crear y destruir comunicaciones

1: Crear( )
GenerarProyecto-Manejador Reporte
DelEstadoDelReporte
2: Destruir( )
7.5.3 Repetición
En un diagrama de colaboración, una repetición (que involucra repetir una serie de
mensajes o estímulos) en la forma general de una interacción es representada
como una propiedad. Las propiedades se discutieron en el Capítulo 3.
Una iteración indica el numero de veces que las comunicaciones se deben realizar
y deben ir encerradas entre llaves ({}) y unir las comunicaciones usando líneas
punteadas. La Figura 7-25, similar a la Figura 7-15 pero usando un diagrama de
876H 87H
colaboración, muestra los pasos 6b de la descripción para la interacción y

colaboración Generar el Reporte del Estado del Proyecto. La figura usa una
iteración que hace que la clase encargada de generar el reporte capture las
unidades de trabajo y la lista de los productos de trabajo, da formato a esta
información y envía ésta al elemento reporte.
2008/06/18 163/195
Figura 7-25. Diagrama de Colaboración Repetición usando una iteración en una

forma general de una interacción.
1: UnidadesDeTrabajo : = ObtenerUnidadesDeTrabajo()
2: ProductoDeTrabajo : = ObtenerProductosDeTrabajo() Proyecto
/ Organización del proyecto : 3: DatoDeSalida : = DarFormatoInfoTrabajador

Organización (UnidadesDeTrabajo,ProductosDeTrabajo)
Reporte
{*[Para cada Trabajador]}
De forma alternativa, una condición guardián indica la condición que se debe

satisfacer para terminar la repetición que debe ir encerrada entre llaves ({}) y unir
las comunicaciones usando líneas punteadas. La Figura 7-26, similar a la Figura 87H 879H
7-16 pero usando un diagrama de colaboración, usa una condición guardián para
mostrar la misma información que la Figura 7-25. 80H
Figura 7-26. Diagrama de Colaboración Repetición usando una condición guardián

en la forma general para una interacción
2: ProductoDeTrabajo : = ObtenerProductosDeTrabajo() Proyecto

Reporte
{[No hay más trabajadores]}
La repetición en la forma instancia de la interacción involucra el mostrar una serie

de comunicaciones o estímulos actuales que serán repetidos. Figura 7-27, similar 81H
2008/06/18 164/195
a la Figura 7-17 pero usando un diagrama de colaboración, muestra la misma

82H
información que la Figura 7-25 y la Figura 7-26 para un proyecto que contiene
83H 84H
exactamente tres trabajadores, cada uno con dos unidades de trabajo y un

producto de trabajo.
Note que la Figura 7-27 puede ser de mas difícil lectura que la Figura 7-17. Para
85H 86H
interacciones más complejas, los diagramas de secuencia son a menudo

preferibles que los diagramas de colaboración, porque los diagramas de secuencia
se leen de arriba hacia abajo. Los diagramas de colaboración son a menudo
preferibles que los diagramas de secuencia cuando se desea mostrar las
relaciones que permiten la comunicación de los elementos.
Figura 7-27. Diagrama de Colaboración Repetición en la forma instancia de la

interacción.
3: ProductoDeTrabajo : = ObtenerProductosDeTrabajo()
Reporte

15: Salida(DatoDeSalida) Proyecto
7.5.4 Condicionar
En un diagrama de colaboración, condicionar – que in Involucra realizar la
comunicación de una serie de mensajes o estímulos en lugar de otros mensajes o
estímulos- en la forma general de una interacción es representada usando la
notación de punto decimal en donde la comunicación de un nivel específico indica
que la condición guardián se debe satisfacer para que el siguiente nivel de
comunicación ocurra. Por ejemplo, entre los elementos A y B, la comunicación 1
puede contener una condición y estar seguida de la comunicación 2. La
comunicación 1 de A hacia B puede disparar las comunicaciones 1.1 y 1.2 entre B
2008/06/18 165/195
y C. Debido a que la condición guardián puede en la comunicación 1, los dos

escenarios siguientes son posibles:
La condición guardián se satisface

• La comunicación 1 ocurre entre A y B, dispara las comunicaciones
1.1 y 1.2 entre B y C. La secuencia total de comunicaciones es 1,
1.1, 1.2 y 2. La comunicación 2 se realiza al último debido a que
cada comunicación asociada a la comunicación 1 debe antecederla.
La condición guardián no se satisface

• La comunicación 1 no ocurre y tampoco se realizan las
comunicaciones 1.1 y 1.2. Sin embargo la comunicación 2 si ocurre,
debido a que no está protegida con la misma condición guardián
como la comunicación 1.
La Figura 7-28, similar a la Figura 7-18 pero usando un diagrama de colaboración,

87H 8H
muestra la descripción para la interacción y colaboración Generar el Reporte del

Estado del Proyecto, donde la clase encargada de generar el reporte requiere que
el rol de clase Organización del proyecto si el proyecto está vacío, ha sido creado
recientemente o está sin especificar; y la clase encargada de generar el reporte
requiere que el rol de clase Organización del proyecto continúe generando
información para el elemento reporte si el proyecto no ha sido creado
recientemente o es un proyecto especificado. En esta figura, solo se muestra la
primera comunicación para generar el reporte actual.
Figura 7-28. Diagrama de Colaboración Condicionar en la forma general de una

interacción
1: [Proyecto no Especificado] SalidaProyectoVacío( )

2: [Proyecto Especificado] GenerarReporte( ) / Organización del proyecto :
Organización
DelEstadoDelReporte
Proyecto
3: Trabajadores : = ObtenerTrabajador( )
El condicionar en la forma instancia de la interacción involucra que una serie de

mensajes o estímulos están comunicados por una condición específica. La Figura 89H
2008/06/18 166/195
7-29 similar a la Figura 7-19 pero usando un diagrama de colaboración, muestra

890H
Figura 7-28 con un proyecto especificado.

891H

interacción
1: GenerarReporte( )
/ Organización del proyecto :
Organización
DelEstadoDelReporte
Proyecto
2: Trabajadores := ObtenerTrabajadores( )
8 Diagramas de Estado
Este capítulo se enfoca en los diagramas de estado, también conocidos como
diagramas de transición de estado, los cuales representan el ciclo de vida de los
elementos que conforman un sistema. Primero se hará una introducción a los
diagramas de estado y como son usados. Después se pasará a los estados y sus
detalles. Finalmente se discutirá sobre las transiciones entre los estados y sus
detalles. Muchos detalles de los diagramas de estado que no fueron profundizados
en el capítulo 3 son completamente cubiertos aquí y a través de éste capítulo, se
incluyen sugerencias relacionadas con los diagramas de estado.
El modelado de estados es un tipo especializado de modelado de comportamiento

concerniente con el modelado del ciclo de vida de un elemento. Usualmente se
aplica el modelado de estados en conjunción con el modelado de interacción y
colaboración (capítulo 7) para explorar el ciclo de vida de la interacción y
colaboración de los elementos.
8.1 Estados
Como se discutió en el capítulo 3, como los elementos se comunican unos con
otros dentro de una sociedad de objetos, cada elemento tiene un ciclo de vida en
el cual éste es creado, sabe algo, puede hacer algo, se puede comunicar con
otros elementos para pedir procesamiento de esos otros elementos, pueden otros
elementos tener comunicación con éste para pedir procesamiento de él y su
destrucción. Un estado es una condición o situación específica de un elemento
durante su ciclo de vida. Defina los estados para sus elementos. El estado actual
2008/06/18 167/195
de un elemento es llamado su estado activo, y se dice que el elemento está

“dentro” ese estado. Hay muchos tipos de estados, incluyendo los estados
simples, iniciales y finales. Las siguientes secciones discuten esos diferentes tipos
de estados.
8.1.1 Estados Simple

Un estado simple indica la condición o situación de un elemento. Por ejemplo el
sistema de administración de proyectos pudiera encontrarse en uno de los
siguientes estados simples:
• Inactivo
o Indica que el sistema de administración de proyectos no está
disponible para sus usuarios porque no esta iniciado o ha sido
apagado.
• Activo
o Indica que el sistema de administración de proyectos ha sido iniciado
y está disponible para sus usuarios.
• Suspendido
o Indica que el sistema de administración de proyectos ha encontrado
algún error severo, quizás porque está corriendo lento un dispositivo
de almacenamiento secundario y requiere la intervención del usuario
antes de convertirse activo otra vez.
En UML, un estado simple es mostrado como un rectángulo con esquinas

redondeadas y etiquetado con el nombre del estado o una descripción de la
situación del elemento. La Figura 8-1. Estados simple muestra los distintos
892H
estados asociados con el sistema de administración de proyectos.
Figura 8-1. Estados simple
2008/06/18 168/195
8.1.2 Estados Inicial y Final

Un estado inicial indica el estado de un elemento cuando es creado. En UML, un
estado inicial es mostrado usando un pequeño círculo relleno. Un estado final
indica el estado de un elemento cuando éste es destruido. En UML, un estado final
es mostrado usando un círculo rodeando un pequeño círculo relleno (como “tiro al
blanco”). La Figura 8-2 actualiza la Figura 8-1 con un estado inicial y un estado
893H 894H
final. Un diagrama de estado debe tener un solo estado inicial pero puede tener
cualquier número de estados finales.
Figura 8-2. Estados simple, inicial y final.
8.2 Transiciones
Dados los estados de un elemento ¿como se relacionan estos estados con otros
estados? las transiciones responden a esta pregunta. Como se discutió en el
capítulo 3, las transiciones entre estados ocurren como a continuación se muestra:
1. Un elemento está en un estado fuente.
2. Un evento ocurre.
3. Una acción es realizada.
4. El elemento entra a un estado destino.
Cuando un evento ocurre, la transición es disparada. En UML, una transición es

mostrada como una línea sólida desde un estado fuente a un estado destino
etiquetada con el evento, seguida por una línea diagonal seguida por la acción,
donde el evento y la acción son opcionales y la línea diagonal es usada solo si una
acción es mostrada. Las siguientes secciones discuten eventos y acciones.
Una transición sin un evento ni acción es mostrada como una transición

automática. Tales transiciones son discutidas en el siguiente capítulo.
2008/06/18 169/195
8.2.1 Eventos
Un evento es una ocurrencia, incluyendo la recepción de una petición. Por
ejemplo, el sistema de administración de proyectos podría responder a los
siguientes eventos:
• Iniciar.
o Indica que el sistema de administración de proyectos se volvería
activo si éste esta inactivo.
• Cerrarse.
o Indica que el sistema de administración de proyectos se volvería
inactivo si éste está activo.
• Error severo.
o Indica que el sistema de administración de proyectos ha encontrado
un error severo, quizás esté ejecutándose en segundo plano, y será
suspendido si está activo.
• Reiniciar
o Indica que el sistema de administración de proyectos se volverá
activo si éste está suspendido.
En UML, un evento es descrito usando la siguiente sintaxis UML:
nombre_del_evento (lista_de_parámetros) [guardia]
en la cual:
• nombre_del_evento
o Es el nombre del evento. Un evento usualmente tiene el mismo
nombre como una operación del elemento al cual el diagrama de
estado pertenece; por consiguiente cuando el elemento recibe el
evento, esa operación es invocada.
• lista_de_parámetros
o Es opcional, y es una lista separada por comas que indica los
parámetros pasados al evento. Cada parámetro podría ser un valor
explícito o una variable. Los paréntesis no son usados cuando el
evento no requiere ningún parámetro.
• guardia
o Es opcional e indica una condición que debe satisfacer la transición
que se dispara o que ocurre. Los corchetes no son mostrados
cuando un guardia no es especificado.
2008/06/18 170/195
UML también le permite mostrar un evento usando pseudocódigo u otro lenguaje.

Por ejemplo, se puede usar la sintaxis de Java, C++, C#, o algún otro lenguaje de
programación.
A continuación se muestra un ejemplo de un evento definido usando la sintaxis

que se acaba de mostrar. El evento informa al sistema de administración de
sistema que inicie:
Iniciar
Si este evento requiere la identificación del usuario, se puede actualizar el evento

como sigue:
Iniciar (Idusuario)
Si el sistema de administración de proyectos responde a este evento solo si puede

iniciar, quizás si hay suficiente memoria disponible, se puede actualizar la
transición como sigue:
Iniciar (IdUsuario) (IDusuario) [Hay suficiente memoria]
La Figura 8-3. Transiciones con eventos.muestra ésta transición ocurrida entre el

895H
estado Inactivo, el cual indica que el sistema de administración de proyectos no

está disponible para procesamiento, y el estado Activo, el cual indica que el
sistema de administración de proyectos está disponible para el procesamiento.
Figura 8-3. Transiciones con eventos.

Crear Destruir
Inactivo
Apagar (IdUsuario) [Puede apagarse el sistema] Iniciar (IdUsuario) [Suficiente memoria disponible]
Activo
Reiniciar Error Severo
Suspendido
La Figura 8-3 también muestra una transición originada desde el estado inicial
896H
etiquetada con el evento que crea una instancia del sistema de administración de
proyectos y una transición al estado final etiquetada con el evento que destruye
una instancia del sistema de administración del proyecto. Finalmente la Figura 8-3. 897H
Transiciones con eventos.muestra varios eventos asociados con el sistema de
2008/06/18 171/195
administración de proyectos, incluyendo los eventos Iniciar, Cerrarse, Error severo

y Reiniciar.
8.2.2 Acciones
Una acción representa procesamiento. Por ejemplo el sistema de administración
de proyectos podría responder a eventos con las siguientes acciones:
• RegistrarMensaje
o Indica que el sistema de administración de proyectos registrará un
mensaje en el historial. Este archivo es utilizado para registrar el
procesamiento del sistema de administración de sistema y puede ser
usado para diagnosticar problemas y algunas cosas más.
• obtenerFechaYHora
o Indica que el sistema operativo regresa la fecha y el tiempo actual
del sistema operativo.
En UML, una acción es descrita usando la siguiente sintaxis UML:
variable_de_regreso := elemento_destino.nombre_de_la_acción
(lista_de_argumentos)
en la cual:
• variable_de_regreso
o Es opcional e indica un nombre para el valor regresado por la acción
al ser invocada como respuesta al evento. Si se escoge no mostrar
una variable de retorno o la acción no regresa un valor, se debe
omitir los dos puntos y el signo de igual.
• elemento_destino
o Es el nombre del elemento que realizará la acción. Si el mismo
elemento que recibe el evento realizará la acción, el elemento
objetivo no es mostrado y se debe omitir el punto.
• nombre_de_la_acción
o Es el nombre de la acción. Una acción usualmente tiene el mismo
nombre que el de una operación del elemento al cual el diagrama de
estado pertenece, o como una operación del elemento destino si uno
es especificado, por consiguiente, cuando la acción es invocada, el
elemento recibe el evento y la operación es invocada.
• lista_de_argumentos
2008/06/18 172/195
o Es opcional, y es una lista separada por comas que indica los

argumentos pasados a la acción. Cada parámetro puede ser un valor
explícito o una variable. Los paréntesis son removidos cuando la
acción no requiere ningún argumento.
UML también le permite mostrar un evento usando pseudocódigo u otro lenguaje.

Por ejemplo, se puede usar la sintaxis de Java, C++, C#, o algún otro lenguaje de
programación.
Continuando con el ejemplo de la sección anterior, la siguiente acción pasa la

zona horaria (fecha/hora) del sistema operativo al usuario usando la operación
obtenerFechaYHora:
SO.obtenerFechaYHora (ZonaHoraria)
Si esta acción regresa algún dato de salida (la fecha y hora actual), se puede
actualizar la acción como sigue:
DT := obtenerFechaYHora (ZonaHoraria)
La Figura 8-4. Transiciones con eventos y acciones actualiza la Figura 8-3 y

89H 89H
muestra las eventos y acciones para las transiciones entre los estados Activo e
Inactivo. También se puede ver el registro de un mensaje usando la acción
RegistrarMensaje cuando el sistema es cerrado, y se puede ver que el evento
Iniciar desencadenando la recuperación de la fecha y la hora usando la acción
obtenerFechaYHora del objeto SO, el cual representa el sistema operativo.
Figura 8-4. Transiciones con eventos y acciones

Crear Destruir
Inactivo
Apagar (IdUsuario) [Puede apagarse el sistema] Iniciar (IdUsuario) [Suficiente memoria disponible]
/ RegistrarMensage(Idusuario, “Apagar”) / DT := OS.ObtieneFechaYTiempo (ZonaHorario)
Activo
Reiniciar Error Severo
Suspendido
8.3 Diagramas De Estado Avanzados

Para ser flexible y poderoso, UML permite colocar uno o mas diagramas de estado
dentro de un estado simple para indicar cuando un elemento está en ese estado,
2008/06/18 173/195
otros elementos dentro de éste tienen sus propios estados. Por ejemplo, dentro
del estado Activo del sistema de administración de proyectos, cada objeto y
subsistema tiene su propio estado, y el diagrama de estado para cada elemento
podría ser mostrado dentro del estado Activo del sistema de administración de
proyectos o usando el diagrama de estado propio del elemento. Esta naturaleza
recursiva de los diagramas de estado es muy poderosa, porque permite aprender
la notación básica de diagramas de estado y reaplicarla para anidar diagramas de
estado sin tener que aprender más notación.
En UML, un estado puede ser mostrado como un rectángulo con esquinas

redondeadas y tres compartimientos separados por líneas sólidas horizontales. La
Figura 8-5 muestra el estado Activo del sistema de administración de proyectos
90H
con tres compartimientos. El compartimiento superior contiene el nombre del

estado o una descripción de la situación del elemento.
El compartimiento de en medio de un estado puede contener transiciones para los

siguientes eventos especiales:
• entrada
o Indica la acción a ser realizada cuando el elemento entra al estado.
• salida
o Indica la acción a ser realizada cuando el elemento sale del estado.
• hacer
o Indica la acción a realizar continuamente mientras el elemento está
dentro del estado.
La Figura 8-5 muestra que cuando el sistema de administración de proyectos entra

901H
a un estado Activo, un mensaje es registrado usando la acción RegistrarMensaje.

Cuando el sistema de administración de proyectos sale del estado Activo, la fecha
y hora del usuario se recuperan usando la acción obtenerFechaYHora del objeto
SO. Finalmente cuando el sistema de administración de proyectos está en estado
Activo, continuamente monitorea su uso utilizando la acción MonitorDeUso.
El compartimiento del fondo de un estado puede contener uno o mas diagramas

de estado anidados separados por líneas punteadas, cada uno con un título que
describe el elemento al cual el diagrama de estado pertenece. Cuando un estado
se vuelve el estado actual de un elemento, todos sus diagramas de estado
anidados se volverán activos simultáneamente.
La Figura 8-5 muestra que cuando el sistema de administración de proyectos entra

902H
al estado Activo, los diagramas de estado anidados tienen cada uno un estado
actual.
2008/06/18 174/195
Ventana de Interfaz de Usuario Principal o Procesamiento en

Primer Plano
Describe el ciclo de vida la interfaz de usuario. Hay dos estados, incluyendo el

estado Mostrado, el cual indica que la interfaz de usuario es visible para el usuario
y el estado Oculto el cual indica que la interfaz de usuario no es visible para el
usuario. El evento Ocultar hace la interfaz de usuario no sea visible para el
usuario, y el evento Mostrar hace la interfaz de usuario visible para el usuario.
Procesamiento en Segundo Plano
Describe el ciclo de vida de como trabaja el sistema y el manejo de las peticiones

del usuario. Hay dos estados, incluyendo el estado de Espera el cual indica que el
sistema de administración de proyectos no está manejando alguna petición del
usuario y el estado Ocupado, el cual indica que el sistema de administración de
proyectos está manejando alguna petición del usuario. El evento
HacerProcesamiento hace al sistema de administración de proyectos ocupado
manejar una petición del usuario y el evento ProcesamientoCompleto pone en
Espera al sistema de administración de proyectos para manejar una petición del
usuario.
Figura 8-5. Diagramas de estado avanzado
Todas las transiciones van de un estado relacionado a cada diagrama de estado

anidado; si uno de esos diagramas de estado anidados activa una transición
2008/06/18 175/195
saliente, todos los diagramas de estado anidados son forzados a salir. La Figura
903H
8-5 indica que cuando el sistema de administración de proyectos está en el estado

Activo y un evento Error Severo ocurre, ambos diagramas de estado anidados son
terminados independientemente de en cual diagrama de estado anidado ocurrió el
evento.
9 Diagramas de Actividad
Este capítulo se centra en los diagramas de actividad, que representan las
actividades y las responsabilidades de los elementos que hacen funcionar un
sistema. Primero, se introducen los diagramas de actividad y cómo se utilizan.
Después, se discuten los estados de acción y sus detalles. Finalmente, se pasa a
los flujos y sus detalles. Muchos detalles de los diagramas de actividad que no
eran fleshed out en el Capítulo 3 se elaboran más completamente aquí, y a través
26H
del capítulo, se incluyen sugerencias relacionadas con los diagramas de actividad.
El modelado de actividad es un tipo especializado de modelado del

comportamiento referido a modelar las actividades y las responsabilidades de los
elementos. Usted aplica generalmente el modelado de actividad conjuntamente
con el modelado de secuencia y de colaboración (el Capítulo 7) para explorar las
263H
actividades y las responsabilidades de los elementos de interacción y

colaboración.
9.1 Estados
Según lo discutido en el Capítulo 3, como los elementos se comunican los unos
264H
con los otros dentro de una sociedad de objetos, cada elemento tiene la
responsabilidad apropiada de reaccionar a las comunicaciones que recibe. Un
estado de acción representa el proceso mientras que un elemento satisface una
responsabilidad. Hay varios tipos de estados de acción, incluyendo estados de
acción simple, inicial, y final. Las secciones próximas discuten estos diversos
tipos de estados de acción.
9.1.1 Estados Simples de Acción (Acciones)

Un estado simple de acción representa el proceso. Por ejemplo, el sistema de
administración de proyectos puede tener las siguientes acciones de acción:
• El Administrador de Proyecto Ingresa los Criterios del Reporte

o Indica que el administrador del proyecto incorpora criterios del
reporte
• El Sistema de Administración de Proyectos Genera el Reporte

o Indica que el sistema de administración de proyectos genera el
reporte
• La Impresora Imprime el Reporte

o Indica que la impresora imprime el reporte
2008/06/18 176/195
En el UML, un estado de acción se muestra con forma de una tapa recta y arcos
inferiores y convexos en los dos lados, y se etiqueta con el nombre de una
operación o de una descripción del proceso. La Figura 9.1 demuestra los diversos
904H
estados de acción asociados al sistema de administración de proyectos.
Figura 9.1. Estados simples de la acción
El Administrador de Proyecto Ingresa

los Criterios del Reporte
El Sistema de Administración de
Proyectos Genera el Reporte
La Impresora Imprime el
Reporte
9.1.2 Estados de la acción inicial y final

Un estado de acción inicial indica el primer estado de acción en un diagrama de
actividad. En UML, se muestra un estado de acción inicial usando un círculo
sólido pequeño. Un estado de acción final indica el estado pasado de la acción en
un diagrama de actividad. En UML, se muestra un estado de la acción final
usando un círculo que rodea otro círculo sólido pequeño (un ojo de toro). La Figura 905H
9.2 actualiza la Figura 9.1 con un estado de acción inicial y final. Un diagrama de
906H
actividad puede tener solamente un estado de acción inicial, pero puede tener
cualquier número de los estados de acción final.
2008/06/18 177/195
Figura 9.2. Estados de Acción simples, iniciales y finales
El Administrador de Proyecto
Ingresa los Criterios del Reporte
El Sistema de Administración de
La Impres ora Imprime el

Report e
9.2 Flujo de transiciones

Dado una colección de estados de acción, ¿cómo están esos estados de acción
relacionados unos con otros? Las transiciones de flujo tratan este asunto. Según
lo discutido en el capítulo 3, una transición de flujo muestra cómo se piden o se
ordenan los estados de acción. Hay varios tipos de transiciones de flujo,
incluyendo las transiciones flujo-de-control y de flujo-de-objeto, que son
mencionadas en el capítulo 3 y que se discuten aquí.
9.2.1 Transiciones de flujo de control

Una transición de flujo-de-control indica la orden de los estados de acción. Es
decir, una vez que un estado fuente de acción complete su proceso, un estado de
acción objetivo comienza su proceso. Por ejemplo, el sistema de administración
de proyectos puede tener la siguiente orden de los estados de acción para la tarea
de generar un reporte:
1. El administrador del proyecto incorpora criterios del reporte que ocurre en el

primer estado de acción, porque el administrador del proyecto debe
incorporar los criterios del reporte antes de que el sistema pueda generar
un reporte.
2. El sistema de administración de proyectos genera el estado de acción del

reporte que ocurre después, porque el sistema de administración de
proyectos debe generar el reporte antes de que la impresora pueda imprimir
el reporte.
2008/06/18 178/195
3. El estado de acción del reporte de las impresiones de la impresora ocurre al

final, una vez que el reporte haya sido generado por el sistema de
administración de proyectos.
En UML, una transición de flujo-de-control se muestra como línea de un estado de

acción fuente a un estado de acción objetivo. La Figura 9.3 muestra el pedido de
907H
los estados de acción asociados al sistema de administración de proyectos.
Figura 9.3. Transiciones Control - Flujo
El Sistema de Adminis tración de

Proyect os Genera el Reporte
Reporte
La Figura 9.3 también muestra una transición de flujo-de-control que origina del
908H
estado inicial para indicar el primer estado de acción, y una transición al estado
final para indicar el ultimo estado de acción.
Las transiciónes de flujo-de-control también son conocidas como transiocnes

default o transicones automaticas, porque están sin etiqueta e inmediatamente
después de que el estado fuente de acción termine el proceso.
9.2.2 Flujo de control de objetos

Una transición de flujo-de-objeto indica que un estado de acción hace entrar o
hace salir un objeto. Por ejemplo, los estados de acción mostrados en la Figura 90H
9.3 pueden tener entradas y salidas como sigue:
• El Administrador del Proyecto Ingresa los Criterios del reporte
2008/06/18 179/195
o Se quita un objeto criterio de reporte y puede ser renombrado como

el estado de accion de EL Administrador del Proyecto Ingresa los
Datos
• El sistema de administración de proyectos Genera el Reporte

o Entra el objeto de Criterio de Reporte y sale un Objeto de Reporte y
se renombra como el estado de acción El Sistema de Administración
de Proyectos Genera el Reporte
• La Impresora Imprime el Reporte

• Entra el objeto Reporte y puede ser renombrado como el estado de
acción La Impresora Imprime el Reporte
En UML, una transición de flujo-de-objeto es mostrada como una flecha punteada

entre un estado de acción y un objeto. Un estado de acción que utiliza un objeto
mientras que la entrada se demuestra con una flecha de transición de flujo-de-
objetos que señala desde el objeto hasta el estado de acción. Un estado de
acción que actualiza o produce un objeto mientras que la salida se muestra con
una flecha de transición de flujo-de-objeto que señala del estado de acción al
objeto. La Figura 9.4 muestra los objetos usados por los estados de acción
910H
asociados al sistema de administración de proyectos.
Note los nuevos nombres para los estados de acción en la Figura 9.4 con respecto
91H
la Figura 9.3. En la Figura 9.3, los nombres del estado de acción transportaron
912H 913H
una cierta idea de las entradas y de las salidas de cada estado. La Figura 9.4 sin
914H
embargo, muestra estas entradas y salidas explícitamente, no hay mas necesidad

de implicarlos redundantemente en los nombres del estado de acción. La ventaja
es los nombres del estado de acción puede ahora centrarse puramente en las
acciones, mientras que las transiciones de flujo-de-control indican claramente las
entradas y las salidas a y desde las acciones.
2008/06/18 180/195
Figura 9.4. Transiciones objeto – flujo y control - flujo
Ingresa los Criterios del Report e
CriterioDeReporte El Sis tema de Administración de

Reporte Reporte
Una transición de flujo-de-control puede ser omitida cuando una transición de flujo-
de-objeto indica el orden de los estados de acción; es decir, cuando un estado de
acción produce una salida que se convierte en la entrada del subsiguiente estado
de acción, la transición de un flujo-de-objeto implica una transición de flujo-de-
control y por lo que una transición flujo-de-control no es necesaria. La Figura 9.5915H
actualiza la Figura 9.4 quitando la innecesaria transición de flujo-de-control.

916H
2008/06/18 181/195
Figura 9.5. Transiciones de flujo-de-objeto y de flujo-de-control sin las innecesarias

transiciones de flujo-de-control
CriterioDe El Sist ema de Administración de

Reporte Proyectos Genera el Reporte
Reporte La Impresora Imprime el

Reporte
9.3 Swimlanes
Según lo discutido en el capítulo 3, un swimlane es una región visual en un
diagrama de actividad que señala el elemento que tiene responsabilidad de los
estados de acción dentro de la región. Por ejemplo, el sistema de administración
de proyectos puede tener los siguientes swimlanes, que se ilustran en la Figura 917H
9.6:
• Administrador del Proyecto

o Muestra los estados de acción que son responsabilidad del
administrador del proyecto. El swimlane hace obvio que el
administrador del proyecto es responsable de incorporar los datos,
así el nombre algo incómodo del estado de acción del administrador
de proyecto incorpora datos que se pueden acortar para incorporar
los datos.
• Sistema de administración de proyectos

o Muestra los estados de acción que son la responsabilidad del
sistema de administración de proyectos. Una vez más porque el
swimlane lo hace obvio quién (o lo que, en este caso) está
generando la información, el nombre algo incómodo del estado de la
acción del sistema de administración de proyectos genera la
información se puede acortar para generar la información.
• Impresora
2008/06/18 182/195
o Demuestra los estados de la acción que son la responsabilidad de

una impresora. Debido a este swimlane, el nombre algo incómodo
del estado de la acción de la información de las impresiones de la
impresora se puede acortar para imprimir la información.
Se avisa cómo el uso de swimlanes permite que se renombren los estados de

acción para omitir el elemento responsable para cada estado de acción.
En UML, un swimlane se demuestra como una región visual separada de

swimlanes vecinos por las líneas verticales en ambos lados y etiquetada en la tapa
con el elemento responsable de estados de acción dentro del swimlane. La Figura 918H
9.6 muestra los swimlanes asociados al sistema de administración de proyectos.

Figura 9.6. Swimlanes
: Administrador del Proyecto : Sistem a de Administración de Proyectos : Impresora
Ingresar los
Datos
CriterioDel Generar la
Reporte Informacion
Report e La Impresora Imprime la

Informacion
9.4 Decisiones
Una decisión implica el seleccionar una transición de flujo-de-control de muchas
transiciones de flujo-de-control basadas sobre una condición. Por ejemplo, una
vez que un informe sea impreso por el sistema de administración de proyectos,
otros informes pueden ser seleccionados y ser impresos si el administrador del
proyecto elige imprimir más reportes.
En UML, una decisión se muestra en forma de diamante con transiciones de flujo-

de-control entrante y transiciones de flujo-de-control saliente donde cada
transición de flujo-de-control es etiquetada con una condición de guardar entre
2008/06/18 183/195
corchetes que indican la condición que se debe satisfacer para la transición al

fuego o que ocurra. La Figura 9.7 muestra que una vez que se imprima un
91H
informe, el administrador del proyecto puede elegir imprimir más informes. Note
que porque la forma del diamante está en el swimlane del administrador del
proyecto, el administrador del proyecto es responsable de tomar la decisión.
Figura 9.7. Decisiones
Administrador del Proyecto S istema de Admi ni str acion de Pr oye ctos Im pr esor a
Ingresar los Datos
CriterioDel Generar la
Reporte Informacion
Reporte La Impresora Imprime la

[ Hay Mas Reportes ]
Informacion
[ No Hay Mas Reportes ]
9.5 Concurrencia
La concurrencia implica el seleccionar múltiples transiciones simultáneamente.
Por ejemplo, mientras que la impresora está imprimiendo un reporte, la impresora
debe también supervisar el control para otras peticiones de impresión entrantes.
En UML, se demuestra la concurrencia usando una barra pesada corta. Si una

barra tiene una transición entrante y dos o mas transiciones salientes, indica que
ocurren todas las transiciones salientes y una vez la transición entrante. A esto se
le llama repartir información. Si una barra tiene dos o mas transiciones entrantes
y una transición saliente, indica que todas las transiciones entrantes deben ocurrir
antes de que ocurra la transición saliente. Esto se llama sincronización del
control. La Figura 9.8 demuestra que la impresora utiliza una concurrencia para
920H
2008/06/18 184/195
imprimir un informe usando el estado de la acción de la información de la

impresión, y supervisar para otras peticiones de impresión entrantes mientras que
maneja la petición actual usando el monitor para el estado de la acción de las
peticiones de impresión. Una vez que ambos de estos estados de la acción hayan
terminado, un administrador del proyecto puede elegir imprimir más informes.
Figura 9.8. Concurrencia
Administrador del Proyecto Sistema de Administracion de Proyectos Impresora
Ingresar los Datos
Generar la
CriterioDel
Informacion
Reporte
Informacion de Monitoreo Para Imprimir Mas

[Hay Mas Reportes] Reporte Pet iciones
Impresion
[ No hay Mas Reportes ]
2008/06/18 185/195
Parte IV.- Mas allá de UML

10 Mecanismos de Extensión
Este capitulo hace una introducción a los mecanismos de extensión del Lenguaje
Unificado de Modelado el cual permite extender el lenguaje. Se discute como
extender el lenguaje usando estereotipos, aplicar extensiones, capturar
características de los elementos del modelo usando propiedades, y extensiones
del paquete usando perfiles.
Según lo discutido en el Capítulo 2, un lenguaje nos permite comunicar algo

acerca de un tema, los requerimientos y el sistema que satisface esos
requerimientos -- por ejemplo, los requerimientos del sistema administración de
proyectos que se ha estado discutiendo en el libro. Un lenguaje extensible permite
que definamos nuevos conceptos, como introducir nuevas palabras y ampliar el
vocabulario de un lenguaje natural. Por ejemplo, en vez de hacer que cada
esfuerzo referente a un sistema de administración de proyectos defina el concepto
de un proyecto, yo puede ampliar UML para incorporar una definición de qué es un
proyecto, que se puede reutilizar por el resto de estos esfuerzos. También, en vez
de tener cada esfuerzo relacionado con el sistema administración de proyectos
defina la relación entre un proyecto y las cosas que integran el proyecto, se puede
ampliar UML para incorporar una definición de una relación con un proyecto y las
cosas que integran un proyecto, qué se puede reutilizar por estos y del resto de
los esfuerzos. Cada esfuerzo puede entonces especializar estas definiciones
como sea necesario. Por ejemplo, un esfuerzo puede implicar proyectos de
desarrollo de software tales como desarrollar un sistema de información o de
tecnología, mientras que otro esfuerzo puede implicar proyectos de infraestructura
tales como instalación de computadoras personales, de servidores, y de cualquier
otro software. Esta capacidad para ampliar UML tiene importante valor para crear
colecciones estandardizadas de los elementos de UML, que pueden ser
reutilizados. Por lo tanto, siempre que uno y la gente se encuentren usando los
mismos conceptos o similares, relaciones, así como la reutilización estos
conceptos y las relaciones, también se debe considerar que se podría ampliar
UML para incorporar estos conceptos y las relaciones para poderlos estandarizar y
reutilizar más fácilmente.
10.1 Lenguaje de Arquitectura

UML está definido dentro de un esquema llamado meta modelado de cuatro capas
que involucra cuatro capas o niveles distintos de abstracción. Cada capa define
elementos, conceptos, y relaciones entre conceptos, basado en los tipos de
elementos de la capa siguiente más general.
Por ejemplo, considere cómo de definen los lenguajes de programación y

programas usando las capas siguientes:
• El meta – meta modelo o capa de nivel M3
2008/06/18 186/195
o En la capa más abstracta, definimos los conceptos de datos,

procesamiento, entrada, y salida donde se procesan datos de
entradas y salida.
• El meta modelo o capa de nivel M2

o En la capa siguiente más específica, se pueden definir los lenguajes
de programación que tengan tipos de datos específicos y tipos de
sentencias de procesamiento, usando conceptos definidos de datos
y procesados en el nivel M3. Por ejemplo, Java tiene los tipos de
datos byte, short, int, long, char, float y double y tiene sentencias
para el procesamiento if, while, do, for, break, continue return.
• El modelo o la capa de nivel M1

o En la capa más específica siguiente, se pueden definir los programas
que utilizan tipos de datos específicos y sentencias específicas para
el procesamiento usando los tipos de elementos definidos en la capa
de nivel M2 -- por ejemplo, un programa de Java que utilice cadenas
de tipo int y char dentro de un ciclo para contar el numero de
caracteres de una cadena.
• El modelo del usuario o capa de nivel M0

o En la capa mas especifica siguiente, se pueden ejecutar programas -
por ejemplo, un programa de Java que cuente el número de
caracteres en una secuencia tal como "Yo amo a UML" que tiene 12
caracteres-.
Dentro de este esquema, como cada capa tiene elementos más específicos en
concreto, la frase "meta" es disminuida y el número de capa decrece.
Para un lenguaje de programación, la capa de nivel M2 define el lenguaje de

programación con los tipos de datos y los tipos de sentencias para el
procesamiento, la capa de nivel M1 define un programa con variables específicas
de los datos y sentencias específicas para el procesamiento usando los elementos
definidos en la capa de nivel M2, y la capa de nivel M0 es un programa en
ejecución que se define en la capa de nivel M1 usando los tipos de datos y los
tipos de sentencias de procesamiento definidas en el nivel M2. Es muy natural que
un programa en ejecución (capa de nivel M0), es una instancia o una ejecución
específica de un programa definido (capa de nivel M1) que usa los tipos de datos y
los tipos de sentencias para el procesamiento del lenguaje de programación (capa
de nivel M2).
Similarmente, para UML, decimos que un modelo, representado usando

diagramas de clase, es una instancia de un meta modelo; un modelo del usuario,
representado usando diagramas de objeto, es una instancia de un modelo
representado usando diagramas de clase; un modelo de usuario, representado
2008/06/18 187/195
usando diagramas de objeto, es un caso de un meta modelo; y los objetos y los

vínculos son instancias de sus clases y asociaciones, respectivamente.
Este esquema de definir y de organizar un lenguaje es importante pues ayuda a

definir el lenguaje y cómo se utiliza; de lo contrario, un lenguaje sería una
mezcolanza de diversos tipos de elementos de modelado, conceptos, y relaciones
entre los conceptos, sin ninguna idea de cómo se define el lenguaje y de cómo
puede ser utilizado.
Similar a cómo el lenguaje de programación Java se define en la capa del meta

modelo, UML se define en la capa del meta modelo como sigue:
• El meta-meta modelo o capa de nivel M3

o El estándar de UML define la noción de un concepto.
• El meta modelo o capa de nivel M2

o El estándar de UML define los conceptos de clase, atributo,
operación, objeto, valor del atributo, asociación, vínculo, y así
sucesivamente, los cuales incluyen todos los conceptos que
componen UML. Cada clase es un meta modelo conocido como
meta clase.
• El modelo o la capa del nivel M1

o Se definen clases, los atributos, las operaciones y las asociaciones
específicas -- por ejemplo, todas las clases y asociaciones con todo
su detalle que pertenece al sistema administración de proyectos
discutido a través del libro.
• El modelo de usuario o la capa del nivel M0

o Se definen objetos, valores de los atributos, y enlaces específicos --
por ejemplo, todos los objetos y los vínculos con sus detalles que
pertenecen al sistema administración de proyectos discutido a través
del libro.
Para asegurarse de que UML permanezca estandardizado, no se puede modificar

el meta modelo que define al lenguaje. Pero para asegurarse de que UML sea
extensible, podemos ampliar al lenguaje definiendo nuevos conceptos usando
estereotipos, describiéndolos usando características, y empaquetándolas y
reutilizándolas usando perfiles.
10.2 Estereotipos
Un estereotipo define un nuevo tipo de elemento de modelado en UML. Use
estereotipos para definir un nuevo tipo de elemento de modelado y después
2008/06/18 188/195
aplique la definición. Por ejemplo, se puede definir el concepto de un proyecto y

de la relación entre el proyecto y las cosas que integran ese proyecto.
10.2.1 Definiendo Estereotipos

En UML se crea una definición de un estereotipo mostrando una clase
representando el estereotipo con una dependencia en otra clase representando el
tipo de elemento de modelado que representa el estereotipo. La clase
representando el nuevo tipo de elemento de modelado y las dependencias son
marcadas con la palabra estereotipo, y las clases que representan el tipo de
elemento de modelado a los cuales aplica el estereotipo son marcadas con la
palabra metaclase. Cada clase se muestra como un rectángulo marcada con las
palabras encerradas entre signos dobles de mayor que y menor que (<< >>) o
corchetes dobles, antes y después del nombre. La dependencia es representada
como una flecha punteada desde la clase que representa el estereotipo hasta la
otra clase que representa el tipo de elemento del modelado al cual aplica el
estereotipo.
Como se discutió al principio de este capítulo, antes de hacer diversos esfuerzos

referente a un sistema de administración de proyectos que define los conceptos de
un proyecto, se puede ampliar UML para incorporar una definición de que cosa es
el proyecto, el cual se puede reutilizar por estos el resto de estos esfuerzos. Antes
de hacer diversos esfuerzos referente a un sistema de administración de
proyectos que definen las relaciones entre un proyecto y las cosas lo integran un
proyecto, se puede ampliar UML para incorporar una definición para las relaciones
entre el proyecto y las cosas que lo integran, para que se pueda reutilizar por el
resto de estos esfuerzos. La Figura 10-1, un diagrama de clase, define el
921H
concepto de un proyecto como estereotipo del proyecto, y define la relación entre

un proyecto y las cosas que integran un proyecto con un estereotipo Hecho de. La
clase metaclase indican que el estereotipo del proyecto se aplica a las clases, y
las asociaciones metaclase indican que el estereotipo Hecho de aplica a las
asociaciones.
Figura 10-1. Definiendo estereotipos
<<metaclase>> <<metaclase>>
Clase Asociacion
<<estereotipo>> <<estereotipo>>
Projecto Hecho de
2008/06/18 189/195
10.2.2 Aplicando Estereotipos

En UML, se aplica una definición de estereotipo a un elemento del modelo,
entonces se le llama elemento estereotipado mostrando el nombre del nuevo tipo
entre signos dobles de menor que y mayor que (<<>>) o corchetes dobles, antes o
en la parte superior del nombre del elemento del modelo.
Ahora que se ha ampliado UML con el concepto de un proyecto y de la relación

entre un proyecto y las cosas que lo integran, puedo aplicar estos estereotipos. La
Figura 10-2, un diagrama de clase, aplica los estereotipos definidos en la Figura
92H 923H
10-1 y muestra un tipo de proyecto de desarrollo nombrado Proyecto de

Desarrollo, y un tipo de proyecto de infraestructura nombrado como Proyecto de
Infraestructura. Un proyecto de desarrollo requiere y se hace de un entorno de
desarrollo, el cual es descrito usando la clase de Entorno de Desarrollo. Un
proyecto de infraestructura se hace de un ambiente o de una plataforma de
deployment, el cual es descrito usando la clase Entorno de Deployment. El
proyecto de desarrollo y el proyecto de la infraestructura están estereotipados
usando el estereotipo Projecto, y sus relaciones están estereotipadas usando el
estereotipo Hecho de.
Figura 10-2. Aplicando estereotipos usando diagramas de clase
<<Proyecto>> <<Proyecto>>
Projecto de Desarrollo Proyecto de Infraestructura
<<Hecho de>> <<Hecho de>>
Entorno de Desarollo Entorno de Deployment
La Figura 10-3, un diagrama de objeto, aplica los estereotipos definidos en la

924H
Figura 10-1, junto con las clases y las asociaciones definidas en la Figura 10-2, y
925H 926H
muestra un proyecto de desarrollo nombrado el SistAdmonProy (el cuál esta

relacionado con el desarrollo de un sistema administración de proyectos), y un
proyecto de infraestructura nombrado como a Java Deployment (el cuál esta
relacionado con el despliegue de un ambiente runtime de Java). El proyecto del
desarrollo de sistema de SistAdmonProy se hace del EntDesJava, que
2008/06/18 190/195
proporciona todas las herramientas de Java para desarrollar el sistema de

administración de proyectos. El proyecto de infraestructura de Java Deployment
se hace del Entorno Unix, que proporciona la infraestructura o la plataforma para
el EntDesJava. Los objetos y los enlaces están marcados con los mismos
estereotipos que sus clases y asociaciones, respectivamente.
Figura 10-3. Aplicación de estereotipos usando diagramas de objetos
SistAdmonProy: Java Deployment:
Deployment de Java:
Proyecto de Desarrollo Proyecto
Proyecto de
de Infraestructura
Infraestructura
EntDesJava:
EntDesJava: Entorno
Unix:Unix:
Entorno
Entorno de
de Desarrollo
Desarrollo Entorno
Enternode
deDeployment
Desarrollo
10.3 Propiedades
Una propiedad es una característica del elemento de un modelo. Se usan
características para definir cualidades y las reglas para un tipo de elemento dado
del modelado. Por ejemplo, las características pueden definir lo siguiente:
cualidades que representan las fechas de inicio y de fin de un proyecto, una
descripción textual específica de la relación entre un proyecto y las cosas que se
integran el proyecto, y una regla que la fecha de inicio debe anteceder a la fecha
de fin.
Las características se muestran como una lista cadena de caracteres separadas

por comas dentro de un par de llaves ({ }) después o en la parte inferior del
nombre de un elemento del modelo. Cada característica se puede expresar en
cualquier lenguaje natural o de programación. Cada cadena de caracteres puede
ser una etiqueta o una restricción, ambos se discuten en las secciones siguientes.
10.3.1 Etiquetas(Tags)
Una etiqueta es un atributo de un elemento del modelo y de su valor
correspondiente -- por ejemplo, los atributos representan de las fechas de inicio y
de fin de un proyecto.
2008/06/18 191/195
10.3.1.1 Definiendo Etiquetas

En UML, se crea una definición para una etiqueta cuando se define un estereotipo
mostrando un nombre para el atributo, llamada palabra clave, seguida por dos
puntos y seguido por el tipo del atributo. Las etiquetas definidas por un
estereotipo se aplican a cada elemento del modelo al cual se le aplica el
estereotipo.
Por ejemplo, la Figura 10-4 actualiza la Figura 10-1 y muestra una etiqueta
927H 928H
llamada FechaDeInicio (la cual es una cadena de caracteres que representa la

fecha del inicio de un proyecto), una etiqueta nombrada FechaDeFin ( la cual es
una cadena de caracteres que representa la fecha para el final de un proyecto), y
una etiqueta nombrada Descripción ( la cual es una cadena de caracteres que
representa una descripción de la relación entre un proyecto y una cosa que lo
integra el proyecto). Las etiquetas FechaDeInicio y FechaDeFin se definen para el
estereotipo Proyecto, y la etiqueta de Descripción se define para el estereotipo
Hecho de.
Figura 10-4. Definiendo estereotipos y tags
Clase Asociacion
Projecto Hecho de
{FechaDeInicio: String, {Descripción:String}
FechaDeFin: String }
10.3.1.2 Aplicando Etiquetas

En UML, la aplicación de una etiqueta (llamada un valor dado a la etiqueta) es
realizada al aplicar un estereotipo mostrando el nombre del atributo seguida por un
signo igual, seguido por su valor, junto con una palabra clave llamada – valor par.
Cuando no se utiliza ningún signo igual o un valor especificado, se asume que la
palabra clave representa un valor boleano de True, y la ausencia de la palabra
clave representa un valor boleano de False.
2008/06/18 192/195
Por ejemplo, la Figura 10-5 actualiza la Figura 10-3 usando las etiquetas en la
92H 930H
Figura 10-4, y muestra que el SistAdmonProy inicia en enero 1 del 2003 y finaliza
931H
en diciembre 31 del 2003. El proyecto Deployment de Java inicia en el diciembre

31 del 2003 y finaliza en enero 1 del 2003, que es obviamente incorrecto, porque
la fecha de inicio es más reciente que la fecha final. Las restricciones se utilizan
para asegurarse para que tales errores no sean permitidos y se discuten en la
sección siguiente. La Figura 10-5 también muestra una descripción del enlace
932H
estereotipado para el estereotipo del vínculo Hecho del proyecto SistAdmonProy e

indica que la descripción del estereotipo para el vínculo Hecho de del proyecto
Deployment de Java está vacía o en blanco.
Figura 10-5. Aplicando estereotipos y tags
SistAdmonProy: Proyecto Deployment de Java: Proyecto
de Desarrollo de Infraestructura
{FechaDeInicio = "Enero 1, 2003", {FechaDeInicio = "Diciembre 31, 2003",
FechaDeFin = "Diciembre 31, 2003"} FechaDeFin = "Enero 1, 2003"}

{Descripción = "Este es el {Descripción = ""}
entorno usado para el
desarrollo"}
EntDesJava: Entorno Unix:

Entorno de Desarrollo Entorno de Deployment
10.3.2 Restricciones
Una restricción es una regla para un elemento del modelo -- por ejemplo, una
regla que la fecha de inicio de un proyecto debe anteceder a la fecha de fin del
proyecto. Las reglas definidas para un estereotipo se aplican a cada elemento del
modelo al cual se aplique el estereotipo, y cada elemento del modelo al cual se
aplica el estereotipo debe apegarse a las reglas.
En UML, una restricción se muestra cuando se define un estereotipo como una

cadena de caracteres que puede ser expresada usando el Lenguaje de
Restricción de Objetos (LRO), del cual se discute en el Capítulo 11. Las
restricciones pueden también ser expresadas usando seudo código u otra
2008/06/18 193/195
lenguaje. Por ejemplo, se puede expresar una restricción usando Java, C++, C #,
u otro lenguaje, ya sea de programación o no.
La Figura 10-6 actualiza la Figura 10-4 y muestra la siguiente restricción en los

93H 934H
proyectos:
The End Date must be on or after the Start Date.
La Fecha de Fin debe ser en o después de la Fecha de Inicio.
La Figura 10-6 también muestra la siguiente restricción en las relaciones entre un

935H
proyecto y las cosas integran un proyecto:
The Description must not be empty.

La Descripción no debe estar vacía.
Según estas reglas, el proyecto SistAdmonProy descrito en la Figura 10-5 se 936H
considera válido. Su fecha de inicio antecede a su fecha de fin. Por otra parte, el
proyecto Deployment de Java descrito en la Figura 10-5 se considera inválido o
937H
erróneo porque este comienza después de que termina.
Figura 10-6. Definiendo estereotipos, etiquetas y restricciones
Clase Asociacion
Projecto Hecho de
{FechaDeInicio: String, {Descripción:String,
FechaDeFin: String, La descripción no debe ser
La FechaDeFin debe estar en o después de la FechaDeInicio} una cadena vacía}
10.4 Perfiles
Un perfil es una colección de definiciones para los estereotipos, definiciones para
las etiquetas, y de restricciones relevantes para un dominio específico o propósito.
Por ejemplo, usted puede agrupar los estereotipos Proyecto y Hecho de con sus
definiciones para las etiquetas y las restricciones de este capítulo, en un perfil para
la administración del proyecto. El perfil de la administración del proyecto puede
2008/06/18 194/195
entonces ser reutilizado al trabajar con otros sistemas de administración de

proyectos además del que este en este libro.
En UML, un perfil se muestra como un paquete marcado con la palabra clave

perfil, y un modelo y todos sus diagramas se pueden mostrar como un paquete
marcado con la palabra clave modelo. La Figura 10-7 muestra un paquete para
938H
aprender UML, que contendría los diagramas y los elementos del modelo definidos
en este libro. De ese paquete, se ve una dependencia al perfil de la
Administración del Proyecto, que contendría las definiciones para los estereotipos,
las definiciones para las etiquetas y las restricciones usadas para la administración
del proyecto, según lo definido en este capítulo. Los perfiles son paquetes, según
lo discutido en el Capítulo 4, y podemos mostrar su contenido en este diagrama
también.
La dependencia en la Figura 10-7 es una dependencia aplicada a un perfil.

93H
Cuando es dibujado de un paquete del modelo cliente a un paquete del perfil

proveedor, tal dependencia indica que el modelo cliente utiliza el perfil del
proveedor; es decir, los elementos en el modelo usan los elementos en el perfil.
En UML, una dependencia de perfil aplicada se muestra como una flecha
punteada de un modelo del cliente a un perfil del proveedor marcado con la
palabra clave perfilAplicado. La Figura 10-7 muestra que el modelo Aprendiendo
940H
UML utiliza el perfil Administración del Proyecto para definir el sistema de

administración de proyecto discutido en este libro.
Figura 10-7. Perfiles
<<modelo>>
Aprendiendo UML
<<perfil>>
Administración del Proyecto
2008/06/18 195/195

ISW512 Act 04 GM 04 UML v1.2

Cargado por

Información del documento

Título original

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

ISW512 Act 04 GM 04 UML v1.2

Cargado por

Copyright:

Formatos disponibles

Consorcio de Universidades©

Guía Metodológica de UML

Control De Versiones Sección Introducción a UML

Nombre del Archivo Versión Fecha Autor Comentarios

Índice del Documento

Parte I.- Fundamentos........................................................................................... 12

2 Introducción a UML ........................................................................................ 12

2.1 Que es UML?................................................................................................ 12

2.1.1 Los tres aspectos de UML ......................................................................... 12

2.1.2 Metas y Alcances....................................................................................... 14

2.2 UML y los Procesos ...................................................................................... 16

2.2.1 Aplicando un Ciclo de Vida en Cascada .................................................... 17

2.2.2 Aplicando un Ciclo de Vida Iterativo .......................................................... 17

2.3 Aprendiendo UML......................................................................................... 18

3 Modelado Orientado a Objetos ...................................................................... 20

3.1 Requerimientos para el manejo del sistema. ................................................ 20

3.2 Alfabetos, Palabras y Sentencias ................................................................. 21

3.2.3 Sentencias ................................................................................................. 22

3.3 El Paradigma de la Orientación a Objetos .................................................... 24

3.3.2 Principios ................................................................................................... 29

3.4 Párrafos ........................................................................................................ 31

3.4.1 Modelado de Estructura............................................................................. 32

3.4.2 Modelado de Comportamiento................................................................... 39

3.4.3 Otros elementos ........................................................................................ 47

3.5 Secciones ..................................................................................................... 48

Parte II.- Modelado de la Estructura...................................................................... 51

4 Diagramas de Clase y Objetos....................................................................... 51

4.1 Clases y objetos ........................................................................................... 51

4.1.2 Objetos ...................................................................................................... 64

4.2 Asociaciones y ligas ..................................................................................... 67

4.2.2 Clases de la Asociación............................................................................. 69

4.2.3 Extremos De la Asociación ........................................................................ 70

4.2.4 Vínculos ..................................................................................................... 78

4.2.5 Objetos Del Vinculo ................................................................................... 80

4.2.6 Extremos Del Vínculo ................................................................................ 80

4.3 Tipos, Clases e Interfaces de Implementación ............................................. 85

4.3.1 Tipos .......................................................................................................... 85

4.3.2 Clases de Implementación......................................................................... 86

4.3.3 Interfaces ................................................................................................... 87

4.4 Generalizaciones, Realizaciones y Dependencias ....................................... 89

4.4.1 Generalizaciones ....................................................................................... 89

4.4.2 clases indiferenciadas................................................................................ 90

4.4.3 Realizaciones ............................................................................................ 93

4.5 Paquetes y Subsistemas .............................................................................. 99

4.5.2 Subsistemas ............................................................................................ 102

5 Diagramas de Caso de Uso ......................................................................... 107

5.1 Actores........................................................................................................ 108

5.2 Casos de uso.............................................................................................. 110

5.3 Asociaciones de Comunicación .................................................................. 114

5.4 Dependencias............................................................................................. 116

5.4.1 Dependencias incluidas ........................................................................... 116

5.4.2 Dependencias Extendidas ....................................................................... 118

5.5 Generalizaciones ........................................................................................ 122

5.5.1 Generalizaciones de actores ................................................................... 122

5.5.2 Generalizaciones de Caso-uso................................................................ 124

6 Diagramas de Componentes y de Deployment............................................ 127

6.1 Componentes ............................................................................................. 127

6.2 Nodos ......................................................................................................... 130

6.3 Dependencias............................................................................................. 132

6.3.1 Dependencias Residentes ....................................................................... 132

6.3.2 Dependencias de Uso.............................................................................. 134

6.3.3 Dependencias de Despliegue .................................................................. 135

6.4 Asociaciones de Comunicación .................................................................. 136