Qu es el UML?

El lenguaje unificado de modelado o UML (Unified Modeling Language) es el sucesor de la oleada de mtodos de anlisis y diseo orientados a objetos (OOA&D) que surgi a finales de la dcada de 1980 y principios de la siguiente. El UML unifica, sobre todo, los mtodos de Booch, Rumbaugh (OMT) y Jacobson, pero su alcance llegar a ser mucho ms amplio. En estos momentos el UML est en pleno proceso de estandarizacin con el OMG (Object Management Group o Grupo de administracin de objetos) y estoy seguro de que se convertir en el lenguaje de modelado estndar del futuro. Decimos, pues, que el UML es un lenguaje de modelado, y no un mtodo. La mayor parte de los mtodos consisten, al menos en principio, en un lenguaje y en un proceso para modelar. El lenguaje de modelado es la notacin (principalmente grfica) de que se valen los mtodos para expresar los diseos. El proceso es la orientacin que nos dan sobre los pasos a seguir para hacer el diseo. Las partes que tratan sobre el proceso en muchos libros de mtodos son ms bien esquemticas. Ms an, considero que la mayora de las personas que dicen estar usando un mtodo estn usando en realidad un lenguaje de modelado, pero rara vez siguen el proceso. As pues, en gran medida el lenguaje de modelado es la parte ms importante del mtodo. Ciertamente, es la clave para la comunicacin. Si usted desea analizar su diseo con alguien, lo que ambos necesitan comprender es el lenguaje de modelado, "no el proceso que usted sigui para lograr tal diseo. Los tres amigos que acabamos de mencionar tambin trabajan en la creacin de un proceso unificado, llamado Objectory. No es necesario utilizar Objectory para usar UML, pues ambos estn claramente separados. En este libro, sin embargo, hablar un poco del proceso, con el fin de situar en contexto las trnicas del lenguaje de modelado. En la exposicin hago uso de los pasos y trminos bsicos de' Objectory, pero cabe aclarar que la obra 110 es una descripcin del proceso de Objectory. Sucede que utilizo muchos procesos diferentes, dependiendo de mi cliente y del tipo de software que est construyendo. Aunque pienso que es valioso tener un lenguaje de modelado estndar, no considero que haya una necesidad comparable de contar con un proceso estndar, si bien sera til cierta armonizacin en el vocabulario. Cmo llegamos hasta aqu En la dcada de 1980, los objetos comenzaron a alejarse de los laboratorios de investigacin y dieron sus primeros pasos hacia el mundo "real". Smalltalk se estabiliz, quedando en una plataforma que la gente poda usar, y naci C++.

Como muchos desarrollos en el software, los objetos estuvieron guiados por los lenguajes de programacin. Muchos se preguntaban cmo se adecuaran los mtodos de diseo a un mundo orientado a objetos. Los mtodos de diseo se haban vuelto muy populares en el desarrollo industrial durante las dcadas de 1970 y 1980. Muchos pensaban que las tcnicas para ayudar al buen anlisis y diseo eran tambin importantes en el desarrollo orientado a objetos. Los libros clave sobre el anlisis orientado a objetos y los mtodos de diseo aparecieron entre 1988 y 1992: Sally Shlaer y Steve Mellor escribieron un par de libros (1989 y 1991) sobre anlisis y diseo; la evolucin del material de estos libros ha dado como resultado su enfoque de diseo recursivo (1997). Peter Coad y Ed Yourdon tambin escribieron libros en los que desarrollaron el enfoque hacia los mtodos ligeros orientados a prototipos de Coad. Vase Coad y Yourdon (1991a y 1991b), Coad y Nicola (1993) y Coad et al. (1995). La comunidad Smalltalk de Portland, Oregon, aport el diseo guiado por la responsabilidad (Responsibity-Driven Design) (Wirfs-Brock el al. 1990) y las tarjetas de clase-responsabilidad colaboracin (Class-Responsibility-Collaboration) (CRe) (Beck y Cunningham 1989). Grady Booch haba trabajado mucho con Rational Software, desarrollando sistemas en Ada. En sus libros se daban varios ejemplos (y las mejores caricaturas del mundo en cuanto a libros de mtodos). Vase Booch (1994 y 1995). Jim Rumbaugh dirigi un equipo en los laboratorios de investigacin de General Electric, cuyo resultado fue un popular libro sobre un mtodo llamado tcnica de modelado de objetos (Object Modeling Technique) (OMT). Vase Rumbaugh el al. (1991) y Rumbaugh (1996). Los libros de Jim Odell, escritos junto con James Martin, se basan en su amplia experiencia en los sistemas de informacin de negocios y de ingeniera de informacin. El resultado fue el libro ms conceptual de todos. Vase Martin y Odell (1994 y 1996). Ivar Jacobson escribi con base en la experiencia adquirida en conmutadores telefnicos para Ericsson e introdujo en el primero de sus libros el concepto de casos de uso (use cases). Vase Jacobson (1994 y 1995).

Cuando me preparaba para viajar a Portland y asistir a la OOPSLA '94, el panorama relativo a los mtodos se vea muy dividido y competido. Cada uno de los autores antes mencionados diriga informalmente un grupo de profesionales que estaban de acuerdo con sus ideas. Todos estos mtodos eran muy similares; sin embargo, tenan entre s gran cantidad de diferencias menores, con frecuencia incmodas. Los mismos conceptos bsicos aparecan con denominaciones muy diferentes, lo cual confunda a mis clientes. En ese entonces, ya se hablaba de estandarizacin, pero nadie pareca dispuesto a hacer algo al respecto. Algunos se oponan por completo a la idea misma de estndares para los mtodos. A otros les atraa la idea pero no tenan la menor intencin de hacer ningn esfuerzo. Un equipo del OMG que dio muestras de querer considerar la estandarizacin solo logr una carta abierta de protesta de parte de los metodlogos ms importantes. Grady Booch intent organizar una reunin informal para abordar el problema, pero tampoco tuvo xito. (Esto me recuerda un conocido chiste: Cul es la diferencia entre un metodlogo y un terrorista? Respuesta: con el terrorista se puede negociar.) Para la comunidad de los mtodos orientados a objetos, la gran noticia en la OOPSLA '94 fue que Jim Rumbaugh haba dejado General Electric para unirse a Grady Booch en Rational Sofhvare, con la intencin de unificar sus mtodos . El ao siguiente estuvo lleno de acontecimientos amenos. Grady y Jim proclamaron que " la guerra de los mtodos ha terminado: la ganamos nosotros", declarando, en esencia, que iban a lograr la estandarizacin a la manera de Microsoft. Otro grupo de metodlogos sugiri la idea de formar una coalicin en contra de Booch. Para la OOPSLA '95, Grady y Jim haban preparado la primera descripcin pblica de su mtodo integrado: la versin 0.8 de la documentacin del Mtodo Unificado (Ullifted Method). De mayor importancia todava, anunciaron que Rational Software haba comprado Objectory y que Ivar Jacohson se unira al equipo unificado. Con una concurrida fiesta, Rational celebr el lanzamiento del documento preliminar de 0.8; esta fiesta, adems, fue muy divertida, a pesar de las canciones de Jim Rumbaugh. Durante 1996, Grady, Jim e Ivar, ahora ampliamente conocidos como los tres amigos, construyeron su mtodo y le pusieron otro nombre: Unified Modeling Language (UML), lenguaje unificado de modelado. Sin embargo, los dems actores importantes de la comunidad de mtodos orientados a objetos no estaban dispuestos a permitir que el UML fuera la ltima palabra. Se cre una fuerza de trabajo en el OMG para llevar a cabo la estandarizacin en el rea de los mtodos. Ello

representaba un intento mucho ms serio que los anteriores por resolver los problemas en esa rea de los mtodos. Como directora del proyecto fue designada Mary Loomis; ms tarde, Jim Odell se uni como codirector y asumi el liderazgo del proyecto. Odell dej muy claro que estaba dispuesto a renunciar a su mtodo por un estndar, pero no quera que Rational impusiera el suyo. En enero de 1997, varias organizaciones entregaron sus propuestas de estandarizacin de mtodos, con el fin de simplificar el intercambio de modelos. Estas propuestas se enfocan en un metamodelo y en una notacin opcional. Corno su propuesta al OMG, la Rational liber la versin 1.0 de la documentacin del UML. Mientras escribo estas lneas, Jim Odell y el grupo OMG han dedicado mucho tiempo a la elaboracin de la semntica del UML y a la armonizacin de las diversas propuestas. Ahora tenemos una propuesta nica del UML 1.1, que cuenta con amplio apoyo de la industria. Notaciones y metamodelos En su condicin actual, el UML define una notacin y un metamodelo. La notacin es el material grfico que se ve en los modelos; es la sintaxis del lenguaje de modelado. Por ejemplo, la denominacin de un diagrama de clases define cmo se representan conceptos y temas como clase, asociacin y multiplicidad. Por supuesto, esto nos lleva a la pregunta de qu significan exactamente asociacin, multiplicidad e, incluso, clase. Por el uso comn se infieren algunas definiciones informales, pero es mucha la gente que exige definiciones ms rigurosas. En el campo de los mtodos formales prevalece la idea de contar con lenguajes de especificacin y diseo rigurosos. En tales tcnicas, los diseos y las especificaciones se representan usando alguna derivacin del clculo de predicados. Tales definiciones son matemticamente rigurosas y no permiten la ambigedad. Sin embargo, el valor de dichas definiciones no es de ninguna manera universal. Incluso, cuando se puede probar que un programa satisface una especificacin matemtica, no hay manera de probar que esa especificacin matemtica se adecue en la prctica a los requisitos reales del sistema. Lo fundamental en el diseo es ver los temas clave para el desarrollo. Los mtodos formales se pierden con frecuencia en infinidad de detalles menores. Igualmente, los mtodos formales son difciles de comprender y manejar, a veces, incluso, ms que los lenguajes de programacin por si fuera poco, ni siquiera son ejecutables. La mayora de los mtodos orientados a objetos (mtodos OO) tienen escaso rigor; su notacin es ms

intuitiva que formal. En general, esto no parece haber causado muchos daos. Estos mtodos pueden ser informales, pero mucha gente sigue encontrndolos tiles y es su utilidad la que cuenta. Sin embargo, los que trabajan con los mtodos OO buscan cmo hacerlos ms rigurosos sin sacrificar su utilidad. Un modo de lograrlo es mediante la definicin de un metamodelo: un diagrama, usualmente un diagrama de clases, que defina la notacin. La figura 1-1 es una pequea parte del metamodelo 1.1 del UML que muestra la relacin entre asociaciones y generalizaciones. (Incluyo este extracto slo para dar una idea de cmo son los metamodelos, pues ni siquiera voy a tratar de explicarlo.)

interpretacin que hace la herramienta CASE del lenguaje de modelado. Por otra parte, si se vale de los diagramas Con fines de comunicacin, tendr un poco ms de libertad. Si usted se desva de la notacin oficial, los dems usuarios no comprendern del todo lo que est diciendo. Sin embargo, hay momentos en que la notacin oficial le puede estorbar. Admito que en es tos casos no dudo ni un momento en adecuar el lenguaje a mis necesidades. Creo que el lenguaje debe ser flexible para ayudar a comunicarme, y no al contrario. Pero esto no sucede con frecuencia y siempre estoy consciente de que esta desviacin es algo malo, si provoca problemas de comunicacin. En este libro mencionar los puntos en los cuales estoy dispuesto a flexibilizar un poco el lenguaje. Por qu analizar y disear? En resumidas cuentas, la cuestin fundamental del desarrollo del software es la escritura del cdigo. Despus de todo, los diagramas son slo imgenes bonitas. Ningn usuario va a agradecer la belleza de los dibujos; lo que el usuario quiere es software que funcione.

Propiedad

Propiedad Estructural

Propiedad de comportamiento
0.1

E
Ordenad o!

Parmetro

Por lo tanto, cuando est considerando usar el UML, es importante preguntarse por qu lo har y cmo le ayudar a usted cuando llegue el momento de escribir el cdigo. No existe una evidencia emprica adecuada que demuestre si estas tcnicos son buenas o malas, pero en las siguientes subsecciones analizar las razones que con frecuencia encuentro para justificar su uso. Aprendizaje de OO Mucho se habla de la curva de aprendizaje asociada a la OO, el infame cambio de paradigmas. De algn modo, cambiar a OO es fcil. En otros sentidos, hay cierto nmero de obstculos cuando se trabaja con objetos, particularmente si se quieren usar en la forma ms ventajosa. No es que sea difcil aprender a programar en un lenguaje OO. El problema es que es necesario cierto tiempo para aprender a aprovechar las ventajas que contiene el lenguaje orientado a objetos. Como lo expresa muy bien Tom Hadfield: los lenguajes de objetos permiten ventajas pero no las proporcionan. Para aprovechar estas ventajas hay que realizar el infame cambio de paradigma. (Slo asegrese de estar sentado al momento de hacerlo!) Las tcnicas en el UML fueron diseadas en cierta medida para ayudar a los usuarios a hacer un buen desarrollo de OO, pero cada tcnica tiene distintas ventajas a las de las dems. Una de las tcnicas ms valiosas para aprender OO es la de las tarjetas CRC (vase la pgina 74), que no son parte del UML oficial (aunque pueden y deben ser usadas con l). Originalmente, las tarjetas CRC fueron diseadas para ensear a

Figura 1-1: Extracto del metamodelo del UML 1.1

Cunto afecta el metamodeIo al usuario de la notacin para modelar? Pues bien, ciertamente, ayuda a definir qu es un modelo bien formado es decir, uno que sintcticamente est correcto. Como tal. el usuario dedicado a los mtodos deber~ entender el metamodelo. Sin embargo, la mayora de los usuarios de los mtodos no necesita un conocimiento tan profundo para obtener algunos beneficios de la notacin del UML. He aqu el porqu pude escribir un libro til antes de que el metarnodelo del UML estuviese totalmente definido. Los cambios en el metamodelo entre la versin 1.0 y la 1.1 no provocaron ningn cambio de importancia en el contenido de la obra. Por otra parte, en este libro no ser riguroso, sino que seguir la ruta tradicional de los mtodos y apelar a la. Intuicin del lector. Qu tan estrictamente debe usted acatar el lenguaje de modelado? Depende del propsito para el que se usa. Si tiene una herramienta CASE que genera cdigo, entonces, para lograr un cdigo aceptable usted deber apegarse a la

trabajar con objetos. Como tales, deliberadamente son diferentes de las tcnicas de diseo tradicionales. Su nfasis en las responsabilidades y la ausencia de notacin compleja las hace particularmente valiosas. Los diagramas de interaccin (vase el captulo 6) son muy tiles, pues hacen muy explicita la estructura de los mensajes y, en consecuencia, tienen la ventaja de resaltar los diseos demasiado centralizados o sobrecentralizados, en los que un objeto realiza todo el trabajo. Los diagramas de clases (vanse los captulos 4 y 5), usados para ilustrar modelos de clases, son tanto buenos como malos para el aprendizaje de objetos. Los modelos de clases son muy similares a los modelos de datos, por 10 que resultan cmodos; muchos de los principios que hacen que un modelo de datos sea bueno tambin hacen que un modelo de clases sea bueno. El mayor problema en el uso de los diagramas de clases es que es ms fcil desarrollar un modelo de clases que est orientado a datos que desarrollar uno orientado a responsabilidades. El concepto de patrones (vase la pgina 42) es vital para el aprendizaje de la OO, pues el empleo de patrones le hace centrarse en lograr buenos diseos de OO y aprender con base en ejemplos. Una vez logrado el dominio de algunas tcnicas para modelar, tales como los diagramas de clases sencillos y los diagramas de interaccin, ha llegado el momento de comenzar a ver los patrones. Otra tcnica importante es el desarrollo iterativo (vase el captulo 2). Esta tcnica no le ayuda a aprender 00 de manera directa, pero es la clave para explotar de manera eficaz la OO. Si desde el principio el desarrollo se hace de manera iterativa, entonces aprender, en contexto, cul es el tipo de proceso adecuado y comenzar a ver por qu los diseadores sugieren hacer las cosas de la manera en que lo hacen.

realmente el significado de la construccin. Con este fin, busco contemplar cualquier construccin desde tres perspectivas: conceptual, especificacin y realizacin (vase el capitulo 4). Comunicacin con los expertos del dominio Uno de nuestros mayores desafos en el desarrollo es el de construir el sistema adecuado, el que resuelva las necesidades de los usuarios a un costo razonable. Esto se hace an ms difcil porque nosotros, con nuestra jerga, tenemos que comunicarnos con usuarios que tambin tienen su propia jerga, incluso ms crptica. (He trabajado mucho en el sector salud y la jerga que all se usa slo la entienden ellos.) Lograr una buena comunicacin, junto con una comprensin adecuada del mundo del usuario, es la clave para el desarrollo de buen software . La tcnica obvia que debe emplearse en esta situacin es la de los casos de uso (vase el captulo 3). Un caso de uso es una toma instantnea de algn aspecto de su sistema. La suma de todos los casos de uso constituye la vista externa del sistema, que es un gran avance hacia la explicacin de lo que har el sistema. Un buen conjunto de casos de uso es clave para comprender lo que quieren sus usuarios. Los casos de uso tambin ofrecen un buen vehculo para la planificacin de proyectos, ya que controlan el desarrollo iterativo, que es en s mismo una tcnica valiosa, puesto que retroalimenta de manera regular a los usuarios sobre el curso que lleva el software. Adems de que los casos de uso sirven para la comunicacin de los elementos superficiales, tambin resulta crucial para observar las cuestiones ms profundas. Esto implica saber cmo entienden su mundo los expertos del dominio. Los diagramas de clases (vanse los captulos 4 y 5) pueden ser muy valiosos aqu, en la medida en que se usen de modo conceptual. En otras palabras, usted debe tratar cada clase como si fuese un concepto en la mente del usuario, como parte de su lenguaje. Los diagramas de Clases que usted disea no son, por tanto, diagramas de datos o de clases, sino diagramas del lenguaje de sus usuarios. El libro sobre los "fundamentos" de James Martin y Jim Odell (1994) es una buena fuente para este tipo de ideas vinculadas a los diagramas de clases. Me he percatado de que los diagramas de actividades (vase el captulo 9) son muy tiles en aquellos casos en los que los procesos de flujo de trabajo (workflow processes) son una parte importante del mundo de los usuarios. Dado que los diagramas de actividades manejan procesos paralelos, pueden ayudarle a usted a deshacerse de secuencias innecesarias. La forma en que estos diagramas dejan de poner nfasis en los vnculos con las clases, las cuales pueden ser un problema en el diseo

Cuando se empieza a usar una tcnica, se tiende a hacerlo siguiendo el libro al pie de la letra. Mi recomendacin es que vaya usted inicindose con las sencillas notaciones sobre las que he hablado aqu, en particular con los diagramas de clases. En la medida en que se vaya sintiendo seguro, podr seleccionar las ideas ms avanzadas a medida que sean necesarias. Quiz descubra tambin que desea ampliar el mtodo. El UML tiene un mecanismo de extensin que utiliza estereotipos. Hablo de estereotipos slo en el contexto de los diagramas de clases, pero usted puede emplear estereotipos con cualquier diagrama, ampliando su significado. Los libros de los tres amigos entran en ms detalles al respecto. Slo asegrese de comprender

posterior, es una ventaja durante esta etapa ms conceptual del proceso de desarrollo. Comprensin del panorama general Como consultor, con frecuencia debo zambullirme en un proyecto complejo y dar la impresin de ser inteligente en un plazo breve. Para ello, considero que las tcnicas de diseo explicadas antes poseen un valor incalculable, pues me ayudan a adquirir una visin completa del sistema. Una ojeada a un diagrama de clases me puede decir rpidamente qu tipos de abstracciones se hallan presentes en el sistema y en dnde se encuentran las partes cuestionables que necesitan ms trabajo. A medida que profundizo ms, quiero saber como colaboran las clases, de modo que solicito ver diagramas de interaccin que ilustren comportamientos clave en el sistema. Si, corno observador externo, esto me es til, lo ser igualmente para el equipo encargado del proyecto. Es fcil perder de vista el bosque al caminar entre los rboles, cuando se trata de un proyecto grande. Teniendo a la mano unos cuantos diagramas seleccionados, es ms fcil solucionar la cuestin del software. Para construir un mapa del camino, utilice diagramas de paquetes (vase el captulo 7) en los niveles ms altos; con ellos se tendr el alcance de los diagramas de clases. Cuando se dibuja un diagrama de clases destinado a un mapa del camino, hay que centrarse en las especificaciones. Es muy importante ocultar las implementaciones en este tipo de trabajo. No documente interaccin por interaccin; en cambio, cntrese en las que son clave. Utilice patrones (vase la pgina 42) para describir las ideas clave. En el sistema; le ayudarn a explicarle por qu el diseo es corno es. Tambin es til describir los diseos que usted haya rechazado y por qu los ha rechazado. Yo siempre termino olvidando este tipo de decisiones. Para mayor informacin Este libro no es una referencia completa ni definitiva sobre el UML, por no hablar de anlisis y diseo orientado a objetos (OO). Se ha dicho mucho y hay mucho, todava, por leer. Conforme vaya explicando los temas particulares, me referir a otros libros que debe usted consultar para lograr mayor informacin con respecto a las ideas del UML y del OOA&D, en general. Por supuesto, el primer paso ms all de este libro debe ser con los libros sobre el UML de los tres amigos. Mientras escribo estas lneas, cada uno de ellos prepara su libro. Grady Booch encabeza el trabajo sobre la gua del usuario. Ser un libro tutorial que contendr una serie de estudios de caso minuciosos sobre la manera de aplicar el

UML a problemas prcticos. Ser ms detallado que ste que tiene usted en sus manos y contendr ms consejos sobre la manera de emplear bien el UML. Jirn Rumbaugh est dirigiendo la redaccin del libro de referencia, la gua definitiva de la notacin y el metamodelo del UML. Ser la fuente autorizada de informacin sobre el significado del lenguaje UML. Ivar Jacobson est trabajando en un libro que describir el proceso de utilizacin del UML. El UML es, estrictamente hablando, un lenguaje de modelado y no contiene nada sobre el proceso de desarrollo del software. Por ello, los tres amigos utilizan el trmino "lenguaje de modelado" y no la palabra "mtodo", ya que, de hecho, un mtodo debe incluir un proceso. En el libro he bosquejado un proceso ligero para darle cierto contexto a las tcnicas y a las notaciones. El libro de Jacobson entrar en mayores detalles. Ciertamente, los libros de los tres amigos no son los nicos que debera usted leer para enterarse de lo referente al anlisis y diseo orientados a objetos (QOA&D). Mi lista de libros recomendables suele cambiar con frecuencia; le recomiendo consultar la versin ms actualizada en la pgina Survey of AnaIysis and Design Methods de mi sitio en Web, cuya direccin es <ourworld.compuserve.com/homepages/Martin_Fowler:> (mi pgina base de Web). Para mayor informacin De manera especial, sugiero leer libros sobre patrones, donde usted encontrar temas que lo llevarn ms all de los conceptos bsicos. Ahora que la guerra de los mtodos ha terminado, considero que ser en los patrones donde se hallar el material ms interesante sobre anlisis y diseo. Sin embargo, es inevitable que surjan nuevas tcnicas de anlisis y diseo, y es muy probable que quienes las propongan sugieran la manera de emplearlas con el UML. sta es otra de las ventajas del UML: promueve el desarrollo de nuevas tcnicas sin duplicar ya el trabajo efectuado.