Introduccin a UML

Modelado
Una empresa de software con xito es aquella que produce de una manera consistente software de calidad que satisface las necesidades de los usuarios. Una empresa que puede desarrollar este software de forma predecible y puntual con un uso eficiente y efectivo de recursos, tanto humanos como materiales, tiene un negocio sostenible. El modelado es una tcnica utilizada en todas las ingenieras. Como tal la ingeniera software debe basarse en el modelado como una parte central de todas las actividades que conducen a la produccin de software de calidad. Podemos definir el proceso software como ``El conjunto de actividades del desarrollo software y las relaciones entre ellas''. Estas actividades varan segn la organizacin y el tipo de sistema, pero en general la gestin del proceso software exige el disponer de un modelo. Construimos modelos para comunicar la arquitectura y el comportamiento deseado en nuestro sistema. Construimos modelos para visualizar y controlar la arquitectura del sistema y para comprender mejor el sistema que estamos construyendo, muchas veces descubriendo posibilidades de simplificacin y reutilizacin. En general, se puede decir que construimos modelos para controlar el riesgo:

Los modelos nos ayudan a visualizar cmo es o qu queremos que sea un sistema. Los modelos nos permiten especificar la estructura o el comportamiento de un sistema. Los modelos nos proporcionan plantillas que nos guan en la construccin de un sistema. Lo modelos documentan las decisiones que hemos adoptado.

Un modelo es bsicamente una abstraccin que incluye lo esencial de un problema complejo o estructura, filtrando los detalles no esenciales, de forma que el problema se hace ms comprensible. No se trata, por tanto, de una representacin alternativa del sistema. Idealmente, una ``representacin'' de un sistema debera mantener toda la informacin de la entidad que representa; por contra, una abstraccin deliberadamente simplifica, quedndose con las caractersticas ms sobresalientes. Siendo un modelo una simplificacin de la realidad, dicha simplificacin no es nica. Muy al contrario, todo sistema debera ser descrito desde diferentes perspectivas utilizando diferentes modelos y cada uno de estos modelos ser una abstraccin semnticamente cerrada del sistema.

As podemos trabajar en modelos estructurales, destacando la organizacin del sistema, o en modelos de comportamiento, resaltando su dinmica. Un nico modelo no es suficiente. Cualquier sistema no trivial se aborda mejor a travs de un peque no conjunto de modelos ``casi'' independientes. Aunque se pueden crear modelos de distinta naturaleza su eleccin no debe ser arbitraria, sino que tiene una gran influencia posterior en a la hora de acometer la resolucin del problema. Aunque todos los sistemas pueden beneficiarse del uso de modelado, tambin es cierto que cuanto ms grande y complejo sea un sistema mayor es la importancia de la utilizacin de buenas tcnicas de modelado: existe un lmite en la capacidad humana de comprender la complejidad. Por tanto, en un sistema software de magnitud industrial el desarrollar un modelo antes de su construccin o renovacin es esencial para la comunicacin entre equipos de trabajo y para asegurar la solidez de la arquitectura. Para el desarrollo de sistemas software, debemos abstraer diferentes vistas del sistema, construir modelos utilizando notaciones no ambiguas, verificar que los modelos satisfacen los requisitos del sistema, y a nadir de forma gradual detalles que transforman el modelo en una implementacin. En general los modelos nos ayudan a organizar, visualizar, comprender y crear sistemas complejos Una vez aceptada la necesidad de modelar el sistema, en muchas ocasiones dicho modelado se realiza informalmente y ad hoc. La importancia de la realizacin de un modelado formal es que las bases del modelado son comunes lo que conlleva una comunicacin no ambigua entre los individuos que forman parte del proyecto e incluso con los usuarios.

Orientacin a objetos
Segn Sommerville, diferentes clases de modelos del sistema contribuyen de formas diferentes al entendimiento del mismo. No hay un modelo del sistema ideal, ni hay un mtodo ideal para desarrollar tal modelo, de modo que el analista no se debera restringir a los modelos propuestos por un mtodo especfico. En este sentido se encuentra la definicin de UML, ya que nos permite la construccin de diferentes modelos del mismo sistema software. Hasta los aos 70 la estrategia de diseo software ms utilizada se basaba en descomponer el diseo en componentes funcionales con la informacin del sistema almacenada en un rea compartida de datos (diseo funcional). Sin embargo Parnas (1972) sugiri una estrategia alternativa a principios de los 70, el diseo orientado a objetos. Bajo la perspectiva algortmica el bloque principal es el procedimiento, esto conduce a los desarrolladores a centrarse en cuestiones de control y de descomposicin. Aunque no hay nada inherentemente malo en este enfoque se ha comprobado que a medida que los sistemas crecen y cambian su mantenimiento resulta complejo.

En la orientacin a objetos el bloque de construccin es el objeto, donde un objeto es ``algo'' extrado del vocabulario del problema o del vocabulario de la solucin. Todo objeto tiene identidad (puede distinguirse de otros objetos), estado (generalmente hay datos asociados a l) y comportamiento (se le puede hacer ``cosas'' y el puede hacer ``cosas'' a otros objetos). Tomando un enfoque orientado a objetos vemos el sistema como una coleccin de objetos, en vez de como una descripcin de funciones. El diseo orientado a objetos propone una estrategia de diseo basada en la ocultacin de informacin, que ve el sistema software como un conjunto de objetos que interaccionan entre s con su propio estado privado, en vez de un conjunto de funciones que comparten un estado global. Es ampliamente aceptado que los diseos y desarrollos orientados a objetos son ms fciles de mantener ya que los objetos se pueden entender y modificar como entidades autnomas. As, el cambiar la implementacin de un objeto aadiendo servicios no debera afectar a otros objetos del sistema. Adems, con frecuencia existe una correspondencia clara entre las entidades del mundo real y los objetos que las controlan en el sistema, lo que mejora el entendimiento y por tanto el mantenimiento del diseo. Los objetos son componentes reusables porque son encapsulaciones independientes del estado y de las operaciones. Basndonos en esta reutilizacin, los diseos se pueden desarrollar utilizando objetos que han sido creados en diseos anteriores. sto reduce los costes del diseo, de la programacin y de la validacin, adems de reducir el riesgo que conlleva el desarrollo software. Actualmente la orientacin a objetos es el enfoque preponderante ya que se ha mostrado vlido en la construccin de sistemas en toda clase de dominios, abarcando todo el abanico de tamaos y complejidades. Adems incorpora un beneficio clave mediante su capacidad de expansin funcional, extendiendo los objetos existentes y aadiendo nuevos objetos propiciando una mayor rapidez de desarrollo, mantenimiento ms sencillo, gran escalabilidad y software reusable. Mas an, la mayora de los lenguajes actuales, sistemas operativos y herramientas son OO de alguna manera, lo que todava ofrece ms motivos para pensar en trminos de objetos. Hoy en da el desarrollo orientado a objetos proporciona la base fundamental para ensamblar sistemas a partir de componentes utilizando tecnologas como JabaBeans o COM+. Visualizar, especificar construir y documentar sistemas OO es exactamente el propsito de UML

Notacin, Herramienta y Proceso

Se suele utilizar el tringulo del xito de un proyecto software (figura 1.1) para explicar los componentes necesarios en todo proyecto. En cualquier caso se necesitan los tres vrtices: una notacin, un proceso, y una herramienta. Podemos disponer de una notacin pero si no sabemos cmo utilizarla (proceso), no nos servir de mucho. Por otro lado podemos tener un gran proceso, pero si no podemos comunicarlo (notacin), la situacin ser en cualquier caso deficiente. Por ltimo, si no podemos documentar los elementos de nuestro proyecto el xito no ser completo.

En resumen, debemos utilizar los tres componentes conjuntamente para especificar, visualizar, documentar y crear de forma incremental e iterativa una solucin software al problema.

Figura: Tringulo de un proyecto software

Hoy en da el diseador software que intenta representar el diseo de un sistema software puede elegir entre una gran variedad de notaciones, cada una generalmente integrada en una metodologa de anlisis y diseo especfica. Precisamente esta gran variedad de eleccin es el principal impedimento para poder hacer uso de los significativos beneficios de la reutilizacin. La llegada de UML (Unified Modeling Language), con un amplio respaldo de las compaas lderes en la industria del software, representa uno de los desarrollos ms importantes dentro de la metodologa orientada a objetos, aportando un lenguaje de modelado universal que puede ser utilizado con cualquier mtodo. Por tanto en nuestro proyecto software utilizaremos UML (seccin 1.3) como lenguaje de notacin, Rose 98 (Rational) o SoftModeler (Softera) como herramienta y como proceso software cualquiera que siga las lneas descritas en la seccin 8.1.

Historia del UML

La notacin UML se deriva y unifica las tres metodologas de anlisis y diseo OO ms extendidas:

Metodologa de Grady Booch para la descripcin de conjuntos de objetos y sus relaciones. Tcnica de modelado orientada a objetos de James Rumbaugh (OMT: Object-Modeling Technique). Aproximacin de Ivar Jacobson (OOSE: Object- Oriented Software Engineering) mediante la metodologa de casos de uso (use case).

El desarrollo de UML comenz a finales de 1994 cuando Grady Booch y Jim Rumbaugh de Rational Software Corporation empezaron a unificar sus mtodos. A finales de 1995, Ivar Jacobson y su compaa Objectory se incorporaron a Rational en su unificacin, aportando el mtodo OOSE. De las tres metodologas de partida, las de Booch y Rumbaugh pueden ser descritas como centradas en objetos, ya que sus aproximaciones se enfocan hacia el modelado de los objetos que componen el sistema, su relacin y colaboracin. Por otro lado, la metodologa de Jacobson es ms centrada a usuario, ya que todo en su mtodo se deriva de los escenarios de uso. UML se ha ido fomentando y aceptando como estndar desde el OMG (seccin 1.2.2), que es tambin el origen de CORBA, el estndar lder en la industria para la programacin de objetos distribuidos. En 1997 UML 1.1 fue aprobada por la OMG convirtindose en la notacin estndar de facto para el anlisis y el diseo orientado a objetos. UML es el primer mtodo en publicar un meta-modelo en su propia notacin, incluyendo la notacin para la mayora de la informacin de requisitos, anlisis y diseo. Se trata pues de un meta-modelo auto-referencial (cualquier lenguaje de modelado de propsito general debera ser capaz de modelarse a s mismo).

Objetivos
Durante el desarrollo del UML sus autores tuvieron en cuenta:

Proporcionar una notacin y semnticas suficientes para poder alcanzar una gran cantidad de aspectos del modelado contemporneo de una forma directa y econmica.

Proporcionar las semnticas suficientes para alcanzar aspectos del modelado que son de esperar en un futuro, como por ejemplo aspectos relacionados con la tecnologa de componentes, el cmputo distribuido, etc. Proporcionar mecanismos de extensin de forma que proyectos concretos puedan extender el meta-modelo a un coste bajo. Proporcionar mecanismos de extensin de forma que aproximaciones de modelado futuras podran desarrollarse encima del UML. Permitir el intercambio de modelos entre una gran variedad de herramientas. Proporcionar semnticas suficientes para especificar las interfaces a bibliotecas para la comparticin y el almacenamiento de componentes del modelo.

Mediante el fomento del uso de UML OMG pretende alcanzar los siguientes objetivos:

Proporcionar a los usuarios un lenguaje de modelado visual expresivo y utilizable para el desarrollo e intercambio de modelos significativos. Proporcionar mecanismos de extensin y especializacin. Ser independiente del proceso de desarrollo y de los lenguajes de programacin. Proporcionar una base formal para entender el lenguaje de modelado. Fomentar el crecimiento del mercado de las herramientas OO. Soportar conceptos de desarrollo de alto nivel como pueden ser colaboraciones, frameworks, patterns, y componentes. Integrar las mejores prcticas utilizadas hasta el momento.

El UML debe entenderse como un estndar para modelado y no como un estndar de proceso software. Aunque UML debe ser aplicado en el contexto de un proceso, la experiencia ha mostrado que organizaciones diferentes y dominios del problema diferentes requieren diferentes procesos. Por ello se han centrado los esfuerzos en un meta-modelo comn (que unifica las semnticas) y una notacin comn que proporcione una representacin de esas semnticas. De todas formas, los autores de UML fomentan un proceso guiado por casos de uso, centrado en la arquitectura, iterativo e incremental 8.1. Bajo estas lneas genricas proponen el proceso software definido en una de las extensiones del UML (Objectory Extension for Software Enginnering), pero en general el proceso software es fuertemente dependiente de la organizacin y del dominio de aplicacin. Por ltimo mencionar que aunque UML abarca todas las tcnicas existentes, es de esperar que aparezcan nuevas tcnicas. El UML se puede adaptar a estas nuevas tcnicas ya que dispone de mecanismos de extensin que no necesitan redefinir el ncleo UML. NOTA: Se consideran fuera del mbito de UML tanto los lenguajes de programacin, como las herramientas, como el proceso software.

OMG
El OMG (Object Management Group) se form en 1989 con el propsito de crear una arquitectura estndar para objetos distribuidos en redes (componentes). En Octubre de 1989 empez a funcionar como una corporacin independiente y sin nimo de lucro. El compromiso asumido por el OMG busca el desarrollo de especificaciones para la industria del software que sean tcnicamente ``excelentes'', comercialmente viables e independientes del vendedor. Hoy en da el consorcio incluye unos 800 miembros (compaas en la industria del software). La primera arquitectura resultante de esta colaboracin fue CORBA ( Common Objet Request Broker Arquitecture). El elemento central de esta arquitectura es el ORB (Object Request Broker). Un ORB permite que un objeto cliente haga una peticin a un servidor sin conocer la interfaz ni la localizacin del objeto servidor. OMG define object management como el desarrollo software que modela el mundo real mediante su representacin como objetos. Estos objetos no son ms que la encapsulacin de atributos, relaciones y mtodos de componentes software identificables.

Estado actual del UML

UML es un lenguaje para especificar, visualizar, construir y documentar los ``artefactos'' software (desde las fases iniciales hasta la implementacin del sistema), as como el modelado de flujo de trabajo y otros sistemas no software. La definicin del UML se basa en los siguientes documentos:

UML Semantics: Define la semntica y sintaxis del UML. Para ello utiliza tres visiones consistentes:
o

Abstract syntax: Para presentar el meta-modelo UML, sus conceptos (metaclases), relaciones, y restricciones se utilizan diagramas de clases. Well-formedness rules: Definen las reglas y restricciones que rigen en los modelos vlidos. Las reglas se expresan en lenguaje natural y en OCL (Object Constraint Language). OCL es un lenguaje de especificacin que utiliza lgica para especificar propiedades invariantes de sistemas que se componen de conjuntos y relaciones entre conjuntos. Semantics: Las semnticas de manejo del modelo se describen en lenguaje natural.

Estas tres visiones constituyen la definicin del UML. Se han creado bajo la idea de que una definicin ms formal conllevara expresiones matemticas que poca gente podra entender de una forma directa.

NOTA: Un meta-modelo es un lenguaje para la especificacin de un modelo, el modelo propsito. Es decir, es un modelo para elementos de modelado. El propsito del metamodelo UML es el proporcionar una declaracin comn y nica de la sintaxis y semnticas de los elementos del UML. La presencia de dicho meta-modelo ha hecho posible que los desarrolladores se hallan puesto de acuerdo en las semnticas, adems de permitir explorar formas de simplificar el lenguaje de modelado unificando los elementos del UML.

UML Notation Guide: Define la notacin y proporciona ejemplos. La notacin ser la sintaxis grfica para expresar la semntica descrita por el meta-modelo UML. La notacin grfica y la sintaxis textual son las partes ms visibles, siendo utilizadas por personas y herramientas en el modelado de sistemas. Tambin contiene las semnticas UML, sin embargo, sus definiciones se encuentran en UML Semantics. UML Extension for the Objectory Process for Software Engineering y UML Extension for Business Modeling: Extensiones especficas de UML, Objectory Process y Business Engineering. El UML es ampliamente aplicable sin extensiones, de forma que las compaas y proyectos slo deberan definir extensiones cuando es necesario el introducir nueva notacin y terminologa. Para reducir la confusin se definen:

UML Variant: Un lenguaje con una semntica bien definida que se construye encima del meta-modelo UML. Este lenguaje puede ser una especializacin del meta-modelo UML, sin cambios en las semnticas del UML o con redefinicin de algunos de sus elementos. UML Extension: Un conjunto predefinido de estereotipos, valores etiquetados, restricciones e iconos de notacin que colectivamente extienden y adaptan el UML a un dominio o un proceso especfico, por ejemplo, Objectory Process Extension.

Object Constraint Language Specification (OCL): El UML incorpora el lenguaje de restriccin de objetos a fin de superar las deficiencias que poseen los elementos UML para definirse a s mismos. Podra haberse utilizado el lenguaje natural, pero su obvia ambigedad provoc la necesidad de la incorporacin del OCL. Se puede decir que se trata de un lenguaje de expresin, porque se utiliza nicamente para expresar un valor, sin provocar cambios en el modelo; de un lenguaje de modelado, porque no es ejecutable, no es un lenguaje de programacin; y de un lenguaje formal, porque todos sus elementos han sido definidos formalmente. Segn los autores, este lenguaje est destinado a la especificacin de invariantes en clases y tipos de clases en el modelo de clases; para describir pre y post-condiciones en operaciones y mtodos; para describir guardas; para ser empleado como un lenguaje de navegacin; para definir reglas de formacin; y para definir restricciones de operaciones.

En un relativamente corto perodo (4 a nos) de tiempo UML ha emergido como el lenguaje de modelado ms dominante en la industria. Existe actualmente una Revision Task Force (RTF) responsable de la generacin de revisiones menores de la especificacin UML 1.1. La primera RTF de UML termin su revisin en Junio de 1999 con el draft final UML 1.3. Los miembros de las segunda RTF estn trabajando en lo que sera la siguiente revisin (UML 1.4). Adems de esta revisin menor tambin se est trabajando en una revisin mayor en lo que sera el UML 2.0.

OOCASE: Object Oriented CASE

Muchas aplicaciones software modernas se han desarrollado basadas en principios orientados a objetos (clases, mtodos, herencia). Una de las ventajas de la orientacin a objetos es que se presta a la representacin notacional de sus principios. Las herramientas CASE orientadas a objetos proporcionan el soporte para las metodologas y notaciones orientadas a objetos, e incluso permiten generar parte del cdigo de las aplicaciones. Las nuevas versiones de las herramientas CASE orientadas a objetos estn ya incorporando los nuevos lenguajes como Java. Muchas de estas herramientas tambin dan soporte a bases de datos relacionales, permitiendo el modelado y diseo lgico y en algunos casos el fsico, de la base de datos, incluyendo la generacin de esquemas e ingeniera inversa sobre tablas y otros elementos del RDBMS. Las herramientas CASE ofrecen grandes ventajas a los desarrolladores de sistemas software de gran tamao. Mientras una espiral de requisitos del sistema sigue llevando la complejidad del sistema a nuevos niveles, las herramientas CASE nos permiten abstraernos del cdigo fuente, a un nivel donde la arquitectura y el diseo son mas aparentes y fciles de entender y modificar. Se puede decir que cuanto mayor es el proyecto software, ms importante resulta el utilizar tecnologas CASE. Ya que los desarrolladores en este tipo de sistemas interaccionan slo con una o varias partes del sistema diseado por los diseadores, deben encontrar de manera sencilla el subconjunto de clases y mtodos, as como asimilar y entender cuales son las interfaces con ellos. En el mismo sentido el gestor del proyecto debe ser capaz de ver una representacin del diseo a alto nivel y entender como funciona en un tiempo razonable. Por estas razones, las herramientas CASE junto con las metodologas nos proporcionan una forma de representar sistemas demasiado complejos de entender ya sea a partir del cdigo subyacente o de alguna forma basada en esquemas. Para alcanzar el grado de abstraccin necesario las herramientas CASE orientadas a objetos (OOCASE) permiten crear diagramas que representan el modelo de objetos utilizando los elementos notacionales de metodologas especficas como: OMT (Object Modeling Technique), Booch, Jacobson Use Cases , UML (Unified Modeling Language) o Fusion. El soporte notacional es slo una forma de clasificar las herramientas CASE, otras caractersticas a tener en cuenta son: el soporte de varios lenguajes de programacin, el uso de ficheros o bibliotecas para almacenar la informacin del modelo y la integracin con software de control de versiones. Las herramientas OOCASE crean diagramas que representan el modelo de objetos utilizando los elementos notacionales de las diferentes metodologas. Estas notaciones representan grficamente clases (incluyendo atributos, mtodos y eventos), relaciones entre objetos (herencia, agregacin, colaboracin), y cardinalidad. Adems la mayora, aunque no todas, las herramientas OOCASE ofrecen la posibilidad de generar un esqueleto del cdigo de la aplicacin. Este esqueleto generalmente incluye la definicin de las clases y los prototipos de las funciones. Analizando la mayor parte de las aplicaciones software nos podemos encontrar con elementos tan dispares como pginas Web, acceso a bases de datos, cdigo C++, cdigo Java, interfaz CORBA de acceso a un servidor C++, etc. Esta disparidad es el reto bsico que tienen que afrontar los vendedores de herramientas CASE que quieran proporcionar un entorno de diseo integrado

Con los a nos va siendo mayor la capacidad de trabajar ms con menos herramientas, lo que supone una mayor integracin y una menor complejidad en las herramientas CASE, lo que nos lleva a una mayor productividad. A la hora de alcanzar una mayor integracin, UML se presenta como una buena alternativa, ya que se basa en un metamodelo extensible. El metamodelo UML es un modelo que describe modelos. Una visin de este modelo nos muestra elementos orientados a objetos como clases, atributos y mtodos, todos ellos y sus interrelaciones representados como metaclases. Al modelo UML se le pueden a nadir ms metaclases, por ejemplo para describir modelos entidad relacin, as como realizar extensiones para tratar con interfaces como las definidas usando CORBA. El estndar UML define notaciones para representar la informacin y su interrelacin desde una perspectiva grfica, adems soporta el uso de un formato de intercambio. El CASE Data Interchange Format (CDIF -www.cdif.org-) es un anexo importante al UML, ya que, aunque UML especifica el tipo y la relacin que existe entre la informacin que ha de ser almacenada en una biblioteca (repository), no especifica cmo se debe guardar esta informacin, dejando la eleccin a los distintos vendedores. El CDIF permite una representacin ASCII para una biblioteca de diseos, dicha representacin puede ser utilizada para transferir los datos del diseo de una herramienta CASE a otra, pudiendo ser utilizada por generadores de informes y otras herramientas de este estilo. Cuando decimos que una herramienta OOCASE ``genera cdigo'', nos estamos refiriendo a cabeceras y prototipos en el caso de C++ o Java, y a informacin de esquema en el caso de bases de datos relacionales. O sea, se proporciona la base para clases, mtodos, y atributos en aplicaciones orientadas a objetos, as como tablas, columnas y relaciones en DBMS relacional. El tener una herramienta CASE que proporcione cdigo de aplicacin y de base de datos ayuda a garantizar que el modelo y su implementacin estn sincronizados. Esta sincronizacin hace que la herramienta de modelado sea ms til para los desarrolladores. Sin un mecanismo integrado para guardar la implementacin y el modelo sincronizados, se produce con frecuencia una desconexin entre ambos. Dicho de otra forma, es frecuente que las mejores soluciones se hagan evidentes en el proceso de implementacin, si estas soluciones, que llevan con frecuencia a modificaciones en el diseo, no son realimentadas hacia atrs en el modelo de una forma conveniente, el modelo puede pasar a estar ``out of date''. El valor intrnseco del modelo se pierde desde el momento en que no podemos confiar en l y por lo tanto deja de usarse. Para soportar la generacin de ficheros de cabecera y prototipos de mtodos, debe haber una forma de asegurar que la herrramienta no sobreescribe el cuerpo de los mtodos y otro cdigo y comentarios introducidos por el desarrollador. La forma ms fcil y frecuente de hacer esto es introducir informacin del modelo dentro del cdigo generado. Esto suele llevar a las protestas de los desarrolladores cuando utilizan por primera vez una herramienta de este tipo. Estas protestas son entendibles, ya que la legibilidad del cdigo fuente se reduce de una forma significativa debido a la informacin introducida por la herramienta CASE en bloques de comentarios. Dos razones reducen la importancia del problema de ``polucin'' del cdigo:

Los desarrolladores estn acostumbrados a ver los comentarios extra y filtrarlos mentalmente. La utilizacin cada vez ms frecuente de entornos de desarrollo integrado cada vez mas sofisticados (ej: Visual Basic de Microsoft). Estos entonos ofrecen browsers para clases y mtodos que hacen la navegacin hacia declaraciones y definiciones especficas muy sencilla, con lo cual los desarrolladores pueden evitar el ``ruido'' introducido en los ficheros de cdigo nativos.

Las herramientas OOCASE necesitan colaborar con otras aplicaciones a lo largo del ciclo de vida del proyecto. Esto es particularmente cierto en el caso del software de control de versiones. Debido a que los modelos estn expuestos a frecuentes cambios durante el anlisis y el diseo, muchos vendedores integran ya este tipo de software. Adems, las herramientas CASE deben trabajar en un entorno multiusuario ya que los proyectos grandes los modelan y construyen equipos de desarrolladores. Las herramientas CASE que almacenan los modelos en ficheros del sistema operativo en vez de utilizar una biblioteca almacn, deben definir unidades de modelo que puedan ser utilizadas de forma concurrente por diferentes diseadores y analistas. Estas unidades adems deben estar bajo el control de algn software de versiones. La granularidad de las unidades de este tipo es un factor importante ya que con frecuencia diferentes partes del modelo estn entrelazadas. Cuando un desarrollador coge una parte del modelo, esa parte debera ser lo suficientemente pequea como para que otros desarrolladores puedan coger otros elementos del modelo y trabajar de una forma independiente. Hay que tener en cuenta que cualquier parte del modelo que es comn a ms de una unidad y a la que se acceda con frecuencia, puede convertirse en un cuello de botella para los procesos de modelado. Las herramientas OOCASE seguirn en el futuro soportando diferentes metodologas. Incluso cuando UML alcance su esperada penetracin en el mercado, aparecern otras metodologas con gran nmero de seguidores, existiendo siempre varias notaciones y metodologas activas. Es por eso, que ser importante que las herramientas CASE que ahora almacenan la informacin del modelo en ficheros evolucionen hacia almacenes a los que puedan acceder diferentes herramientas. Esto har ms fcil el intercambio de informacin entre herramientas que realizan clases especficas de modelado. De todas formas es tambin deseable que se reduzca el nmero de herramientas CASE necesarias para modelar una aplicacin. El nmero de herramientas CASE que soportan UML ha crecido muy considerablemente estos ltimo a nos, en http://www.cetus.com encontramos una lista regularmente actualizada de dichas herramientas.

Modelo conceptual

El modelo conceptual del lenguaje UML contiene tres elementos principales: los bloques bsicos de construccin, las reglas de combinacin de los bloques bsicos y algunos mecanismos comunes.

Bloques de construccin
Los bloques de construccin son de tres clases: elementos, relaciones y diagramas. Los elementos son abstracciones en el modelo, las relaciones ligan estos elementos entre s y los diagramas agrupan colecciones interesantes de elementos y relaciones. Los elementos UML se pueden clasificar en estructurales, de comportamiento, de agrupacin y de anotacin. Las relaciones a su vez sern de dependencia, asociacin, generalizacin y realizacin.

Elementos estructurales

Clase: es una descripcin de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semntica. Una clase implementa una o ms interfaces.

Figura: Representacin de una clase

Interfaz: es una coleccin de operaciones que especifican un servicio de una clase o componente. Por lo tanto, una interfaz describe el comportamiento visible externamente

de ese elemento. Una interfaz puede representar el comportamiento completo de una clase o componente o slo una parte de este comportamiento. Una interfaz define un conjunto de especificaciones de operaciones (o sea, sus signaturas), pero nunca sus implementaciones. Una interfaz raramente se encuentra asilada, ms bien, suele estar conectada a la clase o componente que la realiza.

Figura: Representacin de una interfaz

Colaboracin: define una interaccin y es una sociedad de roles y otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de los comportamientos de sus elementos. Por lo tanto las colaboraciones tienen dimensin tanto estructural como de comportamiento. Una clase dada puede participar en varias colaboraciones.

Figura: Representacin de una colaboracin

Caso de uso: Es una descripcin de un conjunto de secuencias de acciones que un sistema ejecuta y que produce un resultado observable de inters para un actor particular. Un caso de uso se utiliza para estructurar los aspectos de comportamiento en un modelo. Un caso de uso es realizado por una colaboracin.

Figura: Representacin de un caso de uso

Existen otros tres elementos estructurales que son similares a las clases: clase activa, componente, y nodo. Una clase activa es una clase cuyos objetos tienen uno o ms procesos o hilos que constituyen flujos de control independientes pero concurrentes con otros flujos de control (con los que muy probablemente se debern sincronizar). Una clase activa es igual que una clase, excepto en que sus objetos representan elementos cuyo comportamiento es concurrente con otros elementos.

Figura: Representacin de una clase activa

A diferencia de los anteriores, elementos conceptuales o lgicos, los nodos y componentes representan elementos fsicos. Un componente es una parte fsica de un sistema que ofrece un conjunto de interfaces y proporciona la implementacin de dicho conjunto. En un sistema, se pueden encontrar diferentes tipos de componentes de despliegue, tales como componentes COM+, JavBeans, as como componentes que sean artefactos del proceso de desarrollo, tales como archivos de cdigo fuente. Un componente representa tpicamente el empaquetamiento fsico de diferentes elementos lgico, como clases interfaces y colaboraciones.

Figura: Representacin de un componente

Un nodo es un elemento fsico que existe en tiempo de ejecucin, representando un recurso computacional que, por lo general, dispone de algo de memoria y con frecuencia capacidad de procesamiento. Un conjunto de componentes puede residir en un nodo y puede tambin migrar de un nodo a otro.

Figura: Representacin de un nodo

Aunque los anteriores son los siete elementos estructurales bsicos existen variaciones a partir de ellos, por ejemplo los actores y seales (tipos de clases), procesos e hilos (tipos de clases activas) y aplicaciones, documentos, archivos, bibliotecas, pginas y tablas (tipos de componentes).

Elementos de comportamiento
Los elementos de comportamiento son las partes dinmicas de los modelos UML:

Interaccin: es un comportamiento que comprende un conjunto de mensajes intercambiados entre un conjunto de objetos, dentro de un contexto particular, para alcanzar un propsito especfico. Una interaccin involucra muchos otros elementos, incluyendo mensajes, secuencias de accin y enlaces.

Figura: Representacin de un mensaje

Mquina de estados: es un comportamiento que especifica la secuencia de estados por las que pasa un objeto o una interaccin durante su vida en respuesta a eventos, junto con sus reacciones a estos eventos. Una mquina de estados involucra a otros elementos, incluyendo estados, transiciones, eventos y actividades.

Figura: Representacin de un estado

Elementos de agrupacin
Son las partes organizativas de los modelos UML. Hay un elemento de agrupacin principal, los paquetes. Un paquete es un mecanismo de propsito general para organizar elementos en grupos. Los elementos estructurales, los elementos de comportamiento, e incluso otros elementos de agrupacin pueden incluirse en un paquete. Al contrario de los componentes (que existen en tiempo de ejecucin), un paquete es puramente conceptual (slo existe en tiempo de desarrollo).

Figura: Representacin de un paquete

Elementos de anotacin
Son las partes explicativas de los modelo UML. Hay un tipo principal llamado Nota. Una nota es simplemente un smbolo para mostrar restricciones y comentarios junto a un elemento o una coleccin de elementos. Las notas se utilizan para adornar los diagramas con restricciones o comentarios que se expresan mejor en texto informal o formal.

Figura: Representacin de una nota

Relaciones en UML

Dependencia: es una relacin semntica entre dos elementos, en la cual un cambio a un elemento (el elemento independiente) puede afectar a la semntica del otro elemento (el dependiente). Las dependencias generalmente representan relaciones de uso que declara que un cambio en la especificacin de un elemento puede afectar a otro elemento que la utiliza, pero no necesariamente a la inversa. Por ejemplo un refinamiento de un elemento de diseo a un elemento de implementacin. La mayora de las veces se utilizan en el contexto de las clases o paquetes, aunque tambin son habituales en la vinculacin de notas.

Figura: Representacin de una dependencia

Asociacin: es una relacin estructural que describe un conjunto de enlaces, los cuales son conexiones entre objetos. La agregacin es un tipo especial de asociacin, que representa una relacin estructural entre un todo y sus partes.

Figura: Representacin de una asociacin

Generalizacin: es un a relacin de especializacin generalizacin en la cual los objetos del elemento especializado (el hijo) pueden sustituir a los objetos del elemento general (el padre). De esta forma el hijo comparte la estructura y el comportamiento del padre.

Figura: Representacin de una generalizacin

Realizacin: es una relacin semntica entre clasificadores, en donde un clasificador especifica un contrato que otro clasificador garantiza que cumplir. Se pueden encontrar relaciones de realizacin: entre interfaces y las clases o componentes que las realizan, y entre los casos de uso y las colaboraciones que los realizan.

Figura: Representacin de una realizacin

La realizacin es lo suficientemente diferente de la dependencia, la generalizacin y la asociacin como para ser tratada como un tipo aparte de relacin. Semnticamente la realizacin es una mezcla entre dependencia y generalizacin.

Diagramas en UML
Un diagrama es la representacin grfica de un conjunto de elementos, visualizando la mayora de las veces como un grafo conexo de nodos (elementos) y arcos (relaciones). Los diagramas se dibujan para visualizar el sistema desde diferentes perspectivas, de forma que un diagrama es una

proyeccin de un sistema. En teora un diagrama puede contener cualquier combinacin de elementos y relaciones, sin embargo en la prctica solo surge un peque no nmero de combinaciones:

Diagrama de clases. Diagrama de objetos. Diagrama de casos de uso. Diagrama de secuencia. Diagrama de colaboracin. Diagrama de estados. Diagrama de actividades. Diagrama de componentes. Diagrama de despliegue.

Reglas de UML
Los bloques de construccin de UML no pueden combinarse de cualquier manera. Como cualquier lenguaje UML tiene unas reglas que especifican a qu debe parecerse un modelo bien formado. Un modelo bien formado es aquel que es semnticamente autoconsistente y est en armona con todos sus modelos relacionados. UML tiene reglas semnticas para:

Nombres: Cmo llamar a los elementos, relaciones y diagramas. Alcance: El contexto que da significado especfico a un nombre. Visibilidad: Cmo se pueden ver y utilizar esos nombres por otros. Integridad: Cmo se relacionan apropiada y consistentemente unos elementos con otros. Ejecucin: Qu significa ejecutar o simular un modelo dinmico.

Los modelos que construidos durante el proceso software de un sistema con gran cantidad de software tienden a evolucionar y pueden ser vistos por diferentes usuarios de formas diferentes y en momentos diferentes. Por esta razn, es comn en el equipo de desarrollo no slo construir modelos bien formados, sino tambin construir modelos que sean:

Abreviados: Ciertos elementos se ocultan para simplificar la vista. Incompletos: Pueden estar ausentes ciertos elementos. Inconsistentes: No se garantiza la integridad del modelo.

Estos modelos que no llegan a ser bien formados son inevitables conforme los detalles de un sistema van apareciendo y mezclndose durante el proceso software. Las reglas de UML estimulan (pero no obligan) a considerar las cuestiones ms importantes de anlisis, diseo e implementacin que llevan a tales sistemas a convertirse en bien formados con el paso del tiempo.

Mecanismos Comunes
Existen cuatro mecanismos comunes que se aplican de forma consistente a travs de todo el lenguaje:

Especificaciones: UML no es slo un lenguaje grfico, sino que detrs de cada notacin grfica hay una especificacin que proporciona una explicacin textual de la sintaxis y semntica del bloque de construccin. Por ejemplo, detrs del icono de una clase hay una especificacin que proporciona informacin de sus atributos, operaciones, signaturas y comportamiento de la clase (visualmente el icono de la clase puede mostrar slo parte de la especificacin). La notacin grfica de UML se utiliza para visualizar el sistema, la especificacin se utiliza para enunciar los detalles de dicho sistema. Adornos: La mayora de los elementos UML tienen una nica y clara notacin grfica que proporciona una representacin visual de los aspectos ms importantes del elemento. Pero la especificacin puede incluir otros detalles algunos de los cuales se pueden incluir como adornos grficos en la notacin base. Por ejemplo se pueden incluir adornos en el icono de una clase indicando la visibilidad de la operacin. Divisiones comunes: Al modelar sistemas orientados a objetos, el mundo puede dividirse por lo menos en un par de formas: clase-objeto e interfaz-implementacin. Una clase es una abstraccin, un objeto es una manifestacin concreta de dicha abstraccin. Todos los bloques de construccin de UML (y no solo las clases) presentan esta dicotoma. Por ejemplo se puede tener casos de uso e instancias de casos de uso, componentes e instancias de componentes. Una interfaz declara un contrato, una implementacin representa la realizacin concreta de ese contrato responsable de hacer efectiva de forma fidedigna la semntica completa de la interfaz. Casi todos los bloques de construccin presentan esta otra dicotoma. Por ejemplo, se pueden tener casos de uso y las colaboraciones que los realizan, as como operaciones y los mtodos que las implementan.

Mecanismos de extensibilidad: UML proporciona un lenguaje estndar para escribir planos software, pero no es posible que un lenguaje cerrado sea siempre suficiente para expresar todos los matices posibles de todos los modelos en todos los dominios y en todos los momentos. Por esta razn UML es abierto-cerrado, siendo posible extender el lenguaje de manera controlada. Los mecanismos de extensin incluyen: estereotipos, valores etiquetados y restricciones. (ver seccin 7.1)

Diagramas UML

En funcin de las diferentes vistas del modelo, en UML se definen los siguientes diagramas grficos:

Use Case Diagram (Diagrama de casos de uso) (2) Class Diagram (Diagrama de clases) (3) Diagramas de comportamiento:
o o

Statechart Diagram (Diagrama de estados) (5.1) Activity Diagram (Diagrama de actividades) (5.2) Sequence Diagram (Diagrama de secuencia) (4.2) Collaboration Diagram (Diagrama de colaboracin) (4.3) Component Diagram (Diagrama de componentes) (6.1.1) Deployment Diagram (Diagrama de despliegue) (6.1.2)

Diagramas de interaccin (4.1):

o o

Diagramas de implementacin (6.1):

o o

Estos diagramas proporcionan mltiples perspectivas del sistema bajo anlisis. El modelo subyacente integra estas perspectivas de forma que se puede construir un sistema autoconsistente. Estos diagramas, junto con la documentacin de soporte, es lo primero que ve el diseador. Por otro lado podemos ver el modelo de una forma esttica o de una forma dinmica. Estas perspectivas nos dan la siguiente clasificacin:

Modelo esttico (estructural):

o o o o

Diagrama de despliegue Diagrama de componentes Diagrama de clases Diagrama de objetos Diagrama de estados Diagrama de actividades Diagrama de secuencia Diagrama de colaboracin

Modelo dinmico (comportamiento):

o o o o

Diagrama de casos de uso

Los cuatro diagramas estructurales de UML permiten visualizar, especificar, construir y documentar los aspectos estticos de un sistema:

Un diagrama de clases presenta un conjunto de clases, interfaces y colaboraciones, y las relaciones entre ellas. Un diagrama de objetos representa un conjunto de objetos y sus relaciones. Se utilizan para describir estructuras de datos, instantneas de los elementos encontrados en los diagramas de clases. Cubre los mismos aspectos que los diagramas de clases pero desde una perspectiva de casos reales o prototpicos. Un diagrama de componentes muestra un conjunto de componentes y sus relaciones. Los diagramas de componentes se utilizan para describir la vista de implementacin esttica de un sistema. Los diagramas de componentes se relacionan con los diagramas de clases, ya que un componente normalmente se corresponde con una o ms clases, interfaces o colaboraciones. Un diagrama de despliegue muestra un conjunto de nodos y sus relaciones. Los diagramas de despliegue se utilizan para describir la vista de despliegue esttica de un sistema. Los diagramas de despliegue se relacionan con los diagramas de componentes, ya que un nodo normalmente incluye uno o ms componentes.

Los cinco diagramas de comportamiento de UML se emplean para visualizar, especificar, construir y documentar los aspectos dinmicos de un sistema.

Los diagramas de casos de uso organizan los comportamientos del sistema. Un diagrama de caso de uso representa un conjunto de casos de uso y actores (un tipo especial de clases) y sus relaciones. Diagramas de interaccin: Se da este nombre colectivo a los diagramas de secuencia y los diagramas de colaboracin. Ambos diagramas son isomorfos, es decir, se puede convertir de uno a otro sin prdida de informacin.
o

Un diagrama de secuencia es un diagrama de interaccin que resalta la ordenacin temporal de los mensajes. Un diagrama se secuencia presenta un conjunto de objetos y los mensajes enviados y recibidos por ellos., Los objetos suelen ser instancias con nombre o annimas de clases, pero tambin pueden representarse instancias de otros elementos, tales como colaboraciones, componentes y nodos. Un diagrama de colaboracin es un diagrama de interaccin que resalta la organizacin estructural de los objetos que envan y reciben mensajes. Un diagrama de colaboracin muestra un conjunto de objetos, enlaces entre estos objetos y mensajes enviados y recibidos por estos objetos. Los objetos normalmente son instancias con nombre o annimas de clases, pero tambin pueden representar instancias de otros elementos, como colaboraciones, componentes y nodos.

Un diagrama de estado representa una mquina de estados, constituida por estados, transiciones, eventos y actividades. Son especialmente importantes para modelar el comportamiento de una interfaz, una clase o una colaboracin. Los diagramas de estados

resaltan el comportamiento dirigido por eventos de un objeto, lo que es especialmente til al modelar sistemas reactivos.

Un diagrama de actividades es un tipo especial de diagrama de estados que muestra el flujo secuencial o ramificad de actividades en un sistema. conjunto de actividades, Son especialmente importantes par modelar la funcin del sistema, as como para resaltar el flujo de control entre objetos.

A menudo se pude considerar comenzar por un diagrama de estados para describir la respuesta del sistema ante los eventos externos, y despus convertirlo en un diagrama de actividades que se centre en el flujo de control, tambin se puede pasar de los diagramas de actividades a los diagramas de estados.

Modelado de casos de uso Comportamiento del sistema

Un caso de uso describe, posiblemente en lenguaje natural, una forma en que un ``actor'' del mundo real (persona, organizacin o sistema externo) interacciona con el modelo. En general, y aunque a menudo se utilizan los trminos caso de uso y escenario indistintamente, nos referimos a escenario como un camino dentro de un caso de uso, es decir, un camino que muestra una combinacin especfica de condiciones en un caso de uso. El modelo de casos de uso (use case model) documenta el comportamiento del sistema desde el punto de vista del usuario, permitiendo representar las funciones que se desean en el sistema (use cases), el entorno del sistema (actors), y las relaciones entre ellos. Aunque la parte ms visible de dicho modelo son los diagramas de casos de uso, suele ir acompaado de una especificacin textual de cada uno de los casos de uso.

Actores (actors): Los actores no forman parte del sistema, sino que representan elementos que interactan con l. Un actor puede introducir, recibir, o introducir y recibir informacin desde o hacia el sistema. Casos de uso (Use Cases): Los casos de uso modelan un dilogo entre un actor y el sistema describiendo la funcionalidad que ofrece el sistema al actor. El conjunto de casos de uso del sistema constituyen todas las formas de uso definidas en el sistema.

Las relaciones en un diagrama de casos de uso se pueden clasificar:

Caso de Uso - Actor Es posible que exista una relacin de asociacin entre un actor y un caso de uso. Esta asociacin a la que nos referimos como asociacin ``comunica'' representa una comunicacin entre un actor y un caso de uso. Una asociacin puede ser en general navegable en ambas direcciones (de actor a caso de uso y de caso de uso a actor), o en una sola direccin (de actor a caso de uso o de caso de uso a actor). La direccin en que es navegable la asociacin refleja quin inicia la comunicacin.

Caso de Uso - Caso de Uso Las relaciones puede ser de dos tipos: ``incluye'' (``include'') y ``extiende'' (``extends'').

Los principales objetivos del modelo de casos de uso son: permitir la comunicacin entre los desarrolladores y los clientes o usuarios finales durante la captura de requisitos; planificar las iteraciones necesarias en el proceso software y ser la base para la validacin del sistema.

Diagramas de Casos de Uso

Un diagrama de casos de uso (Use Case Diagram) es una representacin grfica de parte o el total de los actores y casos de uso del sistema, incluyendo sus interacciones. Todo sistema tiene como mnimo un diagrama Main Use Case, que es una representacin grfica del entorno del sistema (actores) y su funcionalidad principal (casos de uso). Un diagrama de casos de uso muestra, por tanto, los distintos requisitos funcionales que se esperan de una aplicacin o sistema y cmo se relaciona con su entorno (usuarios u otras aplicaciones). Se muestra como ejemplo los casos de uso de una mquina de caf (figura 2.2). Un caso de uso, denotando un requisito funcional exigido al sistema, se representa en el diagrama por una elipse y un nombre significativo. En el caso del ejemplo se tienen como casos de uso de la mquina de caf RecibirDinero, PedirAzucar, PedirProducto, DarVueltas y Cancelar.

Figura: Representacin de un actor: stickman

Un actor es una entidad que utiliza alguno de los casos de uso del sistema. Se representa mediante el smbolo de la figura 2.1 acompaado de un nombre significativo, si es necesario. En el ejemplo observamos un nico actor representando al usuario de la mquina de caf, aunque en un modelo de casos de uso ms detallado se podra incluir otro actor para responsable del mantenimiento de la mquina. Un actor en un caso de uso representa un rol que alguien o algo podra desempear y no un alguien o algo especfico.

Figura: Ejemplo de casos de uso de una mquina de caf

Entre los elementos de un diagrama de casos de uso se pueden presentar tres tipos de relaciones, representadas por lneas dirigidas o no entre ellos:

``comunica'' (<<communicates>>): Relacin (asociacin) entre un actor y un caso de uso que denota la participacin del actor en dicho caso de uso. En el diagrama del ejemplo de la figura 2.2 todas las lneas que salen del actor denotan este tipo de asociacin (en realidad estereotipada como <<comunicates>>). ``usa'' ( <<uses>>) (o <<include>> en la nueva versin de UML): Relacin de dependencia entre dos casos de uso que denota la inclusin del comportamiento de un escenario en otro. En el caso del ejemplo el caso de uso Cancelar incluye en su comportamiento al de DarVueltas y PedirProducto incluye tambin DarVueltas. ``extiende'' (<< extends>>): Relacin de dependencia entre dos casos de uso que denota que un caso de uso es una especializacin de otro. Por ejemplo, podra tenerse un caso de uso que extienda la forma de pedir azcar, para que permita escoger el tipo de azcar (normal, diettico o moreno) y adems la cantidad en las unidades adecuadas (cucharadas o bolsas). Un posible diagrama se muestra en la figura 2.3.

Figura: Casos de uso con relacin `` extends''

Se utiliza una relacin de tipo <<extends>> entre casos de uso cuando nos encontramos con un caso de uso similar a otro pero que hace algo ms que ste (variante). Por contra, utilizaremos una relacin tipo << uses>> cuando nos encontramos con una parte de comportamiento similar en dos casos de uso y no queremos repetir la descripcin de dicho comportamiento comn. En una relacin << extends>>, un actor que lleve a cabo el caso de uso base puede realizar o no sus extensiones. Mientras, en una relacin <<include>> el actor que realiza el caso de uso base tambin realiza el caso de uso incluido. En general utilizaremos <<extends>> cuando se presenta una variacin del comportamiento normal, y <<include>> cuando se repite un comportamiento en dos casos de uso y queremos evitar dicha repeticin. Por ltimo en un diagrama de casos de uso, adems de las relaciones entre casos de uso y actor (asociaciones) y las dependencias entre casos de uso (<<include>> y <<extends>>), pueden existir relaciones de herencia ya sea entre casos de uso o entre actores. Llamamos modelo de casos de uso a la combinacin de casos de uso y sus correspondientes diagramas. Los modelos de casos de uso se suelen acompaar por un glosario que describe la terminologa utilizada. El glosario y el modelo de casos de uso son importantes puntos de partida para el desarrollo de los diagramas de clases. Por ltimo se debe tener en cuenta, que aunque cada caso de uso puede llevar a diferentes realizaciones, es importante reflejar en cada representacin el motivo que nos ha llevado a descartarla, si es el caso.

Modelado estructural de clases y objetos Clases y Objetos

Un objeto es una representacin de una entidad, ya sea real o conceptual, con lmites bien definidos y con significado dentro de un modelo. Cada objeto en un modelo se caracteriza por su estado, su comportamiento y su identidad. El estado de un objeto es una de las posibles condiciones bajo las que el objeto puede existir. El estado de un objeto cambia con el tiempo y est definido por un conjunto de propiedades (atributos), por los valores de esas propiedades y por las relaciones que dicho objeto puede tener con otros objetos. El comportamiento de un objeto determina la forma en que responde ante peticiones de otros objetos, y tipifica todo lo que el objeto puede hacer. El comportamiento de un objeto se materializa en el conjunto de operaciones definidas para dicho objeto. La identidad implica que cada objeto es nico, incluso si su estado es idntico al de otro objeto. En UML una clase es una descripcin de un grupo de objetos con propiedades comunes (atributos), comportamiento comn (operaciones), relaciones comunes y semntica comn. Por tanto, una clase es una plantilla (template) para la creacin de objetos, donde cada objeto de dicha clase ser una instancia de ella (no pudiendo ser instancia de ms de una clase). Antes de describir los distintos elementos que forman parte de un diagrama de clases, es importante aclarar la forma en que dichos diagramas pueden ser utilizados durante el proceso software. A la hora de confeccionar o interpretar un diagrama de clases pueden considerarse tres perspectivas:

Conceptual: Permite representar los conceptos del dominio. Aunque dichos conceptos suelen llevar, de una forma natural, a las clases que los implementan, puede que no exista una correspondencia directa. Especificacin: Cuando se trata de representar las interfaces del software y no el software en s. Implementacin: Es en esta perspectiva donde realmente tenemos clases, siendo sta la perspectiva ms utilizada.

Un diagrama de clases UML puede ser utilizado desde cualquiera de estas perspectivas, resulta en este caso conveniente el indicar la perspectiva de la que se trata por medio de estereotipos (seccin 7.1).

Relaciones: Asociaciones, Agregaciones y Dependencias

Todos los sistemas se construyen a partir de muchas clases y objetos cuya colaboracin permite lograr el comportamiento deseado en el sistema. La colaboracin entre objetos imponen la existencia de relaciones (relationship) entre ellos: principalmente asociaciones (associations) y agregaciones (aggregations). Una asociacin es una relacin entre instancias de clases. No se trata de un flujo de datos entre las clases, sino que se trata de una relacin estructural que entre los objetos instancias de dichas clases, especificando que los objetos de una clase deben ``conocer'' de alguna manera los objetos de la otra. Por ejemplo:

Un objeto de la clase A enva un mensaje a un objeto de la clase B. Un objeto de la clase A crea un objeto de la clase B. Un objeto de la clase A recibe un mensaje con un objeto de la clase B como argumento.

Es habitual nombrar las asociaciones generalmente con verbo activo o una frase verbal que recoge el significado de la asociacin. Tambin se puede optar por utilizar roles que nombran las clases que intervienen en la asociacin con un (role name) que denote el propsito o la caracterstica por la que una clase se asocia con otra. Un rol es simplemente la cara que la clase de un extremo de la asociacin presenta a la clase del otro extremo. Adems una asociacin puede incluir la multiplicidad asociada a cada una de las clases que intervienen, determinando el nmero de objetos que participan en la relacin. Al margen de su nombre y su multiplicidad una asociacin puede tener una navegacin (navigability) asociada. Si slo existe la navegacin en un sentido hablamos de asociacin unidireccional, si se permite la navegacin en ambos sentidos de la asociacin hablamos de asociacin bidireccional. Desde una perspectiva conceptual, las asociaciones representan relaciones conceptuales entre clases; desde el punto de vista de la especificacin, las asociaciones representan responsabilidades; y desde una perspectiva de implementacin una asociacin se traduce en punteros entre las clases relacionadas. Como hemos mencionado, una asociacin normal representa una relacin estructural entre iguales, es decir, las clases asociadas estn conceptualmente en el mismo nivel, sin ser ninguna ms importante que la otra. Por contra una agregacin es una asociacin especializada en la cual un todo se relaciona con sus partes. Tambin se la suele denominar como la relacin ``parte de''. El que una relacin sea modelada como una asociacin o como una agregacin es a menudo dependiente del dominio. UML ofrece una variedad ms fuerte de agregacin llamada composicin (composition) (seccin 3.5). En este tipo de agregacin el objeto parte debe pertenecer slo a un todo, y adems, los objetos parte viven y mueren con el todo.

Independientemente de su naturaleza asociativa o de agrupacin, ambas relaciones pueden ser reflexivas. En una relacin reflexiva sobre una clase, los objetos de dicha clase se comunican unos con otros. Este hecho aparece reflejado en el diagrama de clases como una asociacin o agregacin reflexiva. En cuanto a la dependencia, la mayora de las veces su utilizacin en el contexto de las clases va ligada a las operaciones, indicando que una clase utiliza otra como argumento en la signatura de una operacin (figura 3.1).

Figura 3.1: Dependencia entre clases originada en una signatura

Tambin encontramos frecuentemente relaciones de dependencia entre paquetes de clases. Si un paquete A depende de un paquete B, entonces hay una o ms clases en el paquete A que inician comunicacin con una o ms clases pblicas del paquete B.

Comportamiento y estructura de los objetos

Una clase plasma un conjunto de responsabilidades que define el comportamiento de los objetos de la clase. Las acciones de las que la clase es responsable se llevan a cabo mediante las operaciones definidas en la clase, de forma que todas las instancias de la clase sern capaces de realizar las operaciones de dicha clase. La estructura de un objeto se define a partir de los atributos de la clase a la que pertenece. Los objetos de una clase asignarn un valor a cada uno de los atributos de su clase. Generalmente los mensajes en los diagramas de interaccin (4.1) se traducen a operaciones en las clases que los reciben, sin embargo, hay casos especiales de mensajes que no llegan a ser operaciones. Por ejemplo, si la clase que recibe el mensaje es de tipo boundary (estereotipo de una clase) que contiene una clase de tipo GUI ( graphical user interface), el mensaje es una declaracin de los requisitos de la GUI. Encontramos otros ejemplos en los mensajes desde o hacia un actor que modela una persona fsica, estos mensajes deben incorporarse al manual de usuario ya que no tiene sentido crear operaciones para personas. Igualmente, si se trata de un mensaje desde o hacia un actor que representa otro sistema, se debe crear una clase que contenga el protocolo que se va a utilizar en la comunicacin con el sistema externo, en este caso el mensaje se traduce a una de las operaciones de la clase creada para el protocolo especfico. Las operaciones tambin se pueden crear independientemente de los diagramas de interaccin, ya que puede ser que no todos los escenarios estn representados en estos diagramas. Adems, pueden existir operaciones que se crean para ayudar a otra operacin. Aunque hemos definido el comportamiento y la estructura como caractersticas asociadas a un objeto, tambin una relacin puede estar dotada de estructura y comportamiento. Se trata de relaciones cuya informacin tiene que ver con el enlace entre los objetos relacionados y no con uno de los objetos en particular. La estructura y el comportamiento que definen una relacin se representa mediante una clase de tipo association class (se profundiza en este concepto en el apartado 3.5). Aunque los casos de uso y escenarios proporcionan la forma de describir el comportamiento del sistema, es decir, la interaccin entre los objetos del sistema, a veces es necesario especificar el comportamiento interno de un objeto. El comportamiento dinmico de un objeto se puede incluir en el diseo utilizando un diagrama de estados y transiciones (state transition diagram) (seccin 5.1), dichos diagramas muestran los estados del objeto, los eventos o mensajes que originan la transicin de un estado a otro, y las acciones consecuencia del cambio de estado. Crearemos un diagrama de este tipo para aquellas clases con un comportamiento dinmico significativo. Este tipo de diagramas de comportamiento tambin se utilizan en la especificacin del comportamiento de agregaciones y de clases control (estereotipo control de una clase).

Generalizacin

El concepto de herencia define otro tipo de relacin entre clases (generalizacin) donde una clase comparte estructura y/o comportamiento con una o ms clases. El trmino superclase se refiere a la clase que guarda la informacin comn, mientras que el trmino subclase se refiere a cada uno de los descendientes de la superclase. A partir de las relaciones de generalizacin se crea una jerarqua de abstraccin en la cual una subclase puede heredar de una o ms superclases. Es por sto que a la herencia tambin se le suele denominar jerarqua ``es una'' o ``clase de''. Una subclase hereda todos los atributos, operaciones y relaciones definidos en alguna de sus superclases, de forma que los atributos y operaciones comunes se definen en el nivel ms alto de la jerarqua. Las subclases se pueden ampliar (especializar) con atributos y operaciones adicionales, que se aplican slo a ese nivel de la jerarqua. Adems una subclase puede tener su propia implementacin de una operacin de la superclase (polimorfismo). Ya que la herencia no es una relacin entre objetos diferentes, este tipo de relaciones no se nombra, no se utilizan roles, ni se expresa multiplicidad, utilizndose la relacin generalizacin sin adornos. Existen dos formas bsicas de identificar herencia en un modelo, por generalizacin o por especializacin:

Generalizacin: La generalizacin proporciona la capacidad de crear superclases que encapsulan la estructura y el comportamiento comn a varias clases. Especializacin: La especializacin proporciona la capacidad de crear subclases que representan refinamientos de una superclase, generalmente aadiendo estructura y comportamiento a las nuevas subclases. Se a naden subclases para especializar el comportamiento de clases ya existentes. Las operaciones heredadas pueden ser reescritas por una subclase, lo que conocemos como polimorfismo, pero por el contrario, la subclase no debera proporcionar una estructura o comportamiento menor que el de su superclase.

Tambin en el caso de la herencia hay que tener en cuenta la perspectiva desde la que se interpreta. Conceptualmente, por ejemplo, una clase ser una subclase de una superclase, si todas las instancias de la subclase se pueden considerar tambin instancias de la superclase. Desde el punto de vista de la especificacin, la herencia implica que la interfaz del subtipo incluye todos los elementos de la interfaz del supertipo. Se dice, en este caso, que la interfaz de la subclase se ajusta ( conform to) a la interfaz de la superclase. Por ltimo, desde el punto de vista de la implementacin la herencia se asocia con la herencia definida en los lenguajes de programacin. La base para la especializacin, es decir, el motivo por el cual se crean subclases en una relacin de herencia es llamada discriminador (trmino utilizado tambin en clasificacin). Generalmente el discriminador tiene un nmero finito de valores, crendose una subclase para cada valor.

Muchas veces existe confusin entre las relaciones clasificacin (classification) y generalizacin (generalization), debemos considerar para evitarlo que: una clasificacin es una relacin entre una clase y sus instancias en funcin de un discriminador; por contra una generalizacin es una relacin entre clases que tambin puede realizarse en funcin de un discriminador. Relacionados con la herencia UML incorpora una serie de conceptos ms avanzados como los siguientes:

Dentro de una jerarqua de clase es comn especificar que ciertas clases son abstractas, es decir que no puede tener instancias directas. En UML se especifica que una clase es abstracta escribiendo su nombre en cursiva. Se puede alterar la semntica normal de herencia imponiendo que una clase no puede tener descendentes. En UML se utiliza para ello la restriccin {leaf}. Igualmente se puede imponer que una clase no puede tener antecesores asociando la restriccin {root} a una clase. Se puede restringir el nmero de instancias posibles de una clase. El nmero de instancias que puede tener una clase es su multiplicidad que ser un nmero cardinal en la esquina superior derecha del icono de la clase.

Por ltimo comentar que son posibles tanto relaciones de herencia nica como mltiple. Mientras que en la herencia nica una clase tiene una nica cadena de superclases, en la herencia mltiple intervienen ms de una cadena de superclases.

Diagrama de clases (estructura esttica)

Los diagramas de clases son diagramas de estructura esttica que muestran las clases del sistema y sus interrelaciones (incluyendo herencia, agregacin, asociacin, etc.). Los diagramas de clase son el pilar bsico del modelado con UML, siendo utilizados tanto para mostrar lo que el sistema puede hacer (anlisis), como para mostrar cmo puede ser construido (diseo). El diagrama de clases de ms alto nivel (main class diagram), ser lgicamente un dibujo de los paquetes que componen el sistema. A su vez cada paquete tendr un main class diagram que muestra las clases del paquete Las clases se documentan con una descripcin de lo que hacen, sus mtodos y sus atributos. Las relaciones entre clases se documentan con una descripcin de su propsito, su cardinalidad (cuantos objetos intervienen en la relacin) y su opcionalidad (cuando un objeto es opcional el que intervenga en una relacin). La descripcin de clases complejas se puede documentar con diagramas de estados (seccin 5.1).

Figura: Diagrama de clases de la mquina de caf

Supongamos el modelado de una mquina de caf. Un diagrama de estructura esttica inicial podra ser el representado en la figura 3.2. En dicha figura vemos que la representacin grfica UML para las clases es un rectngulo con compartimentos internos, siendo dichos rectngulos (clases) los elementos fundamentales del diagrama. Los compartimentos de una clase contienen su nombre, atributos y operaciones. En el ejemplo de la figura 3.2 encontramos las clases Ingrediente, Producto, Maquina, DepositoMonedas y DepositoMonedasIguales. Los atributos, como hemos mencionado, identifican las caractersticas propias de cada clase. Generalmente son de tipos simples, ya que los atributos de tipos compuestos se representan mediante relaciones de composicin con otras clases. La sintaxis textual UML para un atributo es: visibility name : type-expression = initial-value { property-string} Donde visibility puede ser public, protected y private; y type-expression es el tipo del atributo con nombre name. Adems puede especificarse un valor inicial y un conjunto de propiedades del atributo. La visibilidad de un atributo (u operacin puede ser):

public +: Cualquier clase externa con visibilidad hacia la clase dada puede utilizar la caracterstica (ya se atributo u operacin). protected #: Cualquier descendiente de la clase puede utilizar la caracterstica.

private -: Slo el propio clasificador puede utilizar la caracterstica.

En el modelo de la mquina de caf (fig.3.2), la clase Ingrediente tiene dos atributos: cantidad, de tipo float y con valor inicial 0; y nombre de tipo string sin valor inicial. En la herramienta CASE Rational Rose se utiliza para la representacin de la visibilidad los smbolos que se muestran en la figura 3.3.

Figura: Smbolos en Rose para visibilidad privada, protegida y pblica

La sintaxis de una operacin en UML es: visibility name (parameter-list) : return-type-expression {property-string} Donde cada uno de los parmetros en parameter-list se denota igual que un atributo. Los dems elementos son los mismos que encontramos en la notacin de un atributo. Otro detalle importante que se puede especificar en los atributos y operaciones de una clase es su alcance. El alcance de propiedad de una caracterstica especifica si la propiedad aparece en cada instancia de la clase o si slo hay una instancia la propiedad para todas las instancias de la clase. En UML se pueden especificar dos tipos de alcance de propiedad:

instancia: Cada instancia de la clase tiene su propio valor. clasificador: Slo hay un valor para todas las instancias del clasificador.

Un atributo u operacin con alcance de clasificador se denota subrayando la caracterstica. El alcance de clasificador se corresponde con lo que en C++ son atributos y operaciones estticas. Una relacin en un diagrama de clases, se representa mediante una lnea que une dos o ms clases. La lnea puede ir acompaada de diferentes tipos de adornos que definen su semntica y caractersticas. Como hemos ido viendo en esta seccin las relaciones ms comunes entre las clases presentes en un diagrama esttico pueden ser: asociacin (binaria o n-aria), agregacin, generalizacin, dependencia, composicin y clasificacin. Los elementos adicionales que pueden aparecer en la representacin de una relacin son:

Rol: Identifica con nombres a los elementos que aparecen en los extremos de la lnea que denota la relacin, dicho nombre describe la semntica que tiene la relacin en el sentido indicado. Por ejemplo, la asociacin de composicin entre Maquina e Ingrediente recibe el nombre de existencias como rol en ese sentido. Multiplicidad: Indica la cardinalidad de la relacin. En el ejemplo se utilizan 1, 1 ..*, 5, *, como indicadores de multiplicidad.

Una asociacin binaria se representa mediante una lnea slida que une dos clases, se trata de una relacin entre las dos clases no muy fuerte, es decir, no se exige dependencia existencial ni encapsulamiento. Un ejemplo de asociacin de este tipo es la que existe entre una compaa y sus empleados (fig.3.4). En este caso la asociacin binaria recibe el nombre Trabaja Para, y en ella intervienen una o ms instancias (objetos) de la clase Persona denominadas empleado. Adems cada empleado se asocia a un empleador que en este caso es nico.

Figura: Ejemplo de asociacin binaria

La agregacin (aggregation) es, como ya hemos mencionado, una forma especial de asociacin que especifica una relacin todo-parte entre el agregado (todo) y una parte que lo compone. Una agregacin se representa mediante un rombo en el extremo ``todo'' de la relacin. Un ejemplo puede encontrarse entre Producto e Ingrediente en la figura 3.2. Una agregacin de composicin o simplemente composicin (composite aggregation) es una agregacin ms fuerte que implica:

Dependencia existencial: El elemento dependiente desaparece al destruirse el que lo contiene y, si es de cardinalidad 1, es creado al mismo tiempo. Pertenencia fuerte: Se puede decir que el objeto contenido es parte constitutiva y vital del que lo contiene. No comparticin: Los objetos contenidos no son compartidos, esto es, no forman parte del estado de otro objeto.

La composicin se representa mediante un rombo relleno del lado de la clase que contiene a la otra en la agregacin. En el ejemplo de la mquina de caf vemos composiciones entre Maquina y Producto, Maquina y DepositoMonedas y, Maquina y DepositoMonedasIguales. La relacin de generalizacin, denotando herencia entre clases, se representa mediante un tringulo sin rellenar del lado de la superclase. La subclase hereda todos los atributos y mensajes descritos en la superclase. En el ejemplo encontramos generalizacin entre DepositoMonedas (superclase) y DepositoMonedasIguales (subclase). Una clase paramtrica (parametrized class) se corresponde con el concepto de clases molde (template) en C++. Se representa acompaando la clase con un rectngulo en la esquina superior derecha donde estaran los parmetros. Por ejemplo, la clase Lista que utiliza un parmetro formal Tipo se representara como en la figura 3.5, pudiendo representar una lista de diferentes tipos de objetos dependiendo del valor del parmetro.

Figura: Ejemplo de clase paramtrica ( parametrized class)

En UML los paquetes se representan como carpetas (fig 3.6) que pueden presentar relaciones de dependencia o de generalizacin entre ellos.

Figura 3.6: Ejemplo de paquetes

En el ejemplo de la figura 1.11 existen tres paquetes (que aparecen vacos, es decir, con su contenido encapsulado), con dos de ellos dependiendo del Modelo del Mundo. Una dependencia puede ir acompaada de una explicacin del tipo de dependencia de que se trate, utilizando estereotipos.

Estereotipos para clases

Las clases, al igual que los dems elementos notacionales del UML, pueden estar clasificadas de acuerdo a varios criterios, como por ejemplo su objetivo dentro de un programa. Esta clasificacin adicional se puede expresar mediante la utilizacin de estereotipos (seccin 7.1).

Figura 3.11: Ejemplo de estereotipo

En la figura 3.11, Auto3D est clasificado con el estereotipo Mundo (denotado por <<>>), y la clase Window con el de interfaz. Ntese que tambin las relaciones pueden tener esta clasificacin, en este caso la relacin se identifica como Observer. Los estereotipos ms comunes utilizados para clasificar las clases son: Entidad (entity), Frontera (boundary), Control (control), Utilidad (utility) y Excepcin (exception). El Objectory Process, propone una serie de pautas a seguir a la hora de encontrar las clases de nuestro sistema durante la fase de anlisis. Dichas pautas se centran en la bsqueda de los estereotipos entidad, control y frontera:

Una clase entidad modela la informacin de larga vida y su comportamiento asociado. Este tipo de clase suele reflejar entidades del mundo real o elementos necesarios para realizar tareas internas al sistema. Tambin se denominan clase dominio, ya que suelen tratar con abstracciones de entidades del mundo real. Una clase frontera maneja comunicaciones entre el entorno del sistema y el sistema, suelen proporcionar la interfaz del sistema con un usuario o con otro sistema, en general, por tanto, modelan las interfaces del sistema. Cuando se trata de clases que definen la interfaz con otro sistema se refinarn, durante la fase de diseo, para tener en cuenta los protocolos de comunicacin elegidos. Una clase control modela el comportamiento secuenciado especfico de uno o varios casos de uso. Se trata de clases que coordinan los eventos necesarios para llevar a cabo el comportamiento que se especifica en el caso de uso, representan su dinmica.

Diagramas de objetos

Los diagramas de objetos modelan las instancias de elementos contenidos en los diagramas de clases. Un diagrama de objetos muestra un conjunto de objetos y sus relaciones en un momento concreto. En UML, los diagramas de clase se utilizan para visualizar los aspectos estticos del sistema y los diagramas de interaccin se utilizan para ver los aspectos dinmicos del sistema, y constan de instancias de los elementos del diagrama de clases y mensajes enviados entre ellos. En un punto intermedio podemos situar los diagramas de objetos, que contiene un conjunto de instancias de los elementos encontrados en el diagrama de clases, representando slo la parte esttica de un interaccin, consistiendo en los objetos que colaborar pero sin ninguno de los mensajes intercambiados entre ellos. Los diagramas de objetos se emplean para modelar la vista de diseo esttica o la vista de procesos esttica de un sistema al igual que se hace con los diagramas de clases, pero desde la perspectiva de instancias reales o prototpicas. Esta vista sustenta principalmente los requisitos funcionales de un sistema. Los diagramas de objetos permiten modelar estructuras de datos estticas, En general los diagramas de objetos se utilizan para modelar estructuras de objetos, lo que implica tomar una instantnea de los objetos de un sistema en un cierto momento. Un diagrama de objetos representa una escena esttica dentro de la historia representad a por un diagrama de interaccin. Los diagramas de objetos se utilizan para visualizar, especificar, construir y documentar la existencia de ciertas instancias en el sistema, junto a las relaciones entre ellas.

Figura 3.12: Modelado de estructuras de objetos

En la figura 3.12 se representa un conjunto de objetos extrados de la implementacin de un robot. Como indica la figura, un objeto representa al propio robot, (r es una instancia de Robot), y r se encuentra actualmente en estado movimiento. Este objeto tiene un enlace con m, una instancia de Mundo, que representa una abstraccin del modelo del mundo del robot. Este objeto tiene un enlace con un multiobjeto, un conjunto de instancias de Elemento, que representan entidades que el robot ha identificado, pero an no ha asignado en su vista del mundo. En este instante, m est enlazado a dos instancias de rea. Una de ellas (a2) se muestra con sus propios enlaces a tres objetos Pared y un objeto Puerta. Cada una de estas paredes est etiquetada con su anchura actual, y cada una se muestra enlazada a sus paredes vecinas. Como sugiere este diagrama de objetos, el robot ha reconocido el rea que lo contiene, que tiene paredes en tres lados y una puerta en el cuarto. Como vemos los diagramas de objetos son especialmente tiles para modelar estructuras de datos complejas. Evidentemente puede existir una multitud de posibles instancias de una clase particular, y para un conjunto de clases con t relaciones entre ellas, pueden existir muchas ms configuraciones posibles de estos objetos. Por lo tanto, al utilizar diagramas de objetos slo se pueden mostrar significativamente conjuntos interesantes de objetos concretos o prototpicos.

Modelado de interacciones Diagramas de Interaccin

Los diagramas de interaccin se utilizan para modelar los aspectos dinmicos de un sistema, lo que conlleva modelar instancias concretas o prototpicas de clases interfaces, componentes y nodos, junto con los mensajes enviados entre ellos, todo en el contexto de un escenario que ilustra un comportamiento. En el contexto de las clases describen la forma en que grupos de objetos colaboran para proveer un comportamiento. Mientras que un diagrama de casos de uso presenta una visin externa del sistema, la funcionalidad de dichos casos de uso se recoge como un flujo de eventos utilizando para ello interacciones entre sociedades de objetos. Cada caso de uso es una telaraa de de escenarios primarios (flujo normal del caso de uso) y secundarios (flujos excepcionales y alternativos). Por tanto, para un caso de uso podemos definir diferentes instancias (escenarios) que nos ayudan a la identificacin de objetos, clases e interacciones entre objetos necesarios para llevar a cabo la parte de funcionalidad que especifica el caso de uso. Los escenarios documentan el reparto de las responsabilidades que se especifican en el caso de uso. El flujo de eventos de un caso de uso puede recogerse en una especificacin texto acompaada de distintos escenarios especificados mediante diagramas de interaccin (interaction diagrams), donde cada diagrama ser una visin grfica de un escenario. Existen dos tipos de diagramas de interaccin:

Diagramas de secuencia (sequence diagrams): seccin 4.2. Diagramas de colaboracin (collaboration diagrams): seccin 4.3.

Un diagrama de secuencia es un diagrama de interaccin que destaca la ordenacin temporal de los mensajes; un diagrama de colaboracin es un diagrama de interaccin que destaca la organizacin estructural de los objetos que envan y reciben mensajes. Se deberan utilizar diagramas de interaccin cuando se quiere analizar el comportamiento de varios objetos dentro del mismo caso de uso, resultando apropiados para mostrar colaboraciones entre objetos. Si lo que se desea es mostrar el comportamiento de un nico objeto a lo largo de diferentes casos de uso, se deben utilizar los diagramas de estados. Si se desea mostrar el comportamiento de una sociedad de objetos en diferentes casos de uso o en diferentes hilos de ejecucin habr que considerar un diagrama de actividades.

Diagramas de Secuencia

Un diagrama de secuencia muestra las interacciones entre objetos ordenadas en secuencia temporal. Muestra los objetos que se encuentran en el escenario y la secuencia de mensajes intercambiados entre los objetos para llevar a cabo la funcionalidad descrita por el escenario. En aplicaciones grandes adems de los objetos se muestran tambin los componentes y casos de uso. El mostrar los componentes tiene sentido ya que se trata de objetos reutilizables, en cuanto a los casos de uso hay que recordar que se implementan como objetos cuyo rol es encapsular lo definido en el caso de uso. Para mostrar la interaccin con el usuario o con otro sistema se introducen en los diagramas de secuencia las boundary classes. En las primeras fases de diseo el propsito de introducir estas clases es capturar y documentar los requisitos de interfaz, pero no el mostrar como se va a implementar dicha interfaz. Los diagramas de secuencia, formalmente diagramas de traza de eventos o de interaccin de objetos, se utilizan con frecuencia para validar los casos de uso. Documentan el diseo desde el punto de vista de los casos de uso. Observando qu mensajes se envan a los objetos, componentes o casos de uso y viendo a grosso modo cuanto tiempo consume el mtodo invocado, los diagramas de secuencia nos ayudan a comprender los cuellos de botella potenciales, para as poder eliminarlos. A la hora de documentar un diagrama de secuencia resulta importante mantener los enlaces de los mensajes a los mtodos apropiados del diagrama de clases.

Figura 4.1: Ejemplo de diagrama de secuencia

En la figura 4.2 se muestra un ejemplo de diagrama de secuencia, que da detalle al caso de uso PedirProducto del ejemplo de la mquina de caf. Los conceptos ms importantes relacionados con los diagramas de secuencia son:

Lnea de vida de un objeto (lifeline): La lnea de vida de un objeto representa la vida del objeto durante la interaccin. En un diagrama de secuencia un objeto se representa como una lnea vertical punteada con un rectngulo de encabezado y con rectngulos a travs de la lnea principal que denotan la ejecucin de mtodos (activacin). El rectngulo de encabezado contiene el nombre del objeto y el de su clase, en un formato nombreObjeto: nombreClase. Por ejemplo, el objeto m, instancia de la clase MaquinaCafe enva dos mensajes seguidos para dar respuesta a la operacin PedirProducto: Servir al objeto p de la clase Producto y DarVueltas a s mismo (self-delegation). Activacin: Muestra el perodo de tiempo en el cual el objeto se encuentra desarrollando alguna operacin, bien sea por s mismo o por medio de delegacin a alguno de sus atributos. Se denota como un rectngulo delgado sobre la lnea de vida del objeto. En el ejemplo anterior el objeto ingredientes se encuentra activo mientras ejecuta el mtodo correspondiente al mensaje Servir, el objeto p se encuentra activo mientras se ejecuta su mtodo Servir, que ejecuta _ingredientes.Servir, y el objeto m se encuentra activo mientras se ejecuta p.Servir y DarVueltas. Mensaje: El envo de mensajes entre objetos se denota mediante una lnea slida dirigida, desde el objeto que emite el mensaje hacia el objeto que lo ejecuta. En el ejemplo anterior el objeto m enva el mensaje Servir al objeto p y un poco ms adelante en el tiempo el objeto m se enva a s mismo el mensaje DarVueltas. Tiempos de transicin: En un entorno de objetos concurrentes o de demoras en la recepcin de mensajes, es til agregar nombres a los tiempos de salida y llegada de mensajes. Analizando la recepcin de una llamada telefnica puede tenerse un diagrama como el de la figura 4.2.

Figura: Diagrama de secuencia con tiempos de transicin

En este diagrama se tienen tres objetos concurrentes, el que hace la llamada, la central telefnica y el que recibe la llamada. Se nombran los tiempos de los mensajes que enva o recibe caller (a para descolgar, b para el tono de la llamada, c para la marcacin, d para el inicio del enrutamiento de la llamada, d' para la finalizacin del enrutamiento). Estos nombres o tiempos de transicin permiten describir restricciones de tiempo, por ejemplo b-a < 1 sec o demoras entre el envo y la recepcin (entre d y d').

Caminos alternativos de ejecucin y concurrencia: En algunos casos sencillos los caminos alternativos pueden expresarse en un diagrama de secuencias alternativas de ejecucin. Estas alternativas pueden representar condiciones en la ejecucin o diferentes hilos de ejecucin ( threads).

Figura 4.3: Diagrama de secuencia con caminos alternativos

En el diagrama de la figura 4.3 se muestran dos casos. ob1 muestra una condicin al enviar un mensaje a ob3 o a ob2, dependiendo de si x>0 o x<0. Estas dos lneas de ejecucin se vuelven a unir ms adelante, indicando el fin del condicional. Por otra parte ob4 muestra dos posibles operaciones dependiendo de si se sigui la condicin x>0 o x<0. Ya que se presentan en el mismo instante de tiempo, se requiere dividir la lnea del objeto en dos. Esta misma representacin se utiliza para el caso de dos hilos de ejecucin.

Destruccin de un objeto Se representa como una X al final de la lnea de ejecucin del objeto. Por ejemplo, en el diagrama anterior se muestra el final de ob2 y de ob1. Mtodos recursivos Un ejemplo de un mtodo recursivo es el mtodo more en ob1. Es un rectngulo adyacente a la activacin principal y con lneas de llamada de mensajes, que indican la entrada y salida de la recursin.

Diagramas de Colaboracin
Un diagrama de colaboracin es una forma alternativa al diagrama de secuencia de mostrar un escenario. Este tipo de diagrama muestra las interacciones entre objetos organizadas entorno a los objetos y los enlaces entre ellos. Los diagramas de secuencia proporcionan una forma de ver el escenario en un orden temporal qu pasa primero, qu pasa despus -. Los clientes entienden fcilmente este tipo de diagramas, por lo que resultan tiles en las primeras fases de anlisis. Por contra los diagramas de colaboracin proporcionan la representacin principal de un escenario, ya que las colaboraciones se organizan entorno a los enlaces de unos objetos con otros. Este tipo de diagramas se utilizan ms frecuentemente en la fase de diseo, es decir, cuando estamos diseando la implementacin de las relaciones. Se toma como ejemplo el caso de uso PedirProducto (fig. 4.4) ya descrito como diagrama de secuencia.

Figura: Ejemplo diagrama de colaboracin

A diferencia de otras notaciones que muestran tanto el estado y el comportamiento de la clase en el diagrama de clases, UML separa el comportamiento de las clases en los diagramas de colaboracin. Los diagramas de clase de UML no incluyen flujo de mensajes entre clases, es por sto que los diagramas de colaboracin se deben crear en paralelo con los diagramas de clases. Aunque se puede indicar el orden del flujo de mensajes en un diagrama de colaboracin numerando los mensajes, no se suele hacer, ya que para este propsito son mejores los diagramas de secuencia. A continuacin se enumeran los conceptos fundamentales de un diagrama de colaboracin:

Objeto: Se representa con un rectngulo que contiene el nombre y la clase del objeto en un formato nombreObjeto: nombreClase. Enlaces: Un enlace es una instancia de una asociacin en un diagrama de clases. Se representa como una lnea continua que une a dos objetos, acompaada por un nmero que indica el orden dentro de la interaccin. Pueden darse varios niveles de subndices para indicar anidamiento de operaciones. Se pueden utilizar estereotipos para indicar si el objeto que recibe el mensaje es un atributo, un parmetro de un mensaje anterior, si es un objeto local o global. Flujo de mensajes: Expresa el envo de un mensaje. Se representa mediante una flecha dirigida cerca de un enlace. Marcadores de creacin y destruccin de objetos: Puede mostrarse en la grfica qu objetos son creados y destruidos, agregando una restriccin con la palabra new o delete respectivamente. Objeto compuesto: Es una representacin alternativa de un objeto y sus atributos. En esta representacin se muestran los objetos contenidos dentro del rectngulo que representa al objeto que los contiene. Un ejemplo es el objeto Window (figura 4.5).

Figura 4.5: Ejemplo de objeto compuesto

Patrn de diseo: Un diagrama de colaboracin puede especificar un contrato entre objetos, parte esencial para la descripcin de un patrn de diseo. Este diagrama contiene todos los elementos citados de un diagrama de colaboracin, dejando libres posiblemente los tipos exactos de algunos objetos o con nombres genricos para los mensajes. Una ``instanciacin'' del patrn se representa como una elipse unida mediante flechas punteadas a los objetos o clases que participan realmente en el patrn. Estas flechas pueden tener roles, indicando cul es el papel de cada elemento dentro del patrn. Por ejemplo, una instanciacin del patrn Observer se representa en la figura 4.6.

Figura: Diagrama de Colaboracin que describe un patrn

Contexto: Un contexto es una vista de uno o ms elementos dentro del modelo que colaboran en el desarrollo de una accin. Se usa para separar los dems elementos en el modelo de este problema en particular y darle nfasis. Puede mostrar slo los detalles relevantes de las clases u objetos que contiene, para resaltar su utilidad. Un ejemplo es la definicin del tipo CashRegister (figura 4.7).

Figura 4.7: Ejemplo de un contexto

Se representa como un contexto un tipo CashRegister y se muestran los detalles relevantes de Product, Item y Sale para este tipo. Las relaciones de las clases con otras no visibles dentro del contexto pueden omitirse o conectarse al borde del contexto.

Objeto activo: Un objeto activo es el que contiene su propio flujo de control, a diferencia de un objeto pasivo que encapsula datos y slo reacciona al enviarle mensajes. Un objeto activo se representa con un rectngulo de bordes gruesos. Puede contener otros objetos pasivos o activos. Se presenta un ejemplo en la figura 4.8 en el contexto de una produccin en lnea robotizada. Se tiene un ente Factory Manager, un ente robot y un ente oven, tres objetos activos que interactan para desarrollar su tarea.

Figura 4.8: Ejemplo de objetos activos

Los mensajes entre objetos pasivos se denotan mediante una flecha completa, mientras que los mensajes entre objetos activos se denotan con una media flecha. Los hilos de ejecucin se denotan con las letras A y B antes del nmero de orden del mensaje. La sincronizacin entre hilos se muestra mediante un ``/'' y el nuevo nmero de orden. Por ejemplo en A2, B2 / 2: completed (job).

Modelado de comportamiento Diagramas de Estado

Un estado es una condicin durante la vida de un objeto, de forma que cuando dicha condicin se satisface se lleva a cabo alguna accin o se espera por un evento. El estado de un objeto se puede caracterizar por el valor de uno o varios de los atributos de su clase, adems, el estado de un objeto tambin se puede caracterizar por la existencia de un enlace con otro objeto. El diagrama de estados y transiciones engloba todos los mensajes que un objeto puede enviar o recibir. En un diagrama de estados, un escenario representa un camino dentro del diagrama. Dado que generalmente el intervalo entre dos envos de mensajes representa un estado, se pueden utilizar los diagramas de secuencia (4.2) para buscar los diferentes estados de un objeto. En todo diagrama de estados existen por lo menos dos estados especiales inicial y final: start y stop. Cada diagrama debe tener uno y slo un estado start para que el objeto se encuentre en estado consistente. Por contra, un diagrama puede tener varios estados stop. Una transicin en un diagrama de estados puede tener asociada una accin y/o una guarda, adems, una transicin puede disparar un evento. La accin ser el comportamiento que se obtiene cuando ocurre la transicin, y el evento ser el mensaje que se enva a otro objeto del sistema. Por ltimo, la guarda es una expresin boolena sobre los valores de los atributos que hace que la transicin slo se produzca si la condicin evala a true. Tanto las acciones como las guardas son comportamientos del objeto y generalmente se traducen en operaciones de alguna clase. Una transicin entre estados representa un cambio de un estado origen a un estado sucesor destino que podra ser el mismo que el estado origen, dicho cambio de estado puede ir acompaado de alguna accin. Las acciones se asocian a las transiciones y se considera que ocurren de forma rpida y no interrumpible. Por contra, las actividades se asocian a los estados pudiendo consumir ms tiempo, dicha actividad puede verse interrumpida por la ocurrencia de algn evento. Existen dos formas de transicionar en un diagrama de estados: automticamente y no automticamente. Se produce una transicin automtica cuando se acaba la actividad del estado origen (no hay un evento asociado con la transicin). Se produce una transicin no automtica cuando existe un evento que puede pertenecer a otro objeto o incluso estar fuera del sistema. Los diagramas de estados muestran el comportamiento de los objetos, es decir, el conjunto de estados por los cuales pasa un objeto durante su vida, junto con los cambios que permiten pasar de un estado a otro. Un ejemplo para el caso de la mquina de caf son los estados posibles de la clase MaquinaCafe (figura 5.1).

Figura: Ejemplo de diagrama de estados de la Mquina de Caf

Un estado identifica un perodo de tiempo (no instantneo) en la vida del objeto durante el cual est esperando alguna operacin, tiene cierto comportamiento caracterstico o puede recibir cierto tipo de estmulos. En notacin UML, un estado se representa mediante un rectngulo con los bordes redondeados, que puede tener tres compartimentos: uno para el nombre, otro para el valor caracterstico de los atributos del objeto en ese estado y otro para las acciones que se realizan al entrar, salir o estar en un estado (entry, exit o do, respectivamente). En el caso de la figura 5.1, se tienen cuatro estados (Lista, IntroduciendoMonedas, SeleccionandoAzucaryProducto, SirviendoProducto), en los cuales se desarrollan ciertas acciones al entrar, por ejemplo, al entrar al estado IntroduciendoMonedas se debe realizar la accin MostrarDineroActual. Los estados iniciales y finales se representan mediante los smbolos de la figura 5.2.

Figura 5.2: Estado final

Otros conceptos relacionados con los diagramas de estados son:

Eventos Un evento es una ocurrencia que puede causar la transicin de un estado a otro de un objeto. Esta ocurrencia puede ser:
o o o o

Condicin que toma el valor de verdadero o falso. Recepcin de una seal de otro objeto en el modelo. Recepcin de un mensaje. Paso de cierto perodo de tiempo, despus de entrar al estado o de cierta hora y fecha particular.

El nombre de un evento tiene alcance dentro del paquete en el cual est definido, no es local a la clase que lo nombra. En el caso del ejemplo de la figura 5.1, encontramos en varias transiciones el evento userInput, que recibe como parmetro un objeto Button indicando el botn que ha sido presionado por el usuario de la mquina de caf.

Envo de mensajes Adems de mostrar la transicin de estados por medio de eventos, puede representarse el momento en el cual se envan mensajes a otros objetos. Para ello se utiliza una lnea punteada dirigida al diagrama de estados del objeto receptor del mensaje. Si tomamos como ejemplo un control remoto que puede enviar rdenes de encender o apagar al televisor o a la videograbadora se puede obtener un diagrama de estados como el de la figura 5.3

Figura: Ejemplo de envo de mensajes

En la figura observamos un diagrama de estados para cada uno de los tres aparatos, algunas de las transiciones del control remoto causan el envo de mensajes togglePower a los otros aparatos (televisin y videograbadora).

Transicin simple Una transicin simple es una relacin entre dos estados que indica que un objeto en el primer estado puede entrar al segundo estado y ejecutar ciertas operaciones cuando un evento ocurre y si ciertas condiciones son satisfechas. Se representa como una lnea slida entre dos estados, que puede venir acompaada de un texto con el siguiente formato: event-signature [guard-condition] action-expression send-clause Donde event-signature es la descripcin del evento que da lugar a la transicin; guardcondition son las condiciones adicionales al evento necesarias para que la transicin ocurra; action-expression es un mensaje al objeto o a otro objeto que se ejecuta como resultado de la transicin y el cambio de estado; y send-clause son acciones adicionales

que se ejecutan con el cambio de estado, por ejemplo, el envo de eventos a otros paquetes o clases. En el caso del ejemplo inicial de la mquina de caf se tiene una transicin entre los estados IntroduciendoMoneda y SeleccionadoAzucaryProducto que tiene una transicin con el siguiente detalle: userInput(Button) | [TodoOk=true] / MostrarNivelAzucar, MostrarProducto El evento que dispara el cambio de estado es userInput(Button). Se requiere como condicin adicional que no se haya detectado ningn fallo (TodoOk = true) y se ejecuta MostrarNivelAzucar y MostrarProducto.

Transicin interna Es una transicin que permanece en el mismo estado, en vez de involucrar dos estados distintos. Representa un evento que no causa cambio de estado. Se denota como una cadena adicional en el compartimento de acciones del estado. Supongamos el estado de una interfaz pidiendo password al usuario. En este caso puede tenerse una transicin interna que muestre una ayuda al usuario. Esta transicin se muestra en el diagrama de la figura 5.4 con la cadena ``help / display help'' dentro del cuerpo del estado.

Figura: Ejemplo de transicin interna

Subestados Un estado puede descomponerse en subestados, con transiciones entre ellos y conexiones al nivel superior (superestado). Las conexiones se ven al nivel inferior como estados de inicio o fin, los cuales se suponen conectados a las entradas y salidas del nivel inmediatamente superior. Un ejemplo es el estado marcando de un telfono (figura 5.5), que puede descomponerse en los subestados Inicio y marcado parcial.

Figura 5.5: Ejemplo de subestados

Transicin compleja Una transicin compleja relaciona tres o ms estados en una transicin de mltiples fuentes y/o mltiples destinos. Representa la subdivisin en hilos del control del objeto o una sincronizacin. Se representa como una lnea vertical de la cual salen o entran varias lneas de transicin de estado. En el ejemplo de la figura 5.6 se muestra una transicin a dos hilos concurrentes que luego se sincronizan.

Figura: Ejemplo de transicin compleja

Transicin a estados anidados Una transicin hacia un estado complejo, descrito mediante estados anidados, significa la entrada al estado inicial del subdiagrama. Las transiciones que salen del estado complejo se entienden como transiciones desde cada uno de los subestados hacia afuera, a cualquier nivel de profundidad. En la figura 5.1 se encuentran los dos casos nombrados: desde el estado inicial se pasa al estado BuenFuncionamiento (a su estado inicial) y de este estado salen transiciones hacia MalFuncionamiento y hacia el estado final, dichas transiciones deben comprenderse como transiciones de cada uno de los estados internos hacia los estados externos.

Los diagramas de estado resultan adecuados para describir el comportamiento de un objeto a travs de diferentes casos de uso, sin embargo, no resultan del todo adecuados para describir el

comportamiento que incluye a una serie de objetos colaborando entre s. Por lo tanto, resulta til combinar los diagramas de estado con otras tcnicas. Por ejemplo, los diagramas de interaccin (4.1) son idneos para la descripcin del comportamiento de varios objetos en un nico caso de uso, y los diagramas de actividades (5.2) muestran de forma adecuada la secuencia general de acciones en diferentes objetos y casos de uso. No nos debemos plantear el disear diagramas de estados para todas las clases en el sistema, sino slo para aquellas que exhiban un comportamiento interesante de forma que la elaboracin del diagrama de estados nos ayude a entender dicho comportamiento.

Diagramas de Actividades

Un diagrama de actividades puede considerarse como un caso especial de un diagrama de estados en el cual casi todos los estados son estados accin (identifican una accin que se ejecuta al estar en l) y casi todas las transiciones evolucionan al trmino de dicha accin (ejecutada en el estado anterior). Un diagrama de actividades puede dar detalle a un caso de uso, un objeto o un mensaje en un objeto. Permiten representar transiciones internas al margen de las transiciones o eventos externos. En la figura 5.7 se presenta un ejemplo de diagrama de actividades para un mensaje de un objeto. La interpretacin de un diagrama de actividades depende de la perspectiva considerada: en un diagrama conceptual, la actividad es alguna tarea que debe ser realizada; en un diagrama de especificacin o de implementacin, la actividad es un mtodo de una clase. Generalmente se suelen utilizar para modelar los pasos de un algoritmo.

Figura 5.7: Ejemplo de diagrama de actividades

Un estado de accin representa un estado con accin interna, con por lo menos una transicin que identifica la culminacin de la accin (por medio de un evento implcito). No deben tener transiciones internas ni transiciones basadas en eventos, ya que si fuera este el caso, se representara con un diagrama de estados. Los estados de accin se representan por un rectngulo con bordes redondeados, y permiten modelar un paso dentro de un algoritmo. Las flechas dirigidas entre estados de accin representan transiciones con evento implcito que, en el caso de decisiones, pueden tener una condicin o guarda asociada (que al igual que en los diagramas de estado evala a true o a false). Las decisiones se representan mediante una transicin mltiple que sale de un estado y donde cada camino tiene una etiqueta distinta. Se representa mediante un rombo al cual llega la transicin del estado origen y del cual salen las mltiples transiciones de los estados destino. Un ejemplo se muestra en la figura 5.7 cuando no hay caf y se toma una decisin entre hay cola o no hay cola. En un diagrama de actividades tambin pueden existir barras de sincronizacin (synchronization bar), como la que sigue a [found cofee] en la figura 5.7, a las que se encuentran asociadas varios caminos salientes. Cada camino saliente se dirige a una actividad (Put Coffee in Filter, Add Water to Reservoir y Get Cups), realizndose dichas actividades en paralelo. Esto quiere decir que el orden en que se realicen dichas actividades es irrelevante, siendo valido cualquier orden entre ellas. Dado que el diagrama de actividades permite expresar el orden en que se realizan las cosas, resulta adecuado para el modelado de organizaciones (business modeling) y el de programas concurrentes (permiten representa grficamente los hilos de ejecucin). Como la mayora de las tcnicas de modelado de comportamiento, los diagramas de actividades tienen sus puntos fuertes y sus puntos dbiles, de forma que es necesario utilizarlos en combinacin con otras tcnicas. Su principal aportacin al modelado del comportamiento es que soportan el comportamiento paralelo, lo que resulta adecuado para el modelado de flujo de trabajo ( workflow) y programacin multihilo (multi-thread). Por contra, su principal desventaja es que no muestran de una forma clara los enlaces existentes entre las acciones y los objetos, siendo mucho mas apropiado para ello los diagramas de interaccin. En general resulta adecuado utilizar diagramas de actividades para:

Anlisis de casos de uso: Durante el anlisis de los casos de uso no estamos interesados en asociar acciones a objetos, sino en entender qu acciones se necesitan llevar a cabo y cuales son las dependencias en el comportamiento. Comprensin del flujo de trabajo a lo largo de diferentes casos de uso. Modelado de aplicaciones multihilo.

Por contra, resultan en general del todo inadecuados a la hora de mostrar la colaboracin entre objetos y la evolucin del comportamiento de los objetos durante su tiempo de vida.

Modelado de implementacin Diagramas de Implementacin

Un diagrama de implementacin muestra las dependencias entre las partes de cdigo del sistema (diagrama de componentes) o la estructura del sistema en ejecucin (diagrama de despliegue): los diagramas de componentes se utilizan para modelar la vista de implementacin esttica de un sistema, mientras que los diagramas de despliegue se utilizan para modelar la vista de despliegue esttica.

Diagrama de Componentes
Lo que distingue a un diagrama de componentes de otros tipos de diagramas es su contenido. Normalmente contienen componentes, interfaces y relaciones entre ellos. Y como todos los diagramas, tambin puede contener paquetes utilizados para agrupar elementos del modelo. Un diagrama de componentes muestra las organizaciones y dependencias lgicas entre componentes software, sean stos componentes de cdigo fuente, binarios o ejecutables. Desde el punto de vista del diagrama de componentes se tienen en consideracin los requisitos relacionados con la facilidad de desarrollo, la gestin del software, la reutilizacin, y las restricciones impuestas por los lenguajes de programacin y las herramientas utilizadas en el desarrollo. Los elementos de modelado dentro de un diagrama de componentes sern componentes y paquetes. En cuanto a los componentes, slo aparecen tipos de componentes, ya que las instancias especficas de cada tipo se encuentran en el diagrama de despliegue (6.1.2). Dado que los diagramas de componentes muestran los componentes software que constituyen una parte reusable, sus interfaces, y sus interrelaciones, en muchos aspectos se puede considerar que un diagrama de componentes es un diagrama de clases a gran escala. Cada componente en el diagrama debe ser documentado con un diagrama de componentes ms detallado, un diagrama de clases, o un diagrama de casos de uso. Un paquete en un diagrama de componentes representa una divisin fsica del sistema. Los paquetes se organizan en una jerarqua de capas donde cada capa tiene una interfaz bien definida. Un ejemplo tpico de una jerarqua en capas de este tipo es: Interfaz de usuario; Paquetes especficos de la aplicacin; Paquetes reusables; Mecanismos claves; y Paquetes hardware y del sistema operativo. Un diagrama de componentes se representa como un grafo de componentes software unidos por medio de relaciones de dependencia (generalmente de compilacin). Puede mostrar tambin que un componente software contiene una interfaz, es decir, la soporta. Un ejemplo es el de la figura 6.1.

Figura 6.1: componentes

Ejemplo

de

diagrama

de

En el caso de la figura 6.1 tenemos tres componentes, GUI que depende de interfaz, update provista por Planner, Planner dependiendo de la interfaz y reservations provista por Scheduler. Normalmente los diagramas de componentes se utilizan para modelar cdigo fuente, versiones ejecutables, bases de datos fsicas, entre otros:

Cdigo fuente: En el modelado de cdigo fuentes se suelen utilizar para representar las dependencias entre los ficheros de cdigo fuente, o para modelar las diferentes versiones de estos ficheros. Para ello se deben identificar el conjunto de archivos de cdigo fuente de inters y estereotiparlos como archivos file, agruparlos en paquetes, utilizar valores etiquetados para la informacin de versiones y modelar las dependencias de compilacin. Cdigo ejecutable: Se utiliza para modelar la distribucin de una nueva versin a los usuarios. Para tal propsito se identifican el conjunto de componentes ejecutables que intervienen, se utilizan estereotipos para los diferentes tipos de componentes (ejecutables, bibliotecas, tablas, archivos, documentos, etc.), se consideran las relaciones entre dichos componentes que la mayora de las veces incluirn interfaces que son exportadas (realizadas) por ciertos componentes e importadas (utilizadas) por otros. Bases de datos fsica: UML permite el modelado de bases de datos fsicas as como de los esquemas lgicos de bases de datos.

As si tenemos en cuenta las dependencias asociadas al proceso de compilacin un componente podra ser:

Cdigo fuente que depende de otros componentes (no necesariamente cdigo fuente) que deben estar disponibles durante la compilacin del componente. Cdigo objeto binario, como por ejemplo una librera, que puede depender de algn cdigo objeto con el que se linkea.

Cdigo ejecutable que puede depender de otros programas ejecutables con los que interacciones en tiempo de ejecucin.

Se pueden utilizar estereotipos como <<link>> o <<compile>> para distinguir la distinta naturaleza de las dependencias. Igualmente se pueden definir estereotipos para las distintas clases de componentes. UML proporciona algunos estereotipos predefinidos como: <<file>>, <<library>>, <<executable>>, <<table>> y document>>.

Diagrama de Despliegue
Un diagrama de despliegue muestra las relaciones fsicas entre los componentes hardware y software en el sistema final, es decir, la configuracin de los elementos de procesamiento en tiempo de ejecucin y los componentes software (procesos y objetos que se ejecutan en ellos). Estarn formados por instancias de los componentes software que representan manifestaciones del cdigo en tiempo de ejecucin (los componentes que slo sean utilizados en tiempo de compilacin deben mostrarse en el diagrama de componentes). Un diagrama de despliegue es un grafo de nodos unidos por conexiones de comunicacin. Un nodo puede contener instancias de componentes software, objetos, procesos (caso particular de un objeto). En general un nodo ser una unidad de computacin de algn tipo, desde un sensor a un mainframe. Las instancias de componentes software pueden estar unidas por relaciones de dependencia, posiblemente a interfaces (ya que un componente puede tener ms de una interfaz).

Figura: Ejemplo de diagrama de ejecucin

Un ejemplo de diagrama de ejecucin es el de la figura 6.2. En este caso se tienen dos nodos, AdminServer y Joe'sMachine. AdminServer contiene la instancia del componente Scheduler y un objeto activo (proceso) denominado meetingsDB. En Joe'sMachine se encuentra la instancia del componente software Planner, que depende de la interfaz reservations, definida por Scheduler (figura 6.1). Un nodo es un objeto fsico en tiempo de ejecucin que representa un recurso computacional, generalmente con memoria y capacidad de procesamiento. Pueden representarse instancias o tipos de nodos que se representa como un cubo 3D en los diagramas de implementacin. Las instancias de componentes de software muestran unidades de software en tiempo de ejecucin y generalmente ayudan a identificar sus dependencias y su localizacin en nodos. Pueden mostrar tambin qu interfaces implementan y qu objetos contienen. Su representacin es un rectngulo atravesado por una elipse y dos rectngulos ms peque nos. Un ejemplo de componente que implementa dos interfaces es el de la figura 6.3.

Figura 6.3: Ejemplo de componente

Los diagramas de despliegue muestran la configuracin en funcionamiento del sistema, incluyendo su hardware y su software. Para cada componente de un diagrama de despliegue se deben documentar las caractersticas tcnicas requeridas, el trfico de red esperado, el tiempo de respuesta requerido, etc. La mayora de las veces el modelado de la vista de despliegue esttica implica modelar la topologa del hardware sobre el que se ejecuta el sistema. Los diagramas de despliegue son fundamentalmente diagramas de clases que se ocupan de modelar los nodos de un sistema. Aunque UML no es un lenguaje de especificacin hardware de propsito general, se ha diseado para modelar muchos de los aspectos hardware de un sistema a un nivel suficiente para que un ingeniero software pueda especificarla plataforma sobre la que se ejecuta el software del sistema y para que un ingeniero de sistemas pueda manejar la frontera entre el hardware y el software cuando se trata de la relacin entre hardware y software se utilizan los diagramas de despliegue para razonar sobre la topologa de procesadores y dispositivos sobre los que se ejecuta el software. Esta vista cubre principalmente la distribucin, entrega e instalacin de las partes que configuran un sistema fsico. Los diagramas de despliegue se suelen utilizar para modelar:

Sistemas empotrados: Un sistema empotrado es una coleccin de hardware con una gran cantidad de software que interacta con el mundo fsico. Los sistemas empotrados involucran software que controla dispositivo (motores, actuadores) que a su vez estn controlados por estmulos externos como sensores. Sistemas cliente-servidor: Los sistemas cliente-servidor son un extremo del espectro de los sistemas distribuidos y requieren tomar decisiones sobre la conectividad de red de los clientes a los servidores y sobre la distribucin fsica de los componentes software del sistema a travs de nodos. Sistemas completamente distribuidos: En el otro extremo encontramos aquellos sistemas que son ampliamente o totalmente distribuidos y que normalmente incluyen varios niveles de servidores Tales sistemas contienen a menudo varias versiones de componentes software, alguno de los cuales pueden incluso migrar de un nodo a otro. El diseo de tales sistemas requiere tomar decisiones que permitan un cambio continuo de la topologa del sistema.

Mecanismos de Extensin Extensiones

Cuando se utiliza un lenguaje de modelado como UML para comunicar conviene ceirse al ncleo del lenguaje para que los modelos no pierdan la capacidad de poder ser entendidos. De todas formas cuando el modelador se encuentre con la necesidad forzosa de expresar algo fuera de los lmites del lenguaje lo debera hacer de forma controlada para no alterar la capacidad de comunicacin. De otra manera, sera imposible para cualquier otro comprender lo que se ha hecho. La forma ms bsica de comunicar conceptos fuera de los lmites de UML es la utilizacin de notas. Las notas permiten capturar comentarios arbitrarios y restricciones que ayuden a clarificar los modelos que se han creado. Con una base ms formal UML proporciona los estereotipos, valores etiquetados y restricciones, permitiendo a nadir nuevos bloques de construccin, crear nuevas propiedades y especificar nueva semntica.

Estereotipos
El concepto inicial de estereotipo (stereotype) se refera a una clasificacin de alto nivel de un objeto que proporciona una idea del tipo de objeto del que se trata. Dicho concepto ha sido recogido en UML para proporcionar un mecanismo de extensin para el propio lenguaje. Este mecanismo hace posible definir UML como un conjunto mnimo de smbolos que podran ser extendidos, cuando fuese necesario, para proporcionar artefactos de modelado que tienen su significado dentro de un proceso software especfico. Mediante la utilizacin de estereotipos se pueden crear nuevos tipos de elementos de modelado basados en los elementos que forman el metamodelo UML, por tanto, un estereotipo ser un nuevo tipo de elemento de modelado que extiende la semntica del metamodelo pero no la estructura de los tipos o clases preexistentes. Algunos estereotipos estn predefinidos en el UML, otros pueden ser definidos por el usuario. Grficamente un estereotipo se representa como un nombre entre comillas <<nombre-estereotipo>>. Opcionalmente el elemento estereotipado se puede dibujar con un nuevo icono asociado al estereotipo.

Figura 7.1: Estereotipo de una clase

Un estereotipo es un metatipo ya que crea una nueva clase en el metamodelo UML. Mediante la creacin de un estereotipo de crea un nuevo bloque de construccin con sus propias caractersticas (puede proporcionar su propio conjunto de valores etiquetados), semntica (puede proporcionar sus propias restricciones), y notacin (puede proporcionar su propio icono). Todas las extensiones realizadas sobre UML se pueden describir como una coleccin de estereotipos que dentro del diagrama de clases sern estereotipos de clases, asociaciones y generalizaciones. Se pueden pensar en los estereotipos como subtipos de los tipos Class, Association y Generalization del metamodelo.

Valores etiquetados
Figura: Valores etiquetados para gestin del proyecto

Un valor etiquetado es una extensin de las propiedades de un elemento de UML, permitiendo a nadir nueva informacin en la especificacin del elemento. Grficamente un valor etiquetado se representa como una cadena de caracteres entre llaves asociada al nombre del elemento. La cadena incluye un nombre (etiqueta), un separador (=), y un valor (de la etiqueta). Todo elemento UML tiene su propio conjunto de propiedades: las clases tienen nombres, atributos y operaciones; las asociaciones tienen nombres y dos o ms extremos, etc. Si con estereotipos podemos a nadir nuevos elementos a UML, con los valores etiquetados podemos a nadir nuevas propiedades. Un valor etiquetado no es lo mismo que un atributo de una clase, sino que ms bien es un metadato ya que su valor se aplica al propio elemento no a sus instancias. Los valores etiquetados se utilizan frecuentemente para modelar la gestin de configuraciones del proyecto. Entre otras cosas esto conlleva llevar el control de los nmeros de versin, del estado

actual y verificacin e incluso de la fecha de creacin. En la figura 7.2 se muestra un diagrama de paquetes con dichos valores etiquetados.

Restricciones
Una restriccin es una extensin de la semntica UML, que permite a nadir nuevas reglas o modificar las existentes. Grficamente, una restriccin se representa como una cadena de caracteres entre llaves colocada junto al elemento al que est asociada o conectada a l por una relacin de dependencia. Una restriccin especfica condiciones que deben cumplirse para que el modelo est bien formado. Las restricciones se pueden escribir como texto libre, o si se quiere especificar la semntica de manera precisa se puede utilizar OCL.

Figura 7.3: Invariante sobre varias asociaciones

En la figura 7.3 se representa una restriccin que refleja una invariante semntica entre las asociaciones persona -miembro -departamento y persona -director -departamento, que indica que el director del departamento debe ser miembro del departamento.

Caractersticas del proceso software Proceso software

En este momento de su evolucin, el UML se reconoce como un lenguaje de modelado, no como una metodologa o un mtodo. La diferencia es que el lenguaje de modelado es una notacin para expresar las ideas de diseo y anlisis orientado a objetos; un mtodo o proceso software seran los consejos o las lneas a seguir a la hora de realizar el anlisis y diseo orientado a objetos. El desarrollo orientado a objetos conlleva anlisis, diseo y programacin orientada a objetos, es decir se utiliza una estrategia orientada a objetos a lo largo de todo el proceso software:

Anlisis orientado a objetos: Tiene que ver con el desarrollo de un modelo orientado a objetos para el dominio de la aplicacin. Los objetos identificados puede que se correspondan directamente con los objetos del sistema o puede que no. Diseo orientado a objetos: Tiene que ver con el desarrollo de un modelo orientado a objetos del sistema software necesario para llevar a cabo los requisitos que se han identificado. Estos requisitos pueden o no haber sido estructurados entorno a los objetos en el dominio del problema. Programacin orientada a objetos: Tiene que ver con la realizacin del diseo software en un lenguaje de programacin orientado a objetos. Un lenguaje de programacin orientado a objetos soporta directamente la implementacin de objetos, clases y herencia.

Figura 8.1: Proceso Paralelo

Figura 8.2: Proceso serie

En la figura 8.1 se representan los diferentes diagramas de UML y sus relaciones. Estas relaciones son el reflejo de la naturaleza interactiva del modelado orientado a objetos. La figura 8.2 muestra una visin serie del proceso software, en donde las lneas representan una relacin ``documentada por''. Estas figuras muestran que el proceso de modelado orientado a objetos es serie a gran escala e iterativo a pequea escala. El nico elemento dentro de UML en el que podemos encontrar la nocin de proceso de ingeniera del software es en la extensin UML Extension for the Objectory Process for Software Engineering. UML por s mismo es slo una notacin, todava necesitamos un proceso ya que el lenguaje de modelado no prescribe ningn proceso. Sin embargo, los autores de UML proponen un proceso software que es: use-case driven, architecture centric, and iterative and incremental. Los tres conceptos son igualmente importantes: la arquitectura proporciona la estructura en la que ``acomoda'' el trabajo asociado a las iteraciones, adems los casos de uso definen los objetivos y guan el trabajo de cada iteracin.

Dirigido por casos de uso

Como ya sabemos un caso de uso es una parte de la funcionalidad del sistema. El modelo de caos de uso, englobando todos los casos de uso del sistema, describe la funcionalidad completa del sistema. Este modelo reemplaza la especificacin funcional tradicional del sistema: ``qu debe hacer el sistema'' por ``qu debe hacer el sistema para cada usuario''. Pero los casos de uso no son slo una herramienta para especificar los requisitos del sistema, sino que tambin guan su diseo, implementacin y testeado, o sea guan el proceso software. Basado en el modelo de casos de uso, los desarrolladores crean modelos de diseo e implementacin que realizan los casos de uso, los desarrolladores revisan cada uno de los modelos creados para comprobar si se corresponden con el modelo de casos de uso especificado. Igualmente los responsables del testeado del sistema comprueban la implementacin para asegurarse de que los componentes del modelo de implementacin implementan correctamente los casos de uso. En este sentido los casos de uso no solo inician el proceso software sino que permanecen ligados a l durante todo el ciclo de vida. Como use case driven entendemos un proceso software cuyo flujo deriva de los caso de uso. Los casos de uso se especifican, se disean y son la base a partir de la cual los testers construyen los casos de test. Aunque es cierto que los caso de uso guan el proceso, no se seleccionan de forma aislada sino que se desarrollan paralelamente con la arquitectura del sistema. Es decir los caso de uso guan la arquitectura del sistema, y la arquitectura del sistema influye en la seleccin de los caso de uso. Despus, tanto la arquitectura del sistema como los casos de uso maduran a medida que el ciclo de vida avanza.

Centrado en la arquitectura
Los casos de uso por si solos no son suficientes. Se necesita algo ms para llegar a un sistema que funcione. Esto ms es la arquitectura. Podemos pensar en la arquitectura como la visin comn que todos los participantes en el proyecto deben compartir y aceptar. La arquitectura nos da una perspectiva clara del sistema global, la cual es necesaria para controlar su desarrollo. El papel de la arquitectura software es el mismo que el papel que juega la arquitectura en la construccin de un edificio. El edificio se ve desde distintos puntos de vista: estructura, servicios, calefaccin, fontanera, electricidad, etc. Esto permite al constructor tener una visin completa del edificio antes de que comience la construccin. De forma similar la arquitectura software se describe en funcin de las diferentes perspectivas del sistema a construir. El concepto de arquitectura software engloba los aspectos dinmicos y estticos ms importantes del sistema. La arquitectura va por tanto ms all de las necesidades reflejadas en los casos de uso e incluye:

Plataformas del software (arquitectura de la mquina, S.O., sistemas de gestin de bases de datos, protocolos de comunicacin). Bloques reusables (franeworks). Consideraciones de desarrollo. Requisitos no funcionales.

La arquitectura es una visin global del sistema pero sin detalles. El arquitecto debera tener como objetivos la comprensin del sistema, capacidad de adaptacin a cambios futuros y reutilizacin. Es importante reiterar que la arquitectura del sistema y su modelo de casos de uso no son independientes: Todo producto tiene funcionalidad (caso de uso) y forma (arquitectura). Ni una ni otra es suficiente por si sola. Se necesita una interrelacin, por un lado los casos de uso se deben ajustar a la arquitectura y adems la arquitectura debe permitir la realizacin de los casos de uso requeridos ahora y en el futuro. Ambas caractersticas del sistema (funcionalidad y forma) deben evolucionar en paralelo. El arquitecto debe disear una arquitectura que permita la evolucin no slo en el desarrollo actual sino en modificaciones futuras. Para encontrarla el arquitecto debe trabajar desde una comprensin general de las funciones claves del sistema, que pueden no ser ms que un 10% por ciento del total de los casos de uso pero deberan ser los ms significativos. Es decir, se deben tener en cuenta aquellos casos de uso que constituyen el ncleo de las funciones del sistema. Entre las responsabilidades del arquitecto encontramos:

Crear un perfil bsico de la arquitectura empezando por la parte de la arquitectura que no es especfica de los casos de uso (plataforma) basndose en un conocimiento general de la funcionalidad bsica del sistema.

Despus el arquitecto debe trabajar con un subconjunto de los casos de uso identificados (los claves). Cada uno de estos casos de uso se especifica en detalle y se realiza en base a subsistemas. A medida que los casos de uso se especifican y maduran se descubre ms acerca de la arquitectura lo que a su vez lleva a la madurez de ms casos de uso. Este proceso continua hasta que la arquitectura es estable.

Iterativo e incremental
Dado que los proyectos software son largos es comn dividir el trabajo en mini proyectos. Cada mini proyecto es una iteracin que resulta en un incremento. Las iteraciones se refieren a pasos en el flujo de trabajo, y los incrementos a un crecimiento en el producto. Para ser ms efectivas las iteraciones deben ser controladas, es decir deben ser seleccionadas y llevadas a cabo de una forma planeada, de forma que cada una de las iteraciones constituye un mini proyecto software. Los desarrolladores basan la seleccin de las tareas a abordar en cada iteracin partiendo de dos factores: la iteracin maneja un grupo de casos de uso que extienden la utilidad del producto, adems las iteraciones tratan siempre con los riesgos ms altos en el estado actual del proyecto. Pero el desarrollo iterativo no es dividir, sino que las sucesivas iteraciones se construyen a partir de los artefactos en el estado en que fueron dejados en las iteraciones precedentes. Cada iteracin, considerada como un mini proyecto, a partir de los casos de uso aborda el anlisis, diseo, implementacin y test. Por supuesto, un incremento no es necesariamente aditivo, ya que, especialmente en las primeras fases del ciclo de vida, los desarrolladores pueden estar reemplazando un diseo superficial por un diseo ms detallado. En las fases posteriores los incrementos suelen ser aditivos. En cada iteracin los desarrolladores analizan las casos de uso relevantes, crean un diseo utilizando como gua la arquitectura elegida, e implementan el diseo en componentes verificando que dichos componentes aportan la funcionalidad especificada en los caso de uso. Si una iteracin cumple sus objetivos el proceso contina con la siguiente iteracin, por contra, si una iteracin no cumple sus objetivos los desarrolladores deben revisar las decisiones previas e intentar una nueva aproximacin. Para alcanzar el mayor rendimiento un proyecto debera proceder casi siempre a lo largo de su curso directo con solo pequeas desviaciones del curso inicialmente planeado. Por supuesto, desde el momento que problemas imprevistos a nadan iteraciones o alteren la secuencia planeada, el proceso requerir un mayor esfuerzo y tiempo del calculado a priori. Minimizar los imprevistos es uno de los objetivos de la reduccin de riesgos. Podemos resumir los beneficios de asumir un proceso iterativo controlado en:

La iteracin controlada reduce los riesgos de coste a los de una iteracin. Si es necesario repetir una iteracin solo se pierde el esfuerzo de una iteracin y no el valor del producto completo. Reduce el riesgo de no tener el producto en el mercado en la fecha de entrega pactada al comienzo del proyecto. Mediante la planificacin de los riesgos ms altos en las primeras fases del desarrollo, el tiempo consumido en resolverlos se invierte al principio del proceso cuando el equipo est menos apresurado que cerca de la fecha de entrega. En la aproximacin tradicional al proceso software (cascada), cuando durante el testeado del producto se descubre problemas graves el tiempo necesario para resolverlos excede el tiempo disponible y conlleva un retardo en la entrega. Acelera el ritmo del esfuerzo de desarrollo global ya que los desarrolladores trabajan de forma ms eficiente cuando ven objetivos a corto plazo. Acepta una realidad a menudo ignorada, las necesidades de los usuarios y por tanto los requisitos no se pueden definir completamente desde el principio, sino que son refinados en iteraciones sucesivas. Un enfoque iterativo es fcilmente adaptable a cambios en el entorno.

Libros

``UML in a Nutshell''. Sinan si Alhir. Ed. OReilly. 1998. ``UML gota a gota''. Martin Fowler. Ed. Prentice hall. 1999. ``UML Toolkit''. Eriksson & Penker. Ed. John Wiley. 1998. ``Using UML: Software Engineering with objects and components''. Perdita Stevens. Ed. Addison Wesley. 2000. ``El Lenguaje Unificado de Modelado''. Grady Booch, james Rumbaugh, Ivar Jacobson. Ed. Addison Wesley. 1999. ``UML y Patrones''. Craig Larman. Ed. Prentice Hall. 1999. ``The Unified software Development Process". Grady Booch, James Rumbaugh, Ivar Jacobson. Ed. Addison Wesley. 1999. ``Visual Modeling with Rational Rose and UML''. Terry Quatrani. Ed. Addison Wesley. 1998. ``OPEN modeling with UML''. Brian Henderson-Sellers, Bhuvan Unhelkar. Ed. Addison Wesley. 2000.

Enlaces

UML-OMG. http://www.omg.com Popkin Software. http://www.popkin.com/products/sa2001/object/component.htm. UML Forum. http://www.celigent.com/uml. Softera UML. http://www.softera.com. Cetus Links UML. http://www.cetus-links.org/oo_uml.html. Objects by Design: UML Modeling http://www.objectsbydesign.com/tools/umltools_byCompany.html. UML Center Computer Associates. http://www.platinum.com/corp/uml/uml.htm. Rational. http://www.rational.com. Softeam. http://www.objecteering.com. TogetherSoft. http://www.togethersoft.com. The UML Bibliography .http://www.db.informatik.uni-bremen.de/umlbib Software Development Online - SD http://www.sdmagazine.com/features/uml Online's UML Resource Center. Tools.