UML Distilled-Spanish Edition

1/118
F RÓLOGO AL T ERCERA mi DICIÓN ................................................. .................................................. ................................ 4

F RÓLOGO AL F RIMERA mi DICIÓN ................................................. .................................................. ................................. 5
PAG REVESTIR DE NUEVO................................................. .................................................. .................................................. ...................... 5
¿Por qué molestarse con el UML? ............................................ .................................................. .......................................... 6
Estructura del libro .............................................. .................................................. .................................................. 7
Los cambios de la tercera edición ............................................. .................................................. ..................................... 7
Agradecimientos ................................................. .................................................. .................................................. . 7
re IAGRAMS ................................................. .................................................. .................................................. .................. 10
do CAPÍTULO 1. I INTRODUCCIÓN ................................................. .................................................. ......................................... 14
¿Cuál es el UML? ............................................. .................................................. .................................................. .... 14
¿Dónde averiguar más ............................................. .................................................. ........................................... 14
Maneras de utilizar el UML ............................................. .................................................. ............................................ 15
Cómo llegamos a la UML ............................................ .................................................. ............................................ 18
Notaciones y meta-modelos ............................................. .................................................. ...................................... 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
do CAPÍTULO 2. D DESARROLLO PAG PROCESO ................................................. .................................................. ......................... 26
Los procesos iterativos y cascada .............................................. .................................................. ............................ 26
Predictivo y Adaptive Planning .............................................. .................................................. ............................ 28
Los procesos ágiles ................................................ .................................................. .................................................. .... 29
Proceso racional unificado............................................... .................................................. ......................................... 30
Montaje de un proceso a un proyecto ............................................ .................................................. ..................................... 30
Montaje del UML en un proceso ............................................ .................................................. .................................. 32
La elección de un Proceso de Desarrollo .............................................. .................................................. .......................... 35
do CAPÍTULO 3. C MUCHACHA re IAGRAMS: T ÉL mi Ssentials ................................................. .................................................. ........ 35
Propiedades ................................................. .................................................. .................................................. ............. 36
Cuándo utilizar los diagramas de clases ............................................. .................................................. .................................. 38
Multiplicidad................................................. .................................................. .................................................. ............. 38
Programación Interpretación de Propiedades .............................................. .................................................. .............. 39
Asociaciones bidireccionales ................................................ .................................................. ...................................... 41
Operaciones ................................................. .................................................. .................................................. ............ 42
Generalización................................................. .................................................. .................................................. ...... 43
Notas y Comentarios ............................................... .................................................. ............................................. 44
Dependencia................................................. .................................................. .................................................. ......... 44
Reglas de restricción ................................................ .................................................. .................................................. ... 46
do CAPÍTULO 4. S EQUENCE re IAGRAMS ................................................. .................................................. .............................. 47
Creación y eliminación de participantes .............................................. .................................................. .......................... 50
Bucles, condicionales, y similares ........................................... .................................................. .............................. 51
Sincrónica y asincrónica llamadas .............................................. .................................................. ................... 54
Cuándo utilizar los diagramas de secuencia ............................................. .................................................. ........................... 54
do CAPÍTULO 5. C MUCHACHA re IAGRAMS: UN VANZADO do Onceptos ................................................. ................................................. 56
Palabras clave ................................................. .................................................. .................................................. ............. 56
Clasificación y generalización ............................................... .................................................. ........................... 57
Clasificación múltiple y dinámico .............................................. .................................................. ........................ 57
Clase Asociación ................................................ .................................................. .................................................. . 58
Plantilla (parametrizada) Clase ............................................. .................................................. .............................. 61
Enumeraciones ................................................. .................................................. .................................................. ....... 62
Clase activa ................................................ .................................................. .................................................. .......... 63
Visibilidad ................................................. .................................................. .................................................. ................ 63
Mensajes ................................................. .................................................. .................................................. ............. 64
Responsabilidades................................................. .................................................. .................................................. .... 64
Las operaciones y atributos estáticos .............................................. .................................................. .............................. sesenta y cinco
Agregación y Composición ............................................... .................................................. ................................ sesenta y cinco
Propiedades derivadas ................................................ .................................................. .................................................. 66
Interfaces y clases abstractas .............................................. .................................................. .............................. 67
De sólo lectura y congelado ............................................. .................................................. .............................................. 70
Objetos de referencia y el valor de los objetos ............................................. .................................................. ..................... 70
Asociaciones calificados ................................................ .................................................. ............................................ 71
do CAPÍTULO 6. O bject re IAGRAMS ................................................. .................................................. ................................... 72
2/118
Cuándo utilizar diagramas de objetos ............................................. .................................................. ................................. 72
do CAPÍTULO 7. P ackage re IAGRAMS ................................................. .................................................. ................................ 73
Paquetes y dependencias ............................................... .................................................. ................................. 74
Aspectos del paquete ................................................ .................................................. .................................................. .. 76
La implementación de paquetes ................................................ .................................................. ......................................... 76
Cuándo utilizar diagramas de paquetes ............................................. .................................................. ............................. 77
do CAPÍTULO 8. D EPLOYMENT re IAGRAMS ................................................. .................................................. .......................... 78
Cuándo utilizar diagramas de implementación ............................................. .................................................. ........................ 79
do CAPÍTULO 9. U SE do ASES ................................................. .................................................. .............................................. 79
Contenido de un caso de uso ............................................. .................................................. .............................................. 80
Los diagramas de casos ............................................... .................................................. ................................................ 81
Los niveles de los casos de uso .............................................. .................................................. ................................................ 82
Casos de uso y características (o historias) .......................................... .................................................. ......................... 82
Cuándo utilizar los casos de uso ............................................. .................................................. ........................................... 83
do CAPÍTULO 10. S TATE METRO achine re IAGRAMS ................................................. .................................................. ................... 83
Actividades internas ................................................ .................................................. .................................................. .. 85
Estados actividad ................................................ .................................................. .................................................. ....... 85
Superestados ................................................. .................................................. .................................................. .......... 86
Estados concurrentes ................................................ .................................................. .................................................. . 86
La implementación de los diagramas de estado ............................................... .................................................. ................................ 87
Cuándo utilizar los diagramas de estado ............................................. .................................................. ................................... 89
do CAPÍTULO 11. Un CTIVIDAD re IAGRAMS ................................................. .................................................. ............................... 89
Descomposición de una acción ............................................... .................................................. .......................................... 91
Y hay más ............................................... .................................................. .................................................. .. 93
Cuándo utilizar diagramas de actividad ............................................. .................................................. ................................ 93
Particiones ................................................. .................................................. .................................................. .............. 93
Señales ................................................. .................................................. .................................................. .................. 94
Fichas ................................................. .................................................. .................................................. .................. 95
Los flujos y los bordes ............................................... .................................................. .................................................. ... 96
Alfileres y Transformaciones ............................................... .................................................. ....................................... 96
Regiones de expansión ................................................ .................................................. ................................................ 97
Flujo final ................................................ .................................................. .................................................. .............. 98
Especificaciones unirse a ................................................ .................................................. .................................................. 99
do CAPÍTULO 12. C COMUNICACIÓN re IAGRAMS ................................................. .................................................. ................ 100
Cuándo utilizar diagramas de comunicación ............................................. .................................................. ................ 101
do CAPÍTULO 13. C OMPOSITE S STRUCTURAS ................................................. .................................................. .................... 101
Cuándo utilizar Estructuras Compuestas ............................................. .................................................. ....................... 103
do CAPÍTULO 14. C omponent re IAGRAMS ................................................. .................................................. ....................... 103
Cuándo utilizar diagramas de componentes ............................................. .................................................. ...................... 105
do CAPÍTULO 15. C OLLABORATIONS ................................................. .................................................. ................................ 105
Cuándo utilizar Colaboraciones .............................................. .................................................. .................................. 107
do CAPÍTULO 16. yo nteracciones O ERSPECTIVA re IAGRAMS ................................................. .................................................. ..... 107
Cuándo utilizar los diagramas de interacción general ............................................ .................................................. ........ 108
do CAPÍTULO 17. T Iming re IAGRAMS ................................................. .................................................. ................................ 109
Cuándo utilizar diagramas de temporización ............................................. .................................................. ............................... 110
UN PÉNDICE do ENTRE AMBIOS UML V Ersiones ................................................. .................................................. ......... 110
Las revisiones del UML .............................................. .................................................. ............................................. 110
Los cambios en UML destilada .............................................. .................................................. ....................................... 111
Los cambios de UML 1.0 a 1.1 ............................................ .................................................. ................................. 112
Los cambios de UML 1.2 (y 1.1) a 1.3 (y 1.5) .................................... .................................................. ......... 113
Los cambios de UML 1.3 a 1.4 ............................................ .................................................. ................................. 114
Los cambios de UML 1.4. a 1,5 ................................................ .................................................. ............................ 114
De 1.x UML a UML 2.0 .......................................... .................................................. .......................................... 114
segundo IBLIOGRAPHY ................................................. .................................................. .................................................. .......... 116
3/118
Prólogo a la tercera edición
Desde la antigüedad, los arquitectos más talentosos y los diseñadores con más talento han conocido la ley de la parsimonia. Ya sea que se
afirma como una paradoja ( "menos es más"), o un koan ( "Zen mente es la mente de principiante"), su sabiduría es atemporal: reducir todo a
su esencia de manera que forma armoniza con la función. De las pirámides a la Ópera de Sydney, de arquitecturas von Neumann a UNIX y
Smalltalk, los mejores arquitectos y diseñadores se han esforzado por seguir este principio universal y eterno.
Reconociendo el valor de afeitar con la navaja de Occam, cuando el arquitecto y leo busco proyectos y libros que se adhieren a la ley de la
parsimonia. En consecuencia, aplaudo el libro que está leyendo en este momento.
Usted puede encontrar mi última observación sorprendente al principio. Estoy asocia frecuentemente con las especificaciones voluminosos y
densos que definen el Unified Modeling Language (UML). Estas especificaciones permiten a los proveedores de herramientas para implementar el
UML y en metodología para aplicarla. Durante siete años, he presidido grandes equipos internacionales de normalización para especificar UML 1.1
y UML 2.0, así como varias revisiones menores en el medio. Durante este tiempo, el UML ha madurado en la expresividad y precisión, pero
también ha añadido complejidad gratuita como resultado del proceso de normalización. Lamentablemente, los procesos de normalización son
conocidas principalmente por compromisos de diseño por comité que parsimonia y elegancia.
¿Qué puede un experto en UML familiarizado con las minucias arcano de la especificación aprender de destilación de UML 2.0 de Martin? Un
poco, al igual que usted. Para empezar, Martin reduce hábilmente una lengua grande y compleja en un subconjunto pragmática que ha
demostrado ser eficaz en su práctica. Se ha resistido a la ruta fácil de viradas en las páginas adicionales a la última edición de su libro. A medida
que la lengua ha crecido, Martin ha mantenido fiel a su objetivo de buscar la "fracción de UML que es más útil", y que le dice exactamente eso.
La fracción que se refiere es el mítico 20 por ciento de UML que le ayuda a hacer el 80 por ciento de su trabajo. La captura y domesticación de
esta bestia difícil de alcanzar es un logro nada malo!
Es aún más impresionante que Martín logra este objetivo al escribir en un estilo conversacional maravillosamente atractivo. Al compartir sus
opiniones y anécdotas con nosotros, que hace que este libro divertido de leer y nos recuerda que architecting y el diseño de sistemas debe ser a
la vez creativo y productivo. Si seguimos el koan parsimonia en toda su intención, debemos encontrar proyectos de modelado UML para ser tan
agradable como nos encontramos a dedos de pintura y dibujo clases en la escuela primaria. UML debe ser un pararrayos para nuestra
creatividad, así como un láser para especificar con precisión los planos del sistema para que terceros pueden hacer una oferta y construir estos
sistemas. Esta última es la prueba de fuego para cualquier lenguaje de modelo fidedigno.
Por lo tanto, si bien esto puede ser un pequeño libro, no es trivial. Se puede aprender tanto de enfoque de Martin para el modelado
como se puede aprender de sus explicaciones de UML 2.0.
He disfrutado trabajando con Martin para mejorar la selección y corrección del lenguaje UML 2.0 características explicadas en esta revisión.
Hay que tener en cuenta que todas las lenguas vivas, tanto naturales como sintéticos, tienen que evolucionar o morir. elecciones de las nuevas
características de Martin, junto con sus preferencias y las de otros profesionales, son una parte crucial del proceso de revisión de UML.
Mantienen el lenguaje vital y ayudar a evolucionar a través de la selección natural en el mercado.
Mucho trabajo desafiante queda antes de desarrollo basado en modelos se convierte en la corriente principal, pero me siento alentado por libros como
este que explican conceptos básicos de modelado UML con claridad y se aplican de forma pragmática. Espero que aprender de ella como yo he y utilizar
sus nuevos conocimientos para mejorar sus propias prácticas de modelado de software.
Cris Kobryn
Silla, UML Partners' U2 2.0 Presentación Equipo Jefe de
Tecnología, Telelogic
4/118
Prólogo a la primera edición
Cuando empezamos a diseñar el Lenguaje de Modelado Unificado, esperábamos que podríamos producir un medio estándar de expresión de
diseño que no sólo refleje las mejores prácticas de la industria, sino que también ayudar a desmitificar el proceso de modelado de sistemas de
software. Creemos que la disponibilidad de un lenguaje de modelado estándar sería animar a más desarrolladores para modelar sus sistemas
de software antes de su construcción. La adopción rápida y generalizada de la UML demuestra que los beneficios del modelado son de hecho
muy conocidos por la comunidad de desarrolladores.
La creación de la UML era en sí misma un proceso iterativo e incremental muy similar a la modelización de un sistema de software de gran
tamaño. El resultado final es una norma basada en, y el reflejo de las muchas ideas y aportaciones de numerosas personas y empresas de la
comunidad objeto. Comenzamos el esfuerzo UML, pero muchos otros ayudaron a llevarlo a buen término; estamos agradecidos por su
contribución.
Creación y ponerse de acuerdo sobre un lenguaje de modelado estándar es un reto importante por sí mismo. Educar a la comunidad de
desarrollo, y presentar el UML de una manera que es a la vez accesible y en el contexto del proceso de desarrollo de software, también es un
reto importante. En este engañosamente corta libro, actualizado para reflejar los cambios más recientes en el UML, Martin Fowler ha cumplido
con creces este desafío.
En un estilo claro y agradable, Martin no sólo introduce los aspectos clave de UML, pero también demuestra claramente el papel UML
desempeña en el proceso de desarrollo. En el camino, nos tratan a abundantes pepitas de visión modelado y la sabiduría extraídos de Martin
de más de 12 años de experiencia en diseño y modelado.
El resultado es un libro que ha introducido muchos miles de desarrolladores a UML, despertando el apetito para explorar más a los
muchos beneficios del modelado con este lenguaje de modelado ahora estándar.
Recomendamos el libro a cualquier modelista o desarrollador interesado en obtener un primer vistazo a UML y en la obtención de una perspectiva sobre
el papel clave que desempeña en el proceso de desarrollo.
Grady Booch Ivar

Jacobson James
Rumbaugh
Prefacio
He tenido la suerte de muchas maneras en mi vida; uno de mis grandes golpes de fortuna era estar en el lugar adecuado con los
conocimientos adecuados para escribir la primera edición de este libro en 1997. En aquel entonces, el mundo caótico de modelado orientado
a objetos (OO) estaba empezando a unificar bajo el Unificada Modeling Language (UML). Desde entonces, el UML se ha convertido en el
estándar para el modelado gráfico de software, no sólo para los objetos. Mi fortuna es que este libro ha sido el libro más popular en el UML, la
venta de más de un cuarto de millón de copias.
Bueno, eso es muy agradable para mí, pero en caso de que comprar este libro?
Me gustaría hacer hincapié en que este es un breve libro. No es la intención de darle los detalles sobre todas las facetas de la UML, que ha
crecido y crecido a lo largo de los años. Mi intención es encontrar la fracción del UML que es más útil y le dirá exactamente eso. Aunque un libro
grande le da más detalle, también se necesita más tiempo para leer. Y su tiempo es la inversión más grande que va a hacer en un libro. Al
mantener este pequeño libro, he pasado el tiempo de la selección de las mejores partes para salvarte de tener que hacer que la selección sí
mismo. (Por desgracia, al ser más pequeño no significa proporcionalmente más barato; hay un cierto coste fijo para la producción de un libro
técnico de calidad.)
5/118
Una de las razones para que este libro es comenzar a aprender sobre el UML. Debido a que este es un libro corto, será rápidamente ponerse
al día sobre lo esencial de la UML. Con que bajo su cinturón, se puede entrar en más detalles sobre el UML con los libros más grandes, tales
como el Guía del usuario [ Booch, UML usuario] o el
Manual de referencia [ Rumbaugh, UML de referencia].
Este libro también puede actuar como una referencia práctica a las partes más comunes del UML. Aunque el libro no cubre todo, es
mucho más ligero de llevar que la mayoría de los otros libros de UML.
Es también un libro obstinado. He estado trabajando con objetos durante mucho tiempo, y tengo las ideas claras sobre lo que funciona y lo que
no. Cualquier libro refleja las opiniones del autor, y no tratan de ocultar la mía. Así que si estás buscando algo que tiene un sabor de la
objetividad, es posible que desee probar otra cosa.
Aunque muchas personas me han dicho que este libro es una buena introducción a los objetos, yo no lo escribí con esto en mente. Si usted está
después de una introducción al diseño orientado a objetos, sugiero el libro de Craig Larman [Larman].
Muchas personas que están interesadas en el UML están utilizando herramientas. Este libro se centra en la norma y en el uso convencional de
la UML y no entra en los detalles de lo que el apoyo de diversas herramientas. Aunque el UML hizo resolver la torre de Babel de notaciones
pre-UML, muchas diferencias entre lo que molestos siendo herramientas muestran y permiten al dibujar diagramas UML.
No digo mucho en este libro sobre la arquitectura dirigida por modelos (MDA). Aunque muchas personas consideran que los dos para ser la
misma cosa, muchos desarrolladores utilizan UML sin estar interesado en MDA. Si desea obtener más información sobre MDA, me gustaría
empezar con este libro para obtener una visión general del UML primero y luego pasar a un libro que es más específica acerca de la MDA.
A pesar de que el punto principal de este libro es el UML, También he añadido trozos de otro material sobre las técnicas, tales como las tarjetas
CRC, que son valiosas para el diseño orientado a objetos. El UML es sólo una parte de lo que necesita para tener éxito con los objetos, y creo
que es importante para presentarle a algunas otras técnicas.
En un breve libro como éste, es imposible entrar en detalles acerca de cómo el UML se refiere al código fuente, sobre todo porque no hay
manera estándar de hacer que la correspondencia. Sin embargo, yo señalo técnicas comunes de codificación para la implementación de las
piezas del UML. Mis ejemplos de código están en Java y C #, como he encontrado que estas lenguas son entendidas generalmente el más
ampliamente. No asuma que prefiero esos idiomas; He hecho demasiado Smalltalk por eso!
¿Por qué molestarse con el UML?
notaciones de diseño gráfico han estado con nosotros por un tiempo. Para mí, su valor principal está en comunicación y comprensión. Un
buen diagrama a menudo puede ayudar a comunicar las ideas sobre un diseño, sobre todo cuando se quiere evitar una gran cantidad de
detalles. Diagramas también pueden ayudar a entender ya sea un sistema de software o un proceso de negocio. Como parte de un equipo
que trata de averiguar algo, diagramas tanto ayuda para entender y comunicar esa comprensión a lo largo de un equipo. Aunque no son, al
menos todavía, un reemplazo para los lenguajes de programación textual, son un auxiliar útil.
Muchas personas creen que en el futuro, las técnicas gráficas jugarán un papel dominante en el desarrollo de software. Estoy más
escéptico de eso, pero ciertamente es útil tener una apreciación de lo que estas notaciones pueden y no pueden hacer.
De estas notaciones gráficas, la importancia del UML se debe a su amplio uso y normalización dentro de la comunidad de desarrollo
orientado a objetos. El UML se ha convertido no sólo en la notación gráfica dominante en el mundo orientado a objetos, sino también una
técnica muy popular en los círculos no-OO.
6/118
Estructura del libro
Capítulo 1 da una introducción a la UML: lo que es, los diferentes significados que tiene para diferentes personas, y de donde vino.
Capitulo 2 habla de proceso de software. Aunque esto es estrictamente independiente de la UML, creo que es esencial para comprender el
proceso con el fin de ver el contexto de algo así como el UML. En particular, es importante entender el papel del desarrollo iterativo, que ha sido
el enfoque subyacente para procesar la mayor parte de la comunidad OO.
He organizado el resto del libro en torno a los tipos de diagramas UML dentro de la. Los capítulos 3 y 4
discutir las dos partes más útiles de la UML: diagramas de clase (básicos) y los diagramas de secuencia. A pesar de que este libro es
delgado, creo que se puede obtener el máximo valor de la UML mediante el uso de las técnicas que yo hablo en estos capítulos. El UML es
una bestia grande y creciente, pero no es necesario todo.
Capítulo 5 entra en detalles sobre las partes menos esenciales pero todavía útiles de diagramas de clases. Los capítulos 6
mediante 8 describir tres diagramas útiles que arrojan más luz sobre la estructura de un sistema: diagramas de objetos, diagramas del paquete y
los diagramas de despliegue.
capítulos 9 mediante 11 muestran tres además útiles conductual técnicas: casos de uso, diagramas de estado (aunque oficialmente conocido como
diagramas de máquina de estado, que son generalmente llamados diagramas de estado), y los diagramas de actividad. Los capítulos 12 mediante 17 son
diagramas muy breves y cubierta que generalmente son menos importantes, por lo que para éstos, sólo he proporcionado un ejemplo rápido y
explicación.
Las cubiertas interiores resume las partes más útiles de la notación. A menudo he oído a gente decir que estas cubiertas son la parte más
valiosa del libro. Es probable que encuentres a mano para referirse a ellos como lo está leyendo algunas de las otras partes del libro.
Los cambios para la Tercera Edición
Si usted tiene ediciones anteriores de este libro, te estás preguntando qué es diferente y, más importante, si usted debe comprar la
nueva edición.
El desencadenante principal de la tercera edición fue la aparición de UML UML 2. 2 ha añadido un montón de cosas nuevas, incluyendo varios nuevos
tipos de diagramas. Incluso los diagramas familiares tienen una gran cantidad de nueva notación, tales como marcos de interacción en los diagramas de
secuencia. Si quieres estar al tanto de lo que ha ocurrido, pero no quieren que vadear a través de la especificación (Desde luego, no recomiendo que!),
Este libro le debería dar una buena visión de conjunto.
También he tomado esta oportunidad para reescribir por completo la mayor parte del libro, con lo que el texto y los ejemplos hasta la fecha. He
incorporado mucho de lo que he aprendido en la enseñanza y el uso de UML en los últimos cinco años. Así que, aunque el espíritu de este libro
ultrafino UML está intacta, la mayoría de las palabras son nuevas.
Con los años, he trabajado duro para mantener este libro tan actual como es posible. A medida que el UML ha pasado a través de sus cambios, he
hecho todo lo posible para mantener el ritmo. Este libro se basa en las UML 2 borradores que fueron aceptadas por el comité correspondiente, en junio
de 2003. Es poco probable que más cambios se producirán entre dicha votación y más votos formales, así que me siento que UML 2 ya está lo
suficientemente estable como para mi revisión de ir en la impresión. Voy a publicar la información más actualizaciones en mi sitio web ( http://martinfowler.com
).
Expresiones de gratitud
7/118
Durante muchos años, muchas personas han sido parte del éxito de este libro. Mis primeros agradecimiento Carter Shanklin y Kendall Scott.
Carter fue el editor en Addison-Wesley, quien sugirió este libro para mí. Kendall Scott me ayudó a poner juntas las dos primeras ediciones,
trabajando sobre el texto y los gráficos. Entre ellos, se logró lo imposible para conseguir la primera edición a cabo en un corto período de tiempo
increíblemente, manteniendo al mismo tiempo la alta calidad que la gente espera de Addison-Wesley. También mantuvieron empujando a cabo
cambios durante los primeros días de la 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. Ha sido también profundamente involucrado con los
problemas técnicos y personales de hacer metodólogos PERTINA resolver sus diferencias y de acuerdo a una norma común. Su contribución
a este libro es a la vez profundo y difícil de medir, y apuesto a que es el mismo para el UML también.
El UML es una criatura de las normas, pero soy alérgico a los organismos de normalización. Así que para saber lo que está pasando,
necesito una red de espías que pueden mantener a mí al día sobre todas las maquinaciones de los comités. Sin estos espías, incluyendo
Conrad Bock, Steve Cook, Cris Kobryn, Jim Odell, Guus Ramackers, y Jim Rumbaugh, estaría hundido. Todos me han dado consejos útiles y
responde a las preguntas estúpidas.
Grady Booch, Ivar Jacobson y Jim Rumbaugh son conocidos como los Tres Amigos. A pesar de las burlas juguetonas les he dado en los últimos
años, que me han dado mucho apoyo y estímulo con este libro. Nunca olvides que mis golpes generalmente brotan de apreciación aficionado.
Los colaboradores son la clave para la calidad de un libro, y he aprendido de Carter que nunca puede tener demasiados colaboradores. 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 tenía un buen grupo de revisores:
Conrad Bock Craig Larman
Andy Carmichael Steve Mellor
Alistair Cockburn Jim Odell
Steve Cook Alan O'Callaghan
luke Hohmann Guus Ramackers
Pavel Hruby Jim Rumbaugh
Jon Kern Tim Seltzer
Cris Kobryn
Todos estos revisores pasaron tiempo de leer el manuscrito, y cada uno de ellos encontraron al menos un aullador embarazoso. Mi
sincero agradecimiento a todos ellos. Cualquier aulladores que quedan son de mi entera responsabilidad. Voy a publicar una fe de erratas
a la sección de libros de martinfowler.com cuando las encuentro.
El núcleo del equipo que diseñó y escribió la especificación UML son 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 Moller Pedersen,
James Odell, Gunnar OVERGAARD, Karin Palmkvist, Guus Ramackers, Jim Rumbaugh, Bran Selic, Thomas Weigert, y Larry Williams. Sin
ellos, no tendría nada que escribir.
Pavel Hruby desarrollado algunos excelentes plantillas de Visio que utilizo un montón de diagramas UML; se puede obtener en http://phruby.com
.
Muchas personas me han puesto en contacto en la red y en persona con sugerencias y preguntas y para señalar errores. No he podido
hacer un seguimiento de todos ustedes, pero mi agradecimiento sincero no son menos.
8/118
La gente en mi librería favorita técnica, SOFTPRO en Burlington, Massachusetts, me dejaron paso muchas horas allí mirando sus acciones
para encontrar cómo la gente usa el UML en la práctica y me dieron de comer un buen café mientras yo estaba allí.
Para la tercera edición, el editor de adquisición fue de Mike Hendrickson. Kim Arney Mulcahy dirigió el proyecto, así como lo hizo el diseño y la
limpieza de los diagramas. John Fuller, en Addison-Wesley, fue el editor de la producción, mientras que Evelyn Pyle y Rebecca Rider ayudaron
con la corrección de estilo y corrección del libro. Les doy las gracias.
Cindy ha quedado conmigo mientras yo persisto en los libros de escritura. A continuación, las ganancias plantas en el jardín.
Mis padres me eligió una buena educación, de la que todos los resortes de otra persona.
Martin Fowler
Melrose, Massachusetts
http://martinfowler.com
9/118
diagramas
10/118
11/118
12/118
13/118
Capítulo 1 Introducción
¿Cuál es el UML?
Maneras de utilizar el UML
Cómo llegamos a la UML
Notaciones y meta-modelos
diagramas UML
¿Qué es UML legal?
El significado de UML
UML no es suficiente
Por dónde empezar con UML
¿Dónde averiguar más
¿Cuál es el UML?
El Lenguaje de Modelado Unificado (UML) es una familia de notaciones gráficas, respaldado por metamodelo único, que ayuda en la descripción y
diseño de sistemas de software, en particular los sistemas de software construido usando el estilo orientado a objetos (OO). Esa es una definición
algo simplificada. De hecho, el UML es un par de cosas diferentes para diferentes personas. Esto viene tanto de su propia historia y desde los
diferentes puntos de vista que tienen las personas sobre lo que hace un proceso de ingeniería de software efectivo. Como resultado, mi tarea en
gran parte de este capítulo es establecer el escenario para este libro explicando las diferentes maneras en que las personas ven y usan el UML.
lenguajes de modelado gráfico han existido en la industria del software por un largo tiempo. El motor fundamental detrás de todos ellos es que
los lenguajes de programación no están a un nivel suficientemente alto de abstracción para facilitar las discusiones sobre el diseño.
A pesar del hecho de que los lenguajes de modelado gráfico han existido desde hace mucho tiempo, hay una enorme cantidad de
controversia en la industria del software sobre su papel. Estas disputas juegan directamente en cómo la gente percibe el papel del propio
UML.
El UML es un estándar relativamente abierto, controlado por el Grupo de Gestión de objetos (OMG), un consorcio abierto de empresas. El
OMG se formó para construir estándares que apoyaron la interoperabilidad, específicamente la interoperabilidad de los sistemas orientados a
objetos. El OMG es quizás mejor conocido por la normas CORBA (Common Object Request Broker Architecture).
El UML nació de la unificación de los muchos lenguajes de modelado gráfico orientado a objetos que florecieron a finales de 1980 y principios
de 1990. Desde su aparición en 1997, se ha relegado esa torre de Babel en particular a la historia. Eso es un servicio que, y muchos otros
desarrolladores, estoy profundamente agradecido.
14/118
Este libro no es una referencia completa y definitiva de la UML, dejar que el análisis OO solo y diseño. Muchas palabras están ahí fuera y un
montón de cosas que vale la pena leer. Como analizo los temas individuales, también menciono otros libros hay que ir a por más en
profundidad la información allí. Aquí hay algunos libros generales sobre el UML y diseño orientado a objetos.
Al igual que con todas las recomendaciones de libros, puede que tenga que comprobar la versión del UML están escritas para. En junio de
2003, ningún libro publicado utiliza UML 2.0, que no es de extrañar, ya que la tinta es apenas seca en la norma. Los libros que sugerimos son
buenos libros, pero no puedo decir si o cuándo van a ser actualizados con el estándar UML 2.
Si usted es nuevo en objetos, recomiendo mi libro de introducción actual favorito: [Larman]. fuerte enfoque de responsabilidad
impulsada por el autor para diseñar vale la pena seguir.
Porque la palabra conclusiva sobre el UML, usted debe buscar a los documentos oficiales de normalización; pero recuerde, están escritas para
consentir en metodología en la intimidad de sus propios cubículos. Para una versión mucho más digerible de la norma, echar un vistazo a
[Rumbaugh, UML de referencia].
Para un asesoramiento más detallado sobre el diseño orientado a objetos, aprenderá muchas cosas buenas de [Martin].
También sugiero que lea libros sobre las pautas de material que le llevará más allá de los conceptos básicos. Ahora que la guerra ha
terminado métodos, patrones (página 27), donde están la mayor parte del material interesante sobre el análisis y el diseño aparece.
Maneras de utilizar el UML
En el corazón de la función del UML en desarrollo de software son las diferentes formas en que la gente quiere usarlo, diferencias que llevan
más de otros lenguajes de modelado gráfico. Estas diferencias llevan a los argumentos largos y difíciles sobre cómo se debe utilizar el UML.
Para desenredar esto, Steve Mellor y me llegaron de forma independiente con una caracterización de los tres modos en que las personas
utilizan el UML: boceto, plano, y el lenguaje de programación. Con mucho, el más común de los tres, al menos a mi ojo sesgada, es UML como
boceto. En este uso, los desarrolladores pueden utilizar el UML para ayudar a comunicar algunos aspectos de un sistema. Al igual que con los
planos, se puede utilizar en un croquis de ingeniería directa o ingeniería inversa dirección. ingeniería directa dibuja un diagrama UML antes de
escribir código, mientras Ingeniería inversa construye un diagrama UML de código existente con el fin de ayudar a comprender la misma.
La esencia del dibujo es la selectividad. Con dibujo hacia adelante, que esbozar algunos problemas en el código que está a punto de escribir,
por lo general discutirlos con un grupo de personas en su equipo. Su objetivo es utilizar los bocetos para ayudar a comunicar ideas y
alternativas acerca de lo que está a punto de hacer. No se habla sobre todo el código que se va a trabajar, sólo las cuestiones importantes que
desea ejecutar más allá de sus colegas primero o secciones del diseño que quiere visualizar antes de comenzar la programación. Sesiones de
este tipo pueden ser muy corto: una sesión de 10 minutos para discutir un par de horas de programación o de un día para discutir un 2
semanas iteración.
Con la ingeniería inversa, utiliza dibujos para explicar cómo una parte de un sistema que funciona. Usted no se presenta a todas las clases,
sólo aquellos que son interesantes y vale la pena antes de excavar en el código.
Debido a dibujar es bastante informal y dinámico, es necesario hacerlo con rapidez y en colaboración, por lo que un medio común es una pizarra.
Bocetos son también útiles en los documentos, en cuyo caso el foco es la comunicación en lugar de lo completo. Las herramientas que se utilizan
para dibujar son herramientas de dibujo de peso ligero, y con frecuencia las personas no son demasiado particular acerca de mantener a toda regla
estricta de la UML. La mayoría de los diagramas UML que se muestran en los libros, como mis otros libros, son bocetos. Su énfasis está en
comunicación selectiva en lugar de la especificación completa.
15/118
A diferencia de, UML como modelo se trata de integridad. En la ingeniería hacia adelante, la idea es que los modelos son desarrollados por un
diseñador cuyo trabajo consiste en construir un diseño detallado para un programador de código de arriba. Que el diseño debe ser lo
suficientemente completa en la que todas las decisiones de diseño están establecidos, y el programador debe ser capaz de seguir como una
actividad bastante sencillo que requiere poca atención. El diseñador puede ser la misma persona que el programador, pero por lo general el
diseñador es un desarrollador de más alto rango que diseña para un equipo de programadores. La inspiración para este enfoque es otras formas
de ingeniería en la que los ingenieros profesionales crean dibujos de ingeniería que son entregados a las empresas de construcción para construir.
Blueprinting puede ser utilizado para todos los detalles, o un diseñador puede dibujar planos a un área en particular. Un enfoque común es para un diseñador
para desarrollar modelos de nivel de anteproyecto siempre que las interfaces de subsistemas, pero luego dejar que los desarrolladores trabajar en los
detalles de la implementación de esos detalles.
En la ingeniería inversa, 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 es más fácil para los
desarrolladores a entender.
Planos requieren mucho más sofisticadas herramientas de bocetos hacen con el fin de manejar los detalles necesarios para la tarea. CASO
especializada (ingeniería de software asistida por ordenador) herramientas entran en esta categoría, aunque el término caso se ha convertido en
una mala palabra, y los vendedores tratan de evitar ahora. Forward-ingeniería de apoyo herramientas diagrama de dibujo y copia de seguridad con
un depósito para contener la información. La ingeniería inversa herramientas leen e interpretan el código fuente de la misma en el repositorio y
generan diagramas. Herramientas que pueden hacer tanto hacia delante como la ingeniería inversa como esto se denominan viaje ida y vuelta herramientas.
Algunas herramientas utilizan el código fuente como el repositorio y el uso de diagramas como un visor gráfico en el código. Estas herramientas vinculan
más estrechamente en la programación y, a menudo se integran directamente con editores de programación. Me gusta pensar en ellos como sin disparo herramientas.
La línea entre los planos y bocetos es algo borrosa, pero la distinción, creo, se basa en el hecho de que los bocetos son deliberadamente
incompleta, resaltando la información importante, mientras que los modelos tienen la intención de ser exhaustivo, a menudo con el objetivo de
reducir la programación a un simple y bastante actividad mecánica. En un audio, yo diría que son bocetos de exploración, mientras que los
planos son definitivos.
Como lo hace cada vez más en el UML y la programación se vuelve cada vez mecánico, se hace evidente que la programación debe ser
automatizado. De hecho, muchas herramientas CASE hacer algún tipo de generación de código, que automatiza la construcción de una
parte importante de un sistema. Eventualmente, sin embargo, se llega al punto en el que todo el sistema se puede especificar en el UML, y
que llegue
UML como lenguaje de programación. En este entorno, los desarrolladores dibujar diagramas UML que se compilan directamente a código
ejecutable, y el UML se convierte en el código fuente. Obviamente, este uso de UML exige herramientas particularmente sofisticado.
(Además, las nociones de ingeniería directa e inversa no tienen ningún sentido para este modo, como el UML y el código fuente son la misma
cosa.)
Modelo Driven Arquitecture y ejecutable UML
Cuando la gente habla de la UML, también hablan a menudo de Model Driven Architecture
( MDA) [ Kleppe et al.]. En esencia, la MDA es un enfoque estándar para usar el UML como lenguaje de programación; el
estándar es controlado por el OMG, como es el UML. Al producir un entorno de modelado que se ajusta a la MDA, los
proveedores pueden crear modelos que también pueden trabajar con otros ambientes MDA-compatibles.
MDA se habla a menudo acerca de la misma categoría que el UML porque MDA utiliza UML como lenguaje de modelado
básico. Pero, por supuesto, usted no tiene que ser el uso de MDA utilizar el UML.
MDA divide el trabajo de desarrollo en dos áreas principales. Modelers representan una aplicación en particular mediante la creación de
una Plataforma Modelo Independiente (PIM). El PIM es un modelo UML que es independiente de cualquier tecnología en particular.
Herramientas pueden convertir un PIM en una
Plataforma modelo específico (PSM). El PSM es un modelo de un sistema dirigido a un específica
16/118
entorno de ejecución. Otras herramientas y luego toman el PSM y generan código para esa plataforma. El PSM podría
ser UML, pero no tiene que ser.
Así que si usted quiere construir un sistema de almacenamiento utilizando MDA, sería empezar por la creación de un único PIM de su sistema
de almacenamiento. Si a continuación quería este sistema de almacenamiento para ejecutarse en J2EE y .NET, se utiliza algunas herramientas
de terceros para crear dos PSM: uno para cada plataforma. A continuación, más herramientas podrían generar código para las dos plataformas.
Si el proceso de pasar de PIM a PSM al código final es completamente automatizado, tenemos el UML como lenguaje de
programación. Si alguno de los pasos es manual, tenemos planos.
Steve Mellor trabaja desde hace tiempo en este tipo de trabajo y ha utilizado recientemente el término
Ejecutable UML [ Mellor y Balcer]. UML ejecutable es similar a la MDA, pero utiliza términos ligeramente diferentes. Del mismo modo, se
empieza con un modelo independiente de la plataforma que es equivalente a PIM de la MDA. Sin embargo, el siguiente paso es usar un
compilador Modelo para convertir ese modelo UML en un sistema de despliegue en una sola etapa; por lo tanto, no hay necesidad de que
el PSM. Como el término
compilador sugiere, este paso es completamente automático.
Los compiladores de modelos se basan en arquetipos reutilizables. Un arquetipo describe cómo tomar un modelo UML ejecutable
y convertirlo en una plataforma de programación en particular. Así, por ejemplo, el almacenamiento, que iba a comprar un
compilador de modelo y dos arquetipos (J2EE y
. RED). Ejecutar cada arquetipo del modelo de UML ejecutable, y que tenga sus dos versiones del sistema de
almacenamiento.
Ejecutable UML no utiliza el estándar UML completo; muchas construcciones de UML se consideran innecesarios y por lo tanto
no se utilizan. Como resultado, ejecutable UML es más simple que completa UML.
Todo esto suena bien, pero ¿qué tan realista es? En mi opinión, hay dos problemas aquí. En primer lugar está la cuestión de las
herramientas: si son lo suficientemente maduros como para hacer el trabajo. Esto es algo que cambia con el tiempo; Ciertamente, al
momento de escribir esto, no se utilizan ampliamente, y no he visto mucho de ellos en acción.
Un problema más fundamental es la noción de la UML como lenguaje de programación. En mi opinión, vale la pena usar el UML
como lenguaje de programación sólo si resulta en algo que es mucho más productivo que utilizando otro lenguaje de
programación. No estoy convencido de que se trata, en base a varios entornos de desarrollo gráfico que he trabajado en el
pasado. Incluso si es más productiva, que todavía tiene que conseguir una masa crítica de usuarios para que haga la corriente
principal. Eso es un gran obstáculo en sí mismo. Al igual que muchos Smalltalkers viejos, considero Smalltalk sea mucho más
productivo que los lenguajes convencionales actuales. Pero como Smalltalk es ahora sólo un lenguaje de nicho, no veo muchos
proyectos de usarlo. Para evitar el destino de Smalltalk, el UML tiene que ser más suerte, incluso si es superior.
Una de las cuestiones interesantes de todo el UML como lenguaje de programación es cómo modelar la lógica del comportamiento. UML 2
ofrece tres formas de modelado de comportamiento: Los diagramas de interacción, diagramas de estado y diagramas de actividad. Todos tienen
sus defensores para la programación. Si el UML hace ganar popularidad como un lenguaje de programación, será interesante ver cuál de estas
técnicas a tener éxito.
Otra forma en que la gente mira el UML es el rango entre usarlo para conceptual y para el modelado de software. La mayoría de la gente
está familiarizada con el UML se utiliza para el modelado de software. En esto
perspectiva del software, los elementos del UML mapa bastante directamente a los elementos de un sistema de software. Como veremos más
adelante, la asignación de ninguna manera es preceptivo, pero cuando se utiliza el UML, estamos hablando de elementos de software.
Con el punto de vista conceptual, UML representa una descripción de los conceptos de un dominio de estudio. Aquí, no estamos hablando de
elementos de software tanto como estamos construyendo un vocabulario para hablar de un dominio particular.
17/118
No hay reglas duras y rápidas sobre la perspectiva; como resulta, no hay realmente bastante una amplia gama de uso. Algunas herramientas se apagan
automáticamente el código fuente en los diagramas UML, el tratamiento de la UML como una visión alternativa de la fuente. Eso es en gran medida una
perspectiva del software. Si utiliza diagramas UML para tratar de comprender los diversos significados de los términos agrupación de activos con un
grupo de contadores, se encuentra en un marco mucho más conceptual de la mente.
En ediciones anteriores de este libro, he dividido el punto de vista del software en la especificación (interfaz) y la aplicación. En la práctica,
encontré que era demasiado difícil trazar una línea precisa entre los dos, así que siento que la distinción ya no vale la pena hacer un alboroto
acerca. Sin embargo, siempre me siento inclinado a hacer hincapié en la interfaz en lugar de aplicación en mis esquemas.
Estas diferentes formas de utilizar el plomo UML a una serie de argumentos acerca de lo que significan los diagramas UML y cuál es su
relación con el resto del mundo. En particular, afecta a la relación entre el UML y el código fuente. Algunas personas sostienen la opinión de
que el UML se debe utilizar para crear un diseño que es independiente del lenguaje de programación que se utiliza para su implementación.
Otros creen que el diseño independiente del lenguaje es un oxímoron, con un fuerte énfasis en el tarado.
Otra diferencia en puntos de vista es lo que la esencia de la UML es. En mi opinión, la mayoría de los usuarios de la UML, en particular los
dibujantes, ver la esencia de la UML para ser los diagramas. Sin embargo, los creadores de la UML ver los diagramas como secundario; la esencia
de la UML es el meta-modelo. Los diagramas son simplemente una presentación de la meta-modelo. Este punto de vista también tiene sentido
fotocalcadoras y los usuarios del lenguaje de programación UML.
Así que cada vez que lee cualquier cosa que implica el UML, es importante entender el punto de vista del autor. Sólo entonces se puede dar
sentido a los argumentos a menudo feroces que favorece el UML.
Habiendo dicho todo esto, tengo que hacer mis sesgos clara. Casi todo el tiempo, mi uso del UML es como bocetos. Me parece que el UML
esboza útil con ingeniería directa e inversa y en los dos perspectivas conceptuales y software.
No soy un fan de los planos de ingeniería prospectivas se detallan; Creo que es demasiado difícil de hacer bien y se ralentiza un esfuerzo de
desarrollo. Blueprinting a un nivel de contacto de los subsistemas es razonable, pero incluso entonces usted debe esperar para cambiar esas
interfaces ya que los desarrolladores implementen las interacciones a través de la interfaz. El valor de planos de ingeniería inversa depende de
cómo funciona la herramienta. Si se utiliza como un navegador dinámico, que puede ser muy útil; si se genera un documento de gran tamaño, lo
único que hace es matar árboles.
Veo el UML como lenguaje de programación como una buena idea, pero dudo que alguna vez ver el uso significativo. No estoy convencido de que
las formas gráficas son más productivas que las formas textuales para la mayoría de las tareas de programación y que, incluso si lo son, es muy
difícil para un idioma que se acepta ampliamente.
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 breve
guía. No puedo hacer justicia a la UML en sus otros modos en un libro de este tamaño, pero un libro de este tamaño hace una buena introducción a
otros libros que pueden. Así que si usted está interesado en el UML en sus otros modos, me gustaría sugerir que el tratamiento de este libro como una
introducción y pasa a otros libros a medida que los necesite. Si usted está interesado únicamente en bocetos, este libro bien puede ser todo lo que
necesita.
Cómo llegamos a la UML
Voy a admitir, soy un aficionado a la historia. Mi idea favorita de la lectura de la luz es un buen libro de historia. Pero también sé que no es la
idea de que todo el mundo de diversión. Hablo de la historia aquí, porque creo que en muchos aspectos, es difícil de entender que el UML es
sin entender la historia de cómo llegó hasta aquí.
18/118
En la década de 1980, los objetos comenzaron a moverse lejos de los laboratorios de investigación y dieron sus primeros pasos hacia el mundo
"real". Smalltalk se estabilizó en una plataforma que la gente podría utilizar, y C ++ nació. En ese momento, varias personas comenzaron a pensar
en lenguajes de diseño gráfico orientado a objetos.
Los libros clave sobre lenguajes de modelado gráfico orientado a objetos aparecieron entre 1988 y
1992. figuras principales incluyen Grady Booch [Booch, OOAD]; Peter Coad [Coad, OOA], [Coad, OOD]; Ivar Jacobson (Objectory)
[Jacobson, OOSE]; Jim Odell [Odell]; Jim Rumbaugh (OMT) [Rumbaugh, ideas], [Rumbaugh OMT]; Sally Shlaer y Steve Mellor [Shlaer y
Mellor, los datos], [Shlaer y Mellor, afirma]; y Rebecca Wirfs-Brock (impulsado por la responsabilidad Diseño) [Wirfs-Brock].
Cada uno de estos autores fue ahora de manera informal lleva a un grupo de profesionales que le gustaba esas ideas. Todos estos métodos
son muy similares, sin embargo, contenían varias veces molestos pequeñas diferencias entre ellos. Los mismos conceptos básicos
aparecerían en muy diferentes anotaciones, lo que causó confusión a mis clientes.
Durante ese tiempo embriagadora, la estandarización fue como habló, ya que fue ignorada. Un equipo de la OMG trató de mirar a la
estandarización, pero sólo obtuvo una carta abierta de protesta de todos los metodólogos clave. (Esto me recuerda a una vieja broma.
Pregunta: ¿Cuál es la diferencia entre un metodólogo y un terrorista Respuesta: Usted puede negociar con un terrorista.)
El acontecimiento catastrófico que primero inició el UML fue cuando Jim Rumbaugh dejó GE para unirse a Grady Booch en Racional (ahora
parte de IBM). La alianza Booch / Rumbaugh fue visto desde el principio como uno que podría obtener una masa crítica de participación en el
mercado. Grady y Jim proclamaron que "la guerra ha terminado métodos ganamos," básicamente, declarando que iban a lograr la
estandarización "la forma en que Microsoft". Un número de otros metodólogos sugirió la formación de una coalición anti-Booch.
Por OOPSLA '95, Grady y Jim habían preparado su primera descripción pública de su método combinado: la versión 0.8 de la Método unificada documentac
Aún más significativo, se anunció que había comprado Rational Software Objectory y que, por lo tanto, Ivar Jacobson se uniría al equipo
unificado. Racional celebró una fiesta muy concurrida para celebrar el lanzamiento del proyecto de 0,8. (El punto culminante de la fiesta fue la
primera exhibición pública de canto de Jim Rumbaugh, que todos esperamos que sea también la última.)
El próximo año se produjo un proceso más abierto emerger. El OMG, que había permanecido mayormente al margen, ahora tomó un papel
activo. Racional tuvieron que incorporar las ideas de Ivar y también pasó tiempo con otros socios. Más importante, el OMG decidió tomar un
papel importante.
En este punto, es importante darse cuenta de por qué el OMG se involucró. Metodólogos, al igual que los autores del libro, les gusta pensar que
son importantes. Pero no creo que los gritos de los autores del libro, incluso serían escuchadas por el OMG. Lo que consiguió el OMG implicados
eran los gritos de los vendedores de herramientas, todos los cuales tenían miedo de que un estándar controlado por Rational daría herramientas de
Rational una ventaja competitiva injusta. Como resultado, los vendedores energizan el OMG que hacer algo al respecto, bajo la bandera de
interoperabilidad herramienta CASE. Esta bandera fue importante, ya que el OMG fue todo acerca de la interoperabilidad. La idea era crear un UML
que permitiría a las herramientas CASE para intercambiar libremente modelos.
Mary Loomis y Jim Odell presidido el grupo de trabajo inicial. Odell dejó claro que estaba dispuesto a renunciar a su método a una norma, pero
que no quería un estándar racional-impuesta. En Enero
1997, varias organizaciones presentaron propuestas para un estándar de métodos para facilitar el intercambio de modelos. Racional colaborado
con una serie de otras organizaciones y lanzó la versión 1.0 de la documentación UML como su propuesta, el primer animal para responder al
nombre de Unified Modeling Language.
Luego siguió un período corto de torsión del brazo, mientras que las diversas propuestas se fusionaron. El OMG adoptó el 1,1 resultante como
un estándar OMG oficial. Algunas revisiones se hicieron más adelante. Revisión
1,2 era del todo cosmético. Revisión 1.3 fue más significativo. Revisión 1.4 añade una serie de conceptos detallados en torno a los
componentes y perfiles. Revisión 1.5 añade la semántica de acción.
Cuando la gente habla de la UML, que atribuyen principalmente Grady Booch, Ivar Jacobson y Jim Rumbaugh como sus creadores. Se conocen
en general como los tres amigos, aunque al igual que a bromistas
19/118
dejar caer la primera sílaba de la segunda palabra. A pesar de que son los más acreditados con el UML, creo que es algo injusto para darles
el crédito dominante. La notación UML se formó primero en el Método Unificado Booch / Rumbaugh. Desde entonces, gran parte del trabajo
ha sido dirigido por los comités de OMG. Durante estas últimas etapas, Jim Rumbaugh es el único de los tres que ha hecho un compromiso
pesada. Mi opinión es que se trata de estos miembros del comité proceso de UML que merecen el crédito principal para el UML.
Notaciones y meta-modelos
El UML, en su estado actual, define una notación y un modelo de meta. los notación es la materia gráfica que se ve en los modelos; es la
sintaxis gráfica del lenguaje de modelado. Por ejemplo, la notación diagrama de clases define cómo artículos y conceptos, tales como la
clase, la asociación y la multiplicidad, están representados.
Por supuesto, esto lleva a la pregunta de qué es exactamente lo que se entiende por una asociación o multiplicidad o incluso una clase. El uso
común sugiere algunas definiciones informales, pero muchas personas quieren más rigor que eso.
La idea de lenguajes de especificación y diseño riguroso es el más frecuente en el campo de los métodos formales. En tales técnicas,
diseños y especificaciones se representan usando algún derivado de cálculo de predicados. Tales definiciones son matemáticamente
rigurosa y permiten ninguna ambigüedad. Sin embargo, el valor de estas definiciones es de ninguna manera universal. Incluso si se puede
demostrar que un programa satisface una especificación matemática, no hay manera de probar que la especificación matemática a las
necesidades 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
general, esto no parece haber hecho mucho daño. Estos métodos pueden ser informales, pero muchas personas todavía sean de utilidad, y
es la utilidad que cuenta.
Sin embargo, metodólogos están buscando maneras de mejorar el rigor de los métodos sin sacrificar su utilidad. Una forma de hacer esto es
definir una metamodelo: un diagrama, por lo general un diagrama de clases, que define los conceptos de la lengua.
Figura 1.1 , Una pequeña pieza de la meta-modelo de UML, muestra la relación entre características. (El extracto está ahí para dar una
idea de lo que los meta-modelos son similares. Yo ni siquiera voy a tratar de explicarlo.)
Figura 1.1. Un pequeño trozo de la meta-modelo UML
20/118
¿Cuánto afecta el meta-modelo de un usuario de la notación de modelado? La respuesta depende en gran medida del modo de uso. Un
dibujante por lo general no le importa demasiado; un blueprinter debe cuidar un poco más. Es de vital importancia para aquellos que utilizan el
UML como lenguaje de programación, ya que define la sintaxis abstracta de ese idioma.
Muchas de las personas que están involucradas en el desarrollo continuo de la UML están interesados principalmente en el meta-modelo,
especialmente en lo que esto es importante para el uso del UML y un lenguaje de programación. cuestiones de notación a menudo corren
segundo lugar, lo que es importante tener en cuenta si alguna vez tratar de familiarizarse con los documentos de normas propias.
A medida que vaya más profundo en el uso más detallado de la UML, se da cuenta de que necesita mucho más que la notación gráfica. Esta es
la razón por herramientas UML son tan complejos.
No soy rigurosa en este libro. Yo prefiero el camino de los métodos tradicionales y el atractivo principalmente a su intuición. Eso es
natural para un pequeño libro como este escrito por un autor que está inclinado sobre todo para un uso boceto. Si quieres más rigor, hay
que girar a tomos más detalladas.
diagramas UML
UML 2 describe 13 tipos oficiales que figuran en el diagrama Tabla 1.1 y clasificada como se indica en Figura
1.2 . Aunque estos tipos de diagramas son la forma en que muchas personas se acercan a la UML y cómo he organizado este libro, los
autores del UML no ven diagramas como la parte central de la UML. Como resultado, los tipos de diagramas no son particularmente rígida.
A menudo, se puede utilizar legalmente los elementos de un tipo de diagrama en otro diagrama. El estándar UML indica que ciertos
elementos se extrae típicamente en ciertos tipos de diagrama, pero esto no es una receta.
Figura 1.2. Clasificación de tipos de diagramas UML
21/118
Tabla 1.1. Diagrama Tipos Oficiales de la UML
Capítulos de
Diagrama libros Propósito Linaje
Actividad 11 la conducta procesal y paralelo En UML 1
Clase 3, 5 Clase, funciones y relaciones En UML 1
Comunicación 12 La interacción entre los objetos; énfasis en los enlaces UML diagrama 1
colaboración
Componente 14 Estructura y conexiones de componentes En UML 1
estructura 13 la descomposición de una clase en tiempo de ejecución Nuevo a UML 2

compuesta
Despliegue 8 Despliegue de artefactos a los nodos En UML 1
22/118
Tabla 1.1. Diagrama Tipos Oficiales de la UML
Capítulos de
Diagrama libros Propósito Linaje
visión general de dieciséis Mezcla de secuencia y diagrama de actividad Nuevo en UML 2

interacción
Objeto 6 configuraciones de ejemplo de casos Extraoficialmente en UML 1
Paquete 7 En tiempo de compilación estructura jerárquica Extraoficialmente en UML 1
Secuencia 4 La interacción entre los objetos; énfasis en la secuencia En UML 1
Máquina estatal 10 ¿Cómo cambian los eventos de un objeto durante su vida En UML 1
Sincronización 17 La interacción entre los objetos; énfasis en la temporización Nuevo a UML 2
caso de uso 9 Cómo los usuarios interactúan con un sistema de En UML 1
¿Qué es UML legal?

A primera vista, esto debería ser una pregunta fácil de responder: UML legal es lo que se define así formada en la especificación. En la
práctica, sin embargo, la respuesta es un poco más complicado.
Una parte importante de esta pregunta es si el UML tiene reglas descriptivas o prescriptivas. Un lenguaje con normas preceptivas está
controlado por un organismo oficial que establece lo que es o no es legal en el lenguaje y el significado que le dan a los enunciados en dicho
idioma. Un lenguaje con
reglas descriptivas es uno en el que usted entiende sus reglas examinado cómo las personas utilizan el lenguaje en la práctica. Los lenguajes de
programación tienden a tener normas preceptivas establecidas por un comité de normas o proveedor dominante, mientras que las lenguas
naturales, tales como Inglés, tienden a tener reglas descriptivas cuyo significado se establece por convención.
UML es un lenguaje muy preciso, por lo que podría esperar que tenga normas preceptivas. Pero UML es a menudo considerado como el
equivalente en software de los planos en otras disciplinas de ingeniería, y estos planos no son anotaciones preceptivas. Ningún comité dice lo
que los símbolos son legales en un dibujo de ingeniería estructural; la notación ha sido aceptado por convención, de manera similar a un
lenguaje natural. Basta con tener un organismo de normalización no hace el truco tampoco, porque la gente en el campo no pueden seguir todo
el organismo de normalización dice; simplemente hacer que el francés sobre la Academia Francesa. Además, el UML es tan compleja que el
estándar es a menudo abierto a múltiples interpretaciones. Incluso los líderes UML que revisaron este libro no estarían de acuerdo en la
interpretación de la norma UML.
Este problema es importante tanto para mí escribir este libro y para usted, utilizando UML. Si se quiere entender un diagrama UML, es
importante darse cuenta de que la comprensión de la norma UML no es el cuadro completo. La gente hace adoptar convenciones, tanto en la
industria ampliamente y dentro de un proyecto en particular. Como resultado, aunque el estándar UML puede ser la fuente primaria de
información sobre el UML, que puede no ser el único.
Mi actitud es que, para la mayoría de la gente, el UML tiene reglas descriptivas. El estándar UML es la mayor influencia única sobre lo que
significa UML, pero no es el único. Creo que esto se convierta particularmente cierto con UML 2, que introduce algunas convenciones de
notación que entran en conflicto con cualquiera de las definiciones de UML 1 o el uso convencional de UML, así como añade aún más
complejidad a la UML. En este libro, por lo tanto, estoy tratando de resumir el UML como lo encuentro: tanto las normas como el uso
convencional. Cuando tengo que hacer una distinción en este libro, voy a utilizar el término
uso convencional para indicar algo que no está en la norma, pero que creo que es ampliamente utilizado. Para algo que se ajusta al
estándar, voy a utilizar los términos estándar o normativo.
(Normativa es el pueblo estándares término que utilizan para referirse a una declaración que debe ser conforme a estar
23/118
válida en la norma. Así UML no normativa es una forma elegante de decir que algo es estrictamente ilegal según el estándar UML).
Cuando usted está buscando en un diagrama UML, se debe tener en cuenta que un principio general en el UML es que cualquier información
puede ser suprimido para un diagrama particular. Esta supresión puede ocurrir ya sea en general-Ocultar todo show atributos-o-no
específicamente estas tres clases. En un diagrama, por lo tanto, nunca se puede inferir nada por su ausencia. Si una multiplicidad no está
presente, no se puede inferir cuál es el valor que podría ser. Incluso si el metamodelo UML tiene un defecto, como por ejemplo [1] para los
atributos, si usted no ve la información sobre el diagrama, puede ser porque es el valor predeterminado o porque está suprimida.
Una vez dicho esto, hay algunas convenciones generales, tales como propiedades de varios valores siendo sets. En el texto, voy a señalar estas
convenciones por defecto.
Es importante no poner demasiado énfasis en tener UML legal si usted es un dibujante o blueprinter. Es más importante tener un buen diseño
para el sistema, y yo preferiría tener un buen diseño en UML ilegal que un diseño legal, pero pobre. Obviamente, buena y legal es la mejor,
pero es mejor poner su energía en tener un buen diseño de preocuparse por los arcanos de UML. (Por supuesto, usted tiene que ser legal en
UML como lenguaje de programación, o su programa no funcionará correctamente!)
El significado de UML
Una de las cuestiones incómodas sobre el UML es que, aunque la especificación describe con gran detalle lo que UML bien formada es, que no
tiene mucho que decir sobre lo que significa el UML fuera del mundo enrarecido de la meta-modelo de UML. No existe una definición formal de
cómo se asigna el UML para cualquier lenguaje de programación en particular. No se puede mirar un diagrama UML y decir exactamente lo que el
código equivalente se vería así. Sin embargo, se puede obtener una idea aproximada de lo que el código se vería así. En la práctica, eso es
suficiente para ser útil. Los equipos de desarrollo a menudo se forman sus convenciones locales para estos, y usted debe estar familiarizado con
los que está en uso.
UML no es suficiente
Aunque el UML proporciona normalmente un considerable número de diversos diagramas que ayudan a definir una aplicación, no es de
ninguna manera una lista completa de todos los diagramas útiles que puede que desee utilizar. En muchos lugares, diferentes diagramas
pueden ser útiles, y no deben dudar en utilizar un diagrama UML no si no hay diagrama UML se adapte a su propósito.
Figura 1.3 , Un diagrama de flujo de la pantalla, muestra las diferentes pantallas en una interfaz de usuario y cómo se mueve entre ellos. Yo he
visto y utilizado estos diagramas de flujo de la pantalla durante muchos años. Nunca he visto más de una definición muy aproximada de lo que
significan; no hay nada igual en el UML, pero lo he encontrado un diagrama muy útil.
Figura 1.3. Un diagrama de flujo de pantallas informal para la parte de la wiki

( http://c2.com/cgi/wiki )
24/118
Tabla 1.2 muestra otro de los favoritos: la tabla de decisiones. Las tablas de decisión son una buena manera de mostrar condiciones lógicas
complicadas. Usted puede hacer esto con un diagrama de actividad, pero una vez que llegue más allá de los casos simples, la mesa es tanto más
compacto y más clara. Una vez más, muchas formas de tablas de decisión están ahí fuera. 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 tabla de decisión

de calidad al cliente x x Y Y norte norte
El orden de prioridad Y norte Y norte Y norte
El orden internacional Y Y norte norte norte norte
Cuota $ 150 $ 100 $ 70 $ 50 $ 80 $ 60
representante de alerta • • •
Se encontrará con varios tipos de estas cosas en varios libros. No dude en probar las técnicas que parecen apropiadas para su proyecto. Si
funcionan bien, los utilizan. Si no es así, descartarlos. (Esto es, por supuesto, el mismo consejo como para diagramas UML).
Por dónde empezar con UML
Nadie, ni siquiera los creadores de la UML, comprender o utilizar la totalidad de la misma. La mayoría de la gente utiliza un pequeño subconjunto de la
UML y trabajar con eso. Usted tiene que encontrar el subconjunto de UML que funcione para usted y sus colegas.
Si usted está comenzando, sugiero que usted se concentra primero en las formas básicas de diagramas de clases y diagramas de secuencia.
Estos son los más comunes y, en mi opinión, los tipos de diagramas más útiles.
25/118
Una vez que tenga la caída de ellos, puede empezar a utilizar algunos de la notación de diagrama de clase más avanzada y echar un
vistazo a los otros tipos de diagramas. Experimentar con los diagramas y ver lo útil que son para ti. No tenga miedo de soltar cualquier que
no parecen ser útiles para su trabajo.
Capítulo 2. Proceso de Desarrollo

Como ya he mencionado, el UML surgió de un grupo de análisis y métodos de diseño orientado a objetos. Hasta cierto punto, todos ellos
mezclan un lenguaje de modelado gráfico con un proceso que describe cómo hacer para el desarrollo de software.
Curiosamente, como se formó el UML, los diferentes agentes descubrieron que aunque podían ponerse de acuerdo sobre un lenguaje de modelado,
que sin duda no podían ponerse de acuerdo sobre un proceso. Como resultado de ello, acordaron dejar a un acuerdo sobre el proceso hasta más
tarde y para confinar el UML para ser un lenguaje de modelado.
El título de este libro es UML destilada, así que podría haber ignorado proceso de forma segura. Sin embargo, no creo que las técnicas de
modelado tienen ningún sentido sin saber cómo encajan en un proceso. La forma de usar el UML depende mucho del estilo de proceso que
se utiliza.
Como resultado de ello, creo que es importante hablar de proceso de primera para que pueda ver el contexto para el uso del UML. No voy a
entrar en detalles sobre cualquier proceso particular; Simplemente quiero darle suficiente información para ver este contexto e indicadores
sobre dónde puede encontrar más información.
Cuando escuche la gente habla de la UML, se oye a menudo hablar sobre el Rational Unified Process (RUP). RUP es un proceso o, más
estrictamente, un proceso marco que se puede utilizar con UML. Pero aparte de la participación común de varias personas de Racional y el
nombre de "unificado", que no tiene ninguna relación especial con el UML. El UML se puede utilizar con cualquier proceso. RUP es un enfoque
popular y se discute en la página 25.
Los procesos iterativos y cascada
Uno de los mayores debates sobre proceso es que entre cascada y estilos iterativos. Los términos a menudo se mal utilizados, especialmente en lo
que iterativa se ve tan de moda, mientras que el proceso en cascada parece llevar pantalones a cuadros. Como resultado, muchos proyectos
pretenden hacer el desarrollo iterativo, pero realmente están haciendo cascada.
La diferencia esencial entre los dos es la forma de romper un proyecto en trozos más pequeños. Si usted tiene un proyecto que crees que va
a tomar un año, pocas personas se sienten cómodos diciendo que el equipo que se vaya por un año y volver cuando haya terminado.
Algunos desglose es necesario para que la gente pueda abordar el problema y seguir el progreso.
los cascada estilo rompe un proyecto basado en la actividad. Para construir el software, lo que tiene que hacer ciertas actividades: análisis de
requerimientos, diseño, codificación y pruebas. Nuestro proyecto de 1 año por lo tanto 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.
los iterativo estilo rompe un proyecto de subconjuntos de funcionalidad. Es posible que tome un año y dividirlo en iteraciones de 3 meses. En
la primera iteración, se tomaría una cuarta parte de los requisitos y hacer el ciclo de vida del software completo para ese trimestre: análisis,
diseño, código, y la prueba. Al final de la primera iteración, que tendría un sistema que hace un cuarto de la funcionalidad necesaria.
Entonces será hacer una segunda iteración de manera que al final de los 6 meses, que tendría un sistema que hace 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
de fugas en el proceso.
Con el desarrollo de la cascada, por lo general hay algún tipo de traspaso formal entre cada fase, pero a menudo hay expulsiones. Durante la
codificación, algo que puede llegar a que te hace volver a examinar el análisis y diseño. Por cierto, no debe asumir que todo el diseño se
termina cuando comienza la codificación. Es inevitable que los análisis y diseño decisiones tendrán que ser revisados en las fases posteriores.
Sin embargo, estas expulsiones son excepciones y deben minimizarse tanto como sea posible.
Con iteración, por lo general ve algún tipo de actividad de exploración antes de que los verdaderos iteraciones comienzan. Por lo menos, esto hará
que una visión de alto nivel de los requisitos: al menos lo suficiente como para romper los requisitos abajo en las iteraciones que seguirán. Algunas
decisiones de diseño de alto nivel pueden ocurrir durante la exploración también. En el otro extremo, si bien cada iteración debe producir software
integrado listo para la producción, a menudo no acaba de llegar a ese punto y necesita un periodo de estabilización para limar los últimos errores.
Además, algunas actividades, como la formación de los usuarios, se dejan para el final.
Usted también no puede poner el sistema en producción a finales de cada iteración, pero el sistema debe ser de calidad de la producción. A
menudo, sin embargo, puede poner el sistema en producción a intervalos regulares; esto es bueno porque se obtiene el valor del sistema
anterior y se obtiene retroalimentación de mejor calidad. En esta situación, se oye a menudo de un proyecto que tiene múltiples lanzamientos, cada
uno de los cuales se descompone en varios iteraciones.
El desarrollo iterativo ha sido objeto de muchos nombres: incrementales, espiral, evolutiva, y la primavera a la mente jacuzzi. Varias personas
hacen distinciones entre ellos, pero las diferencias no son ni ampliamente de acuerdo en que ni importante en comparación con la dicotomía
iterativo / catarata.
Usted puede tener enfoques híbridos. [McConnell] describe la entrega por etapas ciclo de vida mediante el cual el análisis y diseño de alto nivel
se realizan en primer lugar, en un estilo de cascada, y luego la codificación y las pruebas se dividen en iteraciones. Tal proyecto podría tener 4
meses de análisis y diseño seguido por cuatro de 2 meses iterativo obra del sistema.
La mayoría de los escritores de proceso de software en los últimos años, especialmente en la comunidad orientada a objetos, no les gusta el
enfoque de cascada. De las muchas razones para esto, la más fundamental es que es muy difícil decir si el proyecto es realmente en la pista con
un proceso de cascada. Es demasiado fácil para declarar la victoria con las fases tempranas y ocultar una hoja de horario. Por lo general, la única
forma en que realmente puede saber si usted está en pista es la producción de la prueba, el software integrado. Al hacer esto en varias
ocasiones, un estilo iterativo le da una mejor advertencia si algo va mal.
Por esa sola razón, recomiendo fuertemente que los proyectos no utilizan un enfoque de cascada puro. Al menos debe utilización etapas del
parto, si no es una técnica iterativa más puro.
La comunidad OO ha sido durante mucho tiempo a favor del desarrollo iterativo, y es seguro decir que casi todos los involucrados en la
construcción del UML está a favor de al menos alguna forma de desarrollo iterativo. Mi sentido de la práctica industrial es que el desarrollo
catarata sigue siendo el método más común, sin embargo. Una razón de esto es lo que me refiero al desarrollo como pseudoiterative: La gente
dice estar haciendo el desarrollo iterativo, pero son, de hecho, haciendo cascada. Los síntomas comunes de esto son:
• "Estamos haciendo un análisis de iteración seguido por dos iteraciones de diseño...."

• "El código de este iteración es muy verde todavía, pero vamos a limpiarlo al final."
Es particularmente importante que cada iteración produce a prueba, código integrado que está tan cerca de la calidad de producción posible.
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 al igual que al
final del proyecto. La prueba debe ser que cualquier iteración que no está programado para ser lanzado podría ser liberado sin sustancial el
trabajo de desarrollo adicional.
Una técnica común con iteraciones es utilizar boxeo tiempo. Esto obliga a una iteración a ser un periodo de tiempo fijo. Si parece que no se
puede construir todo lo que la intención de construir durante una iteración, debe decidir a deslizarse algunas funciones de la iteración; no hay
que deslizar la fecha de la iteración.
27/118
La mayoría de los proyectos que utilizan el desarrollo iterativo utilizan la misma longitud de iteración a través del proyecto; de esa manera, se obtiene un
ritmo regular de generaciones.
Me gusta el boxeo tiempo porque la gente por lo general tienen dificultades para deslizarse funcionalidad. Con la práctica función de deslizamiento con regularidad,
que están en una mejor posición para hacer una elección inteligente en un gran deslizamiento de liberación entre una fecha y una función de deslizamiento. la
función se deslice durante iteraciones también es eficaz en ayudar a las personas a aprender lo que las prioridades son las necesidades reales.
Una de las preocupaciones más comunes sobre el desarrollo iterativo es la cuestión de la reanudación. El desarrollo iterativo asume
explícitamente que se le reelaboración y borrar el código existente durante las iteraciones posteriores de un proyecto. En muchos dominios, tales
como la fabricación, la reanudación es visto como un desperdicio. Pero el software no es como la fabricación; como resultado, a menudo es más
eficiente para reelaborar el código existente que parchear alrededor de código que fue mal diseñado. Una serie de prácticas técnicas puede
ayudar mucho a hacer retrabajo sea más eficiente.
• pruebas de regresión automatizadas por lo que le ayudará a detectar rápidamente los defectos que se hayan podido adoptar cuando
se están cambiando las cosas. La familia xUnit de los marcos de prueba es una herramienta particularmente valiosa para la
construcción de pruebas unitarias automatizadas. A partir de la original de JUnit http://junit.org , Ahora hay puertos a 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 de la unidad debe ser
aproximadamente del mismo tamaño que el código de producción.
• refactoring es una técnica disciplinada para cambiar el software existente [Fowler, refactorización]. Refactorización funciona mediante el uso de
una serie de pequeñas transformaciones de comportamiento que preserva a la base de código. Muchas de estas transformaciones se pueden
automatizar (ver
http://www.refactoring.com ).
• Integración continua mantiene un equipo en sincronía para evitar ciclos de integración dolorosas [Fowler y Foemmel]. En el centro de esta se encuentra
un proceso de construcción totalmente automatizado que se puede inició automáticamente cada vez que cualquier miembro del equipo código de cheques
en el código base. Se espera que los desarrolladores de comprobar a diario, por lo que automatizan compilaciones son hecho muchas veces al día. El
proceso de construcción incluye la ejecución de un gran bloque de pruebas de regresión automatizadas de manera que cualquier inconsistencia se
capturan rápidamente para que puedan ser fijadas fácilmente.
Todas estas prácticas técnicas se han popularizado recientemente por la programación extrema [Beck], a pesar de que se utilizaron
antes y puede, y debe, ser utilizado si se utiliza o no XP o cualquier otro proceso ágil.
Planificación predictivo y adaptativo
Una de las razones que perdura la cascada es el deseo de previsibilidad en el desarrollo de software. Nada es más frustrante que no tener una
idea clara de cuánto será el costo de construir algún tipo de software y cuánto tiempo se tardará en construirlo.
Un enfoque predictivo se ve a hacer el trabajo al principio del proyecto con el fin de obtener una mayor comprensión de lo que hay que hacer
después. De esta manera, se puede llegar a un punto en la última parte del proyecto se puede estimar con un grado razonable de precisión.
Con la planificación predictiva, un proyecto consta de dos etapas. La primera etapa viene con planes y es difícil de predecir, pero la segunda
etapa es mucho más predecible porque los planes están en su lugar.
Esto no es necesariamente un asunto de blanco y negro. A medida que el proyecto avanza, se obtiene gradualmente una mayor previsibilidad. E incluso
una vez que tenga un plan de predicción, las cosas van a salir mal. Sólo tiene que esperar que las desviaciones se vuelven menos significativos una vez al
plan sólido está en su lugar.
Sin embargo, hay un debate considerable sobre si muchos proyectos de software pueden nunca ser predecible. En el corazón de esta
cuestión es el análisis de requerimientos. Una de las fuentes únicas de la complejidad en los proyectos de software es la dificultad en la
comprensión de los requisitos para un sistema de software. La mayoría de los proyectos de software experiencia significativa requisitos batir: cambios
en los requisitos en las etapas posteriores del proyecto. Estos cambios hacen añicos las bases de una
28/118
plan de predicción. Puede combatir estos cambios mediante la congelación de los requisitos desde el principio y no permite cambios, pero
esto corre el riesgo de tener un sistema que ya no satisface las necesidades de sus usuarios.
Este problema lleva a dos reacciones muy diferentes. Una ruta es poner más esfuerzo en el proceso en sí requisitos. De esta manera, se
puede obtener un conjunto más preciso de las necesidades, lo que reducirá la pérdida de clientes.
Otra escuela sostiene que los requisitos de rotación es inevitable, que es demasiado difícil para muchos proyectos para estabilizar requisitos lo
suficiente como para utilizar un plan de predicción. Esto puede ser debido a la gran dificultad de imaginar lo que el software puede hacer o porque
las condiciones del mercado obligan a cambios impredecibles. Esta escuela de pensamiento aboga la planificación adaptativa, mediante el cual
predictividad es visto como una ilusión. En lugar de engañarnos a nosotros mismos con la previsibilidad ilusoria, debemos hacer frente a la
realidad del cambio constante y el uso de un enfoque de planificación que trata el cambio como una constante en un proyecto de software. Este
cambio se controla de modo que el proyecto ofrece el mejor software que puede; pero aunque el proyecto es controlable, no es predecible.
La diferencia entre un proyecto de predicción y un proyecto de adaptación a la superficie en muchas formas en que la gente habla de cómo va
el proyecto. Cuando se habla de un proyecto que está haciendo bien porque va de acuerdo al plan, que es una forma de predicción de pensar.
No se puede decir "de acuerdo al plan" en un entorno de adaptación, ya que el plan siempre está cambiando. Esto no quiere decir que los
proyectos de adaptación no planean; por lo general piensan mucho, pero el plan es tratado como una línea de base para evaluar las
consecuencias del cambio en lugar de como una predicción del futuro.
Con un plan de predicción, se puede desarrollar un / contrato de precio fijo-fijo alcance. Tal contrato dice exactamente lo que debe ser construido,
cuánto va a costar, y cuándo va a ser entregado. Tal fijación no es posible con un plan de adaptación. Puede fijar un presupuesto y un tiempo
para la entrega, pero no se puede arreglar lo que la funcionalidad será entregado. Un contrato de adaptación supone que los usuarios van a
colaborar con el equipo de desarrollo de volver a evaluar periódicamente lo que necesita ser construido funcionalidad y cancelará el proyecto si el
progreso termina siendo demasiado lento. Como tal, un proceso de planificación adaptativa se puede fijar precio / 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 preciso, precisa y estable de requisitos. Si no puede estabilizar sus requisitos, el plan de
predicción se basa en la arena y las posibilidades de que el proyecto sigue su curso. Esto lleva a dos importantes consejos.
1. No hacer un plan de predicción hasta que tenga los requisitos precisos y exactos y están
seguros de que no va a cambiar significativamente.
2. Si usted no puede obtener los requisitos exactos, precisos y estables, utilizar un estilo de planificación adaptativa.
Capacidad de predicción y la adaptabilidad de alimentación en la elección del ciclo de vida. Un plan de adaptación absolutamente requiere un proceso
iterativo. la planificación predictiva puede hacerse de cualquier manera, aunque es más fácil ver cómo funciona con cascada o un enfoque de entrega por
etapas.
Los procesos ágiles
En los últimos años, ha habido mucho interés en los procesos de software ágiles. Ágil es un término general que abarca muchos procesos que
comparten un conjunto común de valores y principios definidos por el Manifiesto de desarrollo de software ágil ( http://agileManifesto.org ).
Ejemplos de estos procesos son Extreme Programming (XP), Scrum, Feature Driven Development (FDD), Crystal, y DSDM (Dynamic Systems
Método de Desarrollo).
En términos de nuestra discusión, procesos ágiles son fuertemente adaptativa en su naturaleza. Son también muy procesos orientados a las
personas. enfoques ágiles suponen que el factor más importante en el éxito de un proyecto es la calidad de la gente sobre el proyecto y lo
bien que trabajan juntos en términos humanos. ¿Qué proceso que utilizan y qué herramientas que usan son estrictamente efectos de segundo
orden.
29/118
Los métodos ágiles tienden a utilizar iteraciones cortas, encajadas en tiempo, con más frecuencia de un mes o menos. Debido a que no le dan mucha
importancia a los documentos, los enfoques ágiles desprecian el uso de UML en el modo de anteproyecto. La mayoría utiliza el UML en modo de boceto, con
unos pocos Defender usarlo como un lenguaje de programación.
Los procesos ágiles tienden a ser bajos en ceremonia. Un alto ceremonia, o de peso pesado, proceso tiene una gran cantidad de documentos y
puntos de control durante el proyecto. Los procesos ágiles consideran que la ceremonia hace que sea más difícil hacer cambios y funciona a
contrapelo de las personas con talento. Como resultado, procesos ágiles se caracterizan a menudo como ligero. Es importante darse cuenta de que
la falta de ceremonia es una consecuencia de la adaptabilidad y la gente de orientación en lugar de una propiedad fundamental.
Proceso racional unificado
Aunque el Rational Unified Process (RUP) es independiente de la UML, los dos se habla a menudo juntos. Así que creo que vale la pena
decir algunas cosas sobre él aquí.
Aunque RUP se llama un proceso, que en realidad es un marco de proceso, proporcionando un vocabulario y una estructura suelta para hablar
de procesos. Cuando se utiliza RUP, lo primero que hay que hacer es elegir un caso del complejo: el proceso que se va a utilizar en el proyecto.
casos de desarrollo pueden variar ampliamente, por lo que no asuma que su caso el desarrollo se verá que al igual que cualquier otro caso el
desarrollo. La elección de un caso de desarrollo necesita a alguien desde el principio que está muy familiarizado con RUP: alguien que pueda
adaptar RUP para las necesidades de un proyecto en particular. Por otra parte, hay un número creciente de casos de desarrollo envasados para
empezar.
Cualquiera que sea el caso, el desarrollo, RUP es esencialmente un proceso iterativo. Un estilo de cascada no es compatible con la filosofía
de RUP, aunque por desgracia no es raro encontrarse con proyectos que utilizan un proceso de estilo cascada y se visten con la ropa de
RUP.
Todos los proyectos RUP deben seguir cuatro fases.
1. Comienzo hace una evaluación inicial de un proyecto. Normalmente, en principio, a decidir si

para cometer fondos suficientes para hacer una fase de elaboración.
2. Elaboración identifica los casos de uso principales del proyecto y se basa en el software de iteraciones
con el fin de sacudir la arquitectura del sistema. Al final de elaboración, usted debe tener un buen sentido de los requisitos y de un
sistema de trabajo del esqueleto que actúa como la semilla del desarrollo. En particular, debería haber encontrado y resuelto los
principales riesgos para el proyecto.
3. Construcción continúa el proceso de construcción, el desarrollo de la funcionalidad suficiente para liberar.

4. Transición incluye diversas actividades de la fase tardía de que no se hacen de forma iterativa. estos pueden
incluir el despliegue en el centro de datos, formación de usuarios, y similares.
Hay una buena cantidad de borrosidad entre las fases, especialmente entre elaboración y construcción. Para algunos, el cambio hacia la
construcción es el punto en el que se puede pasar a un modo de planificación predictiva. Para otros, se limita a indicar el punto en el que usted
tiene una visión amplia de requisitos y una arquitectura que cree que va a durar el resto del proyecto.
A veces, RUP se conoce como el Proceso Unificado (UP). Esto se hace generalmente por las organizaciones que deseen hacer uso de la terminología y el
estilo general de RUP sin necesidad de utilizar los productos con licencia de Rational Software. Se puede pensar en RUP como oferta de productos de
Rational basados en la UP, o puede pensar en RUP y UP como la misma cosa. De cualquier manera, usted encontrará personas que están de acuerdo con
usted.
Montaje de un proceso a un proyecto
proyectos de software difieren mucho entre sí. La manera de ir sobre el desarrollo de software depende de muchos factores: el tipo de sistema
que estamos construyendo, la tecnología que está usando, el tamaño y la distribución de 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 haya una talla única para todos los procesos que
funcione para todos los proyectos.
En consecuencia, siempre se tiene que adaptar un proceso para adaptarse a su entorno particular. Una de las primeras cosas que hay que
hacer es mirar a su proyecto y considerar los procesos que parecen cerca de un ajuste. Esto debe darle una lista corta de los procesos a
considerar.
A continuación, debe considerar qué adaptaciones necesita hacer para adaptarse a su proyecto. Tiene que ser un poco cuidadoso con esto.
Muchos procesos son difíciles de apreciar en su totalidad hasta que haya trabajado con ellos. En estos casos, a menudo vale la pena utilizar el
proceso fuera de la caja por un par de iteraciones hasta que aprenda cómo funciona. A continuación, puede empezar a modificar el proceso. Si
desde el principio que esté más familiarizado con el funcionamiento de un proceso, puede modificar desde el principio. Recuerde que por lo
general es más fácil comenzar con muy poco y añadir cosas de lo que es comenzar con demasiado y tomar las cosas de distancia.
Patrones
El UML le indica cómo expresar un diseño orientado a objetos. Los patrones se ven, en cambio, en los resultados del proceso:
diseños de ejemplo.
Muchas personas han comentado que los proyectos tienen problemas porque las personas involucradas no eran conscientes de los
diseños que son bien conocidos para aquellos con más experiencia. Patrones describen las formas más comunes de hacer las cosas y
son recogidos por las personas que manchan la repetición de temas en los diseños. Estas personas toman cada tema y lo describen de
manera que otras personas puedan leer el patrón y ver cómo aplicarlo.
Veamos un ejemplo. Decir que usted tiene algunos de los objetos que se ejecutan en un proceso en el escritorio y que necesitan
comunicarse con otros objetos que se ejecutan en otro proceso. Tal vez este proceso es también en su escritorio; quizás que
reside en otro lugar. Usted no quiere que los objetos en su sistema a tener que preocuparse por encontrar otros objetos en la
red o la ejecución de 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, utilizando el habitual en proceso envía el mensaje. El proxy
entonces es responsable de pasar los mensajes en el objeto real, dondequiera que residan.
La representación es una técnica común que se utiliza en las redes y en otros lugares. La gente tiene mucha experiencia el uso
de proxies, sabiendo cómo se pueden utilizar, cuáles son las ventajas que pueden aportar, sus limitaciones y cómo ponerlas en
práctica. Métodos de libros como éste no hable de este conocimiento; todo lo que discutir es cómo hacer un diagrama de un
proxy, aunque útiles, no es tan útil como discutir la experiencia que implica proxies.
A principios de 1990, algunas personas comenzaron a capturar esta experiencia. Ellos formaron una comunidad interesada en
los patrones de escritura. Estas personas patrocinan conferencias y se han producido varios libros.
El libro más famoso patrones para salir de este grupo es [Banda de los Cuatro], que analiza 23 patrones de diseño en detalle. Si
usted quiere saber acerca de proxies, este libro pasa diez páginas sobre el tema, dando detalles acerca de cómo los objetos
trabajan juntos, los beneficios y las limitaciones del modelo, las variaciones comunes y sugerencias de implementación.
Un patrón es mucho más que un modelo. Un patrón debe incluir también la razón por qué es como es. A menudo se dice que un
patrón es una solución a un problema. El patrón debe identificar claramente el problema, explicar por qué se soluciona el
problema, y también explicar las circunstancias en las que trabaja el patrón y no funciona.
Los patrones son importantes porque son la siguiente etapa más allá de la comprensión de los fundamentos de un idioma o una
técnica de modelado. Patrones que dan una serie de soluciones y también
31/118
mostrar lo que hace un buen modelo y cómo ir sobre la construcción de un modelo. Patrones enseñan por ejemplo.
Cuando empecé, me preguntaba por qué tenía que inventar cosas desde cero. ¿Por qué no tengo manuales para mostrarme
cómo hacer las cosas comunes? La comunidad de patrones está tratando de construir estos manuales.
En la actualidad hay muchos patrones de libros por ahí, y que varían mucho en calidad. Mis favoritos son [Banda de los
Cuatro], [POSA1], [POSA2], [Patrones J2EE Core], [Pont], y con la falta de modestia adecuado [Fowler, AP] y [Fowler, P de
EAA]. También puede echar un vistazo a la página de los patrones de la casa: http://www.hillside.net/patterns .
Sin embargo confía en que está con su proceso cuando se empieza, es esencial para aprender a medida que avanza. De hecho, uno de los
grandes beneficios de desarrollo iterativo es que soporta la mejora de procesos frecuentes.
Al final de cada iteración, llevar a cabo una retrospectiva de iteración, por lo que 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 sus iteraciones son cortos. Una buena manera de hacer esto es hacer una lista
con tres categorías:
1. Guardar: cosas que funcionaron bien que usted quiere asegurarse de que siguen haciendo
2. Problemas: áreas que no están funcionando bien
3. Tratar: cambios en el proceso para mejorarlo
Puede comenzar cada iteración retrospectiva después de la primera mediante la revisión de los artículos de la sesión anterior y ver cómo las
cosas han cambiado. No se olvide de la lista de cosas a tener; es importante no perder de vista lo que está funcionando. 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 una versión mayor, es posible que desee considerar una más formal retrospectiva proyecto que durará un par de
días; ver http://www.retrospectives.com/ y [Kerth] para más detalles. Una de mis mayores irritaciones es cómo las organizaciones de forma
sistemática no para aprender de su propia experiencia y terminan haciendo costosos errores una y otra vez.
Montaje del UML en un proceso
Cuando se ven en lenguajes de modelado gráfico, la gente suele pensar de ellos en el contexto de un proceso en cascada. Un proceso de
cascada por lo general tiene documentos que actúan como los traspasos entre análisis, diseño, y las fases de codificación. Los modelos gráficos a
menudo pueden formar una parte importante de estos documentos. De hecho, muchos de los métodos estructurados a partir de los años 1970 y
1980 se habla mucho de los modelos de análisis y diseño de este tipo.
Aun cuando no se utiliza un enfoque de cascada, que todavía lo hacen las actividades de análisis, diseño, codificación y pruebas. Puede ejecutar un
proyecto iterativo con 1 semana de iteraciones, con cada semana que una miniwaterfall.
Utilizando el UML no implica necesariamente el desarrollo de documentos o la alimentación de una herramienta CASE complejo. Mucha gente
dibujar diagramas UML en pizarras sólo durante una reunión para ayudar a comunicar sus ideas.
Análisis de requerimientos
La actividad de análisis de requisitos consiste en tratar de averiguar lo que los usuarios y clientes de un esfuerzo de software quieren que haga
el sistema. Una serie de técnicas UML puede ser útil aquí:
• Los casos de uso, que describen cómo las personas interactúan con el sistema.
• Un diagrama de clases trazada desde el punto de vista conceptual, que puede ser una buena manera de construir un vocabulario
riguroso del dominio.
32/118
• Un diagrama de actividad, que puede mostrar el flujo de trabajo de la organización, que muestra cómo interactúan los programas y las actividades
humanas. Un diagrama de actividad se puede mostrar el contexto de casos de uso y también los detalles de cómo funciona un caso de uso
complicado.
• Un diagrama de estado, que puede ser útil si un concepto tiene un ciclo de vida interesante, con varios estados y eventos que
cambian ese estado.
Cuando se trabaja en el análisis de requisitos, recuerde que lo más importante es la comunicación con sus usuarios y clientes. Por lo general,
no son gente del software y no estarán familiarizados con UML o cualquier otra técnica. Aún así, he tenido éxito en el uso de estas técnicas con
las personas sin conocimientos técnicos. Para ello, recuerde que es importante mantener la notación a un mínimo. No introducir nada que
específica a la aplicación de software.
Esté preparado para romper las reglas del UML en cualquier momento si le ayuda a comunicarse mejor. El mayor riesgo con el uso de UML en
el análisis es que se dibuja diagramas que los expertos en el dominio no entienden por completo. Un diagrama que no se entiende por las
personas que conocen el dominio es peor que inútil; lo único que hace es criar un falso sentido de confianza para el equipo de desarrollo.
Diseño
Cuando usted está haciendo el diseño, se puede obtener más técnica con los diagramas. Puede utilizar notación más y ser más
precisos acerca de su notación. Algunas técnicas útiles son
• Los diagramas de clases desde la perspectiva del software. Estos muestran las clases en el software y cómo se relacionan entre sí.
• Los diagramas de secuencia para escenarios comunes. Un enfoque valioso es escoger los escenarios más importantes e interesantes
de los casos de uso y el uso de tarjetas de CRC o diagramas de secuencia de averiguar lo que sucede en el software.
• Los diagramas de paquetes para ver la estructura a gran escala del software.
• diagramas de estado para las clases con ciclos biológicos complejos.
• Los diagramas de despliegue para mostrar la distribución física del software.
Muchas de estas mismas técnicas se pueden utilizar para documentar el software una vez que se ha escrito. Esto puede ayudar a la gente
encontrar su camino en el software si tienen que trabajar en él y no están familiarizados con el código.
Con un ciclo de vida en cascada, que haría estos diagramas y actividades como parte de las fases. Los documentos de fin de fase incluyen
generalmente los diagramas UML apropiadas para esa actividad. Un estilo de cascada por lo general implica que el UML se utiliza como
modelo.
En un estilo iterativo, los diagramas UML se pueden utilizar ya sea en un modelo o un estilo de dibujo. Con un plano, los diagramas de
análisis por lo general se construirán en la iteración anterior a la que se basa la funcionalidad. Cada iteración no se inicia desde cero; Más
bien, se modifica el régimen existente de documentos, destacando los cambios en la nueva iteración.
Blueprint diseños se realiza temprano en la iteración y se pueden hacer en piezas para diferentes bits de funcionalidad que son objeto de la
iteración. Una vez más, la iteración implica hacer cambios a un modelo existente en lugar de construir un nuevo modelo cada vez.
Utilizando el UML en modo de boceto implica un proceso más fluido. Un método consiste en pasar un par de días en el comienzo de una
iteración, esbozar el diseño para esa iteración. También se puede hacer sesiones cortas de diseño en cualquier momento durante la iteración, la
creación de una reunión rápida durante media hora cada vez que un desarrollador comienza a hacer frente a una función no trivial.
Con un plan, se espera que la implementación del código de seguir los diagramas. Un cambio del modelo es una desviación que necesita
revisión de los diseñadores que hicieron el proyecto. Un bosquejo se trata generalmente más como un primer corte en el diseño; Si, durante
la codificación, la gente encuentra que el dibujo no es exactamente correcto, deben sentirse libres de cambiar el diseño. Los ejecutores
tienen que utilizar su criterio para determinar si el cambio necesita una discusión más amplia de entender todas las ramificaciones.
33/118
Una de mis preocupaciones con los modelos que es mi propia observación de que es muy difícil conseguir que la derecha, incluso para un buen diseñador. A
menudo encuentro que mis propios diseños no sobreviven contacto con la codificación intacta. Me sigue pareciendo UML esboza útil, pero no me parece que
puedan ser tratados como absolutos.
En ambos modos, tiene sentido para explorar una serie de alternativas de diseño. Por lo general es mejor para explorar alternativas en
modo de boceto para que pueda generar y cambiar las alternativas rápidamente. Una vez que elija un diseño para funcionar con, puede
utilizar ese boceto o un detalle en un plano.
Documentación
Una vez que haya construido el software, puede utilizar el UML para ayudar a documentar lo que ha hecho. Por esto, me parece diagramas
UML útiles para conseguir una comprensión global de un sistema. Al hacer esto, sin embargo, debo subrayar que no creo en la producción de
diagramas detallados de todo el sistema. Para citar Ward Cunningham [Cunningham]:
Cuidadosamente seleccionados y memos bien escritas pueden sustituir fácilmente la documentación del tradicional
diseño integral. Este último rara vez brilla excepto en puntos aislados. Elevar esos puntos. . . y olvidarse del resto.
(P. 384)
Creo que la documentación detallada debe ser generada a partir del código como, por ejemplo, JavaDoc. Usted debe escribir documentación
adicional para resaltar conceptos importantes. Piense en esto como que comprende un primer paso para el lector antes de que él o ella entra
en los detalles basados en códigos. Me gusta estructurar estos documentos como en prosa, lo suficientemente corto como para leer con una
taza de café, utilizando diagramas UML para ayudar a ilustrar la discusión. Yo prefiero los diagramas como bocetos que ponen de relieve las
partes más importantes del sistema. Obviamente, el autor del documento tiene que decidir qué es importante y qué no lo es, pero el escritor es
mucho mejor equipado que el lector haga eso.
Un diagrama de paquetes hace que una buena hoja de ruta lógica del sistema. Este diagrama ayuda a entender las piezas lógicas del sistema
y ver las dependencias y mantenerlos bajo control. Un diagrama de despliegue (ver Capí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 me presento cada operación en cada clase. Muestro sólo las características
importantes que ayudan a entender lo que está ahí. Este diagrama de clases actúa como una tabla gráfica de contenido.
El diagrama de clases debe ser apoyado por un puñado de diagramas de interacción que muestran las interacciones más importantes en
el sistema. Una vez más, la selectividad es importante aquí; recuerda que, en este tipo de documentos, integralidad es el enemigo de la
comprensibilidad.
Si una clase tiene el comportamiento del ciclo de vida complejo, que dibujar un diagrama de máquina de estados (ver capítulo 10 ) Para describirlo. Lo hago sólo si
el comportamiento es lo suficientemente complejo, que me parece que no sucede a menudo.
menudo voy a incluir algún código importante, escrito en un estilo de programa de leer y escribir. Si un algoritmo especialmente complejo está
implicado, voy a considerar el uso de un diagrama de actividad (ver Capítulo 11 ) Pero sólo si me da más entendimiento que el código solo.
Si encuentro conceptos que están surgiendo en varias ocasiones, utilizo patrones (página 27) para captar las ideas básicas.
Una de las cosas más importantes para el documento es el alternativas de diseño que no toma y por qué no hicieron ellos. Eso es a menudo la
pieza más olvidado, pero más útil de la documentación externa que puede proporcionar.
Código heredado comprensión
El UML puede ayudar a determinar un montón retorcido de código desconocido en un par de maneras. La construcción de un boceto de datos clave puede
actuar como un mecanismo de toma de notas gráfica que le ayuda a capturar información importante a medida que aprende sobre él. Bocetos de las clases
dominantes en un paquete y sus interacciones clave pueden ayudar a aclarar lo que está pasando.
34/118
Con herramientas modernas, puede generar diagramas detallados de las partes fundamentales de un sistema. No utilice estas herramientas para generar
informes en papel grandes; en cambio, los utilizan para perforar en áreas clave como usted está explorando el propio código. Una capacidad
particularmente agradable es la de generar un diagrama de secuencia para ver cómo varios objetos colaboran en el manejo de un método complejo.
La elección de un Proceso de Desarrollo
Estoy muy a favor de los procesos de desarrollo iterativo. Como he dicho en este libro antes: Debe utilizar el desarrollo iterativo sólo en
proyectos que desea tener éxito.
Tal vez eso es un poco simplista, pero a medida que envejezco, me sale más agresivo sobre el uso de desarrollo iterativo. bien hecho, es una
técnica esencial, uno puede utilizar para exponer riesgo temprano y obtener un mejor control sobre el desarrollo. No es lo mismo que tener
ninguna gestión, aunque para ser justos, debo señalar que algunos han utilizado de esa manera. Se necesita ser bien planificada. Pero es un
enfoque sólido, y cada libro de desarrollo OO anima a usarlo, por una buena razón.
Usted no debe sorprenderse al escuchar que como uno de los autores del Manifiesto de desarrollo ágil de software, soy muy fan de los
enfoques ágiles. También he tenido muchas experiencias positivas con la programación extrema, y, ciertamente, usted debe considerar sus
prácticas muy en serio.

Libros en el proceso de software han sido siempre común, y el auge de desarrollo ágil de software ha llevado a muchos nuevos libros. En
general, mi libro favorito en proceso en general es [McConnell]. Se da una cobertura amplia y práctica de muchas de las cuestiones implicadas
en el desarrollo de software y una larga lista de prácticas útiles.
Desde la comunidad ágil, [Cockburn, ágil] y [Highsmith] proporciona una buena visión general. Para una gran cantidad de buenos consejos acerca de
cómo aplicar el UML de una manera ágil, véase [Ambler].
Uno de los métodos más populares es ágil Extreme Programming (XP), que se puede profundizar en medio de dichos sitios Web como http://xprogrammin
y http://www.extremeprogramming.org . XP ha dado lugar a muchos libros, por lo que ahora me refiero a él como la metodología anteriormente
ligero. El punto de partida habitual es [Beck].
Aunque está escrito para XP, [Beck y Fowler] da más detalles sobre la planificación de un proyecto iterativo. Gran parte de esto también está
cubierto por los otros libros de XP, pero si usted está interesado sólo en el aspecto de planificación, esto sería una buena opción.
Para obtener más información sobre el Rational Unified Process, mi favorito es la introducción [Kruchten].
Capítulo 3. Diagramas de Clases: Los Fundamentos

Si alguien fuera a venir a usted en un callejón oscuro y decir, "Psst, quiero ver un diagrama UML?" ese diagrama sería probablemente 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 también sujetos a la mayor gama de conceptos de modelado. Aunque los elementos
básicos son necesarios por todo el mundo, los conceptos avanzados se utilizan con menos frecuencia. Por lo tanto, me he roto la discusión de los
diagramas de clases en dos partes: lo esencial (este capítulo) y el avanzado ( Capítulo 5 ).
35/118
UN diagrama de clase describe los tipos de objetos en el sistema y los diferentes tipos de relaciones estáticas que existen entre ellos. Los
diagramas de clases muestran también las propiedades y operaciones de una categoría y las restricciones que se aplican a la forma en que los
objetos están conectados. El UML utiliza el término
característica como un 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 en el diagrama son las 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 sencillo
propiedades
propiedades representar las características estructurales de una clase. Como primera aproximación, se puede pensar que las propiedades como correspondientes a
los campos de una clase. La realidad es más bien involucrado, como veremos más adelante, pero eso es un lugar razonable para empezar.
Las propiedades son un solo concepto, pero aparecen en dos notaciones bastante distintas: atributos y asociaciones. Aunque se ven
muy diferentes en un diagrama, que son realmente la misma cosa.
atributos
los atributo notación describe una propiedad como una línea de texto dentro de la caja de clase en sí. La forma completa de un atributo es:
36/118
nombre de la visibilidad: Tipo multiplicidad = por defecto {propiedad cuerdas}
Un ejemplo de esto es:
- name: String [1] = "sin título" {} readOnly
Solo el nombre es necesario.
• Esta visibilidad marcador indica si el atributo es público (+) o privada (-); Voy a hablar de otras condiciones de visibilidad en
la página 83.
• los nombre del atributo de cómo la clase se refiere al atributo de más o menos corresponde al nombre de un campo en un lenguaje
de programación.
• los tipo del atributo indica una restricción sobre el tipo de objeto puede ser colocado en el atributo. Se puede pensar en esto como
el tipo de un campo en un lenguaje de programación.
• Lo explicaré multiplicidad en la página 38.
• los valor por defecto es el valor de un objeto recién creado si el atributo no se especifica durante la creación.
• los { propiedad-string} le permite indicar propiedades adicionales para el atributo. En el ejemplo, he utilizado { solo lectura} para indicar
que los clientes no pueden modificar la propiedad. Si esto no se encuentra, por lo general puede asumir que el atributo es modificable.
Voy a describir otras cadenas de propiedades a medida que avanzamos.
asociaciones
La otra manera de anotar una propiedad es como una asociación. Gran parte de la misma información que se puede mostrar en un atributo
aparece en una asociación. Las figuras 3.2 y 3.3 mostrar las mismas propiedades representadas en los dos notaciones diferentes.
Figura 3.2. Mostrando propiedades de un pedido como atributos
Figura 3.3. Mostrando propiedades de un pedido como asociaciones
Un asociación es una línea continua entre dos clases, dirigido desde la clase de origen a la clase objetivo. El nombre de la propiedad va
al final de destino de la asociación, junto con su multiplicidad. El extremo de destino de la asociación vincula a la clase que es el tipo de
la propiedad.
37/118
Aunque la mayor parte de la misma información aparece en las dos anotaciones, algunos artículos son diferentes. En particular, las asociaciones
pueden mostrar multiplicidades en ambos extremos de la línea.
Con dos anotaciones para la misma cosa, la pregunta obvia es, ¿Por qué utilizar uno o el otro? En general, tiendo a utilizar atributos de las
cosas pequeñas, como las fechas o Booleanos-en general, los tipos de valor (página 73) -y asociaciones para las clases más importantes,
como los clientes y pedidos. También tienden a preferir utilizar cajas de clase para las clases que son significativos para el diagrama, lo que
conduce a la utilización de las asociaciones, y los atributos de las cosas menos importantes para ese diagrama. La elección es mucho más
sobre el énfasis que sobre cualquier significado subyacente.
Cuándo utilizar los diagramas de clases
Los diagramas de clases son la columna vertebral de la UML, por lo que se encontrará usando todo el tiempo. Este capítulo trata sobre los
conceptos básicos; Capítulo 5 discute muchos de los conceptos avanzados.
El problema con los diagramas de clase es que son tan rico, que puede ser abrumador para su uso. Aquí hay algunos consejos.
• No trate de utilizar todas las anotaciones disponibles para usted. Comenzar con la simple materia en este capítulo: clases,
asociaciones, atributos, la generalización y limitaciones. Introducir otros notaciones de Capítulo 5 Sólo cuando los necesite.
• He encontrado diagramas de clases conceptuales de gran utilidad en la exploración de la lengua de un negocio. Para que esto funcione,
usted tiene que trabajar duro para mantener el software fuera de la discusión y mantener la notación muy sencilla.
• No dibujar modelos para todo; en cambio, se concentran en las áreas clave. Es mejor tener unos diagramas que hacen uso y
guardarlas hasta la fecha, que tener muchos modelos obsoletos, olvidadas.
El mayor peligro con los diagramas de clases es que se puede centrarse exclusivamente en la estructura y el comportamiento de ignorar.
Por lo tanto, al elaborar los diagramas de clases para entender el software, siempre que hacer en conjunción con algún tipo de técnica de
comportamiento. Si vas así, se encontrará el intercambio entre las técnicas con frecuencia.

Todos los libros generales UML que he mencionado en el Capítulo 1 hablar de diagramas de clases con más detalle. gestión de la dependencia es
una característica crítica de los proyectos más grandes. El mejor libro sobre este tema es [Martin].
Multiplicidad
los multiplicidad de una propiedad es una indicación de cuántos objetos pueden ocupar la propiedad. Las multiplicidades más comunes que
se ven son
• 1 ( Un pedido debe tener exactamente un cliente.)

• 0..1 ( Un cliente corporativo puede o no tener un solo representante de ventas.)
• * (Un cliente no tiene que hacer un pedido y no hay límite superior para el número de órdenes de un cliente puede colocar en cero o
más órdenes.)
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 la
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 un número ilimitado). Si los límites inferior y superior son los mismos, se puede utilizar un número; por lo tanto, 1
es equivalente a 1..1. Debido a que es un caso común, * es la abreviatura de 0 .. *.
En atributos, se encuentra con diversos términos que se refieren a la multiplicidad.
• Opcional implica un límite inferior de 0.

• Obligatorio implica un límite inferior de 1 o posiblemente más.
• Single-valorado implica un límite superior de 1.
• multivalor implica un límite superior de más de 1: por lo general *.
Si tengo una propiedad con varios valores, yo prefiero usar una forma plural por su nombre.
Por defecto, los elementos en una multiplicidad de varios valores forman un conjunto, por lo que si le preguntas a un cliente por sus órdenes,
no regresan en cualquier orden. Si el orden de los pedidos en asociación tiene sentido, es necesario añadir { ordenado} al extremo de
asociación. Si desea permitir que los duplicados, añadir
{} No único . ( Si desea mostrar explícitamente el valor por defecto, puede utilizar { desordenada} y { único} .)
También puede ver los nombres orientada de recolección, tales como { bolso} para desordenada, no único.
UML 1 permitió multiplicidades discontinuos, tales como 2, 4 (es decir, 2 o 4, como en los coches en los días antes minivans).
multiplicidades discontinuos no eran muy comunes y UML 2 las retiren.
La multiplicidad por defecto de un atributo es [1]. Aunque esto es cierto en el meta-modelo, no se puede asumir que un atributo en un diagrama
que le falta una multiplicidad tiene un valor de [1], como el diagrama se puede suprimir la información de multiplicidad. Como resultado de ello,
prefiero indicar explícitamente a [1] multiplicidad si es importante.
Programación Interpretación de Propiedades
Al igual que con cualquier otra cosa en el UML, no hay una forma de interpretar las propiedades de código. La representación de software más
común es la de un campo o propiedad de su lenguaje de programación. Por lo que la clase Order Line de Figura 3.1 correspondería a algo como
lo siguiente en Java:
public class OrderLine ...

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

int Cantidad pública; Precio del dinero
público; Pedidos pública; Producto
pública;
Tenga en cuenta que un atributo corresponde normalmente a las propiedades públicas en un idioma que admite propiedades, pero a campos
privados en un idioma que no lo hace. En un lenguaje sin propiedades, puede ver los campos expuestos a través de acceso (Obtención y
establecimiento) métodos. Un atributo de sólo lectura no tendrá ningún método de ajuste (con campos) o conjunto de acciones (de propiedades).
Tenga en cuenta que si usted no da un nombre para una propiedad, es común usar el nombre de la clase de destino.
El uso de campos privados es una interpretación muy centrada en la ejecución del diagrama. Una interpretación más orientado interfaz
podría en lugar de concentrarse en los métodos que consiguen en lugar de la
39/118
los datos subyacentes. En este caso, podríamos ver los atributos de la línea de la orden correspondiente a los métodos siguientes:

cantidad int privado; producto privado; public
int getQuantity () {
Cantidad de devolución; } setQuantity pública vacío (cantidad int)
{
this.quantity = cantidad; } getPrice dinero
público () {
volver producto.getPrecio () multiplicar (cantidad).; }
En este caso, no hay campo de datos de precios; en cambio, es un valor calculado. Pero en lo que se refiere a los clientes de la clase Línea de
pedidos, que se ve igual que un campo. Los clientes no pueden saber lo que es un campo y lo que se calcula. Esta ocultación de información es la
esencia de la encapsulación.
Si tiene múltiples valores de un atributo, esto implica que los datos en cuestión es una colección. Por lo que una clase Order se referiría a un conjunto de
líneas de pedido. Debido a esta multiplicidad se ordena, que la recolección se debe pedir, (tales como una lista en Java o .NET en un IList). Si la colección
no está ordenado, debe, en sentido estricto, no tienen ningún orden significativo y por lo tanto ser implementado con un conjunto, pero la mayoría de las
personas no ordenadas implementar atributos como listas también. Algunas personas utilizan matrices, pero el UML implica un número ilimitado límite
superior, por lo que casi siempre utilizo una colección de estructura de datos.
propiedades de varios valores producen un tipo diferente de interfaz a las propiedades de un solo valor (en Java):
Orden de la clase {
Set ArtículosLínea privadas = new HashSet (); Set pública
getLineItems () {
volver Collections.unmodifiableSet (Elementos de línea); } addLineItem pública
vacío (artículo de pedido arg) {

lineItems.add (arg); } removeLineItem pública vacío (artículo de pedido
arg) {
lineItems.remove (arg); }
En la mayoría de los casos, no se asigna a una propiedad con varios valores; en cambio, se actualiza con agregar y quitar métodos. Con el fin de
controlar su propiedad Elementos de línea, la orden debe controlar la pertenencia de esa colección; como consecuencia, no debe pasar hacia fuera la
colección desnuda. En este caso, he utilizado un proxy de protección para proporcionar un envoltorio de sólo lectura a la colección. También puede
proporcionar un iterador nonupdatable o hacer una copia. Está bien para los clientes para modificar los objetos miembro, pero los clientes no deben
cambiar directamente la propia colección.
Debido atributos de varios valores implican colecciones, que casi nunca se ve clases de colección en un diagrama de clases. Se podría
mostrar sólo en los diagramas de implementación muy bajos niveles de las propias colecciones.
Usted debe tener mucho miedo de las clases que son nada más que una colección de campos y sus descriptores de acceso. diseño orientado a objetos trata
de proporcionar objetos que son capaces de hacer el comportamiento rico, por lo que no se debe simplemente proporcionando datos a otros objetos. Si va a
realizar repetidas llamadas de datos mediante el uso de métodos de acceso, eso es una señal de que algún comportamiento se debe mover al objeto que tiene
los datos.
Estos ejemplos también refuerzan el hecho de que no existe una correspondencia estricta y rápida entre el UML y el código, sin embargo, hay una
similitud. Dentro de un equipo de proyecto, las convenciones del equipo conducirán a una mayor correspondencia.
40/118
Si una propiedad se implementa como un campo o como un valor calculado, que representa algo que un objeto siempre puede proporcionar.
No se debe utilizar una propiedad para modelar una relación transitoria, tal como un objeto que se pasa como un parámetro durante una
llamada al método y se utiliza sólo dentro de los confines de esa interacción.
Asociaciones bidireccionales
Las asociaciones que hemos visto hasta ahora son llamados asociaciones unidireccionales. Otro tipo común de asociación es una asociación
bidireccional, tal como se Figura 3.4 .
Figura 3.4. Una asociación bidireccional
Una asociación bidireccional es un par de propiedades que están unidos entre sí como inversos. La clase de coche tiene la propiedad Propietario:
Persona [1] , y la clase de persona tiene una propiedad coches: coches [*] . ( Tenga en cuenta la forma en la que nombré carros característica en la forma
plural de tipo de la propiedad, una convención común, pero no normativo).
La relación inversa entre ellos implica que si se siguen las dos propiedades, se debe volver a un conjunto que contiene su punto de partida.
Por ejemplo, si comienzo con un MG Midget en particular, encontrar a su dueño, y luego mirar a los coches de su dueño, ese conjunto debe
contener el Enano que empezó.
Como alternativa al etiquetado de una asociación por una propiedad, muchas personas, sobre todo si tienen un fondo de modelado de datos, como para
etiquetar una asociación mediante el uso de una frase verbal ( Figura 3.5 ) De manera que la relación se puede utilizar en una oración. Esto es legal y se
puede añadir una flecha a la asociación para evitar ambigüedades. La mayoría de los modeladores objeto prefieren utilizar un nombre de propiedad, ya
que se corresponde mejor con las responsabilidades y operaciones.
Figura 3.5. Usando una frase verbal para nombrar una asociación
Algunas personas nombrar todas las asociaciones de alguna manera. Decido nombrar una asociación sólo cuando ello mejora la comprensión.
He visto a muchas asociaciones con nombres tales como "tiene" o "se relaciona con".
En Figura 3.4 , La naturaleza bidireccional de la asociación se hace evidente por la flechas de navegación en ambos extremos de la
asociación. Figura 3.5 no tiene flechas; UML permite el uso de esta forma, ya sea para indicar una asociación bidireccional o cuando usted no
está demostrando la navegabilidad. Mi preferencia es usar la flecha de dos puntas de Figura 3.4 cuando se quiere dejar claro que usted tiene
una asociación bidireccional.
La implementación de una asociación bidireccional en un lenguaje de programación es a menudo un poco difícil porque hay que estar seguros de que
ambas propiedades se mantienen sincronizados. Usando C #, utilizo código a lo largo de estas líneas para poner en práctica una asociación bidireccional:
clase Car ...
41/118
Persona propietario pública {
{return conseguir _owner;} conjunto {
. If (! _owner = null) _owner.friendCars () Eliminar (este); _owner = valor;
. If (! _owner = null) _owner.friendCars () Añadir (this); }
} _owner persona privada;
. . .
clase Person ...
públicas IList Coches {
obtener {return (ArrayList.ReadOnly _cars);}} AddCar pública vacío
(arg Car) {
arg.Owner = esta; } IList privada _cars = new ArrayList ();
friendCars IList internos () {
// sólo debe ser utilizado por _cars retorno Car.Owner; }
. . . .
Lo principal es dejar que un lado de la-una asociación lateral de un solo valor, si es posible de control de la relación. Para que esto funcione, el fin
esclavo (persona) tiene que filtrarse la encapsulación de sus datos al final maestro. Esto se suma a la clase de los esclavos un método torpe, que
en realidad no debería estar allí, a menos que el lenguaje tiene el control de acceso de grano fino. He usado la convención de nomenclatura de
"amigo" aquí como un guiño a C ++, donde colocador del maestro sería de hecho un amigo. Al igual que gran código de la propiedad, esto es
bastante repetitivo cosas, por lo que muchas personas prefieren utilizar alguna forma de generación de código para producirlo.
En los modelos conceptuales, navegabilidad no es una cuestión importante, por lo que no muestra ninguna flechas de navegación en los modelos conceptuales.
operaciones
operaciones son las acciones que una clase conoce a llevar a cabo. Operaciones más, obviamente, corresponden a los métodos de una clase.
Normalmente, no se presenta aquellas operaciones que simplemente manipulan propiedades, ya que por lo general se pueden deducir.
La sintaxis completa UML para las operaciones es la siguiente:
nombre de la visibilidad (parámetro-list): retorno de tipo {propiedad cuerdas}
• Esta visibilidad marcador es pública (+) o privada (-); otros en la página 83.
• los nombre es una cadena.
• los parámetro-list es la lista de los parámetros para la operación.
• los -Tipo de retorno es el tipo del valor devuelto, si es que existe.
• los propiedad cuerdas indica los valores de propiedad que se aplican a la operación dada.
Los parámetros en la lista de parámetros están anotadas en una forma similar a los atributos. La forma es:
nombre dirección: type = valor predeterminado
• los nombre , tipo , y valor por defecto son los mismos que para los atributos.
• los dirección indica si el parámetro es de entrada ( en ), salida ( fuera ) o ambos ( InOut ).
Si no se muestra ninguna dirección, se supone que es en .
42/118
Una operación de ejemplo a causa podría ser:
+ balanceOn (fecha: Fecha): Dinero
Con los modelos conceptuales, no se debe utilizar para especificar las operaciones de la interfaz de una clase. En cambio, los utilizan para
indicar las principales responsabilidades de esa clase, tal vez mediante un par de palabras que resumen la responsabilidad CRC (página 65).
A menudo resulta útil distinguir entre las operaciones que cambian el estado del sistema y los que no lo hacen. UML define una consulta como
una operación que obtiene un valor de una clase sin cambiar el sistema estatal, en otras palabras, sin lado effects.You puede marcar una
operación de este tipo con la cadena de propiedades { consulta} . Me refiero a las operaciones que hacen cambiar de estado como modificadores, también
llamado comandos.
En sentido estricto, la diferencia entre consulta y modificadores es si cambian el estado observable [Meyer]. El estado observable es lo que
puede ser percibido desde el exterior. Una operación que actualiza una memoria caché alteraría el estado interno, pero no tendría ningún
efecto que es observable desde el exterior.
Me resulta muy útil para resaltar las consultas, como se puede cambiar el orden de ejecución de consultas y no cambiar el comportamiento del sistema.
Una convención común es tratar de operaciones de escritura de modo que los modificadores no devuelven un valor; de esa manera, se 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 de comandos de
consulta. A veces es difícil de hacer esto todo el tiempo, pero hay que hacerlo lo más que pueda.
Otros términos que a veces se ven son cada vez más los métodos y los métodos de ajuste. UN conseguir método
devuelve un valor de un campo (y no hace nada más). UN método de ajuste pone un valor en un campo (y no hace nada más). Desde el
exterior, un cliente no debería ser capaz de decir si una consulta es un método para conseguir o un modificador es un método de ajuste. El
conocimiento de obtener y establecer métodos es totalmente interna a la clase.
Otra distinción es entre la operación y el método. Un operación es algo que se invoca en un objeto-el procedimiento de declaración-mientras
que una método es el cuerpo de un procedimiento. Los dos son diferentes cuando se tiene polimorfismo. Si usted tiene un supertipo con tres
subtipos, cada uno de los cuales se anula la década de supertipo getPrice operación, que tiene una operación y cuatro métodos que
implementan.
Las personas suelen utilizar los términos operación y método indistintamente, pero hay momentos en que es útil para ser precisos acerca de la
diferencia.
Generalización
Un ejemplo típico de generalización involucra los clientes personales y corporativos de una empresa. Tienen diferencias, pero también
muchas similitudes. Las similitudes se pueden colocar en una clase general de los clientes (el supertipo), con el personal del cliente y el
cliente corporativo como subtipos.
Este fenómeno también está sujeta a diversas interpretaciones en los distintos puntos de vista de la modelización. Conceptualmente, podemos decir
que el cliente corporativo es un subtipo de atención al cliente si todas las instancias del Cliente corporativo también son, por definición, las instancias
de atención al cliente. Un cliente corporativo es entonces un tipo especial de atención al cliente. La idea clave es que todo lo que decimos acerca de
un cliente-asociaciones, atributos, operaciones, es cierto también para un cliente corporativo.
Con la perspectiva del software, la interpretación obvia es la herencia: El cliente corporativo es una subclase de cliente. En lenguajes
orientados a la corriente principal, la subclase hereda todas las características de la superclase y puede anular cualquier método de la
superclase.
Un principio importante del uso de la herencia es efectiva posibilidad de sustitución. Debería ser capaz de sustituir un cliente corporativo
dentro de cualquier código que requiere un cliente, y todo debería funcionar bien. En esencia, esto significa que si escribo código asumiendo
Tengo un cliente, puedo usar libremente cualquier subtipo del cliente. El Cliente corporativo puede responder a ciertos comandos diferente
43/118
de otro cliente, el uso de polimorfismo, pero la persona que llama no debería tener que preocuparse de la diferencia. (Para más
información sobre esto, ver el principio de sustitución de liskov (LSP) en [Martin].)
Aunque la herencia es un poderoso mecanismo, se trae una gran cantidad de equipaje que no siempre se necesita para lograr sustitución. Un
buen ejemplo de esto fue en los primeros días de Java, cuando muchas personas no les gustó la implementación de la clase Vector incorporado
y quería reemplazarlo con algo más ligero. Sin embargo, la única forma en que podían producir una clase que se pueda sustituirlo vector era
hacerla una subclase, y eso significaba que hereda una gran cantidad de datos y el comportamiento no deseado.
Muchos otros mecanismos pueden ser usados para proporcionar clases sustituibles. Como resultado, muchas personas como para diferenciar
entre subtipos, o la herencia de interfaces, y la subclasificación, o la herencia de implementación. Una clase es una subtipo si es sustituible por
su supertipo, si es o no utiliza herencia. subclases se utiliza como sinónimo de herencia regular.
Muchos otros mecanismos disponibles que le permiten tener subtipos sin subclases. Los ejemplos están implementando una interfaz (página
69) y muchos de los patrones de diseño estándar [Banda de los Cuatro].
Notas y comentarios
Las notas son comentarios en los diagramas. Las notas pueden valerse por sí mismos, o pueden estar vinculadas con una línea de puntos a los
elementos que están comentando ( Figura 3.6 ). Pueden aparecer en cualquier tipo de diagrama.
Figura 3.6. Una nota se utiliza como un comentario sobre uno o más elementos de diagrama
La línea discontinua a veces puede ser difícil porque no se puede posicionar exactamente donde termina esta línea. Por lo que una convención
común es poner un pequeño círculo abierto en el extremo de la línea. A veces, es útil tener un comentario en línea sobre un elemento del
diagrama. Esto se puede hacer mediante un prefijo del texto con dos guiones: -.
Dependencia
UN dependencia existe entre dos elementos si los cambios en la definición de un elemento (la
proveedor) puede causar cambios en el otro (el cliente). Con las clases, existen dependencias por varias razones: Una clase envía un mensaje
a otro; una clase tiene otro como parte de sus datos; una clase menciona otro como un parámetro para una operación. Si una clase cambia su
interfaz, cualquier mensaje enviado a esa clase ya no sea válida.
A medida que crecen los sistemas informáticos, que tiene que preocuparse más y más sobre el control de las dependencias. Si dependencias se salen
de control, cada cambio a un sistema tiene un amplio efecto dominó a medida que más y más cosas tienen que cambiar. Cuanto más grande sea la
ondulación, más difícil es cambiar nada.
El UML permite representar las dependencias entre todo tipo de elementos. Se utiliza dependencias siempre que lo desee para mostrar
cómo los cambios en un elemento podrían alterar otros elementos.
Figura 3.7 muestra algunas dependencias que se pueden encontrar en una aplicación de varias capas. La clase de una ventana Beneficios
interfaz de usuario, o presentación clase depende de la clase de empleado: una
44/118
objeto de dominio que captura el comportamiento esencial del sistema, en este caso, las reglas de negocio. Esto significa que si la clase
empleado cambia su interfaz, la ventana de Beneficios puede tener que cambiar.
Figura 3.7. Ejemplo dependencias
Lo importante aquí es que la dependencia es en una sola dirección y va de la clase de presentación a la clase de dominio. De esta manera,
sabemos que podemos alterar libremente la ventana de Beneficios sin esos cambios tienen ningún efecto sobre el empleado u otros objetos
de dominio. He encontrado que una estricta separación de presentación y la lógica de dominio, con la presentación en función del dominio,
pero no al revés, ha sido una regla valiosa para mí seguir.
Una segunda cosa notable de este diagrama es que no existe una dependencia directa de la ventana beneficios a las dos clases de puerta de
enlace de datos. Si estas clases cambian, la clase de empleado puede tener que cambiar. Pero si el cambio es sólo para la implementación de
la clase Empleado, no su interfaz, el cambio se detiene allí.
El UML tiene muchas variedades de dependencia, cada uno con la semántica y palabras clave en particular. La dependencia básica que he
descrito aquí es el que me parece el más útil, y por lo general lo utilizan sin palabras clave. Para añadir más detalles, se puede añadir una palabra
clave correspondiente ( Tabla 3.1 ).
La dependencia básica no es una relación transitiva. Un ejemplo de una transitivo relación es la relación "mayor barba". Si Jim tiene una barba
más grande que Grady, y Grady tiene una barba más grande que Ivar, se puede deducir que Jim tiene una barba más grande que Ivar. Algún
tipo de dependencias, como sustituto, son transitivos, pero en la mayoría de los casos hay una diferencia significativa entre dependencias
directas e indirectas, como la hay en Figura 3.7 .
Muchas relaciones UML implican una dependencia. La asociación navegable del orden al cliente en
Figura 3.1 significa que el orden es dependiente de atención al cliente. Una subclase es dependiente de su superclase, pero no viceversa.
Tabla 3.1. Palabras clave seleccionados de dependencia
Palabra clave Sentido
"llamada" La fuente llama a una operación en el objetivo.
"crear" La fuente crea instancias de la diana.
"derivar" La fuente se deriva de la de destino.
«Instantiate» La fuente es una instancia de la diana. (Tenga en cuenta que si la fuente es una clase, la clase
en sí es una instancia de la clase de la clase; es decir, la clase de destino es una metaclase).
"permiso" El objetivo permite que la fuente a prestaciones particulares del objetivo.
"darse cuenta de" La fuente es una implementación de una especificación o interfaz definida por el objetivo (página 69).
"refinar" Refinamiento indica una relación entre los diferentes niveles semánticas; por ejemplo, la fuente podría ser una clase de
diseño y el objetivo de la correspondiente clase de análisis.
"sustituir" La fuente es sustituible por la diana (página 45).
"rastro" Se utiliza para realizar un seguimiento de las cosas tales como requisitos para las clases o cómo los cambios en un modelo
45/118
Tabla 3.1. Palabras clave seleccionados de dependencia
Palabra clave Sentido
enlace a los cambios en otras partes.
"utilizar" La fuente requiere que el objetivo para su implementación.
Su regla general debería ser minimizar las dependencias, sobre todo cuando cruzan grandes áreas de un sistema. En particular, se debe tener
cuidado con los ciclos, ya que pueden conducir a un ciclo de cambios. No soy muy estricta en este sentido. No me importa dependencias
mutuas entre las clases estrechamente relacionadas, pero sí tratar de eliminar ciclos a un nivel más amplio, sobre todo entre los paquetes.
Tratando de mostrar todas las dependencias en un diagrama de clases es un ejercicio de futilidad; hay demasiados y cambian demasiado.
Sea selectivo y muestran las dependencias sólo cuando están directamente relacionadas con el tema en particular que desea comunicarse.
Para entender y dependencias de control, que es el mejor de su uso con los diagramas de paquetes (páginas 89).
El caso más común que utilizo para dependencias con las clases es cuando ilustra una relación transitoria, como cuando un objeto se pasa a
otro como un parámetro. Es posible que vea usada con palabras clave "parámetro" , "local" , y "global" . También puede ver estas palabras clave en
asociaciones en UML 1 modelos, en cuyo caso se indican enlaces transitorios, no propiedades. Estas palabras clave no son parte del UML 2.
Las dependencias pueden ser determinados por mirar el código, por lo que las herramientas son ideales para hacer análisis de la dependencia. Conseguir
una herramienta de ingeniería inversa imágenes de dependencias es la forma más útil de usar este bit del UML.
Reglas de restricción
Gran parte de lo que está haciendo en la elaboración de un diagrama de clases está indicando limitaciones. Figura 3.1 indica que un pedido se puede
realizar solamente por un único cliente. El diagrama también implica que cada elemento de línea se considera por separado: Usted dice "40 widgets
de marrones, 40 widgets azules, y 40 los widgets rojos", no "120 cosas" en la Orden. Además, el diagrama dice que los clientes corporativos tienen
límites de crédito pero los clientes personales no lo hacen.
Las construcciones básicas de la asociación, atributo, y la generalización hacen mucho para especificar restricciones importantes, pero no
pueden indicar todos los obstáculos. Estas restricciones aún necesitan ser capturado; el diagrama de clases es un buen lugar para hacerlo.
El UML permite utilizar cualquier cosa para describir limitaciones. La única regla es que se los pone dentro de llaves ({}). Se puede utilizar
lenguaje natural, un lenguaje de programación, o el objeto del UML formales Constraint Language (OCL) [más cálido y Kleppe], que se basa
en el cálculo de predicados. Utilizando una notación formal evita el riesgo de interpretaciones erróneas debido a un lenguaje natural ambigua.
Sin embargo, se introduce el riesgo de malas interpretaciones debido a los escritores y los lectores no comprender realmente OCL. A menos
que tenga lectores que se sienten cómodos con el cálculo de predicados, me gustaría sugerir el uso de lenguaje natural.
Opcionalmente, puede nombrar a una restricción al poner el nombre en primer lugar, seguido de dos puntos; por ejemplo, no permitir {incesto:
marido y mujer no deben ser hermanos}.
Diseño por contrato
Diseño por contrato es una técnica de diseño desarrollado por Bertrand Meyer [Meyer]. La técnica es una característica
central del lenguaje Eiffel desarrolló. Diseño por contrato no es específico de Eiffel, sin embargo; es una técnica valiosa que
se puede utilizar con cualquier lenguaje de programación.
En el corazón de Diseño por contrato es la afirmación. Un afirmación es una expresión booleana
46/118
que nunca debe ser falsa y, por lo tanto, será false sólo debido a un error. Por lo general, las afirmaciones se comprueban sólo
durante la depuración y no se comprueban durante la ejecución de la producción. De hecho, un programa nunca debe asumir
que las afirmaciones están siendo revisados.
Diseño por contrato utiliza tres tipos particulares de aseveraciones: post-condiciones, condiciones previas, e invariantes.
Pre-condiciones y post-condiciones se aplican a las operaciones. UN condición post- es una declaración de lo que el mundo
debe ser similar después de la ejecución de una operación. Por ejemplo, si definimos la operación "raíz cuadrada" en un número,
la condición post-tomaría la forma entrada = resultado * resultado, dónde resultado es la salida y entrada
es el valor de entrada. El post-condición es una forma útil de decir lo que hacemos sin decir cómo lo hacemos, en otras palabras,
de separar la interfaz de la aplicación.
UN condición previa es una declaración de cómo esperamos que el mundo sea antes de ejecutar una operación. Podríamos
definir una condición previa para la operación de "raíz cuadrada" de input> = 0.
Tal condición previa dice que se trata de un error de invocar "raíz cuadrada" en un número negativo y que las consecuencias de
hacerlo no están definidos.
A primera vista, esto parece una mala idea, porque hay que poner algún tipo de control en alguna parte para asegurar que "raíz
cuadrada" se invoca correctamente. La cuestión importante es que se encarga de hacerlo.
La condición previa hace explícito que la persona que llama es responsable de comprobar. Sin esta declaración explícita de las
responsabilidades, podemos obtener ya sea demasiado poco de cheques, porque ambas partes asumen que el otro es responsable -o
demasiado, ambas partes de verificación. El exceso de cheques es algo malo, ya que conduce a una gran cantidad de código de
comprobación de duplicados, lo que puede aumentar significativamente la complejidad de un programa. Ser explícito acerca de quién es
el responsable ayuda a reducir esta complejidad. El peligro de que la persona que llama se olvida de comprobar se reduce por el hecho
de que las afirmaciones suelen ser revisados durante la depuración y pruebas.
A partir de estas definiciones de la condición previa y posterior a la condición, podemos ver una fuerte definición del término excepción.
Se produce una excepción cuando una operación se invoca con su condición previa satisfecho todavía no puede regresar con su
post-condición satisfecho.
Un invariante es una afirmación acerca de una clase. Por ejemplo, una clase de cuenta puede tener una invariante que dice que ==
balance de suma (entries.amount ()). El invariante es "siempre" cierto para todas las instancias de la clase. Aquí, "siempre" significa
"siempre que el objeto está disponible para someterse a una operación invocada en él."
En esencia, esto significa que se añade a la invariante y post-condiciones asociadas con todas las operaciones públicas de la
clase dada condiciones previamente. El invariante puede llegar a ser falsa durante la ejecución de un método, pero debe ser
restaurado a cierto por el momento cualquier otro objeto puede hacer nada al receptor.
Las afirmaciones pueden desempeñar un papel único en la subclasificación. Uno de los peligros de la herencia es que se podría
redefinir las operaciones de una subclase ser incompatibles con las operaciones de la superclase. Afirmaciones reducen las
posibilidades de que esto. Las invariantes y post-condiciones de una clase deben aplicarse a todas las subclases. Las subclases
pueden optar por fuerza a los planteamientos, pero no pueden debilitarlos. La condición previa, por el contrario, no puede ser
fortalecida, pero puede debilitarse.
Esto parece extraño al principio, pero es importante para permitir el enlace dinámico. Siempre debe ser capaz de tratar un objeto
subclase como si se tratara de una instancia de la superclase, por el principio de sustitución. Si una subclase reforzó su
condición previa, una operación de superclase puede fallar cuando se aplica a la subclase.
Capítulo 4. Los diagramas de secuencia
47/118
Los diagramas de interacción describir cómo los grupos de objetos colaboran en algún comportamiento. El UML define varias formas de
diagrama de interacción, de los cuales el más común es el diagrama de secuencia.
Típicamente, un diagrama de secuencia de captura el comportamiento de un solo escenario. El diagrama muestra una serie de ejemplos de
objetos y los mensajes que se pasan entre estos objetos en el caso de uso.
Para comenzar la discusión, voy a considerar un escenario simple. Tenemos un pedido y vamos a invocar un comando en él para calcular su
precio. Para hacer eso, la orden tiene que mirar todos los elementos de línea en el orden y determinar sus precios, que están basados en las
reglas de precios de los productos de la línea de orden. Una vez hecho esto para todos los elementos de línea, el orden y luego tiene que
calcular un descuento global, que se basa en reglas atadas al cliente.
Figura 4.1 es un diagrama de secuencia que muestra una implementación de ese escenario. Los diagramas de secuencia muestran la
interacción mostrando cada participante con una línea de vida que corre verticalmente por la página y el orden de los mensajes mediante la
lectura de la página.
Figura 4.1. Un diagrama de secuencia para el control centralizado
Una de las cosas buenas de un diagrama de secuencia es que casi no tengo que explicar la notación. Se puede ver que una instancia de orden
envía getQuantity y obtenerProducto mensajes a la línea de la orden. También puede ver cómo se muestra el orden de invocar un método en sí
mismo y la forma en que el método envía getDiscountInfo a una instancia de cliente.
El diagrama, sin embargo, no muestra todo muy bien. La secuencia de mensajes getQuantity ,
obtenerProducto , getPricingDetails , y calculateBasePrice que hay que hacer para cada línea de pedido en el orden, mientras calculateDiscounts se
invoca sólo una vez. No se puede decir que a partir de este diagrama, aunque voy a introducir un poco más de la notación de manejar esto más
adelante.
La mayoría de las veces, se puede pensar de los participantes en un diagrama de interacción como objetos, como de hecho lo fueron en UML 1. Pero
en UML 2, sus funciones son mucho más complicadas, y para explicar todo totalmente está más allá de este libro. Así que utilizo el término Participantes,
una palabra que no se utiliza formalmente en el UML
48/118
especulación. En UML 1, los participantes fueron objetos y así se destacaron sus nombres, pero en UML 2, se les debe enseñar sin el
subrayado, como he hecho aquí.
En estos diagramas, he llamado a los participantes utilizando el estilo una orden . Esto funciona bien la mayor parte del tiempo. Una sintaxis más
completa es Nombre: Clase , donde tanto el nombre y la clase son opcionales, pero hay que mantener el colon si se utiliza la clase. ( Figura 4.4 , Que se
muestra en la página 58, utiliza este estilo.)
Cada línea de vida tiene una barra de activación que muestra cuando el participante es activo en la interacción. Esto se corresponde con
uno de los métodos del participante estar en la pila. bares de activación son opcionales en UML, pero me parece extremadamente valiosos
para aclarar el comportamiento. Mi única excepción es cuando se explora un diseño durante una sesión de diseño, ya que son difícil de
dibujar en las pizarras.
Naming a menudo es útil para correlacionar los participantes en el diagrama. La llamada obtenerProducto se muestra regresar un producto , que
es el mismo nombre, y por lo tanto el mismo participante, como el un producto
que el getPricingDetails llamada se envía a. Tenga en cuenta que he utilizado una flecha de retorno sólo para esta llamada; Lo hice para mostrar la
correspondencia. Algunas personas utilizan las devoluciones para todas las llamadas, pero yo prefiero usarlos sólo cuando añaden información; de lo
contrario, simplemente el desorden de las cosas. Incluso en este caso, probablemente podría dejar el retorno a cabo sin confundir su lector.
El primer mensaje no tiene un participante que lo envió, ya que proviene de una fuente indeterminada. Se llama mensaje encontrado.
Por otro enfoque a este escenario, echar un vistazo a Figura 4.2 . El problema básico sigue siendo el mismo, pero la forma en la que los
participantes colaboran para poner en práctica es muy diferente. La Orden le pide a cada línea a fin de calcular su propio precio. La Línea de
Orden misma más manos fuera del cálculo a la del producto; Nótese cómo se muestra el paso de un parámetro. Del mismo modo, para calcular
el descuento, la Orden invoca un método en el cliente. Debido a que las necesidades de información de la orden de hacer esto, el cliente
realiza una llamada entrante ( getBaseValue ) el fin de obtener los datos.
Figura 4.2. Un diagrama de secuencia para el control distribuido
La primera cosa a tener en cuenta sobre estos dos diagramas es la claridad con el diagrama de secuencia indica las diferencias en cómo
interactúan los participantes. Esta es la gran fuerza de los diagramas de interacción. No son buenos para mostrar detalles de los algoritmos, tales
como bucles y el comportamiento condicional, pero hacen que las llamadas entre los participantes de cristal claro y dan una muy buena imagen
sobre la que los participantes están haciendo lo que el procesamiento.
La segunda cosa a tener en cuenta es la clara diferencia de estilos entre las dos interacciones. Figura 4.1 es
control centralizado, con un participante más o menos hacer todo el procesamiento y otros participantes no suministrar los datos. Figura
4.2 usos control distribuido, en el que el procesamiento se divide entre muchos participantes, cada uno haciendo un poco del algoritmo.
49/118
Ambos estilos tienen sus fortalezas y debilidades. La mayoría de la gente, especialmente los nuevos en los objetos, están más acostumbrados a un
control centralizado. En muchos sentidos, es más sencillo, ya que todo el proceso está en un solo lugar; con control distribuido, por el contrario, tiene la
sensación de que persigue alrededor de los objetos, tratando de encontrar el programa.
A pesar de esto, el objeto fanáticos como yo prefieren fuertemente control distribuido. Uno de los principales objetivos de un buen diseño es para localizar
los efectos del cambio. Los datos y el comportamiento que tiene acceso a los datos que cambian a menudo juntos. Así que poner los datos y el
comportamiento que se utiliza en un solo lugar es la primera regla de diseño orientado a objetos.
Por otra parte, mediante la distribución de control, se crea más oportunidades para el uso de polimorfismo en lugar de utilizar la lógica
condicional. Si los algoritmos de precios de los productos son diferentes para diferentes tipos de producto, el mecanismo de control
distribuido nos permite usar subclases de producto a manejar estas variaciones.
En general el estilo orientado a objetos es utilizar una gran cantidad de pequeños objetos con una gran cantidad de métodos poco que nos dan una gran
cantidad de puntos de enchufe para anular y la variación. Este estilo es muy confuso para la gente que se utilizan para procedimientos largos; de hecho,
este cambio es el corazón de la cambio de paradigma del objeto de la orientación. Es algo que es muy difícil de enseñar. Parece que la única manera de
entender realmente que es trabajar en un entorno orientado a objetos con el control fuertemente distribuida por un tiempo. Muchas personas dicen
entonces que consiguen repente "ajá" cuando el estilo tiene sentido. En este punto, sus cerebros se han reconectado, y empezar a pensar que el control
descentralizado es realmente más fácil.
Creación y eliminación de participantes
Los diagramas de secuencia muestran alguna notación adicional para la creación y supresión de los participantes ( Figura 4.3 ). Para crear un
participante, se dibuja la flecha mensaje directamente en el cuadro de participante. Un nombre de mensaje es opcional aquí si está utilizando un
constructor, pero por lo general marcan con "nuevo" en cualquier caso. Si el participante de inmediato algo una vez que ha creado, como el
comando de consulta, se inicia una activación justo después del cuadro de participante.
Figura 4.3. Creación y eliminación de participantes
50/118
Supresión de un participante se indica con gran X. Un mensaje flecha que va en la X indica un participante de eliminar explícitamente otra; una X en
el extremo de una línea de vida muestra un participante eliminación de sí mismo.
En un entorno de recolección de basura, que no elimine los objetos directamente, pero es todavía vale la pena utilizar en la X para indicar
cuando un objeto ya no es necesaria y está listo para ser recogido. También es apropiado para operaciones de cierre, lo que indica que el
objeto no es utilizable más.
Bucles, condicionales, y similares
Un problema común con los diagramas de secuencia es la forma de mostrar bucle y el comportamiento condicional. El primero que hay que señalar es que esto
no es lo que los diagramas de secuencia son buenos. Si desea mostrar las estructuras de control de este tipo, que está mejor con un diagrama de actividad o
de hecho con el propio código. El tratamiento de los diagramas de secuencia como una visualización de cómo interactúan los objetos más que como una forma
de lógica de control de modelado.
Dicho esto, aquí está la notación a utilizar. Ambos bucles y condicionales uso marcos de interacción, que son las formas de marcar de un
pedazo de un diagrama de secuencia. Figura 4.4 muestra un algoritmo simple basado en el siguiente pseudocódigo:
Figura 4.4. marcos de interacción
51/118
procedimiento de envío
foreach (LineItem)
si (product.value> $ 10K)
careful.dispatch demás
regular.dispatch final si el
extremo de
si (needsConfirmation) procedimiento de fin messenger.confirm
En general, las tramas consisten en alguna región de un diagrama de secuencia que se divide en uno o más fragmentos. Cada trama tiene un
operador y cada fragmento puede tener un guardia. ( Tabla 4.1 enumera los operadores comunes para los marcos de interacción.) Para
mostrar un bucle, se utiliza el lazo operando con un solo fragmento y poner la base de la iteración en la guardia. Por lógica condicional, se
puede utilizar una alt
operador y puso una condición en cada fragmento. Sólo el fragmento cuya guardia es cierto ejecutará. Si usted tiene una sola región, hay una optar
operador.
marcos de interacción son nuevos en UML 2. Como resultado, es posible que vea los diagramas UML 2 preparados antes y que utilice un enfoque
diferente; También, algunas personas no les gusta los marcos y prefieren algunas de las convenciones de mayor edad. Figura 4.5 muestra algunos de estos
ajustes no oficiales.
Figura 4.5. convenciones mayores por la lógica de control
52/118
UML 1 utiliza iteración marcadores y guardias. Un marcador de iteración * es un añadido al nombre de mensaje. Se puede añadir un poco de
texto entre corchetes para indicar la base de la iteración. guardias son una expresión condicional colocado entre corchetes e indicar que el
mensaje se envía sólo si el guardia es cierto. Si bien estas anotaciones se han caído de los diagramas de secuencia de UML 2, que siguen
siendo legales en los diagramas de comunicación.
Tabla 4.1. Los operadores comunes para los marcos de interacción
Operador Sentido
alt múltiples fragmentos alternativos; sólo el uno cuya condición es verdadera se ejecutará ( Figura
4.4 ).
optar Opcional; el fragmento ejecuta sólo si la condición suministrada es cierto. Equivalente a una
alt con sólo una traza ( Figura 4.4 ).
par Paralela; cada fragmento se ejecuta en paralelo.
lazo Lazo; el fragmento puede ejecutar varias veces, y el guardia indica la base de la iteración ( Figura 4.4 ).
región región crítica; El fragmento puede tener sólo un hilo de ejecución que a la vez.
neg Negativo; el fragmento muestra una interacción no válido.
árbitro Referencia; se refiere a una interacción definida en otro diagrama. El marco se extrae para cubrir las líneas de vida
implicados en la interacción. Se pueden definir parámetros y un valor de retorno.
Dakota del Sur Diagrama de secuencia; utilizado para rodear todo un diagrama de secuencia, si lo desea.
Aunque los marcadores de iteración y guardias pueden ayudar, tienen debilidades. Los guardias no pueden indicar que un conjunto de
guardias son mutuamente excluyentes, como los dos en Figura 4.5 . Ambas notaciones sólo funcionan con un único envío de mensajes y no
funcionan bien cuando varios mensajes que salen de una sola activación están dentro del mismo bucle o bloque condicional.
Para solucionar este último problema, una convención no oficial que se ha vuelto muy popular es el uso de una
pseudomessage, con la condición de bucle o el protector en una variación de la notación de auto-llamada. En
Figura 4.5 , He demostrado esto sin una flecha de mensaje; algunas personas incluyen una flecha mensaje, pero
53/118
dejándolo a cabo ayuda a reforzar que esto no es una llamada real. Algunos también les gusta a gris cortina barra de la activación de la
pseudomessage. Si usted tiene un comportamiento alterativa, se puede demostrar que con un marcador alternativo entre las activaciones.
Aunque me parece activaciones muy útil, que no añaden mucho en el caso de la envío método, mediante el cual se envía un mensaje y no
ocurre nada más dentro de la activación del receptor. Una convención común que he mostrado en Figura 4.5 es dejar caer la activación de
esas llamadas simples.
El estándar UML tiene ningún dispositivo gráfico para mostrar pasar datos; En cambio, es mostrado por los parámetros en el nombre del
mensaje y de retorno flechas. renacuajos de datos han existido en muchos métodos para indicar el movimiento de datos, y muchas personas
todavía les gusta usarlos con UML.
Con todo, a pesar de varios esquemas pueden añadir notación para la lógica condicional a los diagramas de secuencia, no me parece que
funcionan mejor que el código o al menos pseudocódigo. En particular, creo que los marcos de interacción muy pesado, oscureciendo el punto
principal del diagrama, por lo que prefiero pseudomessages.
Las llamadas síncronas y asíncronas

Si usted es excepcionalmente alerta, se le han dado cuenta de que las puntas de flecha en el último par de diagramas son diferentes de las puntas de
flecha anteriormente. Esa pequeña diferencia es bastante importante en UML 2. En UML 2, puntas de flecha rellenas muestran un mensaje sincrónico,
mientras que las puntas de flecha de palo muestran un mensaje asíncrono.
Si una persona que llama envía una mensaje sincrónico, debe esperar hasta que se haga el mensaje, tales como la invocación de una subrutina. Si
una persona que llama envía una de mensajes asíncronos, se puede continuar con el procesamiento y no tiene que esperar una respuesta. Ves las
llamadas asíncronas en las aplicaciones multitarea y en el middleware orientado a mensajes. Asincronía da una mejor capacidad de respuesta y reduce
el acoplamiento temporal, pero es más difícil de depurar.
La diferencia es muy sutil punta de flecha; de hecho, más bien demasiado sutil. Es también un cambio hacia atrás-incompatible introducido en
UML 1.4, antes de entonces un mensaje asíncrono se muestra con la punta de flecha medio-stick, como en Figura 4.5 .
Creo que esta distinción punta de flecha es demasiado sutil. Si desea resaltar mensajes asíncronos, yo recomendaría el uso de la punta de
flecha de media vara obsoletos, lo que llama la atención mucho mejor a una distinción importante. Si está leyendo un diagrama de secuencia,
tenga cuidado de hacer suposiciones acerca de la sincronía de las puntas de flecha a menos que esté seguro de que el autor está haciendo
intencionalmente la distinción.
Cuándo utilizar los diagramas de secuencia
Debe utilizar los diagramas de secuencia cuando se quiere mirar el comportamiento de varios objetos dentro de un solo caso de uso. Los
diagramas son buenos para mostrar la colaboración entre los objetos; que no son tan buenos en la definición precisa del comportamiento.
Si desea ver el comportamiento de un solo objeto a través de muchos casos de uso, utilice un diagrama de estado (véase capítulo 10 ). Si desea
buscar en el comportamiento a través de muchos casos de uso o muchos hilos, considere un diagrama de actividad (véase Capítulo 11 ).
Si desea explorar alternativas múltiples interacciones con rapidez, puede ser mejor con tarjetas CRC, ya que evita un montón de dibujo y
borrado. A menudo es útil tener una sesión de la tarjeta CRC para explorar alternativas de diseño y luego usar los diagramas de secuencia
para capturar cualquier interacción que desea referirse más tarde.
Otras formas útiles de los diagramas de interacción son diagramas de comunicación, para que muestra las conexiones; y diagramas de tiempo, para
mostrar las limitaciones de tiempo.
54/118
Tarjetas CRC
Una de las técnicas más valiosas en dar con un buen diseño orientado a objetos es explorar interacción entre los objetos, porque
se centra en el comportamiento en lugar de datos. CRC (Class- Responsabilidad-Colaboración) diagramas, inventado por Ward
Cunningham a finales de 1980, han resistido la prueba del tiempo como una forma muy eficaz de hacer esto ( Figura 4.6 ). Aunque
no son parte del UML, son una técnica muy popular entre los diseñadores de objetos calificados.
Figura 4.6. Una tarjeta de muestra CRC
Para utilizar tarjetas CRC, usted y sus colegas se reúnen alrededor de una mesa. Tome varios escenarios y actuar hacia fuera
con las tarjetas, recogiéndolos en el aire cuando están activos y moverlos para sugerir la forma en que envían mensajes entre sí
y pasar a su alrededor. Esta técnica es casi imposible describir en un libro sin embargo, se demuestra fácilmente; la mejor
manera de aprender que es tener a alguien que lo ha hecho mostrar a usted.
Una parte importante del pensamiento CRC es la identificación de responsabilidades. UN responsabilidad es una frase corta
que resume algo que debería hacer un objeto: una acción que el objeto realiza, un cierto conocimiento del objeto mantiene, o
algunas decisiones importantes del objeto hace. La idea es que usted debe ser capaz de tomar cualquier clase y resumirlo con
un puñado de responsabilidades. Hacer eso puede ayudar a pensar más claramente sobre el diseño de sus clases.
El segundo se refiere a C colaboradores: las otras clases que necesita esta clase para trabajar con ellos. Esto le da una
idea de los vínculos entre las clases-aún en un nivel alto.
Uno de los principales beneficios de las tarjetas CRC es que estimulan animada discusión entre los desarrolladores. Cuando se
trabaja a través de un caso de uso para ver cómo las clases van a ponerlo en práctica, los diagramas de interacción en este
capítulo pueden ser lentos para dibujar. Por lo general, es necesario considerar alternativas; con diagramas, las alternativas
pueden tomar mucho tiempo para dibujar y borrar. Con las tarjetas CRC, a modelar la interacción recogiendo las cartas y
moverlos. Esto le permite considerar rápidamente alternativas.
Al hacer esto, usted forma ideas acerca de las responsabilidades y escribir en las tarjetas. Pensando en las responsabilidades es
importante, ya que le aleja de la noción de clases como titulares de los datos mudos y alivia los miembros del equipo hacia la
comprensión del comportamiento de alto nivel de cada clase. Una responsabilidad puede corresponder a una operación, a un
atributo, o, más probablemente, a un grupo indeterminado de atributos y operaciones.
Un error común que veo la gente hace es generar una larga lista de responsabilidades de bajo nivel. Pero al hacerlo pierde el
punto. Las responsabilidades deben caber fácilmente en una tarjeta. Pregúntese si la clase debe dividirse o si las
responsabilidades estarían mejor
55/118
declarado por rodar en sentencias de alto nivel.
Muchas personas hacen hincapié en la importancia de los juegos de rol, por lo que cada persona en el equipo juega el papel de una
o más clases. Nunca he visto Ward Cunningham hacer eso, y me parece que el juego de roles se interpone en el camino.
Se han escrito libros sobre la CRC, pero he descubierto que en realidad nunca llegar al corazón de la técnica. El trabajo original
sobre la CRC, escrito con Kent Beck, es [Beck y Cunningham]. Para obtener más información sobre las dos tarjetas CRC y
responsabilidades en el diseño, echar un vistazo a [Wirfs-Brock].
Capítulo 5. Diagramas de Clases: Conceptos avanzados
Los conceptos descritos en Capítulo 3 corresponden a las anotaciones claves en los diagramas de clases. Esos conceptos son los primeros en
comprender y familiarizarse con, ya que comprenderán el 90 por ciento de su esfuerzo en la construcción de diagramas de clases.
La técnica diagrama de clases, sin embargo, ha criado docenas de anotaciones para los conceptos adicionales. Me parece que yo no uso
estas todo el tiempo, pero son útiles cuando son apropiadas. Voy a discutir uno a la vez y señalar algunos de los problemas en su uso.
Es probable que encuentres este capítulo algo pesado en marcha. La buena noticia es que durante su primer paso por el libro, puede saltarse
este capítulo y volver a ella más tarde.
Palabras clave
Uno de los retos de un lenguaje gráfico es que usted tiene que recordar el significado de los símbolos. Con demasiados, usuarios les resulta
muy difícil recordar lo que significan todos los símbolos. Por lo que el UML a menudo trata de reducir el número de símbolos y palabras clave de
uso en su lugar. Si descubre que necesita una construcción de modelado que no está en el UML, pero es similar a algo que es, utiliza el
símbolo de la construcción UML existente, pero lo marca con una palabra clave para demostrar que tiene algo diferente
Un ejemplo de esto es la interfaz. Un UML interfaz ( página 69) es una clase que tiene sólo las operaciones públicas, sin código de método. Esto
corresponde a las interfaces en Java, COM (Component Object módulo), y CORBA. Debido a que es un tipo especial de clase, que se muestra
mediante el icono de la clase con la palabra clave "interfaz" . Palabras clave por lo general se muestran como texto entre guillemets. Como una
alternativa a las palabras clave, puede utilizar iconos especiales, pero entonces se corre en el tema de todo el mundo tener que recordar lo que
significan.
Algunas palabras clave, tales como { abstracto} , aparecen entre llaves. Nunca está muy claro lo que debe ser un técnico en guillemets y lo que
debería ser en curlies. Afortunadamente, si se equivocan, salchichas UML sólo se dará cuenta de graves-o cuidado.
Algunas palabras clave son tan comunes que a menudo se abrevia: "interfaz" a menudo se abrevia a "YO" y { abstracto} a { UN} . Tales
abreviaturas son muy útiles, sobre todo en las pizarras, pero no estándar, por lo que si los usa, asegúrese de encontrar un lugar para explicar
lo que significan.
En UML 1, los guillemets se utilizan principalmente para estereotipos. En UML 2, los estereotipos se definen muy bien, y la descripción de lo
que es y no es un estereotipo está más allá del alcance de este libro. Sin embargo,
56/118
debido a UML 1, muchas personas utilizan el término estereotipo a significar lo mismo que palabra clave, A pesar de que ya no es correcta.
Los estereotipos se utilizan como parte de perfiles. UN perfil toma una parte del UML y se extiende con un grupo coherente de los estereotipos
para un propósito particular, como el modelado de negocios. La semántica de los perfiles completos están más allá de este libro. A menos que
esté en el diseño seria meta-modelo, es poco probable que tenga que crear una. Es más probable que utilice una creada para un fin de
modelado específico, pero afortunadamente, el uso de un perfil no requiere que usted a saber los detalles de la forma en que están vinculados
en el meta-modelo.
Clasificación y generalización
A menudo escucho a la gente habla de subtipos como el es un relación. Los insto a tener cuidado con esa manera de pensar. El problema es
que la frase es un puede significar cosas diferentes.
Considere las siguientes frases.
1. Shep es un Border Collie.

2. Un Border Collie es un perro.
3. Los perros son animales.
4. Un border collie es una raza.
5. El perro es una especie.
Ahora trata de la combinación de las frases. Si combino frases 1 y 2, consigo "Shep es un perro"; 2 y 3 se toman juntos rendimiento "Border
Collie son animales." Y 1 más 2 más 3 me da "Shep es un animal." Hasta aquí todo bien. Ahora trata de 1 y 4: "Shep es una raza." La
combinación de 2 y 5 es "Un Border Collie es una especie." Estos no son tan buenos.
¿Por qué puedo combinar algunas de estas frases y otras no? La razón es que algunos son
clasificación -Los objeto Shep es una instancia del tipo de Border Collie-y algunos son
generalización -el tipo Border Collie es un subtipo del Perro tipo. La generalización es transitivo; clasificación no es. Puedo combinar una
clasificación seguido por una generalización, pero no viceversa.
Digo esto para llegar a tener cuidado con es un. El uso que puede llevar al uso inadecuado de la subclasificación y responsabilidades confusas.
Mejores pruebas para subtipos en este caso serían las frases "Los perros son los tipos de animales" y "Cada instancia de un Border Collie es
una instancia de un perro."
El UML utiliza el símbolo generalización para mostrar generalización. Si necesita mostrar clasificación, utilizar una dependencia con el «Instantiate»
palabra clave.
Múltiple y dinámico Clasificación

Clasificación se refiere a la relación entre un objeto y su tipo. lenguajes de programación convencionales asumen que un objeto pertenece a
una única clase. Pero hay más opciones de clasificación a que eso.
En clasificación único, un objeto pertenece a un solo tipo, que puede heredar de supertipos. En
clasificación múltiple, un objeto puede ser descrita por varios tipos que no están necesariamente conectadas por herencia.
La clasificación múltiple es diferente de la herencia múltiple. La herencia múltiple dice que un tipo puede tener muchas supertipos pero que un
solo tipo debe ser definido para cada objeto. La clasificación múltiple permite que varios tipos para un objeto sin definir un tipo específico para el
propósito.
57/118
Por ejemplo, considere una persona subtipificados ya sea como hombre o mujer, médico o enfermera, paciente o no (véase Figura 5.11 ). La
clasificación múltiple permite que un objeto tiene cualquiera de estos tipos se le asignan en cualquier combinación permitida, sin la necesidad de
tipos que deben definirse para todas las combinaciones legales.
Figura 5.11. La clasificación múltiple
Si utiliza la clasificación múltiple, es necesario asegurarse de que usted deja claro qué combinaciones son legales. UML 2 hace esto mediante la
colocación de cada relación de generalización en una establece generalización. En el diagrama de clases, se etiqueta la punta de flecha
generalización con el nombre del conjunto de generalización, que en UML 1 se llama el discriminador. Clasificación individual corresponde a una
sola generalización establecer sin nombre.
conjuntos de generalización son por disjuntos defecto: cualquier instancia del supertipo puede ser una instancia de solamente uno de los subtipos
dentro de ese conjunto. Si sacas a generalizaciones en una sola flecha, todos ellos deben ser parte del mismo conjunto de generalización, como se
muestra en Figura 5.11 . Como alternativa, puede tener varias flechas con la misma etiqueta de texto.
Para ilustrar, tenga en cuenta las siguientes combinaciones legales de subtipos en el diagrama: (Mujer, Paciente, Nurse); (Hombre,
fisioterapeuta); (Mujer, Paciente); y (Mujer, Doctor, Cirujano). La combinación (paciente, médico, enfermera) es ilegal, ya que contiene dos tipos
del juego de rol generalización.
Otra cuestión es si un objeto puede cambiar su clase. Por ejemplo, cuando una cuenta bancaria está sobregirada, cambia sustancialmente
su comportamiento. En concreto, varias operaciones, incluyendo "retirar" y "cerca", consiguen reemplazado.
clasificación dinámico permite que los objetos a cambio de clase dentro de la estructura de subtipos; clasificación estática no. Con
clasificación estática, una separación se hace entre tipos y estados; clasificación dinámica combina estas nociones.
En caso de utilizar la clasificación múltiple, dinámica? Creo que es útil para el modelado conceptual. Para perspectivas de software, sin
embargo, la distancia entre ella y las implementaciones es demasiado de un salto. En la gran mayoría de los diagramas UML, verá la
clasificación estática único sencillo, por lo que debe ser su defecto.
Clase Asociación
clases de asociación le permiten añadir atributos, operaciones y otras características a las asociaciones, como se muestra en Figura 5.12 .
Podemos ver en el diagrama que una persona puede asistir a muchas reuniones. Nosotros
58/118
necesita mantener información sobre cómo despierta esa persona era; podemos hacer esto añadiendo el atributo de la atención a la
asociación.
Figura 5.12. clase de asociación
Figura 5.13 muestra otra forma de representar esta información: hacer que la asistencia a una clase completa en su propio derecho. Nótese cómo las
multiplicidades se han trasladado.
Figura 5.13. La promoción de una clase de asociación a una clase completa
¿Qué beneficio obtiene con la clase de asociación para compensar la notación adicional que usted tiene que recordar? La clase de asociación
añade una restricción adicional, en la que no puede haber sólo una instancia de la clase de asociación entre dos objetos participantes. Siento
la necesidad de otro ejemplo.
Echar un vistazo a los dos diagramas en Figura 5.14 . Estos diagramas tienen la misma forma. Sin embargo, podemos imaginar una empresa
de jugar diferentes papeles en el mismo contrato, pero es más difícil de imaginar una persona que tenga múltiples competencias en la misma
habilidad; de hecho, es probable que considerar que un error.
Figura 5.14. sutilezas clase de asociación (Rol probablemente no deben ser una
clase de asociación)
59/118
En el UML, sólo el último caso es legal. Sólo puede tener una competencia para cada combinación de persona y habilidad. El diagrama superior
en Figura 5.14 no permitiría que una compañía tenga más de una función en un único contrato. Si tiene que permitir esto, es necesario hacer
clases, una clase completa, al estilo de
Figura 5.13 .
La implementación de clases de asociación no es muy obvio. Mi consejo es implementar una clase de asociación como si donde una clase
completa, pero es proporcionar métodos que obtienen información a las clases unidas por la clase de asociación. Así que para Figura 5.12 , Me
gustaría ver los métodos siguientes en persona:
clase Persona
Lista getAttendances () Lista
getMeetings ()
De esta manera, un cliente de la persona que puede hacerse con las personas en la reunión; si quieren detalles, que pueden conseguir los
mismos asistencias. Si hace esto, recuerde que debe cumplir la restricción de que no puede haber sólo un objeto de asistencia para cualquier
par de persona y de reuniones. Usted debe colocar una marca en el método que crea la Asistencia.
A menudo se encuentran este tipo de construcción con información histórica, como en Figura 5.15 . Sin embargo, me parece que la creación de
clases adicionales o clases de asociación puede hacer que el modelo difícil de entender, así como la inclinación de la aplicación en una dirección
particular, que a menudo es inadecuada.
Figura 5.15. El uso de una clase para una relación temporal
Si tengo este tipo de información temporal, que utilice un "temporal" de palabras clave en la asociación (véase
Figura 5.16 ). El modelo indica que una persona puede trabajar para una única empresa a la vez.
60/118
Con el tiempo, sin embargo, una persona puede trabajar para varias empresas. Esto sugiere una interfaz a lo largo de las líneas de:
Figura 5.16. "Temporal" palabra clave para las asociaciones
clase Person ...

Compañía getEmployer (); // obtener empleador actual empresa getEmployer (Fecha); // obtener
empleador en una fecha determinada vacío changeEmployer (empresa newEmployer, Fecha
CHANGEDATE); leaveEmployer anular (Fecha CHANGEDATE);
los "temporal" palabra clave no es parte de la UML, pero lo menciono aquí por dos razones. En primer lugar, se trata de una idea que he encontrado
útiles en varias ocasiones en mi carrera de modelo. En segundo lugar, muestra cómo puede utilizar palabras clave para extender el UML. Puede
leer mucho más sobre esto en
http://martinfowler.com/ap2/timeNarrative.html .
Plantilla (parametrizada) Clase

Varios idiomas, más notablemente C ++, tienen la noción de una clase parametrizada, o modelo.
(Las plantillas están en la lista para ser incluidos en Java y C # en un futuro próximo.)
Este concepto es más obviamente útil para trabajar con colecciones en un lenguaje fuertemente tipado. De esta manera, se puede definir el comportamiento de
conjuntos, en general, mediante la definición de una clase de plantilla Conjunto .
Conjunto de clase <T> {

inserto vacío (T newElement); remove void (T
anElement);
Cuando haya hecho esto, puede utilizar la definición general para hacer Conjunto clases de elementos más específicos:
Set <Empleado> employeeSet;
Se declara una clase de plantilla en el UML mediante el uso de la notación se muestra en la Figura 5.17 . La T en el diagrama es un marcador de
posición para el parámetro de tipo. (Es posible que tenga más de uno.)
Figura 5.17. clase de plantilla
Un uso de una clase con parámetros, tales como Set <Empleado> , que se llama una derivación. Puede mostrar una derivación de dos
maneras. La primera forma refleja sintaxis el C ++ (ver Figura 5.18 ). Usted describe la expresión de derivación dentro de paréntesis
angulares en forma < :: nombre-parámetro parámetro-valor> . Si
61/118
sólo hay un parámetro, el uso convencional a menudo omite el nombre del parámetro. La notación alternativa (ver Figura 5.19 ) Refuerza el
vínculo a la plantilla y le permite cambiar el nombre del elemento de atado.
Figura 5.18. elemento Bound (versión 1)
Figura 5.19. elemento Bound (versión 2)
los "enlazar" de palabras clave es un estereotipo sobre la relación refinamiento. Esta relación indica que
EmployeeSet se ajustarán a la interfaz de Conjunto . Se puede pensar en el EmployeeSet como un subtipo de
Conjunto . Esto encaja con la otra forma de implementar colecciones de tipo específico, que es declarar todos los subtipos apropiados.
El uso de una derivación se no el mismo que subtipificación, sin embargo. No se le permite añadir características al elemento de cota, que está
completamente especificado por su plantilla; está agregando solamente restringir información de tipo. Si desea agregar características, debe
crear un subtipo.
enumeraciones
(enumeraciones Figura 5.20 ) Se utilizan para mostrar un conjunto fijo de valores que no tienen propiedades distintas de su valor simbólico.
Se muestran como la clase con el "enumeración" palabra clave.
Figura 5.20. Enumeración
62/118
Clase activa
Un clase activa tiene casos, cada uno de los cuales ejecuta y controla su propio hilo de control. invocaciones de métodos pueden ejecutar en el
hilo de un cliente o en hilo del objeto activo. Un buen ejemplo de esto es un procesador de comandos que acepta objetos de comando desde el
exterior y a continuación, ejecuta los comandos dentro de su propio hilo de control.
La notación para las clases de activos ha cambiado de UML 1 a UML 2, como se muestra en Figura 5.21 . en UML
2, una clase activa tiene líneas verticales adicional en el lado; en UML 1, que tenía un borde grueso y fue llamado un objeto activo.
Figura 5.21. clase activa
Visibilidad
Visibilidad es un tema que es simple en principio, pero tiene matices complejos. La simple idea es que cualquier clase tiene elementos públicos y
privados. elementos públicos pueden ser utilizados por cualquier otra clase; elementos privados pueden ser utilizados solamente por la clase
propietaria. Sin embargo, cada idioma tiene sus propias normas. Aunque muchos idiomas utilizan términos tales como publico privado, y protegido,
que significan cosas diferentes en diferentes idiomas. Estas diferencias son pequeñas, pero conducen a confusión, especialmente para aquellos
de nosotros que utilizan más de un idioma.
El UML intenta abordar esto sin entrar en una maraña horrible. Esencialmente, dentro del UML, puede etiquetar cualquier atributo u operación
con un indicador de visibilidad. Se puede utilizar cualquier marcador que te gusta, y su significado depende del idioma. Sin embargo, el UML
proporciona cuatro abreviaturas para la visibilidad: + (público), - ( privado), ~ (paquete), y # (protegido). Estos cuatro niveles se utilizan dentro de
la meta-modelo UML y se definen dentro de ella, pero sus definiciones varían sutilmente de las de otros idiomas.
Cuando se está utilizando la visibilidad, utilizar las reglas de la lengua en la que se está trabajando. Cuando usted está buscando en un modelo
UML de otra parte, tener cuidado de los significados de los marcadores de visibilidad, y ser conscientes de cómo esos significados pueden
cambiar de un idioma a otro.
63/118
La mayoría de las veces, no dibujo marcadores de visibilidad en los diagramas; Las uso sólo si tengo que poner de relieve las diferencias en la
visibilidad de ciertas características. Incluso entonces, puedo mayoría salirse con + y -, que al menos son fáciles de recordar.
mensajes
Estándar UML no muestra ninguna información sobre el mensaje pide a los diagramas de clases. diagramas convencionales Sin embargo, a
veces he visto como Figura 5.22 .
Figura 5.22. Las clases con mensajes
Estos se añaden flechas a los lados de las asociaciones. Las flechas están etiquetados con los mensajes que un objeto envía a otro. Debido a
que no es necesario una asociación a una clase a enviar un mensaje a ella, también puede ser necesario añadir una flecha para mostrar la
dependencia de mensajes entre las clases que no están asociados.
Esta información de mensaje abarca varios casos de uso, por lo que no están numeradas para mostrar las secuencias, a diferencia de los diagramas de
comunicación.
Responsabilidades
A menudo, es útil para mostrar las responsabilidades (página 63) en una clase en un diagrama de clases. La mejor manera de mostrar que es como
cadenas de comentario en su propio compartimiento en la clase ( Figura 5.1 ). Puede nombrar el compartimento, si lo desea, pero por lo general no lo
hacen, ya que rara vez hay ninguna posibilidad de confusión.
Figura 5.1. Mostrando responsabilidades en un diagrama de clases
64/118
Operaciones estáticas y Atributos
El UML se refiere a una operación o un atributo que se aplica a una clase en lugar de a una instancia como
estático. Esto es equivalente a miembros estáticos en lenguajes basados-C. características estáticas están subrayados en un diagrama de clases (ver Figura
5.2 ).
Figura 5.2. notación estática
Agregación y Composición
Una de las fuentes más frecuentes de confusión en el UML es la agregación y composición. Es fácil de explicar con soltura: Agregación es la
parte de relación. Es como decir que un coche tiene un motor y ruedas ya que sus partes. Esto suena bien, pero lo más difícil está
considerando cuál es la diferencia entre la agregación y asociación.
En los días pre-UML, las personas eran por lo general bastante vaga en lo que era la agregación y cuál fue la asociación. Ya sea vaga o no,
siempre eran incompatibles con todos los demás. Como resultado, muchos modeladores piensan que la agregación es importante, aunque por
diferentes razones. Por lo que el UML incluye la agregación ( Figura 5.3 ), Pero sin apenas semántica. Como dice Jim Rumbaugh, "Piense en ello
como un placebo modelado" [Rumbaugh, UML de referencia].
Figura 5.3. Agregación
65/118
Así como la agregación, la UML tiene la propiedad más definido de composición. En Figura 5.4 , Una instancia de Point puede ser parte de un
polígono o puede ser el centro de un círculo, pero no puede ser a la vez. La regla general es que, a pesar de una clase puede ser un
componente de muchas otras clases, cualquier caso debe ser un componente de un solo propietario. El diagrama de clases puede mostrar
varias clases de propietarios potenciales, pero cualquier instancia tiene un solo objeto como su propietario.
Figura 5.4. Composición
Se habrá dado cuenta de que no me presento en las multiplicidades inversa Figura 5.4 . En la mayoría de los casos, como en este caso, es 0..1. Su único otro
valor posible es 1, para los casos en los que la clase de componente está diseñado para que pueda tener una sola otra clase como su propietario.
La regla de "no compartir" es la clave de la composición. Otra hipótesis es que si se elimina el polígono, se debe garantizar
automáticamente que cualquier Punto en propiedad también se eliminan.
La composición es una buena manera de demostrar que poseen propiedades por valor, las propiedades de los objetos de valor (página 73), o las
propiedades que tienen una participación fuerte y un tanto exclusiva de determinados otros componentes. La agregación es estrictamente sentido;
como consecuencia, recomiendo que usted lo ignora en sus propios diagramas. Si lo ves en otros diagramas de las personas, tendrá que cavar más
profundo para averiguar lo que quieren decir con ello. Diferentes autores y los equipos lo utilizan para fines muy diferentes.
Propiedades derivados
propiedades derivadas puede calcularse sobre la base de otros valores. Cuando pensamos en un intervalo de fechas ( Figura 5.5 ), Podemos
pensar en tres propiedades: la fecha de inicio, la fecha de finalización, y el número de días del período. Estos valores están vinculados, por lo que
podemos pensar en la longitud como derivados de los otros dos valores.
Figura 5.5. atributo derivado en un período de tiempo
Derivación de las perspectivas de software puede ser interpretado en un par de maneras diferentes. Puede utilizar la derivación para indicar la
diferencia entre un valor calculado y un valor almacenado. En este caso, nos gustaría interpretar Figura 5.5 como una indicación de que el inicio
y el final son almacenados, pero que la longitud se calcula. Aunque se trata de un uso común, no soy tan entusiasta, porque revela demasiado
de la parte interna de Rango de fechas .
Mi pensamiento preferido es que indica una restricción entre los valores. En este caso, estamos hablando de que la restricción entre los tres
valores se mantiene, pero no es importante cuál de los tres valores se calcula. En este caso, la elección de los que atribuyen a la marca
como derivada es arbitraria y estrictamente necesaria, pero es útil para ayudar a recordar a la gente de la restricción. Este uso también tiene
sentido con diagramas conceptuales.
66/118
Derivación también se puede aplicar a las propiedades usando la notación asociación. En este caso, sólo tiene que marcar el nombre con un
/.
Interfaces y clases abstractas

Un clase abstracta es una clase que no se puede instanciar directamente. En su lugar, se crea una instancia de una subclase. Por lo general,
una clase abstracta tiene una o más operaciones que son abstractos. Un
operación abstracta no tiene ninguna aplicación; es pura declaración de manera que los clientes pueden unirse a la clase abstracta.
La forma más común para indicar una clase abstracta o la operación en el UML es escribir en cursiva el nombre. También puede hacer que las
propiedades abstractas, lo que indica una propiedad o abstractos métodos de descriptor de acceso. Cursiva es difícil de hacer en un pizarras, por lo que
pueden usar la etiqueta: { abstracto} .
Una interfaz es una clase que no tiene ninguna aplicación; es decir, todas sus características son abstractos. Interfaces corresponden
directamente a las interfaces en C # y Java y son un lenguaje común en otros lenguajes de tipo. Se marca una interfaz con la palabra clave "interfaz"
.
Las clases tienen dos tipos de relaciones con interfaces: proporcionar y que requiere. Una clase proporciona una interfaz si es sustituible
para la interfaz. En Java y .NET, una clase puede hacerlo mediante la implementación de la interfaz o la implementación de un subtipo de la
interfaz. En C ++, subclase de la clase que es la interfaz.
Una clase requiere una interfaz si se necesita una instancia de esa interfaz con el fin de trabajar. Esencialmente, esto es tener una
dependencia de la interfaz.
Figura 5.6 muestra estas relaciones en acción, basados en unas pocas clases de colección de Java. Yo podría escribir un Orden clase que
tiene una lista de elementos de línea. Porque estoy usando una lista, el Orden clase depende de la Lista interfaz. Vamos a suponer que utiliza
los métodos es igual , añadir , y obtener .
Cuando los objetos se conectan, el Orden en realidad utilizar una instancia de Lista de arreglo pero no es necesario saber que con el fin de
utilizar estos tres métodos, ya que son todos parte de la Lista interfaz.
Figura 5.6. Un ejemplo de Java de interfaces y una clase abstracta
67/118
los Lista de arreglo en sí es una subclase de la AbstractList clase. AbstractList proporciona algunos, pero no todos, la aplicación de la Lista comportamiento
En particular, la obtener método es abstracto. Como resultado,
Lista de arreglo implementos obtener sino también anula algunas de las otras operaciones en AbstractList . En este caso, se anula añadir pero
está feliz de heredar la implementación de es igual .
¿Por qué no simplemente evitar esto y tienen Orden utilizar Lista de arreglo ¿directamente? Mediante el uso de la interfaz, me permito la ventaja
de hacer más fácil el cambio implementaciones más adelante si lo necesito. Otra aplicación puede proporcionar mejoras de rendimiento, algunas
de las características de interacción de base de datos, u otros beneficios. Por la programación de la interfaz en lugar de a la aplicación, evito
tener que cambiar todo el código si necesito una implementación diferente de Lista . Usted siempre debe tratar de programar a una interfaz como
esta; utilice siempre el tipo más general que pueda.
También debo señalar una arruga pragmática en esto. Cuando los programadores utilizar una colección de este tipo, por lo general
inicializar la colección con una declaración, como este:
Lista ArtículosLínea privadas = new ArrayList ();
Tenga en cuenta que esto introduce una dependencia estricta de Orden al hormigón Lista de arreglo . En teoría, esto es un problema, pero la
gente no se preocupe por eso en la práctica. Debido a que el tipo de artículos de línea está declarada como Lista , ninguna otra parte de la Orden clase
depende de Lista de arreglo . ¿Hay que cambiar la aplicación, sólo hay presente una línea de código de inicialización que hay que preocuparse.
Es bastante común para referirse a una clase concreta de una vez durante la creación, sino de utilizar únicamente la interfaz después.
La notación completa de Figura 5.6 es una manera de anotar las interfaces. Figura 5.7 muestra una notación más compacta. El hecho de que Lista
de arreglo implementos Lista y Colección se muestra por tener iconos de bolas, a menudo referido como piruletas, fuera de ella. El hecho de que Orden
requiere una Lista interfaz se muestra mediante el icono de socket. La conexión es bien evidente.
Figura 5.7. notación de bola y cavidad

68/118
El UML ha utilizado la notación piruleta por un tiempo, pero la notación toma es nuevo a UML 2. (creo que es mi favorita Además de notación.)
Es probable que vea los diagramas antiguos usan el estilo de Figura 5.8 , Donde una dependencia hace las veces de la notación zócalo.
Figura 5.8. dependencias mayores con piruletas
Cualquier clase es una mezcla de una interfaz y una implementación. Por lo tanto, podemos ver a menudo un objeto utilizado a través de la interfaz
de una de sus superclases. En sentido estricto, no sería legal el uso de la notación piruleta de una superclase, como la superclase es una clase, no
una interfaz pura. Pero me inclino estas reglas para mayor claridad.
Así como en los diagramas de clases, la gente ha encontrado útil en otros lugares piruletas. Uno de los problemas perennes con
diagramas de interacción es que no proporcionan una muy buena visualización de comportamiento polimórfico. Aunque no es el uso
normativo, puede indicarlo en la línea de
Figura 5.9 . Aquí, podemos ver que, a pesar de que tenemos una instancia de vendedor, que se utiliza como tal por la calculadora de
experiencia, el objeto período de pago utiliza el vendedor sólo a través de su interfaz de empleado. (Se puede hacer el mismo truco con los
diagramas de comunicación.)
Figura 5.9. El uso de una paleta para mostrar polimorfismo en un diagrama de secuencia
69/118
De sólo lectura y congelado
En la página 37, describí la { solo lectura} palabra clave. Se utiliza esta palabra clave para marcar una propiedad que sólo puede ser leída por los
clientes y que no se puede actualizar. Similar pero diferente es el { congelado} palabra clave de UML 1. Una propiedad es congelado si no se puede
cambiar durante el curso de la vida de un objeto; tales propiedades son a menudo llamados inmutable. A pesar de que fue eliminado de UML 2, { congelado}
es un concepto muy útil, por lo que me gustaría seguir utilizándolo. Así como marcar las propiedades individuales como congelado, se puede aplicar la
palabra clave a una clase para indicar que todas las propiedades de todos los casos se congelan. (He oído que puede ser congelado y reinstalados en
breve).
Objetos de referencia y el valor de los objetos
Una de las cosas comunes decirse de los objetos es que no tienen identidad. Esto es cierto, pero no es tan simple como eso. En la práctica, se
encuentra que la identidad es importante para los objetos de referencia, pero no es tan importante para los objetos de valor.
Los objetos de referencia son cosas tales como atención al cliente. En este caso, la identidad es muy importante, ya que normalmente se desea
solamente un objeto de software para designar a un cliente en el mundo real. Cualquier objeto que hace referencia a un objeto al Cliente lo hará a través
de una referencia o puntero; todos los objetos que hacen referencia a este cliente se hacer referencia al mismo objeto de software. De esta manera, los
cambios a un cliente están disponibles para todos los usuarios del cliente.
Si tiene dos referencias a un cliente y desea ver si son la misma, por lo general comparar sus identidades. Las copias pueden ser rechazada; si
se les permite, tienden a ser realizado en raras ocasiones, quizás para fines de archivo o para la replicación a través de una red. Si se hacen
copias, es necesario resolver cómo sincronizar los cambios.
objetos de valor son cosas tales como la fecha. Que a menudo tienen múltiples objetos de valor que representan el mismo objeto en el
mundo real. Por ejemplo, es normal tener cientos de objetos que designan 1-Ene-04. Estas son todas las copias intercambiables. Las nuevas
fechas se crean y se destruyen con frecuencia.
70/118
Si tiene dos fechas y desea ver si son lo mismo, no mirar sus identidades sino más bien a los valores que representan. Esto generalmente
significa que usted tiene que escribir un operador prueba de igualdad, que para las fechas que hacer una prueba en el año, mes y día, o lo que
es la representación interna. Cada objeto que hace referencia 1-Ene-04 por lo general tiene su propio objeto dedicado, pero también se puede
compartir fechas.
objetos de valor deben ser inmutables; en otras palabras, que no debería ser capaz de tomar un objeto de fecha de 1-Ene-04 y cambiar la
fecha de un mismo objeto a ser de 2-Ene-04. En su lugar, se debe crear un nuevo objeto 2-Jan-04 y utilizar en su lugar. La razón es que si la
fecha se compartieron, actualizaría la fecha de otro objeto de un modo impredecible, un problema conocido como aliasing.
En días pasados, la diferencia entre los objetos de referencia y objetos de valor era más clara. objetos de valor fueron los valores integrados
del sistema de tipos. Ahora se puede ampliar el sistema de tipos con sus propias clases, por lo que este tema requiere una mayor reflexión.
El UML utiliza el concepto de tipo de datos, que se muestra como una palabra clave en el símbolo de la clase. En sentido estricto, el tipo de datos no es lo
mismo que objeto de valor, como tipos de datos no pueden tener identidad. objetos de valor pueden tener una identidad, pero no utilizarlo para la igualdad.
Primitivas en Java serían los tipos de datos, pero las fechas no lo haría, a pesar de que serían objetos de valor.
Si es importante destacar que, utilizo la composición cuando se asocia con un objeto de valor. También puede utilizar una palabra clave en un
tipo de valor; los convencionales comunes que veo son "valor" o «Estructura» .
Asociaciones cualificados
UN asociación cualificado UML es el equivalente de un concepto de programación conocida también como matrices asociativas, mapas,
hash y diccionarios. Figura 5.10 muestra una forma que utiliza un partido de clasificación para representar a la asociación entre las clases
orden y la orden de línea. El calificador dice que, en relación con una Orden, puede haber una línea de pedido para cada instancia del
producto.
Figura 5.10. asociación cualificado
Desde la perspectiva del software, esta asociación cualificado implicaría una interfaz en la línea de
Orden de la clase ...

pública OrderLine getLineItem (Producto aproduct); addLineItem public void (cantidad de número,
producto forProduct);
Por lo tanto, todo el acceso a una línea de pedido requiere un determinado producto como un argumento, lo que sugiere una implementación
usando una estructura de datos clave y valor.
Es común que la gente se confunde acerca de las multiplicidades de una asociación cualificado. En Figura
5.10 , Una orden puede tener muchos elementos de línea, pero la multiplicidad de la asociación cualificado es la multiplicidad en el contexto de
la clasificación. Por lo que el diagrama dice que un pedido ha 0..1 Línea de artículos por producto. Una multiplicidad de 1 indicaría que la Orden
tendría que tener una partida para cada instancia de producto. A * indicaría que tendría Line Varios elementos por producto, sino que el acceso
a los elementos de línea es indexada por producto.
En el modelado conceptual, utilizo el constructo de clasificación sólo para mostrar las limitaciones a lo largo de las líneas de "Línea de pedido individual por
producto en la Orden."
71/118
Capítulo 6. Los diagramas de objetos
Un diagrama de objetos es una instantánea de los objetos en un sistema en un punto en el tiempo. Debido a que muestra los casos en lugar de
clases, un diagrama de objeto es a menudo llamado un diagrama de ejemplo.
Se puede utilizar un diagrama de objeto para mostrar un ejemplo de configuración de los objetos. (Ver Figura 6.1 , Que muestra un conjunto de
clases, y Figura 6.2 , Que muestra un conjunto asociado de los objetos). Este último uso es muy útil cuando las posibles conexiones entre los
objetos son complicadas.
Figura 6.1. Diagrama de clases de la estructura de composición Party
Figura 6.2. diagrama de objeto que muestra ejemplos de casos de Party
Se puede decir que los elementos en Figura 6.2 son instancias porque los nombres están subrayados. Cada nombre tiene la forma nombre de la
instancia: nombre de la clase . Ambas partes del nombre son opcionales, por lo John ,
:Persona , y una persona son nombres legales. Si sólo utiliza el nombre de clase, debe incluir el colon. Puede mostrar los valores de los atributos
y enlaces, como en Figura 6.2 .
Estrictamente, los elementos de un diagrama de objeto son especificaciones de instancia en lugar de casos reales. La razón es que es legal para
dejar atributos obligatorios vacío o para mostrar las especificaciones de instancias de clases abstractas. Se puede pensar en una especificación
instancia como una instancia en parte definida.
Otra forma de ver un diagrama de objeto es como un diagrama de comunicación (página 131), sin mensajes.
Cuándo utilizar diagramas de objetos

72/118
Los diagramas de objetos son útiles para mostrar ejemplos de objetos conectados entre sí. En muchas situaciones, se puede definir una estructura
de forma precisa con un diagrama de clases, pero la estructura sigue siendo difícil de entender. En estas situaciones, un par de ejemplos de
diagramas de objeto puede hacer toda la diferencia.
Capítulo 7. Los diagramas de paquetes
Clases representan la forma básica de la estructuración de un sistema orientado a objetos. A pesar de que son maravillosamente útil, se
necesita algo más para estructurar sistemas grandes, que pueden tener cientos de clases.
UN paquete es una construcción agrupación que le permite tomar cualquier construcción en el UML y el grupo de sus elementos juntos en
unidades de nivel superior. Su uso más común es para las clases de grupo, y esa es la forma en que estoy describiendo aquí, pero recuerde
que puede utilizar paquetes para todos los otros bits del UML también.
En un modelo de UML, cada clase es un miembro de un solo paquete. Los paquetes también pueden ser miembros de otros paquetes, por lo
que se quedan con una estructura jerárquica en la que los paquetes de nivel superior se descomponen en subpaquetes con sus propias
sub-paquetes y así sucesivamente hasta la jerarquía toque fondo en las clases. Un paquete puede contener dos sub-paquetes y clases.
En términos de programación, los paquetes corresponden a tales construcciones de agrupación como paquetes (en Java) y espacios de nombres (en C ++
y .NET).
Cada paquete representa una espacio de nombres, lo que significa que cada clase debe tener un nombre único dentro de su paquete de propietario.
Si quiero crear una clase llamada Fecha, y una clase Date ya está en el paquete del sistema, puedo tener mi clase Date, siempre y cuando lo puse en
un paquete separado. Para que quede claro cuál es cuál, puedo utilizar una plenamente nombre calificado, es decir, un nombre que muestra la
estructura del paquete propietaria. Utiliza dos puntos dobles para mostrar nombres de los paquetes en UML, por lo que las fechas podrían ser
Fecha del sistema y Martin Fowler :: Util :: Fecha .
En los diagramas, los paquetes se muestran con una carpeta con pestañas, como en Figura 7.1 . Simplemente puede mostrar el nombre del paquete o
mostrar el contenido también. En cualquier momento, puede utilizar nombres completos o nombres simplemente regulares. Que muestra el contenido
con iconos de clase le permite mostrar todos los detalles de una clase, incluso hasta el punto de mostrar un diagrama de clases dentro del paquete.
La simple enumeración de los nombres tiene sentido cuando lo que quieres hacer es indicar qué clases son en qué paquetes.
Figura 7.1. Maneras de mostrar los paquetes en los diagramas
73/118
Es muy común ver a una clase etiquetada algo así como Fecha (de java.util) en lugar de la forma completa. Este estilo es una convención
que se ha hecho mucho por Rational Rose; no es parte de la norma.
El UML permite que las clases en un paquete para ser pública o privada. Una clase pública es parte de la interfaz del paquete y puede ser
utilizado por las clases de otros paquetes; una clase privada está oculto. Diferentes entornos de programación tienen diferentes reglas sobre la
visibilidad entre sus constructos de empaquetamiento; que debe seguir la convención de su entorno de programación, incluso si esto significa
doblar las reglas del UML.
Una técnica útil es reducir la interfaz del paquete exportando sólo un pequeño subconjunto de las operaciones asociadas con clases públicas del
paquete. Usted puede hacer esto dando a todas las clases visibilidad privada, de manera que puedan ser vistos solamente por otras clases en el
mismo paquete, y mediante la adición de clases públicas adicionales para el comportamiento público. Estas clases adicionales, llamados fachadas [ Banda
de los Cuatro], entonces delegar las operaciones públicas a sus compañeros más tímidos en el paquete.
¿Cómo elegir qué clases de poner en el que los paquetes? Esto es realmente una pregunta muy complicado que necesita una buena cantidad
de habilidades de diseño para responder. Dos principios útiles son el Cierre principio común y reutilización Común Principio [Martin]. El Cierre
principio común dice que las clases de un paquete deberían necesitar cambiar por razones similares. La reutilización principio común dice que
las clases en un paquete todos deben ser reutilizados juntos. Muchas de las razones para agrupar las clases en los paquetes tienen que ver
con las dependencias entre los paquetes, que voy a venir a continuación.
Paquetes y dependencias
UN diagrama de paquetes muestra paquetes y sus dependencias. Me introdujo el concepto de dependencia en la página 47. Si tiene paquetes
para la presentación y dominio, tiene una dependencia del paquete de presentación para el paquete de dominio si cualquier clase en el paquete
de presentación tiene una dependencia a cualquier clase en el paquete de dominio. De esta manera, las dependencias interpackage resumen
las dependencias entre sus contenidos.
El UML tiene muchas variedades de dependencia, cada uno con la semántica y estereotipo en particular. Me resulta más fácil para empezar la
dependencia unstereotyped y el uso de las dependencias más particulares sólo si lo necesito, lo que casi nunca hago.
74/118
En un medio de gran sistema, trazando un diagrama de paquetes puede ser una de las cosas más valiosas que puede hacer para controlar
la estructura a gran escala del sistema. Idealmente, este diagrama debe ser generada a partir de la misma base de código, para que pueda
ver lo que está realmente allí en el sistema.
Una buena estructura de paquete tiene un flujo claro a las dependencias, un concepto que es difícil de definir, pero a menudo más fácil de
reconocer. Figura 7.2 muestra un diagrama de paquete de ejemplo para una aplicación de empresa, uno que está bien estructurado y tiene un
flujo claro.
Figura 7.2. diagrama de paquetes para una aplicación empresarial
A menudo, se puede identificar un flujo claro porque todas las dependencias se ejecutan en una sola dirección. A pesar de que es un buen
indicador de un sistema bien estructurado, los paquetes de datos del asignador de Figura 7.2 mostrar una excepción a esta regla general. Los
paquetes asignador de datos actúan como una capa aislante entre los paquetes de dominios y de base de datos, un ejemplo de la pauta
Mapper [Fowler, P de EAA].
Muchos autores dicen que no debe haber ciclos en las dependencias (el Principio acíclica Dependencia [Martin]). No tratar esto como
una regla absoluta, pero sí creo que los ciclos deben ser localizados y que, en particular, no debe tener ciclos que atraviesan capas.
Los más dependencias que entran en un paquete, la interfaz más estable es el de paquete tiene que ser, ya que cualquier cambio en su interfaz
será ondulación en todos los paquetes que dependen de él (el establo Dependencias Principio [Martin]). Así que en Figura 7.2 , El paquete de
dominio activo necesita una interfaz más estable que el paquete de datos asignador de arrendamiento. A menudo, usted encontrará que los
paquetes más estables tienden a tener una mayor proporción de interfaces y clases abstractas (el establo abstracciones Principio [Martin].
Las relaciones de dependencia no son transitivos (página 48). Para ver por qué esto es importante para las dependencias, mira Figura 7.2 de
nuevo. Si una clase en los cambios en el envase de dominio activo, que puede tener un cambio de clases dentro del paquete de dominio de
arrendamiento. Pero este cambio no necesariamente a través de ondulación a la presentación de arrendamiento. (Se ondula sólo si el dominio de
arrendamiento cambia su interfaz.)
75/118
Algunos paquetes se utilizan en tantos lugares que sería un desastre para dibujar todas las líneas de dependencia a ellos. En este caso, una
convención es usar una palabra clave, como "global" , en el envase.
paquetes UML también definen construcciones para permitir que los paquetes de Importación y combinación de clases de un paquete a otro,
utilizando dependencias con palabras clave para anotar esto. Sin embargo, las reglas para este tipo de cosas varían mucho con los lenguajes de
programación. En general, creo que la noción general de las dependencias a ser mucho más útil en la práctica.
Aspectos del paquete
Si se piensa en Figura 7.2 , Se dará cuenta de que el diagrama tiene dos tipos de estructuras. Una de ellas es una estructura de capas en la
aplicación: presentación, dominio, asignador de datos y base de datos. La otra es una estructura de áreas temáticas: leasing y activos.
Usted puede hacer esto más evidente mediante la separación de los dos aspectos, como en Figura 7.3 . Con este diagrama, se puede ver
claramente cada aspecto. Sin embargo, estos dos aspectos no son verdaderos paquetes, porque no se puede asignar clases a un solo paquete.
(Usted tendría que escoger uno de cada aspecto.) Este problema refleja el problema en los espacios de nombres jerárquicos en lenguajes de
programación. Aunque los diagramas como Figura 7.3 son no estándar UML, que a menudo son muy útiles para explicar la estructura de una
aplicación compleja.
Figura 7.3. separando Figura 7.2 en dos aspectos
La implementación de paquetes
A menudo, verá un caso en el que un paquete define una interfaz que puede ser implementado por un número de otros paquetes, como el de Figura
7.4 . En este caso, la relación realización indica que la puerta de entrada de base de datos define una interfaz y que las otras clases de puerta
de enlace proporciona una implementación. En la práctica, esto significaría que el paquete de puerta de enlace de base de datos contiene las
interfaces y clases abstractas que están totalmente implementadas por los otros paquetes.
76/118
Figura 7.4. Un paquete implementado por otros paquetes
Es bastante común para una interfaz y su aplicación para estar en paquetes separados. De hecho, un paquete de cliente a menudo
contiene una interfaz para otro paquete para poner en práctica: la misma noción de interfaz necesaria que he discutido en la página 70.
Imaginemos que queremos ofrecer alguna de las interfaces de usuario (UI) controla para cambiar las cosas dentro y fuera. Queremos que esto funcione
con un montón de cosas diferentes, tales como calentadores y luces. Los controles de interfaz de usuario necesidad de invocar métodos en el calentador,
pero no queremos que los controles de tener una dependencia al calentador. Podemos evitar esta dependencia mediante la definición de los controles en
el paquete una interfaz que se implementa a continuación, por cualquier clase que quiere trabajar con estos controles, como en Figura 7.5 . Este es un
ejemplo de la pauta Interface Separado [Fowler, P de EAA].
Figura 7.5. La definición de una interfaz necesaria en un paquete de cliente
Cuándo utilizar diagramas de paquetes
77/118
Encuentro diagramas de paquetes de gran utilidad en sistemas de mayor escala para obtener una imagen de las dependencias entre los
elementos principales de un sistema. Estos diagramas se corresponden bien a las estructuras comunes de programación. Trazado de diagramas
de paquetes y dependencias le ayuda a mantener las dependencias de una aplicación bajo control.
Los diagramas de paquetes representan un mecanismo de agrupación en tiempo de compilación. Para que muestra cómo los objetos se componen en tiempo de ejecución,
utilice un diagrama de estructura de material compuesto (página 135).

La mejor discusión que sé de paquetes y cómo usarlos es [Martin]. Robert Martin ha tenido durante mucho tiempo una obsesión casi patológica
con dependencias y escribe bien acerca de cómo prestar atención a las dependencias para que pueda controlar y minimizarlos.
Capítulo 8. Diagrama de implementación

Los diagramas de despliegue muestran disposición física de un sistema, que revela que las piezas de software se ejecutan sobre qué piezas de
hardware. Los diagramas de despliegue son realmente muy simple; de ahí el breve capítulo.
Figura 8.1 es un ejemplo sencillo de un diagrama de despliegue. Los principales elementos en el diagrama son nodos conectados por caminos
de comunicación. UN nodo es algo que puede albergar algún tipo de software. Los nodos pueden ser de dos formas. UN dispositivo es el
hardware, puede ser un ordenador o una pieza simple de hardware conectado a un sistema. Un entorno de ejecución es un software que sí
anfitriones o contiene otro software, ejemplos son un sistema operativo o un proceso de contenedor.
Figura 8.1. diagrama de despliegue Ejemplo
78/118
Los nodos contienen artefactos, cuales son las manifestaciones físicas de software: Por lo general, los archivos. Estos archivos podrían ser ejecutables
(tales como archivos .exe, binarios, DLLs, archivos JAR, asambleas, o scripts), o archivos de datos, archivos de configuración, documentos HTML, y así
sucesivamente. Añadir un artefacto dentro de un nodo muestra que el artefacto se despliega a ese nodo en el sistema en funcionamiento.
Puede mostrar los artefactos ya sea como cajas de clase o por lista el nombre dentro de un nodo. Si se les muestra como cajas de clase, se
puede añadir un icono del documento o de la "artefacto" palabra clave. Puede etiquetar los nodos o artefactos con valores etiquetados para
indicar diversa información interesante acerca del nodo, como proveedor, el sistema operativo, ubicación o cualquier otra cosa que le apetezca.
A menudo, usted tiene múltiples nodos físicos que llevan a cabo la misma tarea lógica. Puede dejar un número esto con múltiples cajas de los
nodos o indicar el número como un valor etiquetado. En Figura 8.1 , He utilizado la etiqueta
número desplegado para indicar tres servidores web físicas, pero no hay ninguna etiqueta estándar para esto.
Los artefactos son a menudo la implementación de un componente. Para mostrar esto, se puede utilizar un valor etiquetado en el cuadro artefacto.
Las rutas de comunicación entre los nodos indican cómo se comunican las cosas. Puede etiquetar estos caminos con información sobre los
protocolos de comunicación que se utilizan.
Cuándo utilizar diagramas de implementación
No deje que la brevedad de este capítulo hacer pensar que los diagramas de despliegue no se deben utilizar. Son muy útiles en mostrar lo
que se desplegó en donde, por lo que cualquier despliegue no trivial puede hacer un buen uso de ellos.
Capítulo 9. Casos de uso

Los casos de uso son una técnica para capturar los requisitos funcionales de un sistema. Los casos de uso de trabajo mediante la descripción de las
interacciones típicas entre los usuarios de un sistema y el propio sistema y ofrece una perspectiva de cómo se utiliza un sistema.
En vez de describir los casos de uso de frente, me resulta más fácil entrar en ellos por la espalda y se inicia con la descripción de los escenarios. UN guión
es una secuencia de pasos que describen una interacción entre un usuario y un sistema. Así que si tenemos una tienda en línea basada en la Web,
podríamos tener una Comprar un escenario de producto que decir lo siguiente:
El cliente navega por el catálogo y añade artículos a la cesta de la compra deseada. Cuando el cliente desea pagar, el
cliente describe la información de envío y de tarjetas de crédito y confirma la venta. El sistema verifica la autorización
de la tarjeta de crédito y confirma la venta tanto de forma inmediata y con un correo electrónico de seguimiento.
Este escenario es una cosa que puede suceder. Sin embargo, la autorización de tarjeta de crédito puede fallar, y esto sería un escenario
separado. En otro caso, es posible que tenga un cliente habitual para los cuales no es necesario para capturar la información de envío y de
tarjetas de crédito, y esto es un tercer escenario.
Todos estos escenarios son diferentes pero similares. La esencia de su similitud es que en todos estos tres escenarios, el usuario tiene el mismo objetivo:
para comprar un producto. El usuario no siempre tiene éxito, pero sigue siendo el objetivo. Este objetivo del usuario es la clave para los casos de uso: Una caso
de uso es un conjunto de escenarios atados juntos por un objetivo común de usuario.
En caso de uso-hablar, los usuarios reciben el nombre de los actores. Un actor es un papel que un usuario juega con respecto al sistema.
Actores podrían incluir al cliente, representante de servicio al cliente, gerente de ventas, y
79/118
analista de producto. Los actores llevan a cabo los casos de uso. Un único actor puede realizar muchas casos de uso; por el contrario, un caso de uso
puede tener varios actores que realizan la misma. Por lo general, tiene muchos clientes, por lo que muchas personas pueden ser el actor cliente.
Además, una persona puede actuar como más de un actor, como un gerente de ventas que hace tareas representante de servicio al cliente. Un actor
no tiene por qué ser humano. Si el sistema lleva a cabo un servicio de otro sistema informático, que otro sistema es un actor.
Actor en realidad no es el término correcto; papel sería mucho mejor. Al parecer, hubo un error en la traducción del Sueco, y actor es el término
que utiliza la comunidad de casos de uso.
Los casos de uso son bien conocidos como una parte importante de la UML. Sin embargo, la sorpresa es que en muchos aspectos, la definición de
casos de uso en el UML es más bien escasa. Nada en el UML describe cómo se debe capturar el contenido de un caso de uso. Lo que el UML
describe es un diagrama de casos de uso, que muestra cómo los casos de uso se relacionan entre sí. Pero casi todo el valor de los casos de uso
se encuentra en el contenido, y el diagrama es de un valor bastante limitado.
Contenido de un caso de uso
No existe una manera estándar de escribir el contenido de un caso de uso, y diferentes formatos funcionan bien en diferentes casos. Figura
9.1 muestra un estilo común de usar. Se empieza por escoger uno de los escenarios como el escenario principal éxito. Se empieza el cuerpo
del caso de uso escribiendo el escenario principal éxito como una secuencia de pasos numerados. A continuación, tomar los otros escenarios
y escribir como
extensiones, describirlos en términos de variaciones en el escenario principal de éxito. Las extensiones pueden ser éxitos-usuario logra el
objetivo, como en 3A-o fallos, como en 6a.
Figura 9.1. Ejemplo texto caso de uso
Cada caso de uso tiene un principal actor, que llama en el sistema para entregar un servicio. El actor principal es el actor con el objetivo del
caso de uso está tratando de satisfacer y es usualmente, pero no siempre, el iniciador del caso de uso. Puede haber otros agentes, así como
con la que el sistema se comunica mientras que llevar a cabo el caso de uso. Estos son conocidos como actores secundarios.
Cada paso en un caso de uso es un elemento de la interacción entre un actor y el sistema. Cada paso debe ser una simple declaración y poner
de manifiesto que está llevando a cabo la etapa. El paso debe mostrar la intención del actor, no la mecánica de lo que hace el actor. En
consecuencia, no se describe la interfaz de usuario en el caso de uso. De hecho, la escritura del caso de uso por lo general precede el diseño
de la interfaz de usuario.
80/118
Una extensión dentro de los nombres de los casos de uso de una condición que resulta en diferentes interacciones de los descritos en el
principal escenario de éxito (MSS) y establece cuáles son esas diferencias. Comience la extensión nombrando el paso en el que se detecta la
condición y proporcionar una breve descripción de la condición. Siga la condición con escalones numerados en el mismo estilo que el
escenario principal éxito. Terminar estos pasos mediante la descripción de donde regresa al escenario principal éxito, si lo hace.
La estructura de casos de uso es una gran manera de lluvia de ideas alternativas al escenario principal éxito. Para cada paso, preguntar, ¿Cómo pudo
ir de otra manera? y en particular, ¿Qué podría salir mal? Por lo general es mejor que piensen en las distintas condiciones de extensión en primer
lugar, antes de quedar atascada la elaboración de las consecuencias. Es probable que pensar en más condiciones de esta manera, lo que se traduce
en un menor número de pifias que usted tiene que recoger más tarde.
Un paso complicado en un caso de uso puede ser otro caso de uso. En términos UML, se dice que el primer caso de uso incluye el segundo. No hay
forma estándar para mostrar un caso de uso incluido en el texto, pero me parece que el subrayado, lo que sugiere un hipervínculo, funciona muy
bien y en muchas herramientas realmente será un hipervínculo. Así, en Figura 9.1 , El primer paso incluye el caso de uso "Catálogo de buscar y
seleccionar los artículos para comprar."
incluidos los casos de uso pueden ser útiles para un paso complejo que recargar el escenario principal o para conocer los pasos que se repiten
en varios casos de uso. Sin embargo, no trate de romper casos de uso en los casos sub-uso y casos de uso subsub utilizando la descomposición
funcional. tal descomposición es una buena manera de perder mucho tiempo.
Así como los pasos en los escenarios, se puede añadir alguna otra información común a un caso de uso.
• UN condición previa describe lo que el sistema debe garantizar es cierto antes de que el sistema permite que el caso de uso para
empezar. Esto es útil para decirle a los programadores que condiciones no tienen que comprobar si en su código.
• UN garantía describe lo que el sistema garantizará al final del caso de uso. garantías de éxito tienen éxito después de un
escenario; garantías mínimas mantienen después de cualquier escenario.
• UN desencadenar especifica el caso de que se pone el caso de uso comenzado.
Cuando usted está considerando la adición de elementos, sea escéptico. Es mejor que hacer muy poco que demasiado. Además, trabajar duro para
mantener el caso de uso breve y fácil de leer. He encontrado que la larga, los casos de uso detallada no consiguen leídos, que más bien en contra del
propósito.
La cantidad de detalles que necesita en un caso de uso depende de la cantidad de riesgo en ese caso de uso. A menudo, es necesario obtener más información
sobre sólo unos pocos casos de uso clave desde el principio; otros pueden, profundizado justo antes de ponerlas en práctica. Usted no tiene que escribir todos los
detalles abajo; la comunicación verbal es a menudo muy eficaz, sobre todo dentro de un ciclo iterativo en el que se necesita de forma rápida cumplido mediante la
ejecución de código.
Los diagramas de casos
Como ya he dicho anteriormente, el UML no se pronuncia sobre el contenido de un caso de uso, pero sí proporciona un formato de diagrama para
representar ellos, como en Figura 9.2 . Aunque el diagrama a veces es útil, no es obligatorio. En su trabajo de casos de uso, no poner demasiado
esfuerzo en el diagrama. En su lugar, concentrarse en el contenido textual de los casos de uso.
Figura 9.2. Use el diagrama del caso
81/118
La mejor manera de pensar en un diagrama de casos de uso es que es una tabla gráfica de contenidos para el conjunto de casos de uso. Es
también similar al diagrama de contexto utilizado en los métodos estructurados, ya que muestra los límites del sistema y las interacciones con el
mundo exterior. El diagrama de casos de uso muestra los actores, los casos de uso, y las relaciones entre ellos:
• ¿Qué actores llevar a cabo de casos de uso

• ¿Qué casos de uso incluyen otros casos de uso
El UML incluye otras relaciones entre casos de uso más allá del simple incluye, como
"ampliar" . Yo recomiendo que los ignora. He visto demasiadas situaciones en las que los equipos pueden quedar terriblemente colgó cuándo
utilizar diferentes relaciones de casos de uso, y dicha energía es desperdiciada. En su lugar, concentrarse en la descripción textual de un caso
de uso; ahí es donde el valor real de la técnica reside.
Los niveles de casos de uso
Un problema común con los casos de uso es que, al centrarse en la interacción entre el usuario y el sistema, se puede descuidar situaciones
en las que un cambio en un proceso de negocio puede ser la mejor manera de lidiar con el problema. A menudo, se oye la gente habla de
casos de uso del sistema y los casos de uso del negocio. Los términos no son precisas, pero en general, una caso de uso del sistema es una
interacción con el software, mientras que una caso de uso comercial discute cómo un negocio responde a un cliente o un evento.
[Cockburn, casos de uso] sugiere un esquema de niveles de casos de uso. Los casos de uso del núcleo están en "el nivel del mar." El nivel del mar casos de
uso típicamente representan una interacción discreta entre un actor de primario y el sistema. Tales casos de uso entregará algo de valor para el actor principal
y generalmente a partir de un par de minutos a media hora para el actor principal para completar. Los casos de uso que están allí sólo porque se incluyen por
casos de uso del nivel del mar son nivel de los peces. Mayor, A nivel de la cometa casos de uso muestran cómo los casos de uso del nivel del mar encajan en
las interacciones comerciales más amplios. casos de uso a nivel de la cometa son por lo general los casos de uso del negocio, mientras que los niveles de mar
y peces son los casos de uso del sistema. Debe tener la mayor parte de los casos de uso en el nivel del mar. Yo prefiero para indicar el nivel en la parte
superior del caso de uso, como en
Figura 9.1 .
Casos de uso y características (o historias)
Muchos enfoques utilizan características de un sistema de programación-Extreme las llama historias a usuario ayudan a describir los requisitos. Una
pregunta común es cómo las características y casos de uso se interrelacionan.
82/118
Las características son una buena manera de fragmentar un sistema para la planificación de un proyecto iterativo, en el que cada iteración ofrece
una serie de características. Los casos de uso proporcionan un relato de cómo los actores utilizan el sistema. Por lo tanto, aunque ambas técnicas
se describen los requisitos, sus efectos son diferentes.
Aunque se puede ir directamente a las funciones que describen, muchas personas les resulta útil para el desarrollo de casos de uso y luego generar una lista
de características. Una característica puede ser un caso todo uso, un escenario en un caso de uso, un paso en un caso de uso, o alguna variante de
comportamiento, tales como la adición de un nuevo método de depreciación para sus valoraciones de los activos, que no aparece en un caso de uso narrativa.
Por lo general, las características terminan siendo más de grano fino de casos de uso.
Cuándo utilizar los casos de uso
Los casos de uso son una herramienta valiosa para ayudar a entender los requisitos funcionales de un sistema. Un primer paso en casos de uso se debe
hacer desde el principio. Las versiones más detalladas de los casos de uso deben ser trabajadas justo antes de que el desarrollo de casos de uso.
Es importante recordar que los casos de uso representan una externo vista del sistema. Como tal, no esperan que las correlaciones entre casos
de uso y las clases dentro del sistema.
Cuanto más veo de casos de uso, el menos valioso el diagrama de casos de uso parece ser. Con los casos de uso, concentrar su energía en
su texto en lugar de en el diagrama. A pesar del hecho de que el UML no tiene nada que decir sobre el texto de casos de uso, que es el texto
que contiene todo el valor en la técnica.
Un gran peligro de casos de uso es que las personas que sean demasiado complicados y se atascan. Por lo general, obtendrá menos daño por hacer
demasiado poco que haciendo demasiado. Un par de páginas por caso de uso está muy bien para la mayoría de los casos. Si usted tiene muy poco,
por lo menos usted tiene un documento breve y fácil de leer que es un punto de partida para las preguntas. Si usted tiene demasiado, casi nadie va a
leer y entender.

Los casos de uso se popularizó originalmente por Ivar Jacobson en [Jacobson, OOSE].
Aunque los casos de uso han existido desde hace un tiempo, ha habido poca estandarización de su uso. El UML no se pronuncia sobre los contenidos
importantes de un caso de uso y sólo se ha estandarizado los diagramas mucho menos importantes. Como resultado, se puede encontrar una amplia
gama de opiniones divergentes sobre los casos de uso.
En los últimos años, sin embargo, [Cockburn, casos de uso] se ha convertido en el libro estándar sobre el tema. En este capítulo, he seguido la
terminología y los consejos de ese libro por la excelente razón de que cuando hemos desacuerdo en el pasado, he generalmente terminamos
coincidiendo con Alistair Cockburn en el final. También mantiene un sitio Web en http://usecases.org . [Constantino y Lockwood] proporciona
un proceso convincente para derivar las interfaces de usuario de los casos de uso; ver también
http://foruse.com .
Capítulo 10. Diagramas de Máquina de Estados

diagramas de máquina de estados son una técnica familiar para describir el comportamiento de un sistema. Diversas formas de diagramas de estado
han existido desde la década de 1960 y las técnicas orientadas a objetos más antiguos sean adoptados para mostrar el comportamiento. En los enfoques
orientados a objetos, se dibuja un diagrama de máquina de estado para una sola clase para mostrar el comportamiento de toda la vida de un solo objeto.
Siempre que la gente escribe sobre las máquinas de estado, los ejemplos son, inevitablemente, controles de crucero o máquinas expendedoras. Como
estoy un poco aburrido con ellos, decidí usar un controlador para un panel secreto en una gótica
83/118
castillo. En este castillo, quiero mantener mis objetos de valor en una caja fuerte que es difícil de encontrar. Así que para revelar la cerradura de la caja fuerte,
tengo que quitar una vela estratégica de su soporte, pero esto revelará el bloqueo sólo cuando la puerta está cerrada. Una vez que puedo ver la cerradura,
puedo insertar mi llave para abrir la caja fuerte. Para mayor seguridad, me aseguro que yo puedo abrir la caja fuerte sólo si se sustituye la vela en primer lugar.
Si un ladrón descuida esta precaución, voy a desatar un monstruo desagradable para devorarlo.
Figura 10.1 muestra un diagrama de máquina de estados de la clase controlador que dirige mi diagrama de estado de seguridad system.The
inusual comienza con el estado del objeto controlador cuando se crea: en Figura
10.1 , El estado de espera. El diagrama indica esto con pseudoestado inicial, que no es un estado sino que tiene una flecha que apunta al
estado inicial.
Figura 10.1. Un simple diagrama de máquina de estados
El diagrama muestra que el controlador puede estar en tres estados: Espera, Lock, y Open. El diagrama también da las reglas por las que el
controlador cambia de estado a estado. Estas reglas son en forma de transiciones: las líneas que conectan los estados.
los transición indica un movimiento de un estado a otro. Cada transición tiene una etiqueta que viene en tres partes: gatillo-firma [guardia] /
actividad . Todas las partes son opcionales. los
disparador de la firma es por lo general un solo evento que desencadena un cambio potencial del estado. los Guardia , si está presente, es una
condición booleana que debe ser verdadera para la transición a ser tomada. los actividad es un comportamiento que se ejecuta durante la
transición. Puede ser cualquier expresión conductual. La forma completa de una disparador de la firma puede incluir múltiples eventos y
parámetros. Así que en Figura 10.1 , Se lee la transición hacia el exterior desde el estado de espera como "en estado de espera si se retira la vela
que proporciona la puerta está abierta, que revelan la cerradura y pasar al estado de bloqueo."
Las tres partes a una transición son opcionales. Una actividad que falta indica que usted no hace nada durante la transición. Un guardia
faltante indica que siempre toma la transición si ocurre el evento. Un disparador de la firma que falta es poco frecuente, pero ocurre. Indica
que se tome la transición de inmediato, lo que se ve sobre todo con los estados de actividad, que voy a venir en un momento.
Cuando se produce un evento en un estado, puede tomar sólo una transición fuera de él. Así que si usa múltiples transiciones con el mismo caso,
como en el estado de bloqueo de Figura 10.1 , Los guardias deben ser mutuamente excluyentes. Si se produce un evento y no de transición es
válido, por ejemplo, un evento de seguridad cerrada en el estado de espera o un evento de vela-removed con la puerta cerrada en el evento se
ignora.
El estado final indica que la máquina de estado se ha completado, lo que implica la eliminación del objeto de controlador. Por lo tanto, si
alguien debe ser tan descuidado como para caer en mi trampa, el objeto controlador termina, así que tendría que poner el conejo en su jaula,
fregar el suelo, y reinicie el sistema.
84/118
Recuerde que las máquinas de estado pueden mostrar sólo lo que el objeto observa o activa directamente. Así que, aunque se podría esperar
de mí para añadir o quitar cosas de la caja fuerte cuando está abierto, no pongo que en el diagrama de estado, debido a que el controlador no
se puede contar.
Cuando los desarrolladores hablan de objetos, que a menudo se refieren a la situación de los objetos en el sentido de la combinación de todos los
datos en los campos de los objetos. Sin embargo, el estado en un diagrama de máquina de estado es una noción más abstracta de estado; en
esencia, diferentes estados implican una forma diferente de reaccionar a los eventos.
Actividades internas
Los estados pueden reaccionar a los eventos sin transición, usando actividades internas: poniendo el evento, guardia, y la actividad dentro de la caja
Estado mismo.
Figura 10.2 muestra un estado con actividades internas de los eventos de carácter y de ayuda, como se puede encontrar en un campo de texto de
interfaz de usuario. Una actividad interna es similar a una auto-transición: una transición que vuelve al mismo estado. La sintaxis para actividades
internas sigue la misma lógica para el evento, guardia, y el procedimiento.
Figura 10.2. Los eventos internos que se muestran con el estado tipificación de un campo de texto
Figura 10.2 también muestra dos actividades especiales: la entrada y las actividades de salida. los la actividad de entrada se ejecuta cada vez que
entra en un estado; el actividades de salida, cada vez que salga. Sin embargo, las actividades internas no activan las actividades de entrada y
salida; que es la diferencia entre las actividades internas y auto-transiciones.
actividad Unidos
En los estados que he descrito hasta ahora, el objeto es tranquilo y esperando el próximo evento antes de que suceda algo. Sin embargo, puede
hacer que los estados en los que el objeto está haciendo un trabajo en curso.
El estado buscando en Figura 10.3 es tal una estado de actividad: La actividad en curso está marcado con el hacer/ ; de ahí el término do-actividad.
Una vez que se complete la búsqueda, sin ninguna transición de una actividad, como la de mostrar un nuevo hardware, se toman. Si se
produce el evento cancelar durante la actividad, el do-actividad se detuvo sin contemplaciones, y vamos de nuevo al estado de la ventana de
actualización de hardware.
Figura 10.3. Un estado con una actividad
85/118
Ambos do-actividades y actividades regulares representan la realización de algunos comportamientos. La diferencia fundamental entre los dos es que las
actividades regulares se producen "instantánea" y no pueden ser interrumpidos por eventos regulares, mientras que do-actividades pueden tomar tiempo
finito y puede ser interrumpida, como en Figura 10.3 . Instantánea significa cosas diferentes para diferentes sistemas; para sistemas de tiempo real
estricto, podría ser un par de instrucciones de la máquina, pero para el software de escritorio puede ser de varios segundos.
UML 1 utiliza el término acción para las actividades regulares y la actividad utiliza sólo para hacer las cosas ellos actividades.
superestados
A menudo, usted encontrará que varios estados comparten transiciones comunes y actividades internas. En estos casos, puede hacer que se
subestados y mover el comportamiento compartidos en un superestado, como en Figura 10.4 . Sin el superestado, que tendría que dibujar una
transición cancelar para los tres estados dentro del estado Introduzca Detalles de la conexión.
Figura 10.4. Superestado con subestados anidados
Estados concurrentes
Los Estados pueden dividirse en varios diagramas de estados ortogonales que se ejecutan simultáneamente. Figura 10.5
muestra patéticamente simple reloj de alarma que puede reproducir CDs o la radio y mostrar la hora actual o la hora de la alarma.
86/118
Figura 10.5. estados ortogonales simultáneos
La elección de CD / radio y el tiempo / alarma actual son opciones ortogonales. Si usted quiere representar esto con un diagrama de estado no
ortogonal, se necesitaría un diagrama desordenado que conseguir mucho de la mano en caso de que desee más estados. La separación de las
dos áreas de conducta en los diagramas de estado separados hace que sea mucho más claro.
Figura 10.5 también incluye una pseudoestado historia. Esto indica que cuando el reloj está encendido, la elección de radio / CD se remonta al
estado del reloj se encontraba cuando se apagó. La flecha de la pseudoestado la historia indica en qué estado de estar en el primer momento
en que no hay antecedentes.
Los diagramas de estado de ejecución
Un diagrama de estado puede ser implementado en tres formas principales: Interruptor anidada, el patrón de Estado, y tablas de estado. El
enfoque más directo para el manejo de un diagrama de estados es una sentencia switch anidada, tales como Figura 10.6 . Aunque es directa, es
largo aliento, incluso para este caso sencillo. También es muy fácil para que este enfoque se salga de control, por lo que no me gusta usarlo
incluso para casos sencillos.
Figura 10.6 AC # interruptor de anidado para manejar la transición de estado desde Figura
10.1
handleEvent pública vacío (PanelEvent anEvent) {

interruptor (CurrentState) {
PanelState.Open caso:
interruptor (anEvent) {
PanelEvent.SafeClosed caso:
CurrentState = PanelState.Wait; descanso; } descanso;
PanelState.Wait caso:
87/118
PanelEvent.CandleRemoved caso:
si (isDoorOpen) {
RevealLock ();
CurrentState = PanelState.Lock; } descanso; } descanso;
PanelState.Lock caso:
PanelEvent.KeyTurned caso:
si (isCandleIn) {
OpenSafe ();
CurrentState = PanelState.Open; } Else {
ReleaseKillerRabbit (); CurrentState = PanelState.Final;

} descanso; } descanso; }}}
los patrón de Estado [ Banda de los Cuatro] crea una jerarquía de clases del estado para manejar el comportamiento de los estados. Cada estado
en el diagrama tiene una subclase estatales. El controlador dispone de métodos para cada evento, que simplemente reenvía a la clase de estado. El
diagrama de estado de Figura 10.1 produciría una aplicación que se indica por las clases de Figura 10.7 .
Figura 10.7. Una implementación patrón de Estado para Figura 10.1
La parte superior de la jerarquía es una clase abstracta que implementa todos los métodos de gestión de eventos no hagan nada. Para cada estado
concreto, sólo tiene que reemplazar los métodos de eventos específicos para los que ese estado tiene transiciones.
los tabla de estados enfoque capta la información de diagrama de estado como datos. Asi que Figura 10.1 podría terminar representado en una tabla como
Tabla 10.1 . a continuación, construimos ya sea un intérprete que utiliza la tabla de estado en tiempo de ejecución o un generador de código que genera
clases en base a la tabla de estado.
Obviamente, la tabla de estados es más trabajo que hacer una vez, pero luego se puede utilizar cada vez que tenga un problema de estado de sostener. Una
tabla de estado de tiempo de ejecución también se puede modificar sin recompilación, que en
88/118
algunos contextos es bastante práctico. El patrón de estado es más fácil de armar cuando lo necesite, y aunque se necesita una nueva clase
para cada estado, que es una pequeña cantidad de código para escribir en cada caso.
Estas implementaciones son bastante escaso, pero se le debe dar una idea de cómo ir sobre la aplicación de diagramas de estado. En
cada caso, la aplicación de modelos de estado conduce a un código muy repetitivo, por lo que es mejor usar alguna forma de generación
de código para hacerlo.
Tabla 10.1. Una tabla de estado de Figura 10.1

Estado de la fuente objetivo del Estado Evento Guardia Procedimiento
Espere Bloquear vela eliminado Puerta abierta revelar bloqueo
Bloquear Abierto llave girada vela en Abra la caja fuerte
Bloquear Final llave girada vela conejo asesino liberación
Abierto Espere segura cerrada
Cuándo utilizar los diagramas de estado
diagramas de estado son buenos para describir el comportamiento de un objeto a través de varios casos de uso. diagramas de estado no son
muy buenos para describir el comportamiento que implica una serie de objetos que colaboran. Como tal, es útil combinar diagramas de estado
con otras técnicas. Por ejemplo, los diagramas de interacción (ver Capítulo 4 ) Son buenos para describir el comportamiento de varios objetos en
un solo caso de uso, y los diagramas de actividad (ver Capítulo 11 ) Son buenos para mostrar la secuencia general de las actividades de varios
objetos y casos de uso.
No todo el mundo encuentra diagramas de estado natural. Mantenga un ojo en cómo las personas están trabajando con ellos. Puede ser que su
equipo no encuentra útiles diagramas de estado a su forma de trabajar. Eso no es un gran problema; Como siempre, usted debe recordar utilizar la
combinación de técnicas que funcione para usted.
Si usted hace uso de diagramas de estado, no tratar de atraerlos para cada clase en el sistema. Aunque este enfoque es a menudo utilizado por los completistas
de alto ceremonia, es casi siempre una pérdida de esfuerzo. Utilice diagramas de estado sólo para aquellas clases que exhiben un comportamiento interesante,
donde la construcción del diagrama de estado ayuda a entender lo que está pasando. Muchas personas encuentran que la interfaz de usuario y control de
objetos tienen el tipo de comportamiento que es útil para representar con un diagrama de estado.

Ambos Guía del usuario [ Booch, UML usuario] y la Manual de referencia [ Rumbaugh, UML Referencia] tiene más información sobre los diagramas de estado.
diseñadores en tiempo real tienden a utilizar modelos de estado mucho, así que no es sorpresa que [Douglass]) tiene mucho que decir acerca de los
diagramas de estado, incluida la información sobre la manera de ponerlas en práctica. [Martin] contiene un muy buen capítulo sobre las diversas formas de
implementar los diagramas de estado.
Capítulo 11. Los diagramas de actividad
diagramas de actividad son una técnica para describir la lógica de procedimientos, procesos de negocio, y el flujo de trabajo. En muchos sentidos,
juegan un papel similar a los diagramas de flujo, pero la principal diferencia entre ellos y la notación de diagrama de flujo es que apoyan el
comportamiento paralelo.
diagramas de actividad se han visto algunos de los cambios más importantes sobre las versiones de UML, por lo que tienen, como es lógico, han
ampliado significativamente alterado y otra vez para UML 2. En UML 1, la actividad
89/118
diagramas fueron vistos como casos especiales de diagramas de estado. Esto causó una gran cantidad de problemas para las personas que modelan flujos de
trabajo, que los diagramas de actividad son muy adecuadas para. En UML 2, se eliminó la corbata.
Figura 11.1 muestra un ejemplo sencillo de un diagrama de actividad. Comenzamos en el nodo inicial acción y luego hacer la acción de recibir
orden. Una vez hecho esto, nos encontramos con un tenedor. UN tenedor tiene un flujo de entrada y varios flujos concurrentes salientes.
Figura 11.1. Un diagrama de actividad simple
Figura 11.1 dice que cumplir con el pedido, enviar facturas, y las acciones subsiguientes se producen en paralelo. Esencialmente, esto significa
que la secuencia entre ellos es irrelevante. Podría llenar el pedido, enviar la factura, entregar, y luego recibir el pago; o bien, podría enviar la
factura, recibir el pago, llenar la orden, y luego entregar: se obtiene la imagen.
También puedo hacer estas acciones mediante el intercalado. Agarro la primera partida de las tiendas, escribir hasta la factura, agarra el segundo elemento de
línea, poner la factura en un sobre, y así sucesivamente. O, lo que podía hacer algo de esto
90/118
al mismo tiempo: escribir hasta la factura con una mano mientras meto la mano en tiendas con otra. Cualquiera de estas secuencias es
correcto, de acuerdo con el diagrama.
El diagrama de actividad permite a todo el que está haciendo el proceso para elegir el orden en el que hacer las cosas. En otras palabras, el diagrama se
limita a indicar las reglas de secuencia esenciales que tienen que seguir. Esto es importante para el modelado de procesos de negocio, porque a menudo
se producen en paralelo. Es también útil para los algoritmos concurrentes, en el que los hilos independientes pueden hacer las cosas de forma paralela.
Cuando se tiene el paralelismo, se deberá realizar la sincronización. No cerramos la orden hasta que es entregado y pagado. Se demuestra
esto con el unirse antes de la acción Cerrar Orden. Con una combinación, el flujo de salida se toma solamente cuando todos los flujos
entrantes llegan a la unión. Para que pueda cerrar la orden sólo cuando haya recibido el pago tanto y entregado.
UML 1 tenía reglas particulares para el equilibrio de las horquillas y se une, como diagramas de actividad son casos especiales de diagramas de
estado. Con UML 2, ya no es necesaria tal equilibrio.
Se dará cuenta de que los nodos en un diagrama de actividad se denominan acciones, no en las actividades. Estrictamente, una actividad se refiere a una
secuencia de acciones, por lo que el diagrama muestra una actividad que se compone de acciones.
el comportamiento condicional está delineada por las decisiones y las fusiones. UN decisión, llamado rama en UML 1, tiene un solo flujo de
entrada y varios vigilado flujos con destino fuera. Cada flujo de salida tiene un guardia: una condición booleana colocado entre corchetes. Cada
vez que llegue a una decisión, se puede tomar solo uno de los flujos de impresión, por lo que los guardias deben ser mutuamente excluyentes.
Utilizando [ más] como guardia indica que la [ más] flujo se debe utilizar si todos los otros guardias en la decisión son falsas.
En Figura 11.1 , Después de una orden está lleno, hay una decisión. Si usted tiene un pedido urgente, hacer una entrega al día; de lo
contrario, usted hace una entrega regular.
UN unir tiene múltiples flujos de entrada y una única salida. Una fusión marca el fin de la conducta condicionada iniciado por una
decisión.
En mis diagramas, cada acción tiene un único flujo que entra y un único flujo de salir. En UML 1, múltiples flujos de entrada tenían una
combinación implícita. Es decir, su acción se ejecutaría si cualquier flujo disparado. En UML 2, esto ha cambiado por lo que hay una implícita
se unen en su lugar; por lo tanto, la acción se ejecuta sólo si todos los flujos de gatillo. Como resultado de este cambio, le recomiendo que
utilice sólo un único flujo de entrada y salida a una acción y mostrar todo se une y se fusiona de forma explícita; que se evite la confusión.
Descomposición de una acción
Las acciones se pueden descomponer en subactividades. Puedo tomar la lógica entrega de Figura 11.1 y definirlo como su propia actividad ( Figura 11.2 ). A
continuación, se puede llamar así como una acción ( Figura 11.3 en la página 121).
Figura 11.2. Un diagrama de actividad subsidiaria
91/118
Figura 11.3. La actividad de Figura 11.1 modificada para invocar la actividad en
Figura 11.2
92/118
Las acciones pueden ser implementadas ya sea como subactividades o como métodos en clases. Puede mostrar una subactividad utilizando el
símbolo rastrillo. Puede mostrar una llamada en un método con la sintaxis Nombre de clase :: nombre de un metodo . También puede escribir un
fragmento de código en el símbolo de acción si el comportamiento no es invocado una sola llamada al método.
Y aún hay más

Debo destacar que este capítulo sólo roza la superficie de los diagramas de actividad. Al igual que en gran parte de la UML, se podría escribir
un libro entero en esta sola técnica. De hecho, creo que los diagramas de actividad harían un tema muy adecuado para un libro que realmente
excavado en la notación y cómo usarlo.
La cuestión fundamental es la amplitud con que se acostumbran. diagramas de actividad no son la técnica de UML más utilizado en la
actualidad, y sus progenitores de modelado de flujo no eran muy populares tampoco. técnicas esquemáticas aún no han despertado mucho
interés para describir el comportamiento de este tipo de forma. Por otra parte, hay señales en varias comunidades de una demanda reprimida
que una técnica estándar ayudará a satisfacer.
Cuándo utilizar diagramas de actividad
La gran fuerza de los diagramas de actividad radica en el hecho de que apoyan y fomentan un comportamiento paralelo. Esto los hace una gran herramienta
para el flujo de trabajo y el modelado de procesos, y de hecho gran parte del impulso en UML 2 ha venido de las personas involucradas en el flujo de trabajo
hace.
También puede utilizar un diagrama de actividades como un diagrama de flujo UML compatible. Aunque esto le permite hacer diagramas de flujo
de manera que se pega con UML, no es de muy emocionante. En principio, se puede tomar ventajas de las horquillas y se une para describir
algoritmos paralelos para los programas concurrentes. Aunque no viajo en círculos concurrentes que mucho, no he visto mucha evidencia de que
hay personas que los utilizan. Creo que la razón es que la mayor parte de la complejidad de la programación concurrente es para evitar la
contención en los datos, y los diagramas de actividad no ayudan mucho con eso.
La principal ventaja de hacer esto puede venir de gente usando UML como lenguaje de programación. En este caso, los diagramas de actividad
representan una técnica importante para representar la lógica de comportamiento.
He visto a menudo diagramas de actividad se usan para describir un caso de uso. El peligro de este enfoque es que, a menudo, los expertos de
dominio no siguen con facilidad. Si es así, sería mejor con la forma textual de costumbre.

Aunque los diagramas de actividad han sido siempre bastante complicado y son aún más con UML 2, no ha habido un buen libro que los
describe en profundidad. Espero que esta brecha se consigue algún día lleno.
Diversas técnicas orientadas a flujo son de estilo similar a los diagramas de actividad. Uno de los mejores conocido- pero apenas Redes de
Petri bien es sabido, para lo cual http://www.daimi.au.dk/PetriNets/ es un buen sitio web.
particiones
diagramas de actividad te dicen lo que pasa, pero no te dicen quién hace qué. En la programación, esto significa que el diagrama no transmite
la cual clase es responsable de cada acción. En los negocios
93/118
modelado de procesos, esto no transmite la cual parte de una organización, que lleva a cabo la acción. Esto no es necesariamente un
problema; a menudo, tiene sentido concentrarse en lo que se hace en lugar de en quién hace qué partes de la conducta.
Si desea mostrar quién hace qué, puede dividir un diagrama de actividades en particiones, los cuales muestran las acciones que una unidad de clase u
organización lleva a cabo. Figura 11.4 (En la página 122) muestra un ejemplo sencillo de esto, que muestra cómo las acciones implicadas en el
procesamiento de pedidos pueden ser separados entre los diversos departamentos.
Figura 11.4. Particiones en un diagrama de actividad
La división de la Figura 11.4 es un simple partición unidimensional. Este estilo se refiere a menudo como carriles de natación, por razones
obvias y fue la única forma utilizada en 1.x. UML En UML 2, puede utilizar una cuadrícula de dos dimensiones, por lo que la metáfora de la
natación ya no retiene el agua. También puede tomar cada dimensión y dividir las filas o columnas jerárquicamente.
señales
En el ejemplo simple de Figura 11.1 , Diagramas de actividad tienen un punto de partida claramente definido, que corresponde a una invocación
de un programa o rutina. Las acciones también pueden responder a las señales.
94/118
UN señal horaria se produce debido al paso del tiempo. Tales señales pueden indicar el final de un mes en un ejercicio económico o
cada microsegundo en un controlador en tiempo real.
Figura 11.5 muestra una actividad que escucha para dos señales. UN señal indica que la actividad recibe un evento de un proceso
exterior. Esto indica que la actividad en constante escucha de esas señales, y el diagrama define cómo reacciona la actividad.
Figura 11.5. Señales en un diagrama de actividad
En el caso de Figura 11.5 , 2 horas antes de mi salida del vuelo, tengo que empezar a hacer las maletas. Si soy rápido para el paquete de ellos,
todavía no puedo dejar hasta que llegue el taxi. Si el taxi llega antes de que se embalan mis maletas, tiene que esperar a que termine antes de que
vayamos.
Así como la aceptación de las señales, podemos enviarlos. Esto es útil cuando tenemos que enviar un mensaje y luego esperar una respuesta
antes de poder continuar. Figura 11.6 muestra un buen ejemplo de esto con un lenguaje común de tiempo de espera. Tenga en cuenta que los dos
flujos están en una carrera: el primero en llegar al estado final va a ganar y terminar el otro flujo.
Figura 11.6. Enviar y recibir señales
Aunque por lo general se acepta a la espera de un evento externo, también podemos mostrar un flujo de entrar en ellos. Eso indica que no
empezamos a escuchar hasta que el flujo desencadena la aceptan.
fichas
Si eres lo suficientemente valiente como para aventurarse en las profundidades demoníacas de la especificación UML, encontrará que la
sección de la actividad de la especificación habla mucho de fichas y su producción y consumo. El nodo inicial crea un contador, que luego pasa
a la siguiente acción, que ejecuta y luego pasa el testigo a la siguiente. En un tenedor, una ficha llega, y el tenedor produce una ficha
95/118
en cada uno de sus fluye hacia el exterior. Por el contrario, en una combinación, como llega cada símbolo de entrada, no pasa nada hasta que todas las fichas
aparecen en la unión; a continuación, un contador se produce en el flujo de salida.
Puede visualizar las fichas con monedas o fichas se mueven a través del diagrama. A medida que vaya ejemplos más complicados de los
diagramas de actividad, fichas frecuencia que sea más fácil de visualizar las cosas.
Los flujos y los bordes
UML 2 utiliza los términos fluir y borde como sinónimos para describir las conexiones entre dos acciones. El tipo más simple de borde es la
flecha simple entre dos acciones. Se puede dar una ventaja de un nombre si lo desea, pero la mayoría de las veces, será suficiente una simple
flecha.
Si tiene líneas de dificultades de envío, puede utilizar conectores, que sólo ahorrará tener que dibujar una línea de toda la distancia.
Cuando se utiliza conectores, debe utilizar de dos en dos: una con el flujo entrante, uno con un flujo de salida, y ambos con la misma
etiqueta. Tiendo a evitar el uso de conectores, si es posible, ya que rompen la visualización del flujo de control.
Los bordes simples pasan un contador que no tiene otro significado que para controlar el flujo. Sin embargo, también puede pasar objetos a lo largo de
los bordes; a continuación, los objetos desempeñan el papel de fichas, así como los datos de carry. Si estás pasando un objeto a lo largo del borde, se
puede demostrar que al poner una caja de clase en el borde, o puede utilizar pasadores de las acciones, aunque algunos pasadores implican más
sutilezas que describiré en breve.
Todos los estilos muestran en Figura 11.7 son equivalentes; usted debe usar lo que transmite bien lo que está tratando de comunicar. La
mayoría de las veces, la flecha simple es suficiente.
Figura 11.7. Cuatro maneras de mostrar una ventaja
Alfileres y Transformaciones
Las acciones pueden tener parámetros, al igual que lo hacen los métodos. No es necesario para mostrar información acerca de los parámetros
en el diagrama de actividad, pero si lo desea, puede mostrar con patas. Si está descomponiendo una acción, pasadores corresponden a las
casillas de parámetros en el diagrama descompuesto.
Cuando se está dibujando un diagrama de actividades estrictamente, usted tiene que asegurarse de que los parámetros de salida de una acción de
salida coinciden con los parámetros de entrada del otro. Si no coinciden, puede indicar una
96/118
transformación ( Figura 11.8 ) Para ir de una a otra. La transformación debe ser una expresión que está libre de efectos secundarios: en
esencia, una consulta en la quary pin de salida que suministra un objeto del tipo correcto para el pin de entrada.
Figura 11.8. Transformación de un flujo
Usted no tiene que mostrar pines en un diagrama de actividad. Pines son mejores cuando se quiere mirar los datos necesarios y producidos por las
diversas acciones. En el modelado de procesos de negocio, puede usar alfileres para mostrar los recursos producidos y consumidos por las
acciones.
Si utiliza pines, es seguro para mostrar múltiples flujos que entran en la misma acción. La notación pin refuerza unirse a la implícita, y
UML 1 no tienen pines, para que no haya confusión con los supuestos anteriores.
Regiones de expansión
Con los diagramas de actividad, a menudo se encuentra con situaciones en las que la producción de una acción desencadena múltiples invocaciones de
otra acción. Hay varias maneras de mostrar esto, pero la mejor manera es utilizar una región de expansión. Un región de expansión marca un área de
diagrama de actividad donde las acciones se producen una vez por cada elemento de una colección.
En Figura 11.9 , La acción de elegir temas genera una lista de temas como su salida. Cada elemento de esta lista se convierte entonces en un
símbolo de entrada a la acción de escritura del artículo. Del mismo modo, cada acción Artículo de Revisión genera un solo artículo que se
agrega a la lista de salida de la zona de expansión. Cuando todas las fichas en la región de expansión terminan en la colección de salida, la
región genera una sola ficha para la lista que se pasa a Publicar el boletín.
Figura 11.9. región de expansión
97/118
En este caso, usted tiene el mismo número de elementos de la colección de salida como lo hace en la colección de entrada. Sin embargo, es
posible que tenga menos, en cuyo caso la región de expansión actúa como un filtro.
En Figura 11.9 , Todos los artículos son escritos y revisados en paralelo, que está marcada por la
"concurrente" palabra clave. También puede tener una región de expansión iterativo. regiones iterativos deben procesar completamente cada
elemento de entrada de una en una.
Si sólo tiene una única acción que necesita múltiples invocación, utilizará la abreviatura de Figura
11.10 . La taquigrafía asume la expansión simultánea, ya que es el más común. Esta notación se corresponde con el concepto UML 1 de
concurrencia dinámica.
Figura 11.10. Abreviatura de una sola acción en una región de expansión
final de flujo
Una vez que obtenga varias fichas, como en una región de expansión, se encuentra frecuentemente con los flujos que se detienen incluso cuando la
actividad en su conjunto no termina. UN última flujo indica el final de un flujo particular, sin necesidad de terminar toda la actividad.
Figura 11.11 muestra esto mediante la modificación del ejemplo de Figura 11.9 para permitir que los artículos a ser rechazados. Si se rechaza un artículo, el
testigo es destruido por la final del flujo. A diferencia de una final de la actividad, el resto de la actividad puede continuar. Este enfoque permite a las regiones
de expansión para que actúen como filtros, por lo que la colección de salida es menor que la colección de entrada.
Figura 11.11. El flujo final en una actividad
98/118
Únete Especificaciones
Por defecto, una unión permite el paso de la ejecución en su flujo hacia el exterior cuando todos sus flujos de entrada han llegado al unirse. (O
en hablar más formal, emite una señal en su flujo de salida cuando una ficha ha llegado en cada flujo de entrada.) En algunos casos, sobre todo
cuando se tiene un flujo con múltiples fichas, es útil tener una regla más involucrados.
UN unirse a la especificación es una expresión booleana unido a una combinación. Cada vez que un token llega a la unión, unirse a la
especificación se evalúa y si es cierto, se emite un símbolo de salida. Así que en Figura 11.12 , Cada vez que selecciono una copa o insertar
una moneda, la máquina evalúa la especificación de unión. La máquina sacia mi sed sólo si me he puesto en el dinero suficiente. Si, como en
este caso, desea indicar que ha recibido una ficha en cada flujo de entrada, etiquetar los flujos y los incluye en la especificación unirse.
Figura 11.12. unirse a la especificación
99/118
Capítulo 12. Diagramas de Comunicación
diagramas de comunicación, un tipo de diagrama de interacción, hacen hincapié en los enlaces de datos entre los diferentes participantes en la
interacción. En vez de dibujar cada participante como una línea de vida y que muestra la secuencia de mensajes por la dirección vertical, como los
diagramas de secuencia hace, el diagrama de comunicación permite la colocación libre de los participantes, permite dibujar enlaces para mostrar
cómo se conectan los participantes, y el uso de la numeración para mostrar la secuencia de mensajes.
En UML 1.x, estos diagramas fueron llamados diagramas de colaboración. Este nombre se quedó así, y sospecho que será un tiempo
antes la gente se acostumbra al nuevo nombre. (Estos son diferentes de Colaboraciones [página 143], por lo que el cambio de nombre.)
Figura 12.1 muestra un diagrama de comunicación para la misma interacción control centralizado como en Figura
4.2 . Con un diagrama de comunicación, podemos mostrar cómo los participantes están unidos entre sí.
Figura 12.1. diagrama de comunicación para el control centralizado
Además de mostrar enlaces que son instancias de las asociaciones, también podemos mostrar enlaces transitorios, que surgen sólo el
contexto de la interacción. En este caso, el "local" enlace del orden al producto es una variable local; otros enlaces son transitorios "parámetro" y
"global" . Estas palabras clave se utilizaron en UML 1, pero no se encuentran en UML 2. Debido a que son de utilidad, espero que se queden
en torno a su uso convencional.
El estilo de numeración de Figura 12.1 es sencillo y de uso común, pero en realidad no es UML legal. Para ser UML kosher, usted tiene que
utilizar un esquema de numeración decimal anidada, como en Figura 12.2 .
Figura 12.2. diagrama de comunicación con numeración decimal anidada
100/118
La razón de los números decimales anidados es resolver la ambigüedad con la auto-llamadas. En Figura 4.2 , Se puede ver claramente que getDiscountInfo
se llama dentro del método CalculateDiscount . Con la numeración de la plana Figura 12.1 Sin embargo, no se puede decir si getDiscountInfo se
llama dentro de
CalculateDiscount o dentro de la general calculatePrice método. El esquema de numeración anidada resuelve este problema.
A pesar de su ilegalidad, muchas personas prefieren un esquema de numeración plana. Los números anidadas puede ser muy enredado, especialmente en lo
que reciben llamadas en lugar anidada, lo que lleva a estos números de secuencia como 1.1.1.2.1.1. En estos casos, la cura para la ambigüedad puede ser
peor que la enfermedad.
Así como los números, también puede ver las letras en los mensajes; estas letras indican diferentes hilos de control. Así mensajes A5 y B2
estarían en diferentes hilos; Mensajes 1a1 y 1b1 serían diferentes hilos simultáneamente anidados dentro del mensaje 1. También se ven las
letras de hilo en los diagramas de secuencia, aunque esto no expresa la concurrencia visualmente.
diagramas de comunicación no tienen ninguna notación precisa para la lógica de control. Hacen le permiten utilizar marcadores de iteración y
guardias (página 59), pero no le permiten especificar totalmente lógica de control. No existe una notación especial para la creación o eliminación
de objetos, pero la "crear" y "borrar" palabras clave son las convenciones comunes.
Cuándo utilizar diagramas de Comunicación
La cuestión principal con diagramas de comunicación es cuándo usarlos en lugar de los diagramas de secuencia más comunes. Un fuerte parte
de la decisión es la preferencia personal: Algunas personas, como uno sobre el otro. A menudo, que impulsa la elección más que cualquier otra
cosa. En general, la mayoría de la gente parece preferir los diagramas de secuencia, y por una vez, estoy con la mayoría.
Un enfoque más racional dice que los diagramas de secuencia son mejores cuando se quiere hacer hincapié en la secuencia de llamadas y que
los diagramas de comunicación es mejor cuando se quiere hacer hincapié en los enlaces. Muchas personas encuentran que los diagramas de
comunicación son más fáciles de modificar en una pizarra, por lo que son un buen método para explorar alternativas, aunque en esos casos, a
menudo prefiero tarjetas CRC.
Capítulo 13. Estructuras Compuestas

Una de las nuevas características más significativas en UML 2 es la capacidad de descomponer jerárquicamente una clase en una estructura
interna. Esto le permite tomar un objeto complejo y descomponerlo en partes.
Figura 13.1 muestra una clase Visor de TV con sus interfaces proporcionadas y necesarias (página 69). He demostrado esto de dos maneras:
mediante la notación de bola y zócalo y enumerarlos internamente.
101/118
Figura 13.1. Dos maneras de mostrar un visor de televisión y sus interfaces
Figura 13.2 muestra cómo esta clase se descompone internamente en dos partes y que soportan las piezas y requieren las diferentes interfaces.
Cada parte se nombra en el formulario Nombre: Clase , con ambos elementos opcionales de forma individual. Las piezas no son especificaciones
de instancia, por lo que están en negrita en lugar de subrayados.
Figura 13.2. Vista interna de un componente (ejemplo sugerido por Jim

Rumbaugh)
102/118
Puede mostrar cómo están presentes muchos casos de una parte. Figura 13.2 dice que cada televidente contiene una parte del
generador y un control parcial.
Para mostrar una parte implementar una interfaz, se dibuja un conector de delegar esa interfaz. Del mismo modo, para mostrar que una parte
necesita una interfaz, que muestran un conector que delega a esa interfaz. También puede mostrar conectores entre las partes, ya sea con una
simple línea, como lo he hecho aquí, o con la notación bola y cavidad (página 71).
Puede agregar puertos ( Figura 13.3 ) A la estructura externa. Puertos le permiten agrupar las interfaces necesarias y proporcionadas en las
interacciones lógicas que tiene un componente con el mundo exterior.
Figura 13.3. Un componente con múltiples puertos
Cuándo utilizar Estructuras Compuestas
Las estructuras compuestas son nuevos en UML 2, aunque algunos métodos más antiguos tenían algunas ideas similares. Una buena manera de pensar acerca de la
diferencia entre los paquetes y estructuras de materiales compuestos es que los paquetes son una agrupación en tiempo de compilación, mientras que las estructuras
compuestas muestran agrupaciones de tiempo de ejecución. Como tales, son un ajuste natural para que muestra los componentes y la forma en que se rompen en
partes; por lo tanto, gran parte de esta notación se utiliza en diagramas de componentes.
Debido a que las estructuras compuestas son nuevos en el UML, es demasiado pronto para decir qué tan efectivos serán los resultados en la
práctica; muchos miembros del comité UML piensan que estos diagramas se convertirá en una adición muy valiosa.
Capítulo 14. Los diagramas de componentes
Un debate que siempre osciló grande en la comunidad OO es cuál es la diferencia entre un componente y cualquier clase regular. Este no es
un debate que yo quiero a establecerse aquí, pero puedo mostrar la notación UML utiliza para distinguir entre ellos.
UML 1 tenía un símbolo distintivo de un componente ( Figura 14.1 ). UML 2 elimina ese icono, pero permite anotar una caja de clase con un
icono de aspecto similar. Alternativamente, se puede utilizar el "componente"
palabra clave.
Figura 14.1. Notación para componentes
103/118
Que no sea el icono, los componentes no introducen ninguna indicación de que no hemos visto ya. Los componentes están conectados a través de
interfaces implementadas y requeridos, a menudo utilizando la notación socket-ball y- (página 71) al igual que para los diagramas de clase. También puede
descomponer componentes mediante el uso de diagramas de estructura de material compuesto.
Figura 14.2 muestra un ejemplo de diagrama de componente. En este ejemplo, una venta hasta pueden conectarse a un componente del servidor de
ventas, usando una interfaz de mensaje de las ventas. Debido a que la red no es confiable, un componente de la cola de mensajes está configurado
para la caja puede hablar con el servidor cuando la red está en marcha y hablar con una cola cuando la red está caída; la cola entonces hablar con el
servidor cuando la red esté disponible. Como resultado, la cola de mensajes tanto suministra la interfaz de mensaje de ventas para hablar con el
recibo y requiere que la interfaz de hablar con el servidor. El servidor se descompone en dos componentes principales. El procesamiento de
transacciones se da cuenta de la interfaz de mensaje de las ventas, y el conductor habla de contabilidad al sistema de contabilidad.
Figura 14.2. Un ejemplo de diagrama de componente
Como ya he dicho, la cuestión de lo que es un componente es el tema de discusión sin fin. Una de las declaraciones más votos que he
encontrado es la siguiente:
Los componentes no son una tecnología. Tecnología personas parecen encontrar esto difícil de entender. Los componentes
son acerca de cómo los clientes quieren relacionarse con el software. Ellos quieren ser capaces de comprar su software de
una pieza a la vez, y ser capaz de actualizarlo al igual que lo pueden actualizar su estéreo. Ellos quieren nuevas piezas a
trabajar de forma integrada con sus piezas antiguas, y para ser capaz de actualizar en su propio horario, no el horario del
fabricante. Ellos quieren ser capaces de mezclar y combinar piezas de distintos fabricantes. Este es un requisito muy
razonable. Es simplemente difícil de satisfacer.
Ralph Johnson, http://www.c2.com/cgi/wiki?DoComponentsExist
El punto importante es que los componentes representan piezas que son independientemente adquiribles y actualizable. Como resultado, la
división de un sistema en componentes es tanto una decisión de marketing, ya que es una decisión técnica, para lo cual [Hohmann] es un
excelente guía. Es también un recordatorio de que tengan cuidado
104/118
componentes excesivamente de grano fino, porque hay demasiados componentes son difíciles de manejar, especialmente cuando de versiones levanta su
cabeza fea, por lo tanto, el "infierno DLL".
En las versiones anteriores de la UML, se utilizaron los componentes para representar estructuras físicas, tales como DLL. Eso ya no es
cierto; para esta tarea, ahora se utiliza artefactos (página 97).
Cuándo utilizar diagramas de componentes
Utilice diagramas de componentes cuando estás dividiendo el sistema en componentes y quieren mostrar sus interrelaciones a través de
interfaces o la descomposición de los componentes en una estructura de nivel inferior.
Capítulo 15. Colaboraciones

A diferencia de los otros capítulos de este libro, éste no corresponde a un diagrama oficial en UML 2. La norma discute colaboraciones como
parte de estructuras de materiales compuestos, pero el diagrama es realmente muy diferente y se utilizó en UML 1 sin ningún vínculo con
estructuras compuestas . Así que sentí que lo mejor para discutir colaboraciones como su propio capítulo.
Vamos a considerar la idea de una subasta. En cualquier subasta, podríamos tener un vendedor, algunos compradores, un lote de mercancías, y
algunas ofertas de venta. Podemos describir estos elementos en términos de un diagrama de clases ( Figura 15.1 ) Y quizás algunos diagramas de
interacción ( Figura 15.2 ).
Figura 15.1. Una colaboración con su diagrama de clases de papeles
Figura 15.2. Un diagrama de secuencia para la colaboración subasta
105/118
Figura 15.1 no es bastante un diagrama de clases regular. Para empezar, está rodeado por la elipse de trazos, que representa la colaboración
subasta. En segundo lugar, las llamadas clases en la colaboración, pero no son clases papeles que se realizará tal como se aplica, de ahí la
colaboración del hecho de que sus nombres no se capitalizan. No es raro ver a las interfaces actuales o clases que corresponden a las
funciones de colaboración, pero usted no tiene que tener ellos.
En el diagrama de interacción, los participantes están etiquetados de forma ligeramente diferente del caso habitual. En una colaboración, el esquema
de nombres es -participante Nombre / role-name: nombre-clase . Como de costumbre, todos estos elementos son opcionales.
Cuando se utiliza una colaboración, se puede demostrar que mediante la colocación de una ocurrencia colaboración en un diagrama de clases, como
en Figura 15.3 , Un diagrama de clases de algunas de las clases de la aplicación. Los enlaces de la colaboración de las clases indican cómo las
clases desempeñan las diversas funciones definidas en la colaboración.
Figura 15.3. Una ocurrencia colaboración
106/118
El UML sugiere que puede utilizar la notación colaboración ocurrencia de mostrar el uso de patrones, pero casi ninguno patrones autor ha
hecho esto. Erich Gamma desarrolló una notación alternativa agradable ( Figura 15.4 ). Elementos del diagrama se etiquetan con ya sea el
nombre del patrón o una combinación de patrón: papel .
Figura 15.4. Una forma no estándar de muestra el uso patrón en JUnit (junit.org)
Cuándo utilizar Colaboraciones
Colaboraciones han existido desde UML 1, pero admito que casi no los he usado, incluso en mi forma de escribir patrones. Colaboraciones
proporcionan una forma de trozos de grupos de comportamiento interacción cuando los papeles son interpretados por diferentes clases. En la práctica,
sin embargo, no he encontrado que han sido un tipo de diagrama convincente.
Capítulo 16. Descripción de la Interacción Diagramas

diagrama global de interacciones son un injerto juntos de los diagramas de actividad y diagramas de secuencia. Se puede pensar en diagrama
global de interacciones, ya sea como diagramas de actividad en los que las actividades son
107/118
reemplazado por pequeños diagramas de secuencia, o como un diagrama de secuencia roto con notación diagrama de actividad se utiliza para mostrar el
flujo de control. De cualquier manera, hacer un poco de una mezcla extraña.
Figura 16.1 muestra un ejemplo simple de uno; la notación es familiar de lo que ya hemos visto en los capítulos diagrama de actividad y el
diagrama de secuencia. En este diagrama, queremos producir y dar formato a un informe de resumen del pedido. Si el cliente es externo, se
obtiene la información de XML; si es interno, lo entendemos desde una base de datos. Pequeños diagramas de secuencia muestran las dos
alternativas. Una vez que tengamos los datos, formatear el informe; en este caso, no mostramos el diagrama de secuencia sino simplemente
hacer referencia a ella con un marco de interacción referencia.
Figura 16.1. Resumen diagrama de interacción
Cuándo utilizar diagramas Descripción de la Interacción
Estos son nuevos para UML 2, y es demasiado pronto para conseguir mucho sentido de lo bien que van a trabajar a cabo en la práctica. No estoy
interesado en ellos, ya que creo que se mezclan dos estilos que en realidad no se mezclan bien. O bien dibujar un diagrama de actividades o usar un
diagrama de secuencia, dependiendo de lo que mejor sirve a su propósito.
108/118
Capítulo 17. Los diagramas de temporización
Después de salir de la escuela secundaria, empecé en ingeniería electrónica Antes de cambiar en la informática. Así que siento una cierta
familiaridad de angustia cuando veo el UML definir diagramas de tiempo como uno de sus diagramas estándar. diagramas de tiempo han
existido en ingeniería electrónica desde hace mucho tiempo y nunca parecía necesitar la ayuda de la UML para definir su significado. Pero ya
que están en el UML, que merecen una breve mención.
diagramas de temporización son otra forma de diagrama de interacción, en el que el foco está en restricciones de temporización: o bien para un
único objeto o, más útil, para un grupo de objetos. Vamos a echar un escenario simple basado en la bomba y la placa de cocción para una taza
de café. Imaginemos una regla que dice que al menos 10 segundos deben pasar entre la bomba y viniendo sobre la placa de cocción acerca.
Cuando el depósito de agua se vacía, la bomba se apaga y la placa de cocción no puede permanecer durante más de 15 minutos más.
Las figuras 17.1 y 17.2 son formas alternativas de mostrar estas limitaciones de tiempo. Ambos diagramas muestran la misma información
básica. La diferencia principal es que Figura 17.1 muestra los cambios de estado moviendo desde una línea horizontal a otro, mientras Figura
17.2 conserva la misma posición horizontal pero muestra los cambios de estado con una cruz. El estilo de Figura 17.1 funciona mejor cuando hay
sólo unos pocos estados, como en este caso, y Figura 17.2 es mejor cuando hay muchos estados que tratar.
Figura 17.1. Timing estados diagrama que muestra como líneas
Figura 17.2. Timing estados diagrama que muestra como las áreas
109/118
Las líneas discontinuas que he utilizado en los 10s {>} restricciones son opcionales. Usarlos si usted piensa que ayudan a clarificar
exactamente lo que limita el tiempo eventos.
Cuándo utilizar diagramas de tiempo
diagramas de tiempo son útiles para mostrar las limitaciones de tiempo entre los cambios de estado en diferentes objetos. Los diagramas
son particularmente familiar a los ingenieros de hardware.
Los cambios Apéndice entre las versiones de UML

Cuando la primera edición de este libro apareció en los estantes, el UML fue en la versión 1.0. Gran parte de ella parecía haberse estabilizado y
estaba en el proceso de reconocimiento de OMG. Desde entonces, ha habido una serie de revisiones. En este apéndice, se describen los
cambios significativos que han ocurrido desde
1.0 y cómo estos cambios afectan al material de este libro.
En este apéndice se resumen los cambios para que pueda mantenerse al día si usted tiene una impresión anterior del libro. He realizado cambios
en el libro de mantenerse al día con UML, así que si usted tiene una impresión posterior, se describe la situación como lo fue en la fecha de
impresión.
Las revisiones del UML
El lanzamiento público más temprano de lo que llegó a ser el UML fue la versión 0.8 del Método Unificado, que fue lanzado por OOPSLA en
octubre de 1995. Esta fue la obra de Booch y Rumbaugh, como Jacobson no se unió a Rational hasta alrededor de ese tiempo. En 1996,
Rational lanzado versiones 0.9 y 0.91, que incluían el trabajo de Jacobson. Después de la última versión, se cambió el nombre a la UML.
Racional y un grupo de socios presentado la versión 1.0 del UML para el Análisis y Diseño OMG Grupo de Trabajo en enero de 1997.
Posteriormente, la asociación racional y los otros peticionarios combinaron su trabajo y presentaron una sola propuesta para el estándar OMG
en septiembre de 1997, por versión 1.1 del UML. Esto fue aprobado por el OMG hacia el final de 1997. Sin embargo, en un ataque de
ofuscación más oscura, el OMG llamó a esta versión estándar 1.0. Por lo tanto, ahora el UML era a la vez OMG
110/118
versión 1.0 y la versión 1.1 Rational, que no debe confundirse con Rational 1.0. En la práctica, todo el mundo llama esa versión estándar
1.1.
A partir de entonces, hubo una serie de novedades en el UML. UML 1.2 apareció en 1998,
1,3 en 1999, 1,4 en 2001 y 1,5 en 2002. La mayor parte de los cambios entre las versiones 1.x eran bastante profundo en el UML, a excepción de
UML 1,3, lo que provocó algunos cambios muy visibles, especialmente para los casos de uso y diagramas de actividad.
A medida que la serie UML 1 continuación, los desarrolladores del UML puesto sus ojos sobre una modificación sustancial a la UML con UML 2. Los
primeros RFP (solicitud de propuestas) fueron emitidos en 2000, pero UML 2 no comenzaron a estabilizarse correctamente hasta 2003.
es casi seguro que producirse nuevos acontecimientos ocurridos en el UML. El Foro UML ( http: // uml- forum.com ) Es por lo general un buen
lugar para buscar más información. También tengo alguna información UML en mi sitio ( http://martinfowler.com ).
Cambios en UML Distilled
A medida que estas revisiones van, yo he estado tratando de mantenerse al día mediante la revisión UML Distilled con impresiones posteriores. También
he tenido la oportunidad de corregir los errores y hacer aclaraciones.
El periodo más dinámico para mantenerse al día con las cosas fue durante la primera edición de UML destilada,
cuando a menudo nos tuvimos que hacer cambios entre ediciones para mantenerse al día con el estándar UML emergente. El primero a través de
impresiones quinto se basaron en UML 1.0. Cualquier cambio en el UML entre estas impresiones fueron menores. La sexta impresión se llevó UML
1.1 en cuenta.
El séptimo al décimo impresiones se basa en UML 1.2; el undécimo impresión fue el primero en utilizar UML 1.3. Impresiones basadas en
versiones de la UML después de 1,0 tienen el número de versión UML en la cubierta frontal.
El primero sin embargo sexta ediciones de la segunda edición se basaron en la versión 1.3. La séptima impresión fue el primero en tener
en cuenta los cambios de menor importancia de la versión 1.4.
La tercera edición se puso en marcha para actualizar el libro con UML 2 (véase Tabla A.1 ). En el resto de este apéndice, I resumir los cambios
importantes en el UML 1,0-1,1 de 1.2 a 1.3, y desde 1.x a 2.0. No discuto todos los cambios que se producen, sino sólo aquellos que cambie
algo que dije en UML Distilled o que representen características importantes que yo hubiera discutido en UML destilada.
Estoy continuando a seguir el espíritu de UML destilada: para discutir los elementos clave de UML ya que afectan a la aplicación de la UML
dentro de los proyectos del mundo real. Como siempre, las selecciones y los consejos son mi propio. Si existe algún conflicto entre lo que digo
y los documentos oficiales de UML, los documentos de UML son los que siguen. (Pero que me haga saber, para que yo pueda hacer las
correcciones.)
Tabla A.1. UML Distilled y los correspondientes versiones UML

UML Distilled Versiones UML
1ª edición 1.0-1.3 UML
2ª edición 1.3-1.4 UML
3ª edición UML 2.0 en adelante
También he tenido la oportunidad de indicar los errores y omisiones importantes en las ediciones anteriores. Gracias a los lectores que
han señalado estos a mí.
111/118
Los cambios de UML 1,0 a 1,1
Tipo y la implementación de la clase
En la primera edición de UML destilada, Hablé de perspectivas y la forma en que alteran la forma de dibujar e interpretar modelos, en particular,
los diagramas de clases. UML ahora tiene esto en cuenta al decir que todas las clases en un diagrama de clases pueden ser especializados, ya
sea como tipos o clases de implementación.
Un clase de implementación corresponde a una clase en el entorno de software en el que se está desarrollando. UN tipo es bastante más
nebulosa; que representa una abstracción menos aplicación determinada. Esto podría ser un tipo CORBA, una perspectiva de la especificación
de una clase, o el punto de vista conceptual. Si es necesario, se puede añadir estereotipos para diferenciar aún más.
Se puede afirmar que para un diagrama en particular, todas las clases siguen un estereotipo en particular. Esto es lo que haría al dibujar un
diagrama de una perspectiva particular. La perspectiva de implementación usaría clases de implementación, mientras que la especificación y
perspectiva conceptual utilizarían tipos.
Se utiliza la relación de realización para indicar que una clase de implementación implementa uno o más tipos.
Hay una distinción entre el tipo y la interfaz. Una interfaz está destinado a corresponder directamente a una aplicación Java o una interfaz de estilo
COM. por lo tanto sólo tienen interfaces de operaciones y atributos.
Es posible utilizar la clasificación único sencillo, estático con clases de implementación, pero se puede utilizar la clasificación múltiple y dinámica
con tipos. (Supongo que esto es debido a que los principales lenguajes orientados a objetos siguen clasificación único, estático. Si un buen día, se
utiliza un lenguaje que soporte la clasificación múltiple o dinámico, que la restricción realmente no debería aplicarse.)
Las restricciones completas e incompletas discriminador
En ediciones anteriores de UML destilada, He dicho que el { completar} restricción en una generalización indicó que todas las instancias del
supertipo también debe ser una instancia de un subtipo dentro de esa partición. UML 1.1 define en cambio que { completar} indica que todos
los subtipos dentro de esa partición se han especificado, que no es exactamente lo mismo. He encontrado algunas inconsistencias en la
interpretación de esta restricción, por lo que debe tener cuidado de él. Si desea indicar que todas las instancias del supertipo debe ser una
instancia de uno de los subtipos, se sugiere emplear otra restricción para evitar confusiones. Actualmente, estoy usando { obligatorio} .
Composición
En UML 1.0, utilizando composición da a entender que el enlace era inmutable, o congelados, al menos para solo o componentes
valorados. Esa restricción ya no es parte de la definición.
Inmutabilidad y congelado
UML define la restricción { congelado} para definir inmutabilidad en roles de asociación. Como se define actualmente, no parece aplicarlo a
atributos o clases. En mi práctica, ahora utilizo el término
congelado en lugar de la inmutabilidad, y estoy feliz de aplicar la restricción a los roles de asociación, clases y atributos.
Los rendimientos de los diagramas de secuencia
En UML 1.0, un retorno de un diagrama de secuencia se distingue mediante el uso de una punta de flecha stick en lugar de una punta de flecha sólida (ver
impresiones previas). Esta fue una especie de dolor, ya que la distinción era demasiado sutil y fácil de perder. UML 1.1 utiliza una flecha discontinua para un
retorno, lo que me gusta, ya que hace que los rendimientos mucho más evidente. (Como ya he utilizado retornos de trazos de la Patrones de análisis [ Fowler,
AP], sino que también
112/118
Me hace parecer influyente.) Se puede nombrar lo que se devuelve para su uso posterior utilizando el formulario
enoughStock: = comprobar () .
El uso del término "papel"
En UML 1.0, el término papel indicado principalmente una dirección en una asociación (ver impresiones previas). UML 1.1 se refiere a este uso
como una rol de asociación. También hay una papel de la colaboración, que es un papel que una instancia de una clase juega en una
colaboración. UML 1.1 da mucha más importancia a las colaboraciones, y parece que este uso de "papel" puede llegar a ser el principal.
Los cambios de UML 1.2 (y 1.1) a 1.3 (y 1.5)
Casos de uso
Los cambios en los casos de uso implican nuevas relaciones entre casos de uso. UML 1.1 tiene dos relaciones de casos de uso: "usos" y «Extiende»
, ambos de los cuales son los estereotipos de generalización. UML 1.3 ofrece tres tipos de relaciones.
• los "incluir" construir un estereotipo de dependencia. Esto indica que el camino de un caso de uso se incluye en otro. Por lo general,
esto ocurre cuando unos pocos casos de uso comparten pasos comunes. El caso de uso incluido puede factorizar el comportamiento
común. Un ejemplo de un cajero automático podría ser que retirar dinero y Realizar transferencia ambos utilizan Validar cliente. Esto
reemplaza el uso común de "usos" .
• caso de uso generalización indica que un caso de uso es una variación de otra. Por lo tanto, podríamos tener un caso de uso para
retirar el dinero, el uso de base de casos y un caso de uso separado para manejar el caso en que la retirada se rechazó debido a la
falta de fondos. El rechazo puede ser manejado como un caso de uso que se especializa el caso de uso de retirada. (También puede
manejarlo simplemente como otro escenario en el caso Retirar el uso del dinero.) Un caso de uso especializado como esto puede
cambiar cualquier aspecto del caso de uso base.
• los "ampliar" construir un estereotipo de dependencia. Esto proporciona una forma más controlada de la extensión de la relación de
generalización. Aquí, el caso de uso base declara un número de puntos de extensión. El caso de uso se extiende puede alterar
comportamiento sólo en aquellos puntos de extensión. Por lo tanto, si usted está comprando un producto en línea, es posible que
tenga un caso de uso para la compra de un producto con puntos de extensión para capturar la información de envío y la captura de
la información de pago. Ese caso de uso podría entonces ser extendido por un cliente para el que se obtuvo esta información de una
manera diferente.
Existe cierta confusión acerca de la relación entre las viejas relaciones y los nuevos. La mayoría de las personas utilizan "usos" la forma en que el
1.3 «Incluye» se utiliza, por lo que para la mayoría de la gente, podemos decir que
«Incluye» reemplaza "usos" . Y la mayoría de la gente utiliza 1.1 «Extiende» tanto en la forma controlada de la 1,3 «Extiende» y como primordial
general en el estilo de la 1,3 generalización. Por lo tanto, se puede pensar que 1.1 «Extiende» se ha dividido en el 1.3 "ampliar" y generalización.
Ahora bien, aunque esta explicación cubre uso más UML que he visto, no es la forma correcta de utilizar estrictamente esas viejas relaciones.
Sin embargo, la mayoría de las personas no siguen el uso estricto, y yo realmente no quieren meterse en todo lo que aquí.
Los diagramas de actividad
Cuando el UML alcanzó la versión 1.2, hubo un buen número de preguntas abiertas sobre la semántica de los diagramas de actividad. Por lo tanto,
el esfuerzo 1.3 involucrado un buen montón de endurecimiento de esta semántica.
Para el comportamiento condicional, ahora puede usar la actividad de decisiones en forma de diamante para una combinación de comportamiento, así
como una rama. Aunque ni ramas ni fusiones son necesarios para describir el comportamiento condicional, es de estilo cada vez más común para
mostrarles de manera que se puede poner entre paréntesis el comportamiento condicional.
113/118
La barra de sincronización que ahora se conoce como una tenedor control o división -cuando como una unirse -cuando control de sincronización
juntos. Sin embargo, ya no se puede añadir a condiciones arbitrarias se une. Además, debe seguir las reglas de juego para asegurar que se bifurca
y se une coinciden. En esencia, esto significa que cada tenedor debe tener la correspondiente combinación que une las discusiones iniciadas por
ese tenedor. Puede tenedor nido y se une, sin embargo, y puede eliminar las horquillas y se une en el diagrama cuando las discusiones van
directamente de un tenedor a otro tenedor, o uno unirse a otra unión.
Las combinaciones se disparó sólo cuando todos los hilos entrantes completa. Sin embargo, puede tener una condición en un hilo que sale de
un tenedor. Si esa condición es falsa, ese hilo se considera completa para la unión de propósitos.
La característica de múltiples gatillo ya no está presente. En su lugar, puede hacer que la concurrencia dinámica en una actividad, se muestra con
un * en el interior de una caja de actividades. Tal actividad se puede invocar varias veces en paralelo; todas sus invocaciones deben completar antes
de que cualquier transición saliente se pueden tomar. Esto es sin apretar equivalente a, aunque menos flexible que, un disparador y la
sincronización coincidente condición múltiple.
Estas reglas se reducen algunos de flexibilidad de los diagramas de actividad, pero no garantizan que los diagramas de actividad son realmente casos
especiales de las máquinas de estado. La relación entre los diagramas de actividad y máquinas de estado era un asunto de debate en el RTF. Las futuras
versiones del UML (después de 1,4) pueden muy bien hacer que los diagramas de actividad una forma completamente diferente de diagrama.
Los cambios de UML 1.3 a 1.4
El cambio más visible en UML 1.4 es la adición de perfiles, que permite que un grupo de extensiones a ser recogido juntos en un conjunto
coherente. La documentación UML incluye un par de ejemplos de perfiles. Junto con esto, hay una mayor formalismo que participan en la
definición de un estereotipo, y los elementos del modelo ahora puede tener múltiples estereotipos; estaban limitados a un estereotipo de UML
1.3.
artefactos se añadieron a la UML. Un artefacto es una manifestación física de un componente, por lo que, por ejemplo, es un componente
Xerces y todas esas copias de la jarra Xerces en mi unidad de disco son artefactos que implementan el componente Xerces.
Antes de 1.3, no había nada en el meta-modelo de UML para manejar Java visibilidad de paquete. Ahora hay, y es el símbolo "~".
UML 1.4 también hizo que la punta de flecha palo en interacción Diagramas asíncrono marca, un cambio hacia atrás-incompatible
bastante incómodo. Eso llamó a cabo unas pocas personas, incluido yo.
Los cambios de UML 1.4. a 1,5
El principal cambio aquí fue la adición de la semántica de acción a la UML, un paso necesario para hacer UML un lenguaje de programación.
Esto se hizo para permitir a la gente a trabajar en esto sin esperar a que el UML completo 2.
De 1.x UML a UML 2.0

UML 2 representa el cambio más grande que ha ocurrido todavía a la UML. Todo tipo de cosas han cambiado con esta revisión, y
muchos cambios han afectado UML destilada.
Dentro del UML, se han producido profundos cambios en el meta-modelo de UML. Aunque estos cambios no afectan a la discusión en UML
destilada, que son muy importantes para algunos grupos.
114/118
Uno de los cambios más evidentes es la introducción de nuevos tipos de diagramas. Los diagramas de objetos y diagramas de paquetes se extraen
ampliamente antes, pero no eran los tipos oficiales de diagramas; Ahora son. UML 2 cambió el nombre de diagramas de colaboración con los
diagramas de comunicación. UML 2 también ha introducido nuevos tipos de diagramas: diagrama global de interacciones, diagramas de temporización,
y los diagramas de estructura compuesta.
Una gran cantidad de cambios no han tocado UML destilada. He dejado de lado la discusión de construcciones tales como extensiones de máquina de estados,
ciudades, en las interacciones diagramas y tipos de energía en los diagramas de clases.
Así, por esta sección, estoy discutiendo únicos cambios que se hacen en UML destilada. Estos son o bien los cambios en las cosas que
mencioné en anteriores ediciones o cosas nuevas he empezado a discutir con esta edición. Debido a que los cambios son tan numerosos,
los he organizado de acuerdo con los capítulos de este libro.
Los diagramas de clase: Los Essentials ( Capítulo 3 )
Atributos y asociaciones unidireccionales son ahora principalmente simplemente diferentes notaciones para el mismo concepto subyacente de
la propiedad. multiplicidades discontinuos, tales como [2, 4], se han caído. La propiedad congelada se ha caído. He añadido una lista de
palabras clave de dependencias comunes, algunos de los cuales son nuevos en UML 2. El "parámetro" , y "local" palabras clave han sido
retirados.
Los diagramas de secuencia ( Capítulo 4 )
El gran cambio aquí es la notación marco de interacción para los diagramas de secuencia para manejar iterativos, condicionales, y varios otros
controles de comportamiento. Esto ahora le permite expresar algoritmos bastante completo en los diagramas de secuencia, aunque no estoy
convencido de que estos son más claro que el código. Los viejos marcadores de iteración y guardias de los mensajes se han bajado de los
diagramas de secuencia. Las cabezas de las líneas de vida son casos ya no; Yo uso el término partícipe para referirse a ellos. Los diagramas de
colaboración de UML 1 se cambió el nombre a los diagramas de comunicación para UML 2.
Los diagramas de clase: Conceptos ( Capítulo 5 )
Los estereotipos son ahora más estrechamente definidos. Como resultado, ahora me refiero a las palabras en guillemets como palabras clave, sólo
algunos de los cuales son estereotipos. Instancias en diagramas de objetos son ahora las especificaciones de instancia. Las clases ahora pueden
requerir las interfaces, así como proporcionarles. La clasificación múltiple utiliza conjuntos de generalización a generalizaciones grupo en grupos.
Componentes ya no se dibujan con su símbolo especial. objetos activos tienen líneas verticales dobles en lugar de líneas gruesas.
Diagramas máquina de estados ( capítulo 10 )
UML 1 separa las acciones de corta duración de las actividades de larga vida. UML 2 llama a ambas actividades y utiliza el término do-actividad para
las actividades de larga vida.
Los diagramas de actividad ( Capítulo 11 )
UML 1 tratada diagramas de actividad como un caso especial de diagrama de estado. UML 2 rompió ese enlace y como resultado elimina las reglas de
horquillas emparejan y se une a que los diagramas de actividad UML 2 tenían que mantener a. Como resultado de ello, se entienden mejor por el flujo de
contador en lugar de por transición de estado. Un montón de nueva notación por lo tanto apareció, incluyendo el tiempo y aceptar señales, parámetros, unirse
a las especificaciones, pasadores, transformaciones de flujo, sub diagrama rastrillos, las regiones de expansión, y las finales fluir.
Un cambio simple pero incómoda es que UML 1 tratados múltiples flujos de entrada a una actividad por cuenta de combinación implícita, mientras que UML
2 los trata como una implícita unen. Por esta razón, recomiendo el uso de una combinación explícita o unirse al hacer diagramas de actividad.
carriles de nado ahora pueden ser multidimensional y generalmente se llaman particiones.
115/118
Bibliografía
[Caballo amblador] Scott Ambler, Modelado ágil, Wiley, 2002.
[Arroyo] Kent Beck, Extreme Programming Explained: aceptar el cambio, Addison-Wesley, 2000.
[Beck y Fowler] Kent Beck y Martin Fowler, La planificación de la programación extrema, Addison-Wesley,
2000.
[Beck y Cunningham] Kent Beck y Ward Cunningham, "un laboratorio para Enseñar a pensar orientada a objetos" Actas de OOPSLA 89, 24
(10): 1-6.
http://c2.com/doc/oopsla89/paper.html
[Booch, OOAD] Grady Booch, Análisis orientado a objetos y el diseño con aplicaciones, segunda edición. Addison-Wesley, 1994.
[Booch, UML usuario] Grady Booch, Jim Rumbaugh, e Ivar Jacobson, Guía del usuario de UML, Addison-Wesley, 1999.
[Coad, OOA] Peter Coad y Edward Yourdon, Análisis orientado a objetos, Yourdon Press, 1991.
[Coad, OOD] Peter Coad y Edward Yourdon, Diseño Orientado a Objetos, Yourdon Press, 1991.
[Cockburn, ágil] Alistair Cockburn, Desarrollo Ágil de Software, Addison-Wesley, 2001.
[Cockburn, casos de uso] Alistair Cockburn, Escribiendo uso efectivo casos, Addison-Wesley, 2001.
[Constantino y Lockwood] Larry Constantine y Lucy Lockwood, Software para su uso, Addison-Wesley, 2000.
[Cook y Daniels] Steve Cook y John Daniels, El diseño de sistemas de objetos: Modelado orientado a objetos, con Syntropy, Prentice-Hall,
1994.
[Patrones Core J2EE] Deepak Alur, John Crupi, y Dan Malks, Patrones J2EE núcleo, Prentice Hall,
2001.
[Cunningham] Ward Cunningham, "episodios: Un lenguaje de patrones de Desarrollo Competitivo". En Lenguajes de Patrones de Diseño del
Programa 2, Vlissides, Coplien, y Kerth, Addison-Wesley, 1996, pp. 371-388.
[Douglass] Bruce Powel Douglass, Real-Time UML, Addison-Wesley, 1999.
[Fowler, AP] Martin Fowler, Patrones de análisis: Modelos de objetos, reutilizable Addison-Wesley, 1997.
[Fowler, nueva metodología] Martin Fowler, "la nueva metodología"

http://martinfowler.com/articles/newMethodology.html
[Fowler y Foemmel] Martin Fowler y Matthew Foemmel, "integración continua"

http://martinfowler.com/articles/continuousIntegration.html
[Fowler, P de EAA] Martin Fowler, Los patrones de arquitectura de aplicación empresarial, Addison-Wesley,
2003.
[Fowler, refactorización] Martin Fowler, Refactoring: la mejora del diseño de los programas existentes,
Addison-Wesley, 1999.
116/118
[Pandilla de cuatro] Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides, Patrones de diseño: Elementos de software reutilizables
orientada a objetos, Addison-Wesley, 1995.
[Highsmith] Jim Highsmith, Agile Software ecosistemas de desarrollo, Addison-Wesley, 2002.
[Hohmann] Luke Hohmann, Más allá de Arquitectura de Software, Addison-Wesley, 2003.
[Jacobson, OOSE] Ivar Jacobson, Magnus Christerson, Patrik Jonsson, y Gunnar Övergaard,
Object-Oriented Software Engineering: un enfoque de casos de uso Driven, Addison-Wesley, 1992.
[Jacobson, UP] Ivar Jacobson, María Ericsson, y Agneta Jacobson, La ventaja del objeto: Reingeniería de procesos con tecnología de
objetos, Addison-Wesley, 1995.
[Kerth] Norm Kerth, Retrospectivas de proyectos, Dorset House, 2001
[Kleppe et al.] Anneke Kleppe, Jos más cálido, y Wim Bast, Explicación MDA, Addison-Wesley, 2003.
[Kruchten] Philippe Kruchten, El Proceso Unificado de Desarrollo: Una introducción, Addison-Wesley,

1999.
[Larman] Craig Larman, La aplicación de UML y Patrones, 2d ed., Prentice-Hall, 2001.
[Martín] Robert Cecil Martin, Los principios, patrones y prácticas de desarrollo ágil de software,
Prentice-Hall, 2003.
[McConnell] Steve McConnell, Desarrollo rápido: Horarios fierecilla salvaje de software, Microsoft Press, 1996.
[Mellor y Balcer] Steve Mellor y Marc Balcer, Ejecutable UML, Addison-Wesley, 2002.
[Meyer] Bertrand Meyer, Orientada a objetos de software de construcción. Prentice-Hall, 2000.
[Odell] James Martin y James J. Odell, Los métodos orientados a objetos: una fundación (UML), Edición
Prentice Hall, 1998.
[Pont] Michael Pont, Patrones para sistemas embebidos Triggered-Time, Addison-Wesley, 2001.
[POSA1] Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, y Michael Stal,
Patrón-Oriented Software Architecture: un sistema de modelos, Wiley, 1996.
[POSA2] Douglas Schmidt, Michael Stal, Hans Rohnert, y Frank Buschmann, Patrón-Oriented Software Archtecture Volumen 2: Patrones de
concurrentes y en red, objetos, Wiley, 2000.
[Rumbaugh, ideas] James Rumbaugh, OMT Insights, SIGS Books, 1996.
[Rumbaugh, OMT] James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy y William Lorenzen, Orientada a Objetos de
diseño y modelado, Prentice-Hall, 1991.
[Rumbaugh, UML Referencia] James Rumbaugh, Ivar Jacobson y Grady Booch, El Manual de Lenguaje de Modelado Unificado de
referencia, Addison-Wesley, 1999.
[Shlaer y Mellor, datos] Sally Shlaer y Stephen J. Mellor, Orientado a Objetos Análisis de Sistemas: Modelando el mundial en datos, Yourdon
Press, 1989.
[Shlaer y Mellor, estados] Sally Shlaer y Stephen J. Mellor, Ciclos de vida del objeto: Modelando el mundo en los Estados. Yourdon Press,
1991.
117/118
[Más cálido y Kleppe] Jos más cálido y Anneke Kleppe, El lenguaje de restricciones de objetos: modelado preciso con UML, Addison-Wesley,
1998.
[Wirfs-Brock] Rebecca Wirfs-Brock y Alan McKean, Diseño del objeto: Roles y Responsabilidades Colaboraciones. Prentice-Hall, 2003.
118/118

UML Distilled-Spanish Edition

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-Spanish Edition

Cargado por

Copyright:

Formatos disponibles

1/118

F RÓLOGO AL T ERCERA mi DICIÓN ................................................. .................................................. ................................ 4

Grady Booch Ivar

¿Por qué molestarse con el UML?

Los cambios para la Tercera Edición

La tercera edición también tenía un buen grupo de revisores:

Conrad Bock Craig Larman

Andy Carmichael Steve Mellor

Alistair Cockburn Jim Odell

Steve Cook Alan O'Callaghan

luke Hohmann Guus Ramackers

Pavel Hruby Jim Rumbaugh

Jon Kern Tim Seltzer

Maneras de utilizar el UML

Cómo llegamos a la UML

¿Qué es UML legal?

Por dónde empezar con UML

¿Dónde averiguar más

¿Dónde averiguar más

Maneras de utilizar el UML

Modelo Driven Arquitecture y ejecutable UML

Cómo llegamos a la UML

Figura 1.1. Un pequeño trozo de la meta-modelo UML

Figura 1.2. Clasificación de tipos de diagramas UML

Actividad 11 la conducta procesal y paralelo En UML 1

Clase 3, 5 Clase, funciones y relaciones En UML 1

Componente 14 Estructura y conexiones de componentes En UML 1

estructura 13 la descomposición de una clase en tiempo de ejecución Nuevo a UML 2

Despliegue 8 Despliegue de artefactos a los nodos En UML 1

visión general de dieciséis Mezcla de secuencia y diagrama de actividad Nuevo en UML 2

Objeto 6 configuraciones de ejemplo de casos Extraoficialmente en UML 1

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

Secuencia 4 La interacción entre los objetos; énfasis en la secuencia En UML 1

Sincronización 17 La interacción entre los objetos; énfasis en la temporización Nuevo a UML 2

caso de uso 9 Cómo los usuarios interactúan con un sistema de En UML 1

¿Qué es UML legal?

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

Tabla 1.2. Una tabla de decisión

El orden de prioridad Y norte Y norte Y norte

El orden internacional Y Y norte norte norte norte

Cuota $ 150 $ 100 $ 70 $ 50 $ 80 $ 60

Por dónde empezar con UML

Capítulo 2. Proceso de Desarrollo

Los procesos iterativos y cascada

• "Estamos haciendo un análisis de iteración seguido por dos iteraciones de diseño...."

Planificación predictivo y adaptativo

Los procesos ágiles

Proceso racional unificado

Todos los proyectos RUP deben seguir cuatro fases.

1. Comienzo hace una evaluación inicial de un proyecto. Normalmente, en principio, a decidir si

3. Construcción continúa el proceso de construcción, el desarrollo de la funcionalidad suficiente para liberar.

Montaje de un proceso a un proyecto

Montaje del UML en un proceso

Código heredado comprensión

La elección de un Proceso de Desarrollo

¿Dónde averiguar más

Capítulo 3. Diagramas de Clases: Los Fundamentos

Figura 3.1. Un diagrama de clases sencillo

Un ejemplo de esto es:

- name: String [1] = "sin título" {} readOnly

Solo el nombre es necesario.

Figura 3.2. Mostrando propiedades de un pedido como atributos

Figura 3.3. Mostrando propiedades de un pedido como asociaciones