UML Distilled 3rd Ed (001-043) .En - Es

Traducido del inglés al español - www.onlinedoctranslator.
com
1/118
FPRÓLOGO A LAtterceromiDICIÓN................................................. ................................................. .................................4
FPRÓLOGO A LAFPRIMEROmiDICIÓN................................................. ................................................. ................................ 5
PAGREVESTIR DE NUEVO................................................. ................................................. ................................................. ....................5
¿Por qué molestarse con UML?................................................ ................................................. ..........................................6
Estructura del libro................................................. ................................................. .................................................7
Cambios para la tercera edición................................................ ................................................. ....................................7
Agradecimientos ................................................ ................................................. ................................................. .7
DIAGRAMAS................................................. ................................................. ................................................. .................10
CCAPÍTULO1. yoNTRODUCCIÓN................................................. ................................................. ........................................14
¿Qué es el UML?................................................ ................................................. ................................................. ....14
Dónde obtener más información ................................................ ................................................. .........................................14
Formas de utilizar UML ................................................ ................................................. ................................................15
Cómo llegamos al UML................................................ ................................................. ................................................18
Notaciones y metamodelos................................................ ................................................. ........................................20
Diagramas UML................................................. ................................................. ................................................. ......21
¿Qué es UML legal?................................................ ................................................. .................................................23
El significado de UML................................................ ................................................. ................................................24
UML no es suficiente................................................ ................................................. .................................................24
Por dónde empezar con UML................................................ ................................................. ........................................25
CCAPÍTULO2.DDESARROLLOPAGROCESO................................................. ................................................. ........................26
Procesos iterativos y en cascada................................................ ................................................. ............................26
Planificación predictiva y adaptativa................................................ ................................................. ............................28
Procesos ágiles................................................ ................................................. ................................................. ....29
Proceso racional unificado............................................... ................................................. ........................................30
Adaptación de un proceso a un proyecto.................................... ................................................. ....................................30
Adaptación del UML a un proceso ................................................ ................................................. .................................32
Elegir un proceso de desarrollo................................................ ................................................. ..........................35
CCAPÍTULO3.cMUCHACHADIAGRAMAS:TÉLmiESENCIALES................................................. ................................................. .......35
Propiedades................................................. ................................................. ................................................. .............36
Cuándo utilizar diagramas de clases ......................................... ................................................. .................................38
Multiplicidad................................................. ................................................. ................................................. .............38
Interpretación de propiedades en programación ................................................ ................................................. ..............39
Asociaciones bidireccionales................................................ ................................................. ........................................41
Operaciones................................................. ................................................. ................................................. ............42
Generalización................................................. ................................................. ................................................. ......43
Notas y comentarios ................................................. ................................................. .................................................44
Dependencia................................................. ................................................. ................................................. .........44
Reglas de restricción................................................ ................................................. ................................................. ...46
CCAPÍTULO4.SEQUENCIADIAGRAMAS................................................. ................................................. ................................ 47
Crear y eliminar participantes................................................ ................................................. ..........................50
Bucles, condicionales y similares................................................. ................................................. ................................51
Llamadas síncronas y asíncronas................................................ ................................................. ...................54
Cuándo utilizar diagramas de secuencia................................................ ................................................. .........................54
CCAPÍTULO5.CMUCHACHADIAGRAMAS: AAVANZADOCONCEPTOS................................................. ................................................56
Palabras clave ................................................. ................................................. ................................................. .............56
Clasificación y generalización................................................. ................................................. .........................57
Clasificación múltiple y dinámica................................................ ................................................. ........................57
Clase de asociación................................................ ................................................. ................................................. .58
Clase de plantilla (parametrizada)................................................. ................................................. ................................61
Enumeraciones................................................. ................................................. ................................................. .......62
Clase activa ................................................. ................................................. ................................................. ..........63
Visibilidad ................................................. ................................................. ................................................. ................63
Mensajes................................................ ................................................. ................................................. .............64
Responsabilidades................................................. ................................................. ................................................. ....64
Operaciones estáticas y atributos................................................ ................................................. ................................sesenta y cinco
Agregación y composición................................................ ................................................. ................................sesenta y cinco
Propiedades derivadas................................................ ................................................. .................................................66
Interfaces y clases abstractas................................................ ................................................. ................................67
Sólo lectura y congelado................................................ ................................................. ................................................70
Objetos de referencia y objetos de valor................................................ ................................................. ....................70
Asociaciones calificadas................................................ ................................................. ................................................71
CCAPÍTULO6. OhOBJETODIAGRAMAS................................................. ................................................. ................................ 72
2/118
Cuándo utilizar diagramas de objetos.................................... ................................................. .................................72
CCAPÍTULO7.PAGREGARDIAGRAMAS................................................. ................................................. .................................73
Paquetes y dependencias................................................ ................................................. .................................74
Aspectos del paquete................................................ ................................................. ................................................. ..76
Paquetes de implementación................................................ ................................................. ........................................76
Cuándo utilizar diagramas de paquetes................................................ ................................................. .................................77
CCAPÍTULO8.DEMPLEODIAGRAMAS................................................. ................................................. .........................78
Cuándo utilizar diagramas de implementación................................................. ................................................. ........................79
CCAPÍTULO9. tuSECASES................................................. ................................................. .................................................79
Contenido de un caso de uso.................................... ................................................. ................................................80
Diagramas de casos de uso .................................. ................................................. ................................................81
Niveles de casos de uso ................................................ ................................................. ................................................82
Casos de uso y características (o historias) ................................. ................................................. .........................82
Cuándo utilizar casos de uso.................................... ................................................. .........................................83
CCAPÍTULO10.STATEMETROAQUINADIAGRAMAS................................................. ................................................. .................83
Actividades internas ................................................ ................................................. ................................................. ..85
Estados de actividad ................................................ ................................................. ................................................. .......85
Superestados................................................ ................................................. ................................................. ..........86
Estados concurrentes................................................ ................................................. ................................................. .86
Implementación de diagramas de estados................................................ ................................................. ................................87
Cuándo utilizar diagramas de estados................................................ ................................................. ...................................89
CCAPÍTULO11. UnACTIVIDADDIAGRAMAS................................................. ................................................. ................................89
Descomponer una acción................................................ ................................................. ..........................................91
Y hay más................................................ ................................................. ................................................. ..93
Cuándo utilizar diagramas de actividades................................................ ................................................. ................................93
Particiones ................................................. ................................................. ................................................. ..............93
Señales................................................ ................................................. ................................................. .................94
Fichas................................................ ................................................. ................................................. .................95
Flujos y bordes................................................ ................................................. ................................................. ...96
Pines y transformaciones................................................ ................................................. .........................................96
Regiones de expansión................................................ ................................................. ................................................97
Flujo final................................................ ................................................. ................................................. ..............98
Especificaciones de unión................................................ ................................................. .................................................99
CCAPÍTULO12.cCOMUNICACIÓNDIAGRAMAS................................................. ................................................. ...............100
Cuándo utilizar diagramas de comunicación................................................ ................................................. ................101
CCAPÍTULO13.cOPUESTOSESTRUCTURAS................................................. ................................................. ...................101
Cuándo utilizar estructuras compuestas................................................. ................................................. .........................103
CCAPÍTULO14.cOMPONENTEDIAGRAMAS................................................. ................................................. ........................103
Cuándo utilizar diagramas de componentes ......................................... ................................................. ........................105
CCAPÍTULO15.cCOLABORACIONES................................................. ................................................. .................................105
Cuándo utilizar colaboraciones................................................ ................................................. .................................107
CCAPÍTULO16. yoINTERACCIÓNohRESEÑADIAGRAMAS................................................. ................................................. .... 107
Cuándo utilizar diagramas de descripción general de interacción ................................. ................................................. ........108
CCAPÍTULO17.TIMINGDIAGRAMAS................................................. ................................................. .................................109
Cuándo utilizar diagramas de tiempos................................................ ................................................. .................................110
AAPÉNDICECCAMBIA ENTREUMLVERSIONES................................................. ................................................. ........ 110
Revisiones del UML................................................ ................................................. .................................................110
Cambios en UML destilados................................................ ................................................. .........................................111
Cambios de UML 1.0 a 1.1 ................................................ ................................................. .................................112
Cambios de UML 1.2 (y 1.1) a 1.3 (y 1.5).................... ................................................. .........113
Cambios de UML 1.3 a 1.4 ................................................ ................................................. .................................114
Cambios desde UML 1.4. a 1,5 ................................................. ................................................. ............................114
De UML 1.x a UML 2.0................................... ................................................. ..........................................114
BIBLIOGRAFÍA................................................. ................................................. ................................................. ......... 116
3/118
Prólogo a la tercera edición
Desde la antigüedad, los arquitectos más talentosos y los diseñadores más talentosos conocen la ley de la
parsimonia. Ya sea que se exprese como una paradoja ("menos es más") o un koan ("la mente zen es la mente de
principiante"), su sabiduría es eterna: reducir todo a su esencia para que la forma armonice con la función. Desde
las pirámides hasta la Ópera de Sydney, desde las arquitecturas de von Neumann hasta UNIX y Smalltalk, los
mejores arquitectos y diseñadores se han esforzado por seguir este principio universal y eterno.
Reconociendo el valor de afeitarme con la navaja de Occam, cuando hago arquitectura y leo busco proyectos y
libros que se adhieran a la ley de la parsimonia. En consecuencia, aplaudo el libro que estás leyendo ahora.
Puede que al principio le sorprenda mi último comentario. Con frecuencia se me asocia con las voluminosas y densas
especificaciones que definen el Lenguaje Unificado de Modelado (UML). Estas especificaciones permiten a los
proveedores de herramientas implementar UML y a los metodólogos aplicarlo. Durante siete años, he presidido grandes
equipos de estandarización internacionales para especificar UML 1.1 y UML 2.0, así como varias revisiones menores en el
medio. Durante este tiempo, UML ha madurado en expresividad y precisión, pero también ha añadido complejidad
gratuita como resultado del proceso de estandarización. Lamentablemente, los procesos de estandarización son más
conocidos por los compromisos de diseño por comité que por la elegancia parsimoniosa.
¿Qué puede aprender un experto en UML familiarizado con las minucias misteriosas de la especificación de la
destilación de UML 2.0 que hace Martin? Bastante, al igual que tú. Para empezar, Martin reduce hábilmente un
lenguaje amplio y complejo a un subconjunto pragmático que ha demostrado ser eficaz en su práctica. Se ha
resistido a la ruta fácil de agregar páginas adicionales a la última edición de su libro. A medida que el lenguaje
creció, Martin se mantuvo fiel a su objetivo de buscar la "fracción de UML que es más útil" y decirle precisamente
eso. La fracción a la que se refiere es el mítico 20 por ciento de UML que te ayuda a hacer el 80 por ciento de tu
trabajo. ¡Capturar y domesticar a esta escurridiza bestia no es un logro fácil!
Es aún más impresionante que Martin logre este objetivo mientras escribe en un estilo conversacional maravillosamente
atractivo. Al compartir sus opiniones y anécdotas con nosotros, hace que la lectura de este libro sea divertida y nos recuerda
que la arquitectura y el diseño de sistemas deben ser a la vez creativos y productivos. Si seguimos el koan de la parsimonia en
toda su extensión, deberíamos encontrar que los proyectos de modelado UML son tan divertidos como las clases de pintura
con los dedos y de dibujo en la escuela primaria. UML debería ser un pararrayos para nuestra creatividad, así como un láser
para especificar con precisión planos de sistemas para que terceros puedan ofertar y construir esos sistemas. Esta última es la
prueba de fuego para cualquier lenguaje de modelo genuino.
Así que, si bien este puede ser un libro pequeño, no es trivial. Puede aprender tanto del enfoque de Martin
sobre el modelado como de sus explicaciones de UML 2.0.
Disfruté trabajando con Martin para mejorar la selección y corrección de las características del lenguaje UML 2.0
explicadas en esta revisión. Necesitamos tener presente que todas las lenguas vivas, tanto naturales como sintéticas,
deben evolucionar o perecer. Las elecciones de Martin sobre nuevas características, junto con sus preferencias y las de
otros profesionales, son una parte crucial del proceso de revisión de UML. Mantienen la lengua vital y la ayudan a
evolucionar mediante la selección natural en el mercado.
Queda mucho trabajo desafiante antes de que el desarrollo impulsado por modelos se generalice, pero me alientan libros
como este que explican claramente los conceptos básicos del modelado UML y los aplican de manera pragmática. Espero que
aprenda de ello como lo he hecho yo y que utilice sus nuevos conocimientos para mejorar sus propias prácticas de modelado
de software.
cris kobryn
Presidente, tecnólogo jefe del equipo de presentación
UML 2.0 de U2 Partners, Telelogic
4/118
Prólogo a la primera edición
Cuando comenzamos a diseñar el Lenguaje Unificado de Modelado, esperábamos poder producir un medio
estándar para expresar el diseño que no sólo reflejara las mejores prácticas de la industria, sino que también
ayudara a desmitificar el proceso de modelado de sistemas de software. Creíamos que la disponibilidad de un
lenguaje de modelado estándar alentaría a más desarrolladores a modelar sus sistemas de software antes de
construirlos. La adopción rápida y generalizada de UML demuestra que los beneficios del modelado son bien
conocidos por la comunidad de desarrolladores.
La creación del UML fue en sí misma un proceso iterativo e incremental muy similar al modelado de un gran
sistema de software. El resultado final es un estándar construido sobre, y que refleja, las muchas ideas y
contribuciones realizadas por numerosos individuos y empresas de la comunidad de objetos. Comenzamos el
esfuerzo de UML, pero muchos otros ayudaron a llevarlo a una conclusión exitosa; estamos agradecidos por su
contribución.
Crear y acordar un lenguaje de modelado estándar es un desafío importante en sí mismo. Educar a la comunidad
de desarrollo y presentar UML de una manera que sea accesible y en el contexto del proceso de desarrollo de
software también es un desafío importante. En este libro engañosamente breve, actualizado para reflejar los
cambios más recientes en UML, Martin Fowler ha superado con creces este desafío.
En un estilo claro y amigable, Martin no sólo presenta los aspectos clave de UML, sino que también demuestra
claramente el papel que desempeña UML en el proceso de desarrollo. A lo largo del camino, recibimos abundantes
conocimientos y sabiduría sobre modelado extraídos de los más de 12 años de experiencia en diseño y modelado de
Martin.
El resultado es un libro que ha introducido UML a miles de desarrolladores, despertando su apetito por
explorar más a fondo los numerosos beneficios del modelado con este lenguaje de modelado ahora
estándar.
Recomendamos el libro a cualquier modelador o desarrollador interesado en echar un primer vistazo a UML y obtener
una perspectiva sobre el papel clave que desempeña en el proceso de desarrollo.
Grady Booch
Ivar Jacobson
James Rumbaugh
Prefacio
He tenido suerte en muchos sentidos en mi vida; Uno de mis grandes golpes de fortuna fue estar en el lugar correcto y
con el conocimiento adecuado para escribir la primera edición de este libro en 1997. En aquel entonces, el caótico
mundo del modelado orientado a objetos (OO) apenas comenzaba a unificarse bajo el Sistema Unificado. Lenguaje de
modelado (UML). Desde entonces, UML se ha convertido en el estándar para el modelado gráfico de software, no sólo
de objetos. Mi fortuna es que este libro ha sido el más popular sobre UML, vendiendo más de un cuarto de millón de
copias.
Bueno, eso es muy bueno para mí, pero ¿deberías comprar este libro?
Me gusta recalcar que este es un libro breve. No pretende brindarle detalles sobre cada faceta de UML, que ha
crecido y crecido a lo largo de los años. Mi intención es encontrar esa fracción del UML que sea más útil y decirles
precisamente eso. Aunque un libro más grande ofrece más detalles, también lleva más tiempo leerlo. Y tu tiempo
es la mayor inversión que harás en un libro. Al mantener este libro pequeño, he dedicado tiempo a seleccionar las
mejores partes para evitar que tengas que hacer esa selección tú mismo. (Lamentablemente, ser más pequeño no
significa proporcionalmente más barato; producir un libro técnico de calidad conlleva un cierto costo fijo).
5/118
Una razón para tener este libro es comenzar a aprender sobre UML. Dado que se trata de un libro breve,
rápidamente se pondrá al día con los conceptos básicos de UML. Con eso en su haber, puede entrar en más
detalles sobre el UML con los libros más grandes, como elGuía del usuario[Booch, usuario de UML] o el Manual
de referencia[Rumbaugh, Referencia UML].
Este libro también puede actuar como una referencia útil para las partes más comunes de UML. Aunque el
libro no cubre todo, es mucho más liviano de llevar que la mayoría de los otros libros UML.
También es un libro obstinado. Llevo mucho tiempo trabajando con objetos y tengo ideas definidas sobre lo que
funciona y lo que no. Cualquier libro refleja las opiniones del autor y no intento ocultar la mía. Entonces, si está
buscando algo que tenga un toque de objetividad, es posible que desee probar otra cosa.
Aunque mucha gente me ha dicho que este libro es una buena introducción a los objetos, no lo escribí con eso
en mente. Si buscas una introducción al diseño OO, te sugiero el libro de Craig Larman [Larman].
Muchas personas interesadas en UML están utilizando herramientas. Este libro se concentra en el uso estándar y
convencional de UML y no entra en detalles sobre lo que admiten varias herramientas. Aunque UML resolvió la
torre de Babel de notaciones anteriores a UML, persisten muchas diferencias molestas entre lo que las
herramientas muestran y permiten al dibujar diagramas UML.
No digo mucho en este libro sobre arquitectura basada en modelos (MDA). Aunque mucha gente considera
que los dos son lo mismo, muchos desarrolladores utilizan UML sin estar interesados en MDA. Si desea
obtener más información sobre MDA, primero comenzaría con este libro para obtener una descripción general
de UML y luego pasaría a un libro que sea más específico sobre MDA.
Aunque el punto principal de este libro es el UML, también he añadido fragmentos de otro material sobre
técnicas, como las tarjetas CRC, que son valiosas para el diseño OO. UML es sólo una parte de lo que necesitas
para tener éxito con los objetos y creo que es importante presentarte algunas otras técnicas.
En un libro breve como este, es imposible entrar en detalles sobre cómo se relaciona UML con el código fuente,
particularmente porque no existe una forma estándar de establecer esa correspondencia. Sin embargo, sí señalo
técnicas de codificación comunes para implementar partes de UML. Mis ejemplos de código están en Java y C#, ya
que descubrí que estos lenguajes suelen ser los más comprendidos. No asuma que prefiero esos idiomas; ¡He
hecho demasiado Smalltalk para eso!
¿Por qué molestarse con UML?
Las notaciones de diseño gráfico llevan un tiempo con nosotros. Para mí, su valor principal está en la
comunicación y la comprensión. Un buen diagrama a menudo puede ayudar a comunicar ideas sobre un diseño,
especialmente cuando se desea evitar muchos detalles. Los diagramas también pueden ayudarle a comprender
un sistema de software o un proceso empresarial. Como parte de un equipo que intenta descubrir algo, los
diagramas ayudan a comprender y comunicar esa comprensión a todo el equipo. Aunque no son, al menos
todavía, un sustituto de los lenguajes de programación textual, son un asistente útil.
Mucha gente cree que en el futuro las técnicas gráficas desempeñarán un papel dominante en el desarrollo
de software. Soy más escéptico al respecto, pero ciertamente es útil tener una idea de lo que estas notaciones
pueden y no pueden hacer.
De estas notaciones gráficas, la importancia de UML proviene de su amplio uso y estandarización dentro de
la comunidad de desarrollo OO. UML se ha convertido no sólo en la notación gráfica dominante dentro del
mundo OO sino también en una técnica popular en círculos no OO.
6/118
Estructura del libro
Capítulo 1 ofrece una introducción al UML: qué es, los diferentes significados que tiene para diferentes
personas y de dónde viene.
Capitulo 2 habla sobre el proceso de software. Aunque esto es estrictamente independiente del UML, creo que es
esencial entender el proceso para poder ver el contexto de algo como el UML. En particular, es importante
comprender el papel del desarrollo iterativo, que ha sido el enfoque subyacente del proceso para la mayor parte
de la comunidad OO.
He organizado el resto del libro en torno a los tipos de diagramas dentro de UML.Capítulos 3 y4 Analice las dos
partes más útiles de UML: diagramas de clases (núcleo) y diagramas de secuencia. Aunque este libro es breve,
creo que se puede aprovechar al máximo el UML utilizando las técnicas de las que hablo en estos capítulos. El
UML es una bestia grande y en crecimiento, pero no es necesario todo.
Capítulo 5 detalla las partes menos esenciales pero aún útiles de los diagramas de clases.Capítulos 6 a través de8
describir tres diagramas útiles que arrojan más luz sobre elestructurade un sistema: diagramas de objetos,
diagramas de paquetes y diagramas de implementación.
Capítulos 9 a través de11 mostrar tres útiles másconductualtécnicas: casos de uso, diagramas de estado (aunque oficialmente
se conocen como diagramas de máquina de estados, generalmente se les llama diagramas de estado) y diagramas de
actividad.Capítulos 12 a través de17 son muy breves y cubren diagramas que generalmente son menos importantes, por lo que
para estos, solo proporcioné un ejemplo rápido y una explicación.
Las portadas interiores resumen las partes más útiles de la notación. Muchas veces he oído decir a la gente que
estas portadas son la parte más valiosa del libro. Probablemente le resultará útil consultarlos mientras lee
algunas de las otras partes del libro.
Cambios para la tercera edición

Si tiene ediciones anteriores de este libro, probablemente se esté preguntando qué es diferente y, lo que es
más importante, si debería comprar la nueva edición.
El principal desencadenante de la tercera edición fue la aparición de UML 2. UML 2 ha añadido muchas cosas nuevas,
incluidos varios tipos de diagramas nuevos. Incluso los diagramas familiares tienen muchas notaciones nuevas, como
los marcos de interacción en los diagramas de secuencia. Si desea estar al tanto de lo que sucedió pero no quiere
profundizar en las especificaciones (¡ciertamente no lo recomiendo!), este libro debería brindarle una buena descripción
general.
También aproveché esta oportunidad para reescribir completamente la mayor parte del libro, actualizando el texto y
los ejemplos. He incorporado mucho de lo que aprendí al enseñar y usar UML durante los últimos cinco años. Entonces,
aunque el espíritu de este libro UML ultradelgado está intacto, la mayoría de las palabras son nuevas.
A lo largo de los años, he trabajado duro para mantener este libro lo más actualizado posible. A medida que UML ha ido
experimentando cambios, he hecho todo lo posible para mantener el ritmo. Este libro se basa en los borradores de UML 2 que fueron
aceptados por el comité correspondiente en junio de 2003. Es poco probable que se produzcan más cambios entre esa votación y
votaciones más formales, por lo que siento que UML 2 ahora es lo suficientemente estable como para que mi revisión se realice. en
impresión. Publicaré información sobre cualquier actualización adicional en mi sitio web.
(http://martinfowler.com ).
Expresiones de gratitud
7/118
A lo largo de muchos años, muchas personas han sido parte del éxito de este libro. Mi primer agradecimiento es
para Carter Shanklin y Kendall Scott. Carter fue el editor de Addison-Wesley que me sugirió este libro. Kendall
Scott me ayudó a armar las dos primeras ediciones, trabajando en el texto y los gráficos. Entre ellos, lograron lo
imposible al publicar la primera edición en un tiempo increíblemente corto, manteniendo al mismo tiempo la alta
calidad que la gente espera de Addison-Wesley. También siguieron impulsando cambios durante los primeros
días de UML, cuando nada parecía estable.
Jim Odell ha sido mi mentor y guía durante gran parte de la primera parte de mi carrera. También ha estado
profundamente involucrado en las cuestiones técnicas y personales de hacer que los metodólogos obstinados
resuelvan sus diferencias y acepten un estándar común. Su contribución a este libro es profunda y difícil de
medir, y apuesto a que es lo mismo para UML también.
El UML es una criatura de estándares, pero soy alérgico a los organismos de estándares. Entonces, para saber
qué está pasando, necesito una red de espías que puedan mantenerme informado sobre todas las
maquinaciones de los comités. Sin estos espías, incluidos Conrad Bock, Steve Cook, Cris Kobryn, Jim Odell, Guus
Ramackers y Jim Rumbaugh, estaría hundido. Todos me han dado consejos útiles y respondido preguntas
estúpidas.
Grady Booch, Ivar Jacobson y Jim Rumbaugh son conocidos como los Tres Amigos. A pesar de las bromas
divertidas que les he dado a lo largo de los años, me han brindado mucho apoyo y aliento con este libro. Nunca
olvides que mis golpes generalmente surgen de un cariñoso aprecio.
Los críticos son la clave para la calidad de un libro y aprendí de Carter que nunca hay demasiados críticos. Los
revisores de las ediciones anteriores de este libro fueron Simmi Kochhar Bhargava, Grady Booch, Eric Evans, Tom
Hadfield, Ivar Jacobson, Ronald E. Jeffries, Joshua Kerievsky, Helen Klein, Jim Odell, Jim Rumbaugh y Vivek Salgar.
La tercera edición también contó con un excelente grupo de críticos:
Conrado Bock Craig Larman
Andy Carmichael Steve Mellor
Alistair Cockburn Jim Odell
Steve Cook Alan O'Callaghan
Lucas Hohmann Guus Ramackers
Pavel Hrubý Jim Rumbaugh
Jon Kern Tim Seltzer
cris kobryn
Todos estos revisores dedicaron tiempo a leer el manuscrito y cada uno de ellos encontró al menos un aullido
vergonzoso. Mi más sincero agradecimiento a todos ellos. Cualquier aullador que quede es enteramente mi
responsabilidad. Publicaré una hoja de erratas en la sección de libros demartinfowler.com cuando los encuentro.
El equipo central que diseñó y escribió la especificación UML está formado por Don Baisley, Morgan Björkander,
Conrad Bock, Steve Cook, Philippe Desfray, Nathan Dykman, Anders Ek, David Frankel, Eran Gery, Øystein
Haugen, Sridhar Iyengar, Cris Kobryn, Birger Møller. Pedersen, James Odell, Gunnar Övergaard, Karin Palmkvist,
Guus Ramackers, Jim Rumbaugh, Bran Selic, Thomas Weigert y Larry Williams. Sin ellos no tendría nada sobre
qué escribir.
Pavel Hruby desarrolló algunas excelentes plantillas de Visio que uso mucho para diagramas UML; puedes
conseguirlos enhttp://phruby.com .
Mucha gente se ha puesto en contacto conmigo por la Red y personalmente para hacerme sugerencias, dudas y
señalar errores. No he podido seguirles la pista a todos, pero mi agradecimiento no es menos sincero.
8/118
La gente de mi librería técnica favorita, SoftPro en Burlington, Massachusetts, me dejó pasar muchas horas allí
mirando sus existencias para descubrir cómo la gente usa UML en la práctica y me dieron un buen café mientras
estuve allí.
Para la tercera edición, el editor de adquisiciones fue Mike Hendrickson. Kim Arney Mulcahy dirigió el proyecto,
además de realizar el diseño y la limpieza de los diagramas. John Fuller, de Addison-Wesley, fue el editor de
producción, mientras que Evelyn Pyle y Rebecca Rider ayudaron con la corrección y corrección del libro. Les
agradezco a todos.
Cindy se ha quedado conmigo mientras yo persisto en escribir libros. Luego planta las ganancias en el
jardín.
Mis padres me empezaron con una buena educación, de la que surge todo lo demás.
Martín Fowler
Melrose (Massachusetts)
http://martinfowler.com
9/118
Diagramas
10/118
11/118
12/118
13/118
Capítulo 1 Introducción
¿Qué es el UML?
Formas de utilizar el UML
Cómo llegamos al UML
Notaciones y metamodelos
Diagramas UML
¿Qué es UML legal?
El significado de UML
UML no es suficiente
Por dónde empezar con UML
Dónde encontrar más información
¿Qué es el UML?
El Lenguaje Unificado de Modelado (UML) es una familia de notaciones gráficas, respaldadas por un metamodelo único,
que ayudan a describir y diseñar sistemas de software, particularmente sistemas de software construidos utilizando el
estilo orientado a objetos (OO). Esa es una definición algo simplificada. De hecho, UML es algo diferente para diferentes
personas. Esto proviene tanto de su propia historia como de las diferentes opiniones que tiene la gente sobre lo que
constituye un proceso de ingeniería de software eficaz. Como resultado, mi tarea en gran parte de este capítulo es
preparar el escenario para este libro explicando las diferentes maneras en que la gente ve y usa UML.
Los lenguajes de modelado gráfico existen en la industria del software desde hace mucho tiempo. El factor fundamental detrás
de todos ellos es que los lenguajes de programación no tienen un nivel de abstracción lo suficientemente alto como para
facilitar las discusiones sobre diseño.
A pesar de que los lenguajes de modelado gráfico existen desde hace mucho tiempo, existe una enorme
controversia en la industria del software sobre su papel. Estas disputas influyen directamente en cómo la gente
percibe el papel del propio UML.
UML es un estándar relativamente abierto, controlado por Object Management Group (OMG), un consorcio
abierto de empresas. El OMG se formó para crear estándares que respaldaran la interoperabilidad,
específicamente la interoperabilidad de sistemas orientados a objetos. El OMG es quizás mejor conocido por los
estándares CORBA (Common Object Request Broker Architecture).
El UML nació de la unificación de muchos lenguajes de modelado gráfico orientados a objetos que prosperaron a
finales de los 80 y principios de los 90. Desde su aparición en 1997, ha relegado a la historia aquella particular torre de
Babel. Ese es un servicio por el que yo y muchos otros desarrolladores estamos profundamente agradecidos.
14/118
Este libro no es una referencia completa y definitiva a UML, y mucho menos al análisis y diseño de OO. Hay muchas palabras
ahí fuera y muchas cosas que valen la pena leer. Mientras hablo de los temas individuales, también menciono otros libros a los
que deberías consultar para obtener información más detallada. A continuación se muestran algunos libros generales sobre
UML y diseño orientado a objetos.
Como ocurre con todas las recomendaciones de libros, es posible que deba comprobar para qué versión de UML están
escritos. Hasta junio de 2003, ningún libro publicado utiliza UML 2.0, lo cual no es sorprendente, ya que la tinta apenas
está seca en el estándar. Los libros que sugiero son buenos libros, pero no puedo decir si se actualizarán al estándar
UML 2 ni cuándo.
Si eres nuevo en el mundo de los objetos, te recomiendo mi libro introductorio favorito actual: [Larman]. Vale la
pena seguir el fuerte enfoque de diseño impulsado por la responsabilidad del autor.
Para obtener información concluyente sobre UML, debe consultar los documentos de estándares oficiales; pero
recuerde, están escritos para metodólogos que den su consentimiento en la privacidad de sus propios cubículos. Para
obtener una versión mucho más digerible del estándar, consulte [Rumbaugh, UML Reference].
Para obtener consejos más detallados sobre el diseño orientado a objetos, aprenderá muchas cosas buenas de [Martin].
También te sugiero que leas libros sobre patrones para obtener material que te llevará más allá de lo básico. Ahora
que la guerra de métodos ha terminado, los patrones (página 27) son donde aparece la mayor parte del material
interesante sobre análisis y diseño.
Formas de utilizar el UML

En el centro del papel de UML en el desarrollo de software están las diferentes formas en que la gente quiere
usarlo, diferencias que se mantienen con otros lenguajes de modelado gráfico. Estas diferencias dan lugar a
largas y difíciles discusiones sobre cómo debería utilizarse UML.
Para desenredar esto, Steve Mellor y yo creamos de forma independiente una caracterización de los tres modos en los
que la gente usa UML: boceto, plano y lenguaje de programación. Con diferencia, el más común de los tres, al menos
desde mi punto de vista parcial, esUML como boceto. En este uso, los desarrolladores utilizan UML para ayudar a
comunicar algunos aspectos de un sistema. Al igual que con los planos, puede utilizar bocetos en una dirección de
ingeniería avanzada o de ingeniería inversa.ingeniería avanzadadibuja un diagrama UML antes de escribir código,
mientrasIngeniería inversaconstruye un diagrama UML a partir del código existente para ayudar a comprenderlo.
La esencia del dibujo es la selectividad. Con el boceto avanzado, usted resume algunos problemas del código que
está a punto de escribir y, por lo general, los discute con un grupo de personas de su equipo. Tu objetivo es
utilizar los bocetos para ayudar a comunicar ideas y alternativas sobre lo que estás a punto de hacer. No hablas
de todo el código en el que vas a trabajar, solo temas importantes que deseas analizar primero con tus colegas o
secciones del diseño que deseas visualizar antes de comenzar a programar. Sesiones como ésta pueden ser muy
cortas: una sesión de 10 minutos para discutir unas horas de programación o un día para discutir una iteración
de 2 semanas.
Con la ingeniería inversa, se utilizan bocetos para explicar cómo funciona alguna parte de un sistema. No muestra todas las
clases, simplemente aquellas que son interesantes y de las que vale la pena hablar antes de profundizar en el código.
Dado que dibujar es bastante informal y dinámico, es necesario hacerlo de forma rápida y colaborativa, por lo que un medio
común es una pizarra. Los bocetos también son útiles en los documentos, en cuyo caso el foco es la comunicación más que la
integridad. Las herramientas utilizadas para dibujar son herramientas de dibujo livianas y, a menudo, las personas no son
demasiado exigentes a la hora de cumplir con todas las reglas estrictas de UML. La mayoría de los diagramas UML que se
muestran en libros, como mis otros libros, son bocetos. Su énfasis está en la comunicación selectiva más que en la
especificación completa.
15/118
A diferencia de,UML como modelose trata de integridad. En ingeniería avanzada, la idea es que los planos sean
desarrollados por un diseñador cuyo trabajo es construir un diseño detallado para que un programador lo codifique.
Ese diseño debe ser lo suficientemente completo en el sentido de que se exponen todas las decisiones de diseño y el
programador debe poder seguirlo como una actividad bastante sencilla que requiere poca reflexión. El diseñador puede
ser la misma persona que el programador, pero normalmente el diseñador es un desarrollador de mayor rango que
diseña para un equipo de programadores. La inspiración para este enfoque son otras formas de ingeniería en las que
ingenieros profesionales crean dibujos de ingeniería que se entregan a las empresas constructoras para que los
construyan.
Se pueden utilizar planos para todos los detalles, o un diseñador puede dibujar planos para un área en particular. Un
enfoque común es que un diseñador desarrolle modelos a nivel de plano en cuanto a interfaces de subsistemas, pero
luego permita que los desarrolladores resuelvan los detalles de la implementación de esos detalles.
En ingeniería inversa, los planos tienen como objetivo transmitir información detallada sobre el código, ya sea en documentos
en papel o como un navegador gráfico interactivo. Los planos pueden mostrar todos los detalles de una clase en una forma
gráfica que sea más fácil de entender para los desarrolladores.
Los planos requieren herramientas mucho más sofisticadas que los bocetos para poder manejar los detalles necesarios
para la tarea. Las herramientas especializadas CASE (ingeniería de software asistida por computadora) entran en esta
categoría, aunque el término CASE se ha convertido en una mala palabra y los proveedores intentan evitarlo ahora. Las
herramientas de ingeniería avanzada admiten el dibujo de diagramas y lo respaldan con un repositorio para almacenar la
información. Las herramientas de ingeniería inversa leen el código fuente, lo interpretan en el repositorio y generan
diagramas. Las herramientas que pueden realizar ingeniería directa e inversa como esta se denominanida y vuelta
herramientas.
Algunas herramientas utilizan el propio código fuente como repositorio y utilizan diagramas como ventana gráfica del código. Estas
herramientas se relacionan mucho más estrechamente con la programación y, a menudo, se integran directamente con los editores
de programación. Me gusta pensar en estos comotripleherramientas.
La línea entre planos y bocetos es algo borrosa, pero creo que la distinción se basa en el hecho de que los bocetos son
deliberadamente incompletos y resaltan información importante, mientras que los planos pretenden ser completos, a
menudo con el objetivo de reducir la programación a un nivel simple y bastante razonable. actividad mecánica. En
pocas palabras, diría que los bocetos son exploratorios, mientras que los planos son definitivos.
A medida que se hace más y más en UML y la programación se vuelve cada vez más mecánica, se vuelve obvio
que la programación debe automatizarse. De hecho, muchas herramientas CASE realizan algún tipo de
generación de código, lo que automatiza la construcción de una parte importante de un sistema. Sin embargo,
eventualmente llega al punto en el que todo el sistema se puede especificar en el UML y llega a UML como
lenguaje de programación. En este entorno, los desarrolladores dibujan diagramas UML que se compilan
directamente en código ejecutable y el UML se convierte en el código fuente. Obviamente, este uso de UML
exige herramientas particularmente sofisticadas. (Además, las nociones de ingeniería directa e inversa no tienen
ningún sentido para este modo, ya que UML y el código fuente son lo mismo).
Arquitectura basada en modelos y UML ejecutable
Cuando la gente habla de UML, también suele hablar deArquitectura basada en modelos (MDA)
[Kleppe et al.]. Básicamente, MDA es un enfoque estándar para utilizar UML como lenguaje de
programación; el estándar está controlado por OMG, al igual que UML. Al producir un entorno de
modelado que cumpla con la MDA, los proveedores pueden crear modelos que también puedan
funcionar con otros entornos compatibles con la MDA.
A menudo se habla de MDA al mismo tiempo que de UML porque MDA utiliza UML como su
lenguaje de modelado básico. Pero, por supuesto, no es necesario utilizar MDA para utilizar UML.
MDA divide el trabajo de desarrollo en dos áreas principales. Los modeladores representan una aplicación
particular creando unModelo independiente de plataforma(PIM). El PIM es un modelo UML independiente de
cualquier tecnología en particular. Luego, las herramientas pueden convertir un PIM en un Modelo específico de
plataforma(PSM). El PSM es un modelo de sistema dirigido a un objetivo específico.
16/118
entorno de ejecución. Luego, otras herramientas toman el PSM y generan código para esa
plataforma. El PSM podría ser UML pero no tiene por qué serlo.
Entonces, si desea crear un sistema de almacenamiento utilizando MDA, debe comenzar creando un PIM único de
su sistema de almacenamiento. Si luego quisiera que este sistema de almacenamiento se ejecutara en J2EE y .NET,
utilizaría algunas herramientas del proveedor para crear dos PSM: uno para cada plataforma. Luego, otras
herramientas generarían código para las dos plataformas.
Si el proceso de pasar del PIM al PSM al código final está completamente automatizado, tenemos el
UML como lenguaje de programación. Si alguno de los pasos es manual, tenemos planos.
Steve Mellor ha estado activo durante mucho tiempo en este tipo de trabajo y recientemente ha utilizado el
término UML ejecutable[Mellor y Balcer]. El UML ejecutable es similar a MDA pero utiliza términos ligeramente
diferentes. De manera similar, se comienza con un modelo independiente de la plataforma que es equivalente al
PIM de MDA. Sin embargo, el siguiente paso es utilizar un compilador de modelos para convertir ese modelo UML
en un sistema implementable en un solo paso; por lo tanto, no es necesario el PSM. como el término compilador
sugiere, este paso es completamente automático.
Los compiladores de modelos se basan en arquetipos reutilizables. Unarquetipodescribe cómo tomar

un modelo UML ejecutable y convertirlo en una plataforma de programación particular. Entonces,
para el ejemplo de almacenamiento, compraría un compilador de modelos y dos arquetipos (J2EE
y .NET). Ejecute cada arquetipo en su modelo UML ejecutable y tendrá sus dos versiones del sistema
de almacenamiento.
El UML ejecutable no utiliza el estándar UML completo; Muchas construcciones de UML se consideran
innecesarias y, por lo tanto, no se utilizan. Como resultado, el UML ejecutable es más simple que el UML
completo.
Todo esto suena bien, pero ¿qué tan realista es? En mi opinión, aquí hay dos cuestiones. Primero está
la cuestión de las herramientas: si son lo suficientemente maduras para hacer el trabajo. Esto es algo
que cambia con el tiempo; ciertamente, mientras escribo esto, no se usan mucho y no los he visto
mucho en acción.
Una cuestión más fundamental es la noción general de UML como lenguaje de programación. En mi opinión,
vale la pena usar UML como lenguaje de programación sólo si resulta en algo que sea significativamente
más productivo que usar otro lenguaje de programación. No estoy convencido de que lo sea, según varios
entornos de desarrollo gráfico con los que he trabajado en el pasado. Incluso si es más productivo, todavía
necesita conseguir una masa crítica de usuarios para convertirse en algo común. Ese es un gran obstáculo
en sí mismo. Como muchos antiguos Smalltalkers, considero que Smalltalk es mucho más productivo que
los lenguajes convencionales actuales. Pero como Smalltalk ahora es sólo un lenguaje de nicho, no veo
muchos proyectos que lo utilicen. Para evitar el destino de Smalltalk, el UML tiene que tener más suerte,
incluso si es superior.
Una de las cuestiones interesantes en torno al UML como lenguaje de programación es cómo modelar la lógica
del comportamiento. UML 2 ofrece tres formas de modelado de comportamiento: diagramas de interacción,
diagramas de estado y diagramas de actividad. Todos tienen sus defensores para la programación. Si UML gana
popularidad como lenguaje de programación, será interesante ver cuál de estas técnicas tiene éxito.
Otra forma en que la gente ve el UML es el rango entre su uso para modelado conceptual y de software. La mayoría
de la gente está familiarizada con el UML utilizado para el modelado de software. En esto perspectiva del software,
los elementos del UML se asignan de forma bastante directa a elementos de un sistema de software. Como
veremos, el mapeo no es en absoluto prescriptivo, pero cuando utilizamos UML, estamos hablando de elementos de
software.
Con elperspectiva conceptual, el UML representa una descripción de los conceptos de un dominio de estudio.
Aquí, no estamos hablando tanto de elementos de software como de construir un vocabulario para hablar sobre
un dominio en particular.
17/118
No existen reglas estrictas sobre la perspectiva; Resulta que existe una gama de usos bastante amplia. Algunas
herramientas convierten automáticamente el código fuente en diagramas UML, tratando el UML como una vista
alternativa del código fuente. Esa es en gran medida una perspectiva de software. Si utiliza diagramas UML para intentar
comprender los diversos significados de los términosgrupo de activoscon un grupo de contadores, estás en un estado
de ánimo mucho más conceptual.
En ediciones anteriores de este libro, dividí la perspectiva del software en especificación (interfaz) e
implementación. En la práctica, descubrí que era demasiado difícil trazar una línea precisa entre los dos, por lo
que creo que ya no vale la pena preocuparse por la distinción. Sin embargo, siempre me inclino a enfatizar la
interfaz más que la implementación en mis diagramas.
Estas diferentes formas de utilizar UML dan lugar a una serie de argumentos sobre lo que significan los
diagramas UML y cuál es su relación con el resto del mundo. En particular, afecta la relación entre UML y el
código fuente. Algunas personas opinan que UML debería usarse para crear un diseño que sea independiente
del lenguaje de programación que se use para la implementación. Otros creen que el diseño independiente del
lenguaje es un oxímoron, con un fuerte énfasis en lo idiota.
Otra diferencia de puntos de vista es cuál es la esencia de UML. En mi opinión, la mayoría de los usuarios de UML,
particularmente los dibujantes, ven la esencia de UML en los diagramas. Sin embargo, los creadores del UML ven los
diagramas como algo secundario; La esencia del UML es el metamodelo. Los diagramas son simplemente una
presentación del metamodelo. Esta visión también tiene sentido para los diseñadores de planos y los usuarios del
lenguaje de programación UML.
Entonces, siempre que leas algo relacionado con UML, es importante comprender el punto de vista del autor.
Sólo entonces se podrán entender los argumentos, a menudo feroces, que fomenta el UML.
Dicho todo esto, debo dejar claros mis prejuicios. Casi todo el tiempo, uso UML como bocetos. Encuentro que
los bocetos UML son útiles con ingeniería directa e inversa y tanto en la perspectiva conceptual como de
software.
No soy un fanático de los planos detallados de ingeniería avanzada; Creo que es demasiado difícil hacerlo bien y
ralentiza el esfuerzo de desarrollo. La creación de planos a un nivel de interfaces de subsistema es razonable, pero
incluso entonces debería esperar cambiar esas interfaces a medida que los desarrolladores implementen las
interacciones en toda la interfaz. El valor de los planos de ingeniería inversa depende de cómo funciona la herramienta.
Si se utiliza como navegador dinámico, puede resultar muy útil; si genera un documento grande, lo único que hace es
matar árboles.
Veo el UML como lenguaje de programación como una buena idea, pero dudo que alguna vez tenga un uso significativo. No
estoy convencido de que las formas gráficas sean más productivas que las textuales para la mayoría de las tareas de
programación y que incluso si lo fueran, es muy difícil que un lenguaje sea ampliamente aceptado.
Como resultado de mis prejuicios, este libro se centra mucho más en el uso de UML para dibujar. Afortunadamente,
esto tiene sentido para una guía breve. No puedo hacer justicia a UML en sus otros modos en un libro de este tamaño,
pero un libro de este tamaño es una buena introducción a otros libros que sí pueden hacerlo. Entonces, si está
interesado en UML en sus otros modos, le sugiero que trate este libro como una introducción y pase a otros libros
cuando los necesite. Si sólo le interesan los bocetos, este libro puede ser todo lo que necesita.
Cómo llegamos al UML

Lo admito, soy un aficionado a la historia. Mi idea favorita de lectura ligera es un buen libro de historia. Pero
también sé que no todo el mundo tiene la idea de diversión. Hablo de historia aquí porque creo que, en muchos
sentidos, es difícil entender dónde está el UML sin comprender la historia de cómo llegó hasta aquí.
18/118
En la década de 1980, los objetos comenzaron a alejarse de los laboratorios de investigación y dieron sus primeros pasos
hacia el mundo "real". Smalltalk se estabilizó hasta convertirse en una plataforma que la gente podía usar y nació C++. En ese
momento, varias personas empezaron a pensar en lenguajes de diseño gráfico orientados a objetos.
Los libros clave sobre lenguajes de modelado gráfico orientados a objetos aparecieron entre 1988 y 1992. Entre
las figuras destacadas se encuentran Grady Booch [Booch, OOAD]; Peter Coad [Coad, OOA], [Coad, OOD]; Ivar
Jacobson (Objeción) [Jacobson, OOSE]; Jim Odell [Odell]; Jim Rumbaugh (OMT) [Rumbaugh, ideas], [Rumbaugh,
OMT]; Sally Shlaer y Steve Mellor [Shlaer y Mellor, datos], [Shlaer y Mellor, estados]; y Rebecca Wirfs-Brock
(Diseño impulsado por la responsabilidad) [Wirfs-Brock].
Cada uno de esos autores lideraba ahora informalmente un grupo de profesionales a quienes les gustaban esas ideas.
Todos estos métodos eran muy similares, pero contenían una serie de diferencias menores, a menudo molestas, entre
ellos. Los mismos conceptos básicos aparecían en notaciones muy diferentes, lo que causaba confusión a mis clientes.
Durante esa época agitada, se hablaba tanto de la estandarización como de se ignoraba. Un equipo del OMG
intentó estudiar la estandarización, pero sólo recibió una carta abierta de protesta de todos los metodólogos
clave. (Esto me recuerda un viejo chiste. Pregunta: ¿Cuál es la diferencia entre un metodólogo y un
terrorista? Respuesta: Se puede negociar con un terrorista).
El evento catastrófico que inició el UML fue cuando Jim Rumbaugh dejó GE para unirse a Grady Booch en
Rational (ahora parte de IBM). La alianza Booch/Rumbaugh fue vista desde el principio como una alianza que
podría conseguir una masa crítica de cuota de mercado. Grady y Jim proclamaron que "la guerra de métodos ha
terminado y la ganamos", básicamente declarando que iban a lograr la estandarización "al estilo Microsoft".
Varios otros metodólogos sugirieron formar una coalición anti-Booch.
Para OOPSLA '95, Grady y Jim habían preparado su primera descripción pública de su método fusionado: la
versión 0.8 delMétodo unificadodocumentación. Aún más significativo, anunciaron que Rational Software había
comprado Objectory y que, por lo tanto, Ivar Jacobson se uniría al equipo de Unified. Rational celebró una fiesta
muy concurrida para celebrar el lanzamiento del borrador 0.8. (Lo más destacado de la fiesta fue la primera
exhibición pública del canto de Jim Rumbaugh; todos esperamos que sea también la última).
El año siguiente surgió un proceso más abierto. El OMG, que en su mayor parte se había mantenido al margen, ahora
asumió un papel activo. Rational tuvo que incorporar las ideas de Ivar y también pasó tiempo con otros socios. Más
importante aún, el OMG decidió asumir un papel importante.
En este punto, es importante comprender por qué OMG se involucró. A los metodólogos, al igual que a los autores de libros,
les gusta pensar que son importantes. Pero no creo que el Dios mío pueda siquiera escuchar los gritos de los autores de libros.
Lo que involucró al OMG fueron los gritos de los proveedores de herramientas, todos los cuales estaban asustados de que un
estándar controlado por Rational le diera a las herramientas de Rational una ventaja competitiva injusta. Como resultado, los
proveedores animaron a OMG a hacer algo al respecto, bajo el lema de interoperabilidad de herramientas CASE. Esta pancarta
era importante, ya que OMG tenía que ver con la interoperabilidad. La idea era crear un UML que permitiera a las
herramientas CASE intercambiar modelos libremente.
Mary Loomis y Jim Odell presidieron el grupo de trabajo inicial. Odell dejó claro que estaba dispuesto a renunciar
a su método por una norma, pero que no quería una norma impuesta por la Racionalidad. En enero de 1997,
varias organizaciones presentaron propuestas para una norma de métodos para facilitar el intercambio de
modelos. Rational colaboró con varias otras organizaciones y lanzó la versión 1.0 de la documentación UML
como su propuesta, el primer animal que responde al nombre Unified Modeling Language.
Luego siguió un breve período de tensión mientras se fusionaban las diversas propuestas. OMG adoptó el 1.1
resultante como estándar oficial de OMG. Posteriormente se hicieron algunas revisiones. La revisión 1.2 fue
completamente cosmética. La revisión 1.3 fue más significativa. La revisión 1.4 agregó una serie de conceptos
detallados sobre componentes y perfiles. La revisión 1.5 agregó semántica de acción.
Cuando la gente habla de UML, atribuye principalmente a Grady Booch, Ivar Jacobson y Jim Rumbaugh como sus
creadores. Generalmente se les conoce como los Tres Amigos, aunque a los bromistas les gusta
19/118
suelte la primera sílaba de la segunda palabra. Aunque se les atribuye el mayor crédito por el UML, creo que es
algo injusto darles el crédito dominante. La notación UML se formó por primera vez en el Método Unificado
Booch/Rumbaugh. Desde entonces, gran parte del trabajo ha sido dirigido por comités de OMG. Durante estas
últimas etapas, Jim Rumbaugh es el único de los tres que ha asumido un compromiso importante. Mi opinión es
que son estos miembros del proceso del comité UML los que merecen el crédito principal por el UML.
Notaciones y metamodelos
El UML, en su estado actual, define una notación y un metamodelo. Elnotaciónson los elementos gráficos que
ves en los modelos; es la sintaxis gráfica del lenguaje de modelado. Por ejemplo, la notación de diagrama de
clases define cómo se representan elementos y conceptos, como clase, asociación y multiplicidad.
Por supuesto, esto lleva a la pregunta de qué se entiende exactamente por asociación o multiplicidad o incluso
por clase. El uso común sugiere algunas definiciones informales, pero mucha gente quiere más rigor que eso.
La idea de especificaciones rigurosas y lenguajes de diseño prevalece más en el campo de los métodos formales. En
tales técnicas, los diseños y especificaciones se representan utilizando alguna derivada del cálculo de predicados.
Estas definiciones son matemáticamente rigurosas y no permiten ambigüedades. Sin embargo, el valor de estas
definiciones no es de ninguna manera universal. Incluso si se puede demostrar que un programa satisface una
especificación matemática, no hay forma de demostrar que la especificación matemática cumple con los requisitos
reales del sistema.
La mayoría de los lenguajes de modelado gráfico tienen muy poco rigor; su notación apela a la intuición más
que a una definición formal. En conjunto, esto no parece haber causado mucho daño. Estos métodos pueden
ser informales, pero muchas personas todavía los encuentran útiles, y lo que cuenta es la utilidad.
Sin embargo, los metodólogos buscan formas de mejorar el rigor de los métodos sin sacrificar su utilidad. Una
forma de hacerlo es definir unmetamodelo:un diagrama, generalmente un diagrama de clases, que define los
conceptos del lenguaje.
Figura 1.1 , una pequeña parte del metamodelo UML, muestra la relación entre características. (El extracto
está ahí para darle una idea de cómo son los metamodelos. Ni siquiera voy a intentar explicarlo).
Figura 1.1. Una pequeña parte del metamodelo UML
20/118
¿Cuánto afecta el metamodelo a un usuario de la notación de modelado? La respuesta depende principalmente del
modo de uso. A un dibujante normalmente no le importa demasiado; un blueprinter debería preocuparse un poco más.
Es de vital importancia para quienes utilizan UML como lenguaje de programación, ya que define la sintaxis abstracta de
ese lenguaje.
Muchas de las personas que participan en el desarrollo actual de UML están interesadas principalmente en el
metamodelo, particularmente porque es importante para el uso de UML y un lenguaje de programación. Las
cuestiones de notación suelen ocupar un segundo lugar, lo cual es importante tener en cuenta si alguna vez
intenta familiarizarse con los documentos de estándares en sí.
A medida que profundiza en el uso más detallado de UML, se da cuenta de que necesita mucho más que la
notación gráfica. Por eso las herramientas UML son tan complejas.
No soy riguroso en este libro. Prefiero el camino de los métodos tradicionales y apelo principalmente a tu
intuición. Eso es natural para un libro pequeño como este, escrito por un autor que se inclina principalmente por el
uso de bocetos. Si quieres más rigor, deberías recurrir a tomos más detallados.
Diagramas UML
UML 2 describe 13 tipos de diagramas oficiales enumerados enTabla 1.1 y clasificado como se indica enFigura 1.2 .
Aunque estos tipos de diagramas son la forma en que muchas personas abordan UML y cómo he organizado este
libro, los autores de UML no ven los diagramas como la parte central de UML. Como resultado, los tipos de
diagramas no son particularmente rígidos. A menudo, puedes utilizar legalmente elementos de un tipo de diagrama
en otro diagrama. El estándar UML indica que ciertos elementos normalmente se dibujan en ciertos tipos de
diagramas, pero esto no es una prescripción.
Figura 1.2. Clasificación de tipos de diagramas UML
21/118
Tabla 1.1. Tipos de diagramas oficiales de UML
Libro
Diagrama Capítulos Objetivo Linaje
Actividad 11 Comportamiento procedimental y En UML 1
Clase 3, 5 paralelo Clase, características y relaciones En UML 1
Comunicación 12 Interacción entre objetos; énfasis en los Colaboración UML 1
enlaces diagrama
Componente 14 Estructura y conexiones de En UML 1

componentes.
Compuesto 13 Descomposición en tiempo de ejecución de una clase. Nuevo en UML 2
estructura
Despliegue 8 Implementación de artefactos en nodos. En UML 1
22/118
Tabla 1.1. Tipos de diagramas oficiales de UML
Libro
Diagrama Capítulos Objetivo Linaje
Interacción dieciséis Combinación de diagrama de secuencia y actividad. Nuevo en UML 2
descripción general
Objeto 6 Configuraciones de ejemplo de instancias Extraoficialmente en UML 1
Paquete 7 Estructura jerárquica en tiempo de compilación Extraoficialmente en UML 1
Secuencia 4 Interacción entre objetos; énfasis en la En UML 1

secuencia
Máquina estatal 10 Cómo los eventos cambian un objeto a lo largo de su vida En UML 1
Momento 17 Interacción entre objetos; énfasis en el Nuevo en UML 2

tiempo
Caso de uso 9 Cómo interactúan los usuarios con un sistema En UML 1
¿Qué es UML legal?

A primera vista, esta debería ser una pregunta sencilla de responder: UML legal es lo que se define como bien
formado en la especificación. En la práctica, sin embargo, la respuesta es un poco más complicada.
Una parte importante de esta pregunta es si UML tiene reglas descriptivas o prescriptivas. un idioma conreglas
prescriptivasestá controlado por un organismo oficial que establece lo que es o no legal en el idioma y qué significado
se le da a las expresiones en ese idioma. un idioma con reglas descriptivases aquel en el que se comprenden sus
reglas observando cómo la gente usa el idioma en la práctica. Los lenguajes de programación tienden a tener reglas
prescriptivas establecidas por un comité de estándares o un proveedor dominante, mientras que los lenguajes
naturales, como el inglés, tienden a tener reglas descriptivas cuyo significado está establecido por convención.
UML es un lenguaje bastante preciso, por lo que es de esperar que tenga reglas prescriptivas. Pero a menudo se
considera que UML es el software equivalente a los planos de otras disciplinas de ingeniería, y estos planos no son
notaciones prescriptivas. Ningún comité dice cuáles son los símbolos legales en un dibujo de ingeniería estructural; la
notación ha sido aceptada por convención, de manera similar a un lenguaje natural. El simple hecho de tener un
organismo de normalización tampoco es suficiente, porque es posible que la gente en el campo no siga todo lo que dice
el organismo de normalización; Pregúntenle a los franceses sobre la Académie Française. Además, el UML es tan
complejo que el estándar suele estar abierto a múltiples interpretaciones. Incluso los líderes de UML que revisaron este
libro no estarían de acuerdo con la interpretación del estándar UML.
Esta cuestión es importante tanto para mí al escribir este libro como para usted que utiliza UML. Si desea comprender
un diagrama UML, es importante darse cuenta de que comprender el estándar UML no es el panorama completo. La
gente adopta convenciones, tanto en la industria en general como dentro de un proyecto en particular. Como
resultado, aunque el estándar UML puede ser la principal fuente de información sobre UML, no puede ser la única.
Mi actitud es que, para la mayoría de la gente, UML tiene reglas descriptivas. El estándar UML es la mayor
influencia en lo que significa UML, pero no es la única. Creo que esto será particularmente cierto con UML 2, que
introduce algunas convenciones de notación que entran en conflicto con la definición de UML 1 o con el uso
convencional de UML, además de agregar aún más complejidad a UML. Por lo tanto, en este libro intento
resumir el UML tal como lo encuentro: tanto los estándares como el uso convencional. Cuando tenga que hacer
una distinción en este libro, usaré el término uso convencionalpara indicar algo que no está en el estándar pero
que creo que se usa ampliamente. Para algo que se ajuste al estándar, usaré los términosestándaronormativo.
(Normativo es el término estándar que la gente usa para referirse a una declaración que usted debe cumplir
para ser
23/118
válido en la norma. Así que UML no normativo es una forma elegante de decir que algo es estrictamente
ilegal según el estándar UML).
Cuando estás mirando un diagrama UML, debes tener en cuenta que un principio general en UML es que
cualquier información puede serreprimidopara un diagrama en particular. Esta supresión puede ocurrir de forma
general (ocultar todos los atributos) o específicamente (no mostrar estas tres clases). Por lo tanto, en un diagrama
nunca se puede inferir nada por su ausencia. Si falta una multiplicidad, no se puede inferir qué valor podría tener.
Incluso si el metamodelo UML tiene un valor predeterminado, como [1] para atributos, si no ve la información en
el diagrama, puede ser porque es el valor predeterminado o porque está suprimido.
Dicho esto, existen algunas convenciones generales, como que las propiedades multivalor sean conjuntos. En el texto,
señalaré estas convenciones predeterminadas.
Es importante no poner demasiado énfasis en tener UML legal si eres dibujante o impresor de planos. Es más
importante tener un buen diseño para su sistema, y prefiero tener un buen diseño en UML ilegal que un diseño
legal pero deficiente. Obviamente, lo bueno y lo legal es lo mejor, pero es mejor que pongas tu energía en tener
un buen diseño que preocuparte por los arcanos de UML. (Por supuesto, debes ser legal en UML como lenguaje
de programación, ¡o tu programa no se ejecutará correctamente!)
El significado de UML
Uno de los problemas incómodos de UML es que, aunque la especificación describe con gran detalle qué es UML
bien formado, no tiene mucho que decir sobre lo que significa UML fuera del mundo enrarecido del metamodelo
UML. No existe una definición formal de cómo UML se asigna a ningún lenguaje de programación en particular.
No puedes mirar un diagrama UML y decirexactamentecómo se vería el código equivalente. Sin embargo, puedes
obtener unidea aproximadade cómo se vería el código. En la práctica, eso es suficiente para ser útil. Los equipos
de desarrollo a menudo forman sus convenciones locales para estos, y necesitarás estar familiarizado con las que
se utilizan.
UML no es suficiente
Aunque UML proporciona una cantidad considerable de diagramas diversos que ayudan a definir una aplicación, de ninguna
manera es una lista completa de todos los diagramas útiles que es posible que desee utilizar. En muchos lugares, pueden
resultar útiles diferentes diagramas y no debería dudar en utilizar un diagrama que no sea UML si ningún diagrama UML se
adapta a su propósito.
Figura 1.3 , un diagrama de flujo de pantalla, muestra las distintas pantallas en una interfaz de usuario y cómo se
mueve entre ellas. He visto y usado estos diagramas de flujo de pantalla durante muchos años. Nunca he visto
más que una definición muy aproximada de lo que significan; No hay nada parecido en UML, pero me parece un
diagrama muy útil.
Figura 1.3. Un diagrama de flujo de pantalla informal para parte de la wiki.

(http://c2.com/cgi/wiki )
24/118
Tabla 1.2 muestra otro favorito: la tabla de decisiones. Las tablas de decisión son una buena manera de mostrar
condiciones lógicas complicadas. Puedes hacer esto con un diagrama de actividades, pero una vez que vas más allá de
los casos simples, la tabla es más compacta y más clara. Nuevamente, existen muchas formas de tablas de decisiones.
Tabla 1.2 divide la tabla en dos secciones: condiciones encima de la línea doble y consecuencias debajo de ella. Cada
columna muestra cómo una combinación particular de condiciones conduce a un conjunto particular de
consecuencias.
Tabla 1.2. Una mesa de decisiones

Cliente premium X X Y Y norte norte
Orden de prioridad Y norte Y norte Y norte
Orden internacional Y Y norte norte norte norte
Tarifa $150 $100 $70 $50 $80 $60

Representante de alerta • • •
Te encontrarás con varios tipos de estas cosas en varios libros. No dude en probar técnicas que le parezcan
apropiadas para su proyecto. Si funcionan bien, úsalos. Si no, deséchelos. (Este es, por supuesto, el mismo
consejo que para los diagramas UML).
Por dónde empezar con UML

Nadie, ni siquiera los creadores del UML, lo entiende ni lo utiliza en su totalidad. La mayoría de la gente utiliza un
pequeño subconjunto de UML y trabaja con él. Tienes que encontrar el subconjunto de UML que funcione para ti y
tus colegas.
Si está empezando, le sugiero que se concentre primero en las formas básicas de los diagramas de clases y los
diagramas de secuencia. Estos son los tipos de diagramas más comunes y, en mi opinión, los más útiles.
25/118
Una vez que los domine, puede comenzar a usar algunas de las notaciones de diagramas de clases más
avanzadas y echar un vistazo a los otros tipos de diagramas. Experimente con los diagramas y vea lo útiles que
le resultan. No temas dejar caer alguno que no parezca útil para tu trabajo.
Capítulo 2. Proceso de desarrollo

Como ya mencioné, UML surgió de un montón de métodos de diseño y análisis de OO. Hasta cierto punto, todos
ellos mezclaron un lenguaje de modelado gráfico con un proceso que describía cómo desarrollar software.
Curiosamente, a medida que se formó el UML, los diversos actores descubrieron que, aunque podían ponerse de acuerdo
sobre un lenguaje de modelado, ciertamente no podían ponerse de acuerdo sobre un proceso. Como resultado, acordaron
dejar cualquier acuerdo sobre el proceso para más tarde y limitar el UML a ser un lenguaje de modelado.
El título de este libro esUML destilado, por lo que podría haber ignorado el proceso con seguridad. Sin embargo, no
creo que las técnicas de modelado tengan ningún sentido sin saber cómo encajan en un proceso. La forma en que
utilice UML depende mucho del estilo de proceso que utilice.
Como resultado, creo que es importante hablar primero sobre el proceso para que puedas ver el contexto para usar
UML. No voy a entrar en grandes detalles sobre ningún proceso en particular; Simplemente quiero brindarle suficiente
información para ver este contexto y sugerencias sobre dónde puede obtener más información.
Cuando escuchas a la gente hablar sobre UML, a menudo los escuchas hablar sobre el Proceso Unificado
Racional (RUP). RUP es un proceso (o, más estrictamente, un marco de proceso) que puede utilizar con UML. Pero
aparte de la participación común de varias personas de Rational y el nombre "unificado", no tiene ninguna
relación especial con UML. El UML se puede utilizar con cualquier proceso. RUP es un enfoque popular y se
analiza en la página 25.
Procesos iterativos y en cascada

Uno de los mayores debates sobre el proceso es el que existe entre los estilos en cascada y los iterativos. Los términos a menudo se
usan mal, particularmente porque lo iterativo se considera una moda, mientras que el proceso en cascada parece usar pantalones a
cuadros. Como resultado, muchos proyectos afirman realizar un desarrollo iterativo pero en realidad lo hacen en cascada.
La diferencia esencial entre los dos es cómo se divide un proyecto en partes más pequeñas. Si tiene un proyecto
que cree que llevará un año, pocas personas se sienten cómodas diciéndole al equipo que se vaya por un año y
que regrese cuando haya terminado. Se necesita algún desglose para que las personas puedan abordar el
problema y seguir el progreso.
ElcascadaEl estilo desglosa un proyecto basado en la actividad. Para crear software, es necesario realizar ciertas actividades:
análisis de requisitos, diseño, codificación y pruebas. Por lo tanto, nuestro proyecto de 1 año podría tener una fase de análisis
de 2 meses, seguida de una fase de diseño de 4 meses, seguida de una fase de codificación de 3 meses, seguida de una fase
de prueba de 3 meses.
EliterativoEl estilo divide un proyecto en subconjuntos de funcionalidad. Podrías tomarte un año y dividirlo en
iteraciones de 3 meses. En la primera iteración, tomaría una cuarta parte de los requisitos y realizaría el ciclo de
vida completo del software para ese trimestre: análisis, diseño, código y prueba. Al final de la primera iteración,
tendría un sistema que realiza una cuarta parte de la funcionalidad necesaria. Luego harías una segunda
iteración para que al final de 6 meses tengas un sistema que haga la mitad de la funcionalidad.
26/118
Por supuesto, lo anterior es una descripción simplificada, pero es la esencia de la diferencia. En la práctica, por
supuesto, algunas impurezas se filtran en el proceso.
Con el desarrollo en cascada, generalmente hay algún tipo de transferencia formal entre cada fase, pero a
menudo hay contraflujos. Durante la codificación, puede surgir algo que le haga revisar el análisis y el diseño.
Ciertamente no debes asumir que todo el diseño está terminado cuando comienza la codificación. Es inevitable
que las decisiones de análisis y diseño deban revisarse en fases posteriores. Sin embargo, estos reflujos son
excepciones y deben minimizarse tanto como sea posible.
Con la iteración, normalmente se ve algún tipo de actividad de exploración antes de que comiencen las verdaderas
iteraciones. Como mínimo, esto obtendrá una vista de alto nivel de los requisitos: al menos lo suficiente para dividir los
requisitos en las iteraciones que seguirán. También pueden ocurrir algunas decisiones de diseño de alto nivel durante
la exploración. En el otro extremo, aunque cada iteración debería producir software integrado listo para producción, a
menudo no llega a ese punto y necesita un período de estabilización para solucionar los últimos errores. Además,
algunas actividades, como la formación de usuarios, se dejan para el final.
Es posible que no ponga el sistema en producción al final de cada iteración, pero el sistema debe tener calidad de
producción. Sin embargo, a menudo es posible poner el sistema en producción a intervalos regulares; Esto es
bueno porque obtienes valor del sistema antes y obtienes comentarios de mejor calidad. En esta situación, a
menudo se oye hablar de un proyecto que tiene múltipleslanzamientos, cada uno de los cuales se divide en
variositeraciones.
El desarrollo iterativo ha recibido muchos nombres: me vienen a la mente incremental, espiral, evolutivo y
jacuzzi. Varias personas hacen distinciones entre ellos, pero las distinciones no están ampliamente aceptadas ni
son tan importantes en comparación con la dicotomía iterativo/cascada.
Puedes tener enfoques híbridos. [McConnell] describe elentrega por etapasCiclo de vida en el que el análisis y el diseño
de alto nivel se realizan primero, en forma de cascada, y luego la codificación y las pruebas se dividen en iteraciones. Un
proyecto de este tipo podría tener cuatro meses de análisis y diseño seguidos de cuatro compilaciones iterativas del
sistema de dos meses de duración.
A la mayoría de los escritores sobre procesos de software de los últimos años, especialmente en la comunidad
orientada a objetos, no les gusta el enfoque en cascada. De las muchas razones para esto, la más fundamental es
que es muy difícil decir si el proyecto realmente va por buen camino con un proceso en cascada. Es demasiado
fácil cantar victoria en las primeras fases y ocultar un error en el calendario. Por lo general, la única manera de
saber realmente si va por buen camino es producir software integrado y probado. Al hacer esto repetidamente,
un estilo iterativo le avisará mejor si algo va mal.
Sólo por esa razón, recomiendo encarecidamente que los proyectos no utilicen un enfoque puramente en cascada. Al
menos debería utilizar la entrega por etapas, si no una técnica iterativa más pura.
La comunidad OO ha estado a favor del desarrollo iterativo durante mucho tiempo, y es seguro decir que casi todos los
involucrados en la construcción de UML están a favor de al menos alguna forma de desarrollo iterativo. Sin embargo,
mi percepción de la práctica industrial es que el desarrollo en cascada sigue siendo el enfoque más común. Una razón
para esto es lo que yo llamo desarrollo pseudoiterativo: la gente afirma estar haciendo un desarrollo iterativo pero en
realidad lo está haciendo en cascada. Los síntomas comunes de esto son:
• "Estamos haciendo una iteración de análisis seguida de dos iteraciones de diseño..."

• "El código de esta iteración tiene muchos errores, pero lo limpiaremos al final".
Es particularmente importante que cada iteración produzca un código integrado y probado que se acerque lo más
posible a la calidad de producción. Las pruebas y la integración son las actividades más difíciles de estimar, por lo que
es importante no tener una actividad abierta como esa al final del proyecto. La prueba debería ser que cualquier
iteración que no esté programada para ser lanzada pueda ser lanzada sin un trabajo de desarrollo adicional sustancial.
Una técnica común con iteraciones es usarboxeo de tiempo. Esto obliga a que una iteración tenga una duración
de tiempo fija. Si parece que no puede construir todo lo que pretendía construir durante una iteración, debe
decidir eliminar alguna funcionalidad de la iteración; no debes deslizar la fecha de la iteración.
27/118
La mayoría de los proyectos que utilizan desarrollo iterativo utilizan la misma duración de iteración en todo el proyecto; de esa
manera, obtendrás un ritmo regular de construcciones.
Me gusta el timeboxing porque la gente suele tener dificultades para deslizarse en la funcionalidad. Al practicar la función de
deslizamiento con regularidad, están en una mejor posición para tomar una decisión inteligente en un lanzamiento importante entre
deslizar una fecha y deslizar la función. La función de deslizamiento durante las iteraciones también es eficaz para ayudar a las
personas a aprender cuáles son las prioridades reales de los requisitos.
Una de las preocupaciones más comunes sobre el desarrollo iterativo es la cuestión del retrabajo. El desarrollo
iterativo asume explícitamente que volverá a trabajar y eliminará el código existente durante las iteraciones
posteriores de un proyecto. En muchos ámbitos, como el de la fabricación, el retrabajo se considera un desperdicio.
Pero el software no es como la fabricación; como resultado, a menudo es más eficiente reelaborar el código existente
que corregir el código que fue mal diseñado. Una serie de prácticas técnicas pueden ayudar enormemente a que el
retrabajo sea más eficiente.
• Pruebas de regresión automatizadasayuda permitiéndote detectar rápidamente cualquier defecto que se

haya podido introducir al cambiar cosas. La familia xUnit de marcos de prueba es una herramienta
particularmente valiosa para crear pruebas unitarias automatizadas. Comenzando con el JUnit originalhttp://
junit.org , ahora hay puertos para casi todos los idiomas imaginables (ver http://www.xprogramming.com/
software.htm ). Una buena regla general es que el tamaño de su código de prueba unitaria debe ser
aproximadamente del mismo tamaño que su código de producción.
• Refactorizaciónes una técnica disciplinada para cambiar el software existente [Fowler, refactoring]. La refactorización
funciona mediante el uso de una serie de pequeñas transformaciones en el código base que preservan el comportamiento.
Muchas de estas transformaciones se pueden automatizar (ver
http://www.refactoring.com ).
• Integración continuamantiene un equipo sincronizado para evitar ciclos de integración dolorosos [Fowler y Foemmel]. En el
centro de esto se encuentra un proceso de compilación totalmente automatizado que se puede iniciar automáticamente cada
vez que cualquier miembro del equipo ingresa el código en la base del código. Se espera que los desarrolladores se registren
diariamente, por lo que las compilaciones automatizadas se realizan muchas veces al día. El proceso de construcción incluye
la ejecución de un gran bloque de pruebas de regresión automatizadas para detectar rápidamente cualquier inconsistencia y
poder solucionarla fácilmente.
Todas estas prácticas técnicas han sido popularizadas recientemente por Extreme Programming [Beck],
aunque se usaron antes y pueden y deben usarse ya sea que use XP o cualquier otro proceso ágil o no.
Planificación predictiva y adaptativa

Una de las razones por las que la cascada perdura es el deseo de previsibilidad en el desarrollo de software. No
hay nada más frustrante que no tener una idea clara de cuánto costará crear un software y cuánto tiempo llevará
hacerlo.
Un enfoque predictivo busca trabajar en las primeras etapas del proyecto para lograr una mayor comprensión de
lo que se debe hacer más adelante. De esta manera, puede llegar a un punto en el que la última parte del
proyecto pueda estimarse con un grado razonable de precisión. Conplanificación predictiva, un proyecto tiene
dos etapas. La primera etapa presenta planes y es difícil de predecir, pero la segunda etapa es mucho más
predecible porque los planes ya están en marcha.
Este no es necesariamente un asunto en blanco y negro. A medida que avanza el proyecto, gradualmente se obtiene más
previsibilidad. E incluso una vez que tenga un plan predictivo, las cosas saldrán mal. Simplemente se espera que las
desviaciones sean menos significativas una vez que se implemente un plan sólido.
Sin embargo, existe un debate considerable sobre si muchos proyectos de software podrán llegar a ser predecibles. En
el centro de esta pregunta está el análisis de requisitos. Una de las fuentes únicas de complejidad en los proyectos de
software es la dificultad para comprender los requisitos de un sistema de software. La mayoría de los proyectos de
software experimentan importantesrotación de requisitos: cambios en los requisitos en las últimas etapas del
proyecto. Estos cambios hacen añicos los cimientos de una
28/118
plano predictivo. Puede combatir estos cambios congelando los requisitos desde el principio y no permitiendo
cambios, pero esto corre el riesgo de entregar un sistema que ya no satisfaga las necesidades de sus usuarios.
Este problema conduce a dos reacciones muy diferentes. Una ruta es poner más esfuerzo en el proceso de
requisitos en sí. De esta manera, puede obtener un conjunto de requisitos más preciso, lo que reducirá la
deserción.
Otra escuela sostiene que la rotación de requisitos es inevitable, que es demasiado difícil para muchos proyectos
estabilizar los requisitos lo suficiente como para utilizar un plan predictivo. Esto puede deberse a la enorme dificultad
de imaginar lo que el software puede hacer o a que las condiciones del mercado obligan a cambios impredecibles.
Esta escuela de pensamiento defiendeplanificación adaptativa, por lo que la predictibilidad se considera una ilusión.
En lugar de engañarnos con una previsibilidad ilusoria, deberíamos enfrentar la realidad del cambio constante y
utilizar un enfoque de planificación que trate el cambio como una constante en un proyecto de software. Este cambio
se controla para que el proyecto entregue el mejor software posible; pero aunque el proyecto es controlable, no es
predecible.
La diferencia entre un proyecto predictivo y un proyecto adaptativo surge de muchas maneras cuando la gente
habla sobre cómo va el proyecto. Cuando la gente habla de un proyecto que está funcionando bien porque va
según lo planeado, es una forma de pensamiento predictivo. No se puede decir "según el plan" en un entorno
adaptativo, porque el plan siempre está cambiando. Esto no significa que los proyectos adaptativos no
planifiquen; Por lo general, planifican mucho, pero el plan se trata como una base para evaluar las
consecuencias del cambio y no como una predicción del futuro.
Con un plan predictivo, puede desarrollar un contrato de precio fijo/alcance fijo. Un contrato de este tipo dice
exactamente qué se debe construir, cuánto costará y cuándo se entregará. Esta solución no es posible con un plan
adaptativo. Puede fijar un presupuesto y un tiempo de entrega, pero no puede fijar qué funcionalidad se entregará. Un
contrato adaptativo supone que los usuarios colaborarán con el equipo de desarrollo para reevaluar periódicamente
qué funcionalidad se debe crear y cancelarán el proyecto si el progreso termina siendo demasiado lento. Como tal, un
proceso de planificación adaptativa puede tener un precio fijo y un alcance variable.
Naturalmente, el enfoque adaptativo es menos deseable, ya que cualquiera preferiría una mayor previsibilidad
en un proyecto de software. Sin embargo, la previsibilidad depende de un conjunto de requisitos preciso, exacto
y estable. Si no puede estabilizar sus requisitos, el plan predictivo se basa en arena y hay muchas posibilidades
de que el proyecto se desvíe. Esto lleva a dos consejos importantes.
1. No haga un plan predictivo hasta que tenga requisitos precisos y exactos y esté seguro de que no
cambiarán significativamente.
2. Si no puede obtener requisitos precisos, exactos y estables, utilice un estilo de planificación adaptativo.
La predictibilidad y la adaptabilidad influyen en la elección del ciclo de vida. Un plan adaptativo requiere absolutamente un
proceso iterativo. La planificación predictiva se puede realizar de cualquier manera, aunque es más fácil ver cómo funciona
con un enfoque en cascada o de entrega por etapas.
Procesos ágiles
En los últimos años, ha habido mucho interés en los procesos de software ágiles.Ágiles un término general que
cubre muchos procesos que comparten un conjunto común de valores y principios según lo definido por el
Manifiesto de Desarrollo Ágil de Software (http://agileManifiesto.org ). Ejemplos de estos procesos son Extreme
Programming (XP), Scrum, Feature Driven Development (FDD), Crystal y DSDM (Método de desarrollo de sistemas
dinámicos).
En términos de nuestra discusión, los procesos ágiles son fuertemente adaptativos por naturaleza. También son procesos
muy orientados a las personas. Los enfoques ágiles suponen que el factor más importante para el éxito de un proyecto es la
calidad de las personas que participan en el proyecto y qué tan bien trabajan juntas en términos humanos. El proceso que
utilizan y las herramientas que utilizan son efectos estrictamente de segundo orden.
29/118
Los métodos ágiles tienden a utilizar iteraciones cortas y con plazos determinados, normalmente de un mes o menos.
Debido a que no dan mucho peso a los documentos, los enfoques ágiles desdeñan el uso de UML en modo plano. La
mayoría usa UML en modo boceto, y algunos recomiendan usarlo como lenguaje de programación.
Los procesos ágiles tienden a ser bajos enceremonia. Un proceso de alta ceremonia o de gran peso tiene muchos
documentos y puntos de control durante el proyecto. Los procesos ágiles consideran que la ceremonia dificulta la
realización de cambios y va en contra de la corriente de las personas talentosas. Como resultado, los procesos ágiles a
menudo se caracterizan comoligero. Es importante darse cuenta de que la falta de ceremonia es una consecuencia de
la adaptabilidad y la orientación de las personas más que una propiedad fundamental.
Proceso racional unificado

Aunque el Proceso Unificado Racional (RUP) es independiente del UML, a menudo se habla de ambos juntos.
Así que creo que vale la pena decir aquí algunas cosas al respecto.
Aunque a RUP se le llama proceso, en realidad es un marco de trabajo que proporciona un vocabulario y una estructura
flexible para hablar de procesos. Cuando utiliza RUP, lo primero que debe hacer es elegir uncaso de desarrollo: el
proceso que vas a utilizar en el proyecto. Los casos de desarrollo pueden variar ampliamente, así que no asuma que su
caso de desarrollo se parecerá mucho a cualquier otro caso de desarrollo. Para elegir un caso de desarrollo se necesita
desde el principio a alguien que esté muy familiarizado con RUP: alguien que pueda adaptar RUP a las necesidades de
un proyecto en particular. Alternativamente, existe un creciente conjunto de casos de desarrollo empaquetados para
empezar.
Cualquiera que sea el caso de desarrollo, RUP es esencialmente un proceso iterativo. Un estilo en cascada no es
compatible con la filosofía de RUP, aunque lamentablemente no es raro encontrarse con proyectos que utilizan un
proceso de estilo en cascada y disfrazarlo con la ropa de RUP.
Todos los proyectos RUP deben seguir cuatro fases.
1.Comienzohace una evaluación inicial de un proyecto. Por lo general, al inicio, usted decide si compromete fondos
suficientes para realizar una fase de elaboración.
2.Elaboraciónidentifica los casos de uso principales del proyecto y construye software en iteraciones para
cambiar la arquitectura del sistema. Al final de la elaboración, debes tener una buena idea de los
requisitos y un sistema de trabajo esquelético que actúa como semilla del desarrollo. En particular,
debería haber encontrado y resuelto los principales riesgos para el proyecto.
3.Construccióncontinúa el proceso de construcción, desarrollando suficiente funcionalidad para lanzar.

4.TransiciónIncluye varias actividades de última etapa que no se realizan de forma iterativa. Estos pueden incluir
implementación en el centro de datos, capacitación de usuarios y similares.
Hay bastante confusión entre las fases, especialmente entre la elaboración y la construcción. Para algunos, el
paso a la construcción es el punto en el que se puede pasar a un modo de planificación predictiva. Para otros,
simplemente indica el punto en el que tienes una visión amplia de los requisitos y una arquitectura que crees que
durará el resto del proyecto.
A veces, RUP se denomina proceso unificado (UP). Esto lo suelen hacer organizaciones que desean utilizar la
terminología y el estilo general de RUP sin utilizar los productos con licencia de Rational Software. Puede pensar
en RUP como la oferta de productos de Rational basada en UP, o puede pensar en RUP y UP como la misma cosa.
De cualquier manera, encontrarás personas que estén de acuerdo contigo.
Adaptar un proceso a un proyecto
Los proyectos de software difieren mucho entre sí. La forma en que se desarrolla software depende de muchos
factores: el tipo de sistema que se construye, la tecnología que se utiliza, el tamaño y la distribución del equipo,
la naturaleza de los riesgos, las consecuencias del fracaso, los estilos de trabajo.
30/118
del equipo y la cultura de la organización. Como resultado, nunca se debe esperar que exista un proceso único
que funcione para todos los proyectos.
En consecuencia, siempre hay que adaptar un proceso para que se ajuste a su entorno particular. Una de las
primeras cosas que debe hacer es analizar su proyecto y considerar qué procesos parecen encajar. Esto debería
brindarle una breve lista de procesos a considerar.
Luego deberías considerar qué adaptaciones necesitas hacer para adaptarlas a tu proyecto. Hay que tener algo
de cuidado con esto. Muchos procesos son difíciles de apreciar plenamente hasta que se ha trabajado con ellos.
En estos casos, a menudo vale la pena utilizar el proceso de fábrica durante un par de iteraciones hasta que
aprenda cómo funciona. Entonces puedes empezar a modificar el proceso. Si desde el principio estás más
familiarizado con cómo funciona un proceso, puedes modificarlo desde el principio. Recuerde que generalmente
es más fácil comenzar con muy poco y agregar cosas que comenzar con demasiado y quitar cosas.
Patrones
El UML le indica cómo expresar un diseño orientado a objetos. Los patrones, en cambio, miran los
resultados del proceso: diseños de ejemplo.
Mucha gente ha comentado que los proyectos tienen problemas porque las personas involucradas no
conocían diseños que son bien conocidos por quienes tienen más experiencia. Los patrones describen
formas comunes de hacer las cosas y son recopilados por personas que detectan temas repetidos en los
diseños. Estas personas toman cada tema y lo describen para que otras personas puedan leer el patrón y
ver cómo aplicarlo.
Veamos un ejemplo. Digamos que tiene algunos objetos ejecutándose en un proceso en su escritorio
y que necesitan comunicarse con otros objetos que se ejecutan en otro proceso. Quizás este proceso
también esté en tu escritorio; tal vez resida en otra parte. No desea que los objetos de su sistema
tengan que preocuparse por encontrar otros objetos en la red o ejecutar llamadas a procedimientos
remotos.
Lo que puede hacer es crear un objeto proxy dentro de su proceso local para el objeto remoto. El
proxy tiene la misma interfaz que el objeto remoto. Sus objetos locales hablan con el proxy mediante
los envíos habituales de mensajes durante el proceso. El proxy es entonces responsable de pasar
cualquier mensaje al objeto real, dondequiera que resida.
Los proxies son una técnica común utilizada en redes y otros lugares. La gente tiene mucha
experiencia en el uso de proxies, sabe cómo se pueden utilizar, qué ventajas pueden aportar, sus
limitaciones y cómo implementarlos. Los libros de métodos como este no analizan este conocimiento;
lo único que discuten es cómo se puede diagramar un proxy, aunque útil, no es tan útil como discutir
la experiencia con proxys.
A principios de la década de 1990, algunas personas comenzaron a captar esta experiencia. Formaron una
comunidad interesada en patrones de escritura. Estas personas patrocinan conferencias y han producido
varios libros.
El libro de patrones más famoso que surgió de este grupo es [Gang of Four], que analiza en detalle
23 patrones de diseño. Si desea obtener información sobre los proxies, este libro dedica diez páginas
al tema y brinda detalles sobre cómo funcionan los objetos juntos, los beneficios y limitaciones del
patrón, las variaciones comunes y los consejos de implementación.
Un patrón es mucho más que un modelo. Un patrón también debe incluir la razón por la que es como
es. Se suele decir que un patrón es la solución a un problema. El patrón debe identificar claramente el
problema, explicar por qué lo resuelve y también explicar las circunstancias bajo las cuales el patrón
funciona y no funciona.
Los patrones son importantes porque son el siguiente paso más allá de comprender los conceptos básicos
de un lenguaje o una técnica de modelado. Los patrones te dan una serie de soluciones y además
31/118
mostrarle qué hace que un modelo sea bueno y cómo se construye un modelo. Los patrones enseñan
con el ejemplo.
Cuando comencé me preguntaba por qué tenía que inventar cosas desde cero. ¿Por qué no tenía
manuales que me mostraran cómo hacer cosas comunes? La comunidad de patrones está intentando
crear estos manuales.
En la actualidad existen muchos libros de patrones y su calidad varía mucho. Mis favoritos son
[Gang of Four], [POSA1], [POSA2], [Core J2EE Patterns], [Pont], y con la adecuada inmodestia
[Fowler, AP] y [Fowler, P of EAA]. También puedes echar un vistazo a la página de inicio de patrones:
http://www.hillside.net/patterns .
Por muy seguro que esté con su proceso al comenzar, es esencial aprender a medida que avanza. De hecho, uno
de los grandes beneficios del desarrollo iterativo es que respalda la mejora frecuente de los procesos.
Al final de cada iteración, realice unaretrospectiva de iteración, mediante el cual el equipo se reúne para
considerar cómo fueron las cosas y cómo se pueden mejorar. Un par de horas es suficiente si las iteraciones
son cortas. Una buena forma de hacerlo es hacer una lista con tres categorías:
1.Mantener:Cosas que funcionaron bien y que deseas asegurarte de continuar haciendo.

2.Problemas:áreas que no están funcionando bien
3.Intentar:cambios en su proceso para mejorarlo
Puede comenzar cada iteración retrospectiva después de la primera revisando los elementos de la sesión anterior y
viendo cómo han cambiado las cosas. No olvides la lista de cosas que debes conservar; es importante realizar un
seguimiento de las cosas que funcionan. Si no lo hace, puede perder el sentido de perspectiva sobre el proyecto y
potencialmente dejar de prestar atención a las prácticas ganadoras.
Al final de un proyecto o en un lanzamiento importante, es posible que desee considerar una reunión más
formal.retrospectiva del proyectoeso durará un par de días; verhttp://www.retrospectives.com/ y [Kerth]
para más detalles. Una de mis mayores irritaciones es cómo las organizaciones constantemente no aprenden de
su propia experiencia y terminan cometiendo errores costosos una y otra vez.
Adaptar el UML a un proceso

Cuando analizan lenguajes de modelado gráfico, la gente suele pensar en ellos en el contexto de un proceso en
cascada. Un proceso en cascada generalmente tiene documentos que actúan como transferencia entre las fases de
análisis, diseño y codificación. Los modelos gráficos suelen formar una parte importante de estos documentos. De
hecho, muchos de los métodos estructurados de las décadas de 1970 y 1980 hablan mucho sobre modelos de
análisis y diseño como este.
Ya sea que utilice o no un enfoque en cascada, aún realiza las actividades de análisis, diseño, codificación y
pruebas. Puede ejecutar un proyecto iterativo con iteraciones de 1 semana, con cada semana una minicascada.
Usar UML no implica necesariamente desarrollar documentos o alimentar una herramienta CASE compleja. Mucha
gente dibuja diagramas UML en pizarras blancas sólo durante una reunión para ayudar a comunicar sus ideas.
Análisis de requerimientos
La actividad de análisis de requisitos implica tratar de descubrir qué quieren los usuarios y clientes de un
esfuerzo de software que haga el sistema. Varias técnicas UML pueden resultar útiles aquí:
• Casos de uso, que describen cómo las personas interactúan con el sistema.
• Un diagrama de clases elaborado desde la perspectiva conceptual, que puede ser una buena forma de
desarrollar un vocabulario riguroso del dominio.
32/118
• Un diagrama de actividades, que puede mostrar el flujo de trabajo de la organización, mostrando cómo interactúan el
software y las actividades humanas. Un diagrama de actividad puede mostrar el contexto de los casos de uso y también los
detalles de cómo funciona un caso de uso complicado.
• Un diagrama de estado, que puede resultar útil si un concepto tiene un ciclo de vida interesante, con varios
estados y eventos que cambian ese estado.
Cuando trabajes en análisis de requisitos, recuerda que lo más importante es la comunicación con tus usuarios y
clientes. Por lo general, no son expertos en software y no estarán familiarizados con UML o cualquier otra técnica.
Aun así, he tenido éxito al utilizar estas técnicas con personas sin conocimientos técnicos. Para ello, recuerda que
es importante mantener la notación al mínimo. No introduzca nada que sea específico de la implementación del
software.
Esté preparado para romper las reglas de UML en cualquier momento si eso le ayuda a comunicarse mejor. El mayor
riesgo al utilizar UML en el análisis es que se dibujan diagramas que los expertos en el dominio no comprenden
completamente. Un diagrama que no es comprendido por las personas que conocen el dominio es peor que inútil; lo
único que hace es generar una falsa sensación de confianza en el equipo de desarrollo.
Diseño
Cuando haces diseño, puedes volverte más técnico con tus diagramas. Puede utilizar más notación y ser
más preciso acerca de su notación. Algunas técnicas útiles son
• Diagramas de clases desde una perspectiva del software. Estos muestran las clases en el software y cómo se
interrelacionan.
• Diagramas de secuencia para escenarios comunes. Un enfoque valioso es elegir los escenarios más
importantes e interesantes de los casos de uso y utilizar tarjetas CRC o diagramas de secuencia para
descubrir qué sucede en el software.
• Diagramas de paquetes para mostrar la organización a gran escala del software.
• Diagramas de estado para clases con historias de vida complejas.
• Diagramas de implementación para mostrar el diseño físico del software.
Muchas de estas mismas técnicas se pueden utilizar para documentar el software una vez escrito. Esto puede
ayudar a las personas a orientarse en el software si tienen que trabajar en él y no están familiarizadas con el
código.
Con un ciclo de vida en cascada, harías estos diagramas y actividades como parte de las fases. Los documentos
de final de fase suelen incluir los diagramas UML adecuados para esa actividad. Un estilo en cascada
normalmente implica que el UML se utiliza como modelo.
En un estilo iterativo, los diagramas UML se pueden utilizar en un estilo de plano o boceto. Con un plano, los
diagramas de análisis generalmente se construirán en la iteración anterior a la que construye la funcionalidad.
Cada iteración no comienza desde cero; más bien, modifica el cuerpo de documentos existente, destacando los
cambios en la nueva iteración.
Los diseños de planos generalmente se realizan al principio de la iteración y se pueden realizar en partes para diferentes
partes de funcionalidad que están destinadas a la iteración. Nuevamente, la iteración implica realizar cambios en un modelo
existente en lugar de construir un modelo nuevo cada vez.
Usar UML en modo boceto implica un proceso más fluido. Un enfoque es dedicar un par de días al comienzo
de una iteración, esbozando el diseño para esa iteración. También puede realizar sesiones de diseño breves en
cualquier momento durante la iteración, organizando una reunión rápida de media hora cada vez que un
desarrollador comience a abordar una función no trivial.
Con un plano, se espera que la implementación del código siga los diagramas. Un cambio del plano es una desviación
que necesita revisión por parte de los diseñadores que hicieron el plano. Un boceto suele tratarse más como un
primer corte del diseño; Si, durante la codificación, las personas descubren que el boceto no es exactamente
correcto, deberían sentirse libres de cambiar el diseño. Los implementadores deben utilizar su criterio para
determinar si el cambio necesita una discusión más amplia para comprender todas sus ramificaciones.
33/118
Una de mis preocupaciones con los planos es mi propia observación de que es muy difícil hacerlos bien, incluso para un buen
diseñador. A menudo encuentro que mis propios diseños no sobreviven intactos al contacto con la codificación. Todavía
encuentro útiles los bocetos UML, pero no creo que puedan tratarse como absolutos.
En ambos modos, tiene sentido explorar varias alternativas de diseño. Generalmente es mejor explorar
alternativas en modo boceto para poder generar y cambiar las alternativas rápidamente. Una vez que elijas un
diseño para ejecutar, puedes usar ese boceto o detallarlo en un plano.
Documentación
Una vez que haya creado el software, puede utilizar UML para ayudar a documentar lo que ha hecho. Para ello, los
diagramas UML me resultan útiles para obtener una comprensión general de un sistema. Sin embargo, al hacer esto
debo subrayar que no creo en la necesidad de producir diagramas detallados de todo el sistema. Para citar a Ward
Cunningham [Cunningham]:
Los memorandos cuidadosamente seleccionados y bien redactados pueden sustituir fácilmente

la documentación de diseño integral tradicional. Este último rara vez brilla salvo en lugares
aislados. Eleve esos puntos. . . y olvídate del resto. (pág. 384)
Creo que se debería generar documentación detallada a partir del código, como, por ejemplo, JavaDoc. Debe
escribir documentación adicional para resaltar conceptos importantes. Piense en esto como un primer paso para
el lector antes de entrar en los detalles basados en el código. Me gusta estructurarlos como documentos en
prosa, lo suficientemente breves como para leerlos con una taza de café, utilizando diagramas UML para ayudar
a ilustrar la discusión. Prefiero los diagramas como bocetos que resaltan las partes más importantes del sistema.
Obviamente, el redactor del documento necesita decidir qué es importante y qué no, pero está mucho mejor
equipado que el lector para hacerlo.
Un diagrama de paquete constituye una buena hoja de ruta lógica del sistema. Este diagrama me ayuda a
comprender las piezas lógicas del sistema, ver las dependencias y mantenerlas bajo control. Un diagrama de
implementación (verCapítulo 8 ), que muestra la imagen física de alto nivel, también puede resultar útil en esta
etapa.
Dentro de cada paquete, me gusta ver un diagrama de clases. No muestro todas las operaciones en todas las clases. Muestro
solo las características importantes que me ayudan a comprender lo que hay allí. Este diagrama de clases actúa como una
tabla de contenidos gráfica.
El diagrama de clases debe estar respaldado por un puñado de diagramas de interacción que muestren las
interacciones más importantes en el sistema. Una vez más, la selectividad es importante aquí; Recuerde que, en
este tipo de documentos, la exhaustividad es enemiga de la comprensibilidad.
Si una clase tiene un comportamiento de ciclo de vida complejo, dibujo un diagrama de máquina de estados (verCapítulo 10 ) para
describirlo. Hago esto sólo si el comportamiento es lo suficientemente complejo, lo cual no ocurre con frecuencia.
A menudo incluyo algún código importante, escrito en un estilo de programa alfabetizado. Si se trata de un
algoritmo particularmente complejo, consideraré usar un diagrama de actividad (verCapítulo 11 ) pero solo si me
da más comprensión que el código solo.
Si encuentro conceptos que surgen repetidamente, uso patrones (página 27) para capturar las ideas básicas.
Una de las cosas más importantes que debe documentar son las alternativas de diseño que no tomó y por qué no
las hizo. Esta suele ser la documentación externa más olvidada pero más útil que puede proporcionar.
Comprender el código heredado
El UML puede ayudarle a descubrir un montón de códigos desconocidos de dos maneras. Crear un bosquejo de hechos clave
puede actuar como un mecanismo gráfico para tomar notas que le ayude a capturar información importante a medida que
la aprende. Los bocetos de las clases clave de un paquete y sus interacciones clave pueden ayudar a aclarar lo que está
sucediendo.
34/118
Con herramientas modernas, puede generar diagramas detallados para partes clave de un sistema. No utilice estas
herramientas para generar grandes informes en papel; en su lugar, utilícelos para profundizar en áreas clave mientras
explora el código en sí. Una capacidad particularmente interesante es la de generar un diagrama de secuencia para ver
cómo múltiples objetos colaboran en el manejo de un método complejo.
Elegir un proceso de desarrollo

Estoy firmemente a favor de los procesos de desarrollo iterativos. Como he dicho antes en este libro: debes
utilizar el desarrollo iterativo sólo en proyectos que quieras que tengan éxito.
Quizás eso sea un poco simplista, pero a medida que envejezco, me vuelvo más agresivo en el uso del desarrollo
iterativo. Si se hace bien, es una técnica esencial que se puede utilizar para exponer el riesgo tempranamente y
obtener un mejor control sobre el desarrollo. No es lo mismo que no tener gestión, aunque para ser justos debo
señalar que algunos lo han usado así. Es necesario que esté bien planificado. Pero es un enfoque sólido y todos
los libros sobre desarrollo OO alientan su uso, por una buena razón.
No debería sorprenderle saber que, como autor del Manifiesto para el desarrollo ágil de software, soy un gran
admirador de los enfoques ágiles. También he tenido muchas experiencias positivas con la Programación
Extrema y ciertamente deberías considerar sus prácticas muy seriamente.
Los libros sobre procesos de software siempre han sido comunes y el auge del desarrollo ágil de software ha dado lugar
a muchos libros nuevos. En general, mi libro favorito sobre el proceso en general es [McConnell]. Ofrece una cobertura
amplia y práctica de muchas de las cuestiones involucradas en el desarrollo de software y una larga lista de prácticas
útiles.
De la comunidad ágil, [Cockburn, ágil] y [Highsmith] brindan una buena descripción general. Para obtener muchos
buenos consejos sobre cómo aplicar UML de forma ágil, consulte [Ambler].
Uno de los métodos ágiles más populares es la Programación Extrema (XP), en la que puede profundizar a través
de sitios web comohttp://xprogramming.com yhttp://www.extremeprogramming.org . XP ha generado
muchos libros, por lo que ahora me refiero a él como la antigua metodología ligera. El punto de partida habitual
es [Beck].
Aunque está escrito para XP, [Beck y Fowler] brindan más detalles sobre la planificación de un proyecto iterativo.
Gran parte de esto también está cubierto en otros libros de XP, pero si solo está interesado en el aspecto de
planificación, esta sería una buena opción.
Para obtener más información sobre el Proceso Unificado Racional, mi introducción favorita es [Kruchten].
Capítulo 3. Diagramas de clases: lo esencial

Si alguien se te acercara en un callejón oscuro y te dijera: "Psst, ¿quieres ver un diagrama UML?" ese diagrama
probablemente sería un diagrama de clases. La mayoría de los diagramas UML que veo son diagramas de clases.
El diagrama de clases no sólo es ampliamente utilizado sino que también está sujeto a la mayor variedad de conceptos
de modelado. Aunque todos necesitan los elementos básicos, los conceptos avanzados se utilizan con menos frecuencia.
Por lo tanto, he dividido mi discusión sobre los diagramas de clases en dos partes: lo esencial (este capítulo) y lo
avanzado (Capítulo 5 ).
35/118
Adiagrama de claseDescribe los tipos de objetos en el sistema y los diversos tipos de relaciones estáticas que
existen entre ellos. Los diagramas de clases también muestran las propiedades y operaciones de una clase y las
restricciones que se aplican a la forma en que se conectan los objetos. El UML utiliza el término característicacomo
término general que cubre propiedades y operaciones de una clase.
Figura 3.1 muestra un modelo de clase simple que no sorprendería a nadie que haya trabajado con el
procesamiento de pedidos. Los cuadros del diagrama son clases, que se dividen en tres compartimentos: el
nombre de la clase (en negrita), sus atributos y sus operaciones.Figura 3.1 También muestra dos tipos de
relaciones entre clases: asociaciones y generalizaciones.
Figura 3.1. Un diagrama de clases simple
Propiedades
Propiedadesrepresentan características estructurales de una clase. Como primera aproximación, puede pensar que las
propiedades corresponden a campos de una clase. La realidad es bastante complicada, como veremos, pero ese es un
lugar razonable para comenzar.
Las propiedades son un concepto único, pero aparecen en dos notaciones bastante distintas: atributos y
asociaciones. Aunque parecen bastante diferentes en un diagrama, en realidad son lo mismo.
Atributos
ElatributoLa notación describe una propiedad como una línea de texto dentro del propio cuadro de clase. La forma completa
de un atributo es:
36/118
nombre de visibilidad: tipo multiplicidad = predeterminado {cadena de propiedad}
Un ejemplo de esto es:
- nombre: Cadena [1] = "Sin título" {readOnly}
Solo elnombrees necesario.
• Estevisibilidadel marcador indica si el atributo es público (+) o privado (-); Enfermo

analice otras visibilidades en la página 83.
• Elnombredel atributo (cómo la clase se refiere al atributo) corresponde aproximadamente a la
Nombre de un campo en un lenguaje de programación.
• Eltipodel atributo indica una restricción sobre qué tipo de objeto puede colocarse en el
atributo. Puedes pensar en esto como el tipo de campo en un lenguaje de programación.
• Lo explicarémultiplicidaden la página 38.
• Elvalor por defectoes el valor de un objeto recién creado si el atributo no se especifica durante la
creación.
• El{cadena de propiedad}le permite indicar propiedades adicionales para el atributo. En el ejemplo, usé{solo
lectura}para indicar que los clientes no pueden modificar la propiedad. Si falta esto, normalmente se puede
asumir que el atributo es modificable. Describiré otras cadenas de propiedades a medida que avancemos.
Asociaciones
La otra forma de registrar una propiedad es como asociación. Gran parte de la misma información que puede mostrar
en un atributo aparece en una asociación.Figuras 3.2 y3.3 muestran las mismas propiedades representadas en las dos
notaciones diferentes.
Figura 3.2. Mostrar propiedades de un pedido como atributos
Figura 3.3. Mostrar propiedades de un pedido como asociaciones
UnasociaciónEs una línea continua entre dos clases, dirigida desde la clase de origen a la clase de destino.
El nombre de la propiedad va al final de la asociación, junto con su multiplicidad. El extremo objetivo de la
asociación se vincula a la clase que es el tipo de propiedad.
37/118
Aunque la mayor parte de la misma información aparece en ambas notaciones, algunos elementos son diferentes. En
particular, las asociaciones pueden mostrar multiplicidades en ambos extremos de la línea.
Con dos notaciones para la misma cosa, la pregunta obvia es: ¿Por qué deberías usar una u otra? En general,
tiendo a utilizar atributos para cosas pequeñas, como fechas o valores booleanos (en general, tipos de valor
(página 73)) y asociaciones para clases más importantes, como clientes y pedidos. También tiendo a preferir usar
cuadros de clase para las clases que son importantes para el diagrama, lo que lleva al uso de asociaciones y
atributos para cosas menos importantes para ese diagrama. La elección tiene mucho más que ver con el énfasis
que con cualquier significado subyacente.
Cuándo utilizar diagramas de clases
Los diagramas de clases son la columna vertebral de UML, por lo que los utilizará todo el tiempo. Este capítulo
cubre los conceptos básicos;Capítulo 5 analiza muchos de los conceptos avanzados.
El problema con los diagramas de clases es que son tan ricos que su uso puede resultar abrumador. Aquí hay algunos
consejos.
• No intente utilizar todas las notaciones disponibles. Comience con las cosas simples de este capítulo:
clases, asociaciones, atributos, generalización y restricciones. Introducir otras notaciones deCapítulo 5
sólo cuando los necesitas.
• Los diagramas de clases conceptuales me parecen muy útiles para explorar el lenguaje de una empresa. Para
que esto funcione, hay que trabajar duro para mantener el software fuera de la discusión y mantener la
notación muy simple.
• No dibujes modelos para todo; en su lugar, concéntrese en las áreas clave. Es mejor tener unos cuantos
diagramas que puedas utilizar y mantener actualizados que tener muchos modelos olvidados y obsoletos.
El mayor peligro de los diagramas de clases es que puede centrarse exclusivamente en la estructura e
ignorar el comportamiento. Por lo tanto, cuando dibuje diagramas de clases para comprender el software,
hágalo siempre junto con alguna forma de técnica de comportamiento. Si te va bien, te encontrarás
cambiando entre las técnicas con frecuencia.
Todos los libros generales de UML que mencioné enCapítulo 1 Hable sobre los diagramas de clases con más detalle. La
gestión de dependencias es una característica crítica de proyectos más grandes. El mejor libro sobre este tema es [Martin].
Multiplicidad
Elmultiplicidadde una propiedad es una indicación de cuántos objetos pueden llenar la propiedad. Las
multiplicidades más comunes que verá son
• 1(Un pedido debe tener exactamente un cliente).

• 0..1(Un cliente corporativo puede tener o no un único representante de ventas).
• * (Un cliente no necesita realizar un pedido y no existe un límite superior para la cantidad de pedidos que un
cliente puede realizar (cero o más pedidos).
De manera más general, las multiplicidades se definen con un límite inferior y un límite superior, como 2..4 para los
jugadores de un juego de canasta. El límite inferior puede ser cualquier número positivo o cero; la parte superior es
38/118
cualquier número positivo o * (para ilimitado). Si los límites superior e inferior son iguales, puede utilizar un número;
por tanto, 1 es equivalente a 1...1. Debido a que es un caso común, * es la abreviatura de 0..*.
En los atributos encontramos diversos términos que hacen referencia a la multiplicidad.
• Opcionalimplica un límite inferior de 0.

• Obligatorioimplica un límite inferior de 1 o posiblemente más.
• De valor únicoimplica un límite superior de 1.
• multivalorimplica un límite superior de más de 1: normalmente *.
Si tengo una propiedad con varios valores, prefiero usar una forma plural para su nombre.
De forma predeterminada, los elementos de una multiplicidad multivaluada forman un conjunto, por lo que si le
pide a un cliente sus pedidos, no regresa en ningún orden. Si el orden de las órdenes en asociación tiene significado,
es necesario agregar{ordenado}hasta el final de la asociación. Si desea permitir duplicados, agregue
{no único}. (Si desea mostrar explícitamente el valor predeterminado, puede usar{desordenado}y{único}.)
También puede ver nombres orientados a colecciones, como{bolsa}por desordenado, no único.
UML 1 permitía multiplicidades discontinuas, como 2, 4 (es decir, 2 o 4, como en los automóviles en la
época anterior a las minivans). Las multiplicidades discontinuas no eran muy comunes y UML 2 las eliminó.
La multiplicidad predeterminada de un atributo es [1]. Aunque esto es cierto en el metamodelo, no se puede asumir que
un atributo en un diagrama al que le falta una multiplicidad tiene un valor de [1], ya que el diagrama puede estar
suprimiendo la información de multiplicidad. Como resultado, prefiero indicar explícitamente una multiplicidad [1] si es
importante.
Programación Interpretación de Propiedades

Como ocurre con cualquier otra cosa en UML, no existe una única forma de interpretar las propiedades en el código. La
representación de software más común es la de un campo o propiedad de su lenguaje de programación. Entonces la
clase Línea de Orden deFigura 3.1 correspondería a algo como lo siguiente en Java:
Línea de pedido de clase pública...

cantidad int privada;
precio del dinero privado;
orden de pedido privado;
producto privado producto
En un lenguaje como C#, que tiene propiedades, correspondería a:

público int Cantidad;
Precio del dinero público;
Orden público Orden;
Producto público Producto;
Tenga en cuenta que un atributo normalmente corresponde a propiedades públicas en un idioma que admite propiedades,
pero a campos privados en un idioma que no las admite. En un idioma sin propiedades, es posible que vea los campos
expuestos a través de métodos de acceso (obtención y configuración). Un atributo de solo lectura no tendrá ningún método
de configuración (con campos) ni acción de configuración (para propiedades). Tenga en cuenta que si no le da un nombre a
una propiedad, es común usar el nombre de la clase de destino.
El uso de campos privados es una interpretación del diagrama muy centrada en la implementación. Una interpretación más
orientada a la interfaz podría concentrarse en los métodos de obtención en lugar de en los métodos de obtención.
39/118
datos subyacentes. En este caso, podríamos ver los atributos de la Línea de Orden correspondientes a los
siguientes métodos:

cantidad int privada;
producto privado Producto; public
int obtenerCantidad() {
cantidad de devolución;
}
conjunto vacío públicoCantidad (cantidad int) {
esta.cantidad = cantidad;
}
dinero público getPrice() {
devolver producto.getPrice().multiply(cantidad);
}
En este caso, no existe ningún campo de datos para el precio; en cambio, es un valor calculado. Pero en lo que respecta a los
clientes de la clase Línea de pedido, tiene el mismo aspecto que un campo. Los clientes no pueden saber qué es un campo y
qué se calcula. Esta ocultación de información es la esencia de la encapsulación.
Si un atributo tiene varios valores, esto implica que los datos en cuestión son una colección. Entonces, una clase de Orden se
referiría a una colección de Líneas de Orden. Debido a que esta multiplicidad está ordenada, esa colección debe estar
ordenada (como una Lista en Java o una IList en .NET). Si la colección está desordenada, estrictamente no debería tener un
orden significativo y, por lo tanto, implementarse con un conjunto, pero la mayoría de las personas también implementan
atributos desordenados como listas. Algunas personas usan matrices, pero UML implica un límite superior ilimitado, por lo
que casi siempre uso una colección para la estructura de datos.
Las propiedades multivalor generan un tipo diferente de interfaz a las propiedades de un solo valor (en Java):
Orden de clase {
Conjunto privado de elementos de línea = nuevo
HashSet(); conjunto público getLineItems() {
return Collections.unmodifiableSet(lineItems);
}
addLineItem público vacío (argumento OrderItem) {
lineItems.add (arg);
}
removeLineItem público vacío (argumento OrderItem) {
lineItems.remove(arg);
}
En la mayoría de los casos, no asigna una propiedad con varios valores; en su lugar, actualiza con métodos de agregar y
eliminar. Para controlar su propiedad Elementos de línea, el pedido debe controlar la membresía de esa colección; como
resultado, no debería distribuirse la colección de desnudos. En este caso, utilicé un proxy de protección para
proporcionar un contenedor de solo lectura a la colección. También puede proporcionar un iterador no actualizable o
hacer una copia. Está bien que los clientes modifiquen los objetos miembro, pero no deberían cambiar directamente la
colección en sí.
Debido a que los atributos multivalor implican colecciones, casi nunca se ven clases de colección en un
diagrama de clases. Los mostraría sólo en diagramas de implementación de muy bajo nivel de las propias
colecciones.
Deberías tener mucho miedo de las clases que no son más que una colección de campos y sus descriptores de acceso. El diseño
orientado a objetos consiste en proporcionar objetos que sean capaces de tener un comportamiento rico, por lo que no deberían
simplemente proporcionar datos a otros objetos. Si realiza repetidas solicitudes de datos mediante el uso de descriptores de acceso, es
una señal de que algún comportamiento debe trasladarse al objeto que tiene los datos.
Estos ejemplos también refuerzan el hecho de que no existe una correspondencia estricta entre UML y el código, pero sí
una similitud. Dentro de un equipo de proyecto, las convenciones de equipo conducirán a una correspondencia más
estrecha.
40/118
Ya sea que una propiedad se implemente como un campo o como un valor calculado, representa algo que un objeto
siempre puede proporcionar. No debe usar una propiedad para modelar una relación transitoria, como un objeto
que se pasa como parámetro durante una llamada a un método y se usa solo dentro de los límites de esa interacción.
Asociaciones bidireccionales
Las asociaciones que hemos visto hasta ahora se denominan asociaciones unidireccionales. Otro tipo común de
asociación es una asociación bidireccional, comoFigura 3.4 .
Figura 3.4. Una asociación bidireccional
Una asociación bidireccional es un par de propiedades que están vinculadas entre sí como inversas. La clase Car tiene
propiedad.propietario:Persona[1], y la clase Persona tiene una propiedadcoches:Coche[*]. (Observa cómo nombré el
carrospropiedad en la forma plural del tipo de propiedad, una convención común pero no normativa).
El vínculo inverso entre ellos implica que si sigues ambas propiedades, deberías volver a un conjunto que
contiene tu punto de partida. Por ejemplo, si empiezo con un MG Midget en particular, encuentro a su dueño y
luego miro los autos de su dueño, ese conjunto debe contener el Midget desde el que comencé.
Como alternativa a etiquetar una asociación por una propiedad, a muchas personas, especialmente si tienen
experiencia en modelado de datos, les gusta etiquetar una asociación usando una frase verbal (Figura 3.5 ) para que la
relación pueda usarse en una oración. Esto es legal y puedes agregar una flecha a la asociación para evitar
ambigüedades. La mayoría de los modeladores de objetos prefieren usar un nombre de propiedad, ya que corresponde
mejor a las responsabilidades y operaciones.
Figura 3.5. Usar una frase verbal para nombrar una asociación
Algunas personas nombran cada asociación de alguna manera. Elijo nombrar una asociación sólo cuando hacerlo
mejora la comprensión. He visto demasiadas asociaciones con nombres como "tiene" o "está relacionado con".
EnFigura 3.4 , la naturaleza bidireccional de la asociación se hace evidente por laflechas de navegabilidaden
ambos extremos de la asociación.Figura 3.5 no tiene flechas; UML le permite usar este formulario ya sea para
indicar una asociación bidireccional o cuando no muestra navegabilidad. Mi preferencia es utilizar la flecha de
doble punta deFigura 3.4 cuando quieras dejar claro que tienes una asociación bidireccional.
Implementar una asociación bidireccional en un lenguaje de programación suele ser un poco complicado porque hay
que asegurarse de que ambas propiedades se mantengan sincronizadas. Usando C#, uso código similar a este para
implementar una asociación bidireccional:
coche de clase...
41/118
Propietario de persona pública {
obtener {return _owner;}
colocar {
if (_propietario! = nulo) _propietario.friendCars().Remove(this);
_propietario = valor;
if (_propietario! = nulo) _propietario.friendCars().Add(this);
}
}
Persona privada _propietario;
...
persona de clase...
coches IList públicos {
obtener {return ArrayList.ReadOnly(_cars);}
}
public void AddCar(Car arg) {
arg.Propietario = esto;
}
IList privada _cars = nueva ArrayList(); IList interna
friendCars() {
//sólo debe ser utilizado por Car.Owner return
_cars;
}
....
Lo principal es dejar que un lado de la asociación (un lado con un solo valor, si es posible) controle la relación. Para que
esto funcione, el extremo esclavo (Persona) necesita filtrar la encapsulación de sus datos al extremo maestro. Esto
agrega a la clase esclava un método incómodo, que en realidad no debería estar ahí, a menos que el lenguaje tenga un
control de acceso detallado. He usado la convención de nomenclatura de "amigo" aquí como un guiño a C++, donde el
configurador maestro sería de hecho un amigo. Como gran parte del código de propiedad, esto es bastante repetitivo,
razón por la cual muchas personas prefieren usar alguna forma de generación de código para producirlo.
En los modelos conceptuales, la navegabilidad no es una cuestión importante, por lo que no muestro ninguna flecha de navegabilidad en los
modelos conceptuales.
Operaciones
Operacionesson las acciones que una clase sabe realizar. Las operaciones corresponden más obviamente a los
métodos de una clase. Normalmente, no se muestran aquellas operaciones que simplemente manipulan propiedades,
porque normalmente se pueden inferir.
La sintaxis UML completa para operaciones es:
nombre de visibilidad (lista de parámetros): tipo de retorno {cadena de propiedad}
• Estevisibilidadel marcador es público (+) o privado (-); otros en la página 83.

• Elnombrees una cuerda.
• Ellista de parámetroses la lista de parámetros para la operación.
• Eltipo de retornoes el tipo de valor devuelto, si lo hay.
• Elcadena de propiedadindica los valores de propiedad que se aplican a la operación dada.
Los parámetros en la lista de parámetros están anotados de manera similar a los atributos. La forma es:
nombre de dirección: tipo = valor predeterminado
• Elnombre,tipo, yvalor por defectoson los mismos que para los atributos.
• Eldirecciónindica si el parámetro es de entrada (en), producción (afuera) o ambos (En fuera). Si no se
muestra ninguna dirección, se supone que esen.
42/118
Un ejemplo de operación a cuenta podría ser:
+ balanceOn (fecha: Fecha): Dinero
Con los modelos conceptuales, no debes usar operaciones para especificar la interfaz de una clase. En su lugar,
utilícelos para indicar las responsabilidades principales de esa clase, tal vez usando un par de palabras que resuman
una responsabilidad de la CDN (página 65).
A menudo encuentro útil distinguir entre operaciones que cambian el estado del sistema y aquellas que no. UML
define unconsultacomo una operación que obtiene un valor de una clase sin cambiar el estado del sistema; en
otras palabras, sin efectos secundarios. Puede marcar dicha operación con la cadena de propiedad{consulta}. Me
refiero a operaciones que cambian de estado comomodificadores, también llamados comandos.
Estrictamente, la diferencia entre consulta y modificadores es si cambian el estado observable [Meyer]. El estado
observable es lo que se puede percibir desde el exterior. Una operación que actualice un caché alteraría el estado
interno pero no tendría ningún efecto observable desde el exterior.
Me resulta útil resaltar las consultas, ya que se puede cambiar el orden de ejecución de las consultas y no cambiar el
comportamiento del sistema. Una convención común es intentar escribir operaciones de modo que los modificadores no
devuelvan un valor; de esa manera, puede confiar en el hecho de que las operaciones que devuelven un valor son consultas.
[Meyer] se refiere a esto como el principio de separación comando-consulta. A veces resulta incómodo hacer esto todo el
tiempo, pero debes hacerlo tanto como puedas.
Otros términos que a veces ves son métodos de obtención y métodos de configuración. Amétodo de obtención devuelve
un valor de un campo (y no hace nada más). Amétodo de configuraciónpone un valor en un campo (y no hace nada más).
Desde el exterior, un cliente no debería poder saber si una consulta es un método de obtención o un modificador es un
método de configuración. El conocimiento de cómo obtener y configurar métodos es completamente interno a la clase.
Otra distinción es entre operación y método. Unoperaciónes algo que se invoca en un objeto (la declaración de
procedimiento), mientras que unmétodoes el cuerpo de un procedimiento. Los dos son diferentes cuando tienes
polimorfismo. Si tiene un supertipo con tres subtipos, cada uno de los cuales anula el supertipoobtenerPrecio
operación, tiene una operación y cuatro métodos que la implementan.
La gente suele utilizar los términosoperaciónymétodoindistintamente, pero hay ocasiones en las que es útil ser
preciso acerca de la diferencia.
Generalización
Un ejemplo típico degeneralizaciónInvolucra a los clientes personales y corporativos de una empresa. Tienen
diferencias pero también muchas similitudes. Las similitudes se pueden ubicar en una clase de Cliente general
(el supertipo), con Cliente personal y Cliente corporativo como subtipos.
Este fenómeno también está sujeto a diversas interpretaciones desde las distintas perspectivas de modelización.
Conceptualmente, podemos decir que Cliente Corporativo es un subtipo de Cliente si todas las instancias de
Cliente Corporativo son también, por definición, instancias de Cliente. Un Cliente Corporativo es entonces un
tipo especial de Cliente. La idea clave es que todo lo que decimos sobre un Cliente (asociaciones, atributos,
operaciones) es cierto también para un Cliente Corporativo.
Desde una perspectiva de software, la interpretación obvia es la herencia: el Cliente corporativo es una subclase
del Cliente. En los lenguajes OO convencionales, la subclase hereda todas las características de la superclase y
puede anular cualquier método de la superclase.
Un principio importante para utilizar la herencia de forma eficaz essustituibilidad. Debería poder sustituir un Cliente
corporativo dentro de cualquier código que requiera un Cliente y todo debería funcionar bien. Básicamente, esto
significa que si escribo código asumiendo que tengo un Cliente, puedo usar libremente cualquier subtipo de Cliente.
El Cliente Corporativo puede responder a ciertos comandos de manera diferente
43/118

UML Distilled 3rd Ed (001-043) .En - Es

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

UML Distilled 3rd Ed (001-043) .En - Es

Cargado por

Copyright:

Formatos disponibles

Traducido del inglés al español - www.onlinedoctranslator.

¿Por qué molestarse con UML?

Cambios para la tercera edición

La tercera edición también contó con un excelente grupo de críticos:

Conrado Bock Craig Larman

Andy Carmichael Steve Mellor

Alistair Cockburn Jim Odell

Steve Cook Alan O'Callaghan

Lucas Hohmann Guus Ramackers

Pavel Hrubý Jim Rumbaugh

Jon Kern Tim Seltzer

Formas de utilizar el UML

Cómo llegamos al UML

¿Qué es UML legal?

Por dónde empezar con UML

Dónde encontrar más información

Dónde encontrar más información

Formas de utilizar el UML

Arquitectura basada en modelos y UML ejecutable

Los compiladores de modelos se basan en arquetipos reutilizables. Unarquetipodescribe cómo tomar

Cómo llegamos al UML

Figura 1.1. Una pequeña parte del metamodelo UML

Figura 1.2. Clasificación de tipos de diagramas UML

Componente 14 Estructura y conexiones de En UML 1

Despliegue 8 Implementación de artefactos en nodos. En UML 1

Objeto 6 Configuraciones de ejemplo de instancias Extraoficialmente en UML 1

Paquete 7 Estructura jerárquica en tiempo de compilación Extraoficialmente en UML 1

Secuencia 4 Interacción entre objetos; énfasis en la En UML 1

Momento 17 Interacción entre objetos; énfasis en el Nuevo en UML 2

¿Qué es UML legal?

Figura 1.3. Un diagrama de flujo de pantalla informal para parte de la wiki.

Tabla 1.2. Una mesa de decisiones

Orden de prioridad Y norte Y norte Y norte

Orden internacional Y Y norte norte norte norte

Tarifa $150 $100 $70 $50 $80 $60

Por dónde empezar con UML

Capítulo 2. Proceso de desarrollo

Procesos iterativos y en cascada

• "Estamos haciendo una iteración de análisis seguida de dos iteraciones de diseño..."

• Pruebas de regresión automatizadasayuda permitiéndote detectar rápidamente cualquier defecto que se

Planificación predictiva y adaptativa

Proceso racional unificado

Todos los proyectos RUP deben seguir cuatro fases.

3.Construccióncontinúa el proceso de construcción, desarrollando suficiente funcionalidad para lanzar.

Adaptar un proceso a un proyecto

1.Mantener:Cosas que funcionaron bien y que deseas asegurarte de continuar haciendo.

Adaptar el UML a un proceso

Los memorandos cuidadosamente seleccionados y bien redactados pueden sustituir fácilmente

Comprender el código heredado

Elegir un proceso de desarrollo

Dónde encontrar más información

Capítulo 3. Diagramas de clases: lo esencial

Figura 3.1. Un diagrama de clases simple

Un ejemplo de esto es:

- nombre: Cadena [1] = "Sin título" {readOnly}

Solo elnombrees necesario.

• Estevisibilidadel marcador indica si el atributo es público (+) o privado (-); Enfermo

Figura 3.2. Mostrar propiedades de un pedido como atributos

Figura 3.3. Mostrar propiedades de un pedido como asociaciones

Cuándo utilizar diagramas de clases

Dónde encontrar más información

• 1(Un pedido debe tener exactamente un cliente).

En los atributos encontramos diversos términos que hacen referencia a la multiplicidad.