Lenguaje Unificado de ModeladoDe Wikipedia, la enciclopedia libre(Redirigido desde UML) Saltar a navegacin, bsqueda Lenguaje Unificado de Modelado (UML, por sus siglas en ingls, Unified Modeling Language) es el lenguaje de modelado de sistemas de software ms conocido y utilizado en la actualidad; est respaldado por el OMG (Object Management Group). Es un lenguaje grfico para visualizar, especificar, construir y documentar un sistema de software. UML ofrece un estndar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocios y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programacin, esquemas de bases de datos y componentes de software reutilizables. Es importante resaltar que UML es un "lenguaje" para especificar y no para describir mtodos o procesos. Se utiliza para definir un sistema de software, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que est descrito el modelo. Se puede aplicar en una gran variedad de formas para dar soporte a una metodologa de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en s mismo qu metodologa o proceso usar. UML no puede compararse con la programacin estructurada, pues UML significa (Lengua de Modelacin Unificada), no es programacin, solo se diagrama la realidad de una utilizacin en un requerimiento. Mientras que, programacin estructurada, es una forma de programar como lo es la orientacin a objetos, sin embargo, la orientacin a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML slo para lenguajes orientados a objetos UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas.

Contenido[ocultar]1 2

Diagramas Software para modelado en UML o2.1 Software Libre o2.2 Freeware para modelado en UML o2.3 Otro software 3 Estandarizacin de UML 4 Crticas a UML 5 Vase tambin 6 Referencias7

Enlaces externos

Diagramas [editar]

Jerarqua de los diagramas UML 2.0, mostrados como un diagrama de clases En UML 2.0 hay 13 tipos diferentes de diagramas. Para comprenderlos de manera concreta, a veces es til categorizarlos jerrquicamente, como se muestra en la figura de la derecha. Los Diagramas de Estructura enfatizan en los elementos que deben existir en el sistema modelado:Diagrama de Diagrama de Diagrama de Diagrama de Diagrama de Diagrama de

clases componentes objetos estructura compuesta (UML 2.0) despliegue paquetes

Los Diagramas de Comportamiento enfatizan en lo que debe suceder en el sistema modelado:Diagrama de Diagrama de Diagrama de

actividades casos de uso estados

Los Diagramas de Interaccin son un subtipo de diagramas de comportamiento, que enfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado:Diagrama de Diagrama de Diagrama de Diagrama de

secuencia colaboracin tiempos (UML 2.0) vista de interaccin (UML 2.0)

Software para modelado en UML [editar]A continuacin, se listan algunos de los programas ms populares para el modelado en UML

Software Libre [editar]Estos programas estn bajo licencias libres, siendo posible su libre uso, estudio y modificacin.ArgoUML, Herramienta de modelado UML escrito en Java (enlace externo) BOUML, Ligera herramienta de modelado UML y generacin de cdigo C++,

Java e IDL. Disponible para Windows, Unix/Linux y Mac OS X (Sitio Oficial) Fujaba, No solo sirve para modelar sino que puede generar cdigo Java automticamente. Tambin es capaz de hacer ingeniera inversa y crear los diagramas a partir del cdigo Java [1]. Dia Puede ser usado para modelar varios tipos de diagramas UML (enlace externo) gModeler Herramienta para modelado de UML basada en Flash (utilizable desde el navegador), que permite generar cdigo Action Script 2.0 Compatible (enlace externo) MonoUML Herramienta CASE para la plataforma mono (Sitio Oficial) Papyrus, Herramienta grfica basada en Eclipse para el modelado con UML2, es de cdigo abierto y se ofrece bajo licencia EPL (Sitio Oficial) StarUML Herramienta de modelado para Windows desarrollada en Delphi. Bastante estable y utilizable (enlace externo) TCM, Toolkit for Conceptual Modeling, herramienta para crear diversos tipos de diagramas incluidos UML [http://wwwhome.cs.utwente.nl/~tcm/ Web oficial) Umbrello Herramienta para modelado UML para el entorno KDE (enlace externo) UMLet Herramienta para modelado rpido de UML tambin escrita en Java (enlace externo) Netbeans mdulo UML

Freeware para modelado en UML [editar]Aunque gratuitos, estos programas se encuentran bajo licencias que no permiten el estudio y modificacin de los mismos.JUDE Community Herramienta de modelado UML (Sitio Oficial) Omondo plugin para Eclipse. Herramienta de modelado UML para Java Oracle JDeveloper Un IDE para Java con soporte de diagramas UML Visual Paradigm for UML, Herramienta de modelado UML y herramienta

CASE que cuenta con una versin gratuita denominada Community Edition (enlace externo)

Otro software [editar]Software comercial de modelado UML:Enterprise Architect de Sparx Systems Borland Together Corel iGrafx Microsoft Visio PowerDesigner de Sybase Rational Rose de IBM Poseidon for UML de GentleWare MagicDraw UML

Estandarizacin de UML [editar]Adems de haberse convertido en un estndar de facto, UML es un estndar industrial promovido por el grupo OMG al mismo nivel que el estndar CORBA para intercambio de objetos distribuidos. Para la revisin de UML se formaron dos "corrientes" que promovan la aparicin de la nueva versin desde distintos puntos de vista. Finalmente se impuso la visin ms industrial frente a la acadmica. Recientemente se ha publicado la versin 2.0 en la que aparecen muchas novedades y cambios que, fundamentalmente, se centran en resolver carencias prcticas. Adems, esta versin recibe diversas mejoras que provienen del lenguaje SDL.

Crticas a UML [editar]A pesar de su status de estndar ampliamente reconocido y utilizado, UML siempre ha sido muy criticado por su carencia de una semntica precisa, lo que ha dado lugar a que la interpretacin de un modelo UML no pueda ser objetiva. Otro problema de UML es que no se presta con facilidad al diseo de sistemas distribuidos. En tales sistemas cobran importancia factores como transmisin, serializacin, persistencia, etc. UML no cuenta con maneras de describir tales factores. No se puede, por ejemplo, usar UML para sealar que un objeto es persistente o remoto, o que existe en un servidor que corre continuamente y que es compartido entre varias instancias de ejecucin del sistema analizado. Sin embargo, UML si acepta la creacin de nuestros propios componentes para este tipo de modelado. Object Management Group

Vase tambin [editar]Entorno de desarrollo integrado Herramienta CASE Tcnica de Modelado a Objetos Programacin orientada a objetos XMI, un formato estndar basado en XML para el intercambio de modelos OCL, Lenguaje de especificacin para los diferentes modelos en UML. Webml, Metodologa para el diseo de Sistemas de Informacin Web.

UML.

Referencias [editar]Martin

fowler, kendall sccott, "UML Gota a Gota", 1999.

Enlaces externos [editar]Grupo Oficial del lenguaje Modelado - (En Ingles) Especificacin oficial (En Ingles) UML Jokes (En Ingles) Introduccin a UML 2.0 (En Castellano) Introduccin a UML 2.0 Parte II (En Castellano) Introduccin a UML 2.0 (En ingls) Amplia informacin sobre UML (En ingls) Base de conocimiento de UML (En Castellano) Centro de recursos de UML abierto a la comunidad

(En Castellano

http://www.epidataconsulting.com/tikiwiki/tiki-read_article.php?articleId=15Introduccin a UML 2.0

Introduccin a UML 2.0La evolucin de la programacin hacia la ejecucin y validacin automtica de modelos Por: Quirn en: Mar 04 of Oct, 2005 [20:30 UTC] (72825 lecturas)

En este artculo nos introduciremos al mundo del diseo de aplicaciones de software a travs de su puerta ms novedosa: UML 2.0.

(19832 bytes)Tabla de Contenidos

Introduccin Conociendo UML 2.0 oObjetivos del UML 2.0 oEl UML y la Industria del Software oConceptos bsicos sobre UML o(Muy) Breve Resea Histrica oEl Nuevo Enfoque del UML 2.0 Reestructuracin del Lenguaje OCL Especificacin para el Intercambio de Diagramas Infraestructura Superestructura oLa Superestructura del UML Organizacin de la superestructura Diagramas de Estructura y Diagramas de comportamiento Breve descripcin sobre los diagramas oConclusin Cmo sigo? Bibliografa

IntroduccinAl momento de desarrollar el nuevo estndar 2.0 de UML, la OMG se plante, entre otros, dos objetivos que podramos considerar principales, debido a la influencia de stos en la nueva versin del estndar: 1.Hacer el lenguaje de modelado ms extensible. 2.Permitir la validacin y ejecucin de modelos. En el presente artculo, se muestran los principales cambios en UML 2.0, cmo stos influyen en los objetivos planteados anteriormente, la nueva estructura de UML 2.0, los nuevos diagramas y los cambios ms importantes en los diagramas preexistentes. La evolucin de la programacin hacia la ejecucin y validacin automtica de modelos

Conociendo UML 2.0En este artculo nos introduciremos al mundo del diseo de aplicaciones de software, a travs de su puerta ms novedosa: UML 2.0. ste es el comienzo de una serie de artculos en los que iremos, poco a poco, conociendo el UML 2.0 en detalle. En el presente trabajo, nos enfocaremos en el lenguaje propiamente dicho; su historia, estructura, cambios y objetivos de mayor influencia, en esta nueva y radical versin.

Objetivos del UML 2.0Al momento de desarrollar el nuevo estndar 2.0 del UML, la OMG se propuso, entre otros, dos objetivos que podramos considerar principales debido a la influencia de stos en la versin final del estndar. Estos objetivos son: 1.Hacer el lenguaje de modelado mucho ms extensible de lo que era. 2.Permitir la validacin y ejecucin de modelos creados mediante el UML. UML 2.0 se desarrolla sobre la base de estos dos objetivos, causando un quiebre respecto a versiones anteriores. Para entender la razn del quiebre y el por qu de esta evolucin tan marcada, nos profundizaremos un poco en la historia y definicin misma del UML.

El UML y la Industria del SoftwareEl UML se ha vuelto el estndar de facto (impuesto por la industria y los usuarios) para el modelado de aplicaciones de software. En los ltimos aos, su popularidad trascendi al desarrollo de software y, en la actualidad, el UML es utilizado para modelar muchos otros dominios, como por ejemplo el modelado de procesos de negocios.

Conceptos bsicos sobre UMLUML son las siglas para Unified Modeling Language, que en castellano quiere decir: Lenguaje de Modelado Unificado. Para comprender qu es el UML, basta con analizar cada una de las palabras que lo componen, por separado.

Lenguaje: el UML es, precisamente, un lenguaje. Lo que implica que ste cuenta con unasintaxis y una semntica. Por lo tanto, al modelar un concepto en UML, existen reglas sobre cmo deben agruparse los elementos del lenguaje y el significado de esta agrupacin. Modelado: el UML es visual. Mediante su sintaxis se modelan distintos aspectos del mundo real, que permiten una mejor interpretacin y entendimiento de ste. Unificado: unifica varias tcnicas de modelado en una nica. Ya que el UML proviene de tcnicas orientadas a objetos, se crea con la fuerte intencin de que este permita un correcto modelado orientado a objetos.

(Muy) Breve Resea HistricaLas races del UML provienen de tres mtodos distintos. El mtodo de Grady Booch, la Tcnica de Modelado de Objetos de James Rumbaugh y Objetory, de Ivar Jacobson. Conocidas estas tres personalidades como los tres amigos. En 1994 Booch, Rumbaugh y Jacobson dieron forma a la primera versin del UML y en 1997 fue aceptado por la OMG, fecha en la que fue lanzada la versin v1.1 del UML. Desde entonces, UML atraves varias revisiones y refinamientos hasta llegar a la versin actual: UML 2.0. Qu es la OMG? La OMG (Object Management Group) es una asociacin sin fines de lucro formada por grandes corporaciones, muchas de ellas de la industria del software, como por ejemplo: IBM, Apple Computer, Sun Microsystems Inc y Hewlett-Packard?. Esta asociacin se encarga de la definicin y mantenimiento de estndares para aplicaciones de la industria de la computacin. Otro de los estndares definidos por la OMG, adems del UML, es CORBA, el cual permite interoperabilidad multiplataforma a nivel de objetos de negocio. Podemos encontrar ms informacin sobre la OMG en su sitio oficial: http://www.omg.org/ Es importante destacar que, a lo largo de estas constantes revisiones, muchas tcnicas existentes fueron agregadas a UML. Esta constante ampliacin del lenguaje hizo que el UML fuera perdiendo identidad, convirtindose en una agrupacin de distintas tcnicas de modelado, sin demasiada cohesin entre ellas. Esto transform al UML en un lenguaje sin identidad y, en muchos puntos, ambiguo o falto de coherencia conceptual.

El Nuevo Enfoque del UML 2.0En las versiones previas del UML, se haca un fuerte hincapi en que UML no era un lenguaje de programacin. Un modelo creado mediante UML no poda ejecutarse. En el UML 2.0, esta asuncin cambi de manera drstica y se modific el lenguaje, de manera tal que permitiera capturar mucho ms comportamiento (Behavior). De esta forma, se permiti la creacin de herramientas que soporten la automatizacin y generacin de cdigo ejecutable, a partir de modelos UML. Estndares que conforman el UML

Superestructura: Es la especificacin que usamos todos los das. Aqu se encuentran todos losdiagramas que la mayora de los desarrolladores conocen.

Infraestructura: Conceptos de bajo nivel. Meta-Modelo da soporte a la superestructura, entreotras.

OCL: Lenguaje de restriccin. De utilidad para especificar conceptos ambiguos sobre los distintoselementos del diagrama.

XMI / Intercambio de diagramas: Permite compartir diagramas entre diferentes herramientas demodelado UML.

Reestructuracin del LenguajePara lograr los objetivos enunciados, varios aspectos del lenguaje fueron reestructurados y/o modificados. La especificacin se separ en cuatro especificaciones (paquetes) bien definidas, tal como se muestra en la Figura 1. Es interesante destacar que el UML 2.0 puede definirse a s mismo. Es decir, su estructura y organizacin es modelable utilizando el propio UML 2.0; de esta manera, se da un ejemplo de utilizacin del UML en un dominio distinto al del desarrollo de software. En este caso, cada paquete del diagrama representa cada una de las cuatro especificaciones que componen el lenguaje. ::

:: Figura 1: Especificaciones principales del UML 2.0 Veamos a continuacin, un poco ms en detalle cada una de las principales especificaciones que componen UML 2.0. No nos explayaremos demasiado, debido a que en futuras ediciones habr oportunidad de profundizar en cada una de ellas.

OCLOCL son siglas en ingls que significan: Object Constraint Language y que en castellano se traducen como: Lenguaje de Restricciones de Objetos. El OCL define un lenguaje simple, para escribir restricciones y expresiones sobre elementos de un modelo. El OCL suele ser til cuando se est

especificando un dominio particular mediante el UML y es necesario restringir los valores permitidos para los objetos del dominio. El OCL brinda la posibilidad definir en los elementos de un diagrama, entre otros: invariantes, precondiciones, poscondiciones y restricciones. El OCL fue incorporado al UML en la versin 1.1. El OCL fue originalmente especificado por IBM y es un ejemplo ms de las muchas herramientas agregadas al UML.

Especificacin para el Intercambio de DiagramasLa especificacin para el intercambio de diagramas fue escrita para facilitar una manera de compartir modelos, realizados mediante UML, entre diferentes herramientas de modelado. En versiones anteriores del UML, se utilizaba un Schema XML para capturar los elementos utilizados en el diagrama; pero este Schema no deca nada acerca de la manera en que el modelo deba graficarse. Para solucionar este problema, la nueva especificacin para el intercambio de diagramas fue desarrollada utilizando un nuevo Schema XML, que permite construir una representacin SVG (Scalable Vector Graphics). Esta especificacin es denominada con las siglas XMI, que en ingls significa: XML Metadata Interchange; y en castellano se traduce como: XML de Intercambio de Metadata (datos que representan datos). Tpicamente esta especificacin es solamente utilizada por quienes desarrollan herramientas de modelado UML.

InfraestructuraEn la Infraestructura del UML se definen los conceptos centrales y de ms bajo nivel. La Infraestructura es un meta-modelo (un modelo de modelos) y mediante la misma se modela el resto del UML. Generalmente, la infraestructura no es utilizada por usuarios finales del UML; pero provee la piedra fundamental sobre la cual la Superestructura es definida. Esta ltima s es la utilizada por el comn de los usuarios. La Infraestructura brinda tambin varios mecanismos de extensin, que hacen del UML un lenguaje configurable. Para los usuarios normales del UML basta con saber si la infraestructura existe y cules son sus objetivos.

SuperestructuraLa superestructura del UML es la definicin formal de los elementos del UML. Esta definicin sola contiene ms de 640 pginas. La superestructura es tpicamente utilizada por los desarrolladores de aplicacin. Es aquella sobre la que hablan los libros y la que la mayora conoce de versiones anteriores del UML.

La Superestructura del UMLEs en la Superestructura donde encontramos los cambios que ms afectan en el da a da a quienes trabajan como desarrolladores de aplicaciones de negocios, es decir, profesionales que, en general, deben interpretar o crear modelos que especifiquen el dominio de tales aplicaciones. Es aqu dnde se definen los diagramas y los elementos que los componen. La Superestructura se encuentra dividida en niveles. Estos niveles se conocen como:

Bsico (L1): Contiene los elementos bsicos del UML 2.0, entre ellos: Diagramas de clases,Diagramas de actividades, Diagramas de Interacciones, y Diagramas de Casos de Uso

Intermedio (L2): Contiene los siguientes diagramas: Diagramas de estado, Perfiles, Diagramasde Componentes y Diagramas de despliegue.

Completo (L3): Representa la especificacin del UML 2.0 completa, como por ejemplo: lasAcciones, Caractersticas avanzadas y PowerTypes? entre otros. Es importante destacar que basta con que una herramienta implemente el nivel de conformidad Bsico (L1), para que se considere UML 2.0 compatible. Por eso, es normal ver una disparidad de caractersticas (features) bastante amplia entre dos herramientas distintas, aunque stas sean UML 2.0 compatibles.

Organizacin de la superestructuraEl bloque de construccin bsico del UML es un diagrama. La estructura de los diagramas UML est reflejado por el diagrama de la figura 2, de acuerdo con la especificacin del UML 2.0 del Object Development Group. Los detalles sobre estos diagramas especficos se organizan de acuerdo a esta estructura taxonmica, que da la perspectiva a los diagramas y a sus interrelaciones. Los diagramas de interaccin comparten propiedades y atributos similares, como lo hacen los diagramas estructurales

y de comportamiento. En color azul se distinguen aquellos diagramas que aparecen en esta versin del UML.

Figura 2: Estructura taxonmica del UML 2.0

Diagramas de Estructura y Diagramas de comportamientoLos diagramas estructurales representan elementos y as componen un sistema o una funcin. Estos diagramas pueden reflejar las relaciones estticas de una estructura, como lo hacen los diagramas de clases o de paquetes, o arquitecturas en tiempo de ejecucin, tales como diagramas de Objetos o de Estructura de Composicin. Los diagramas de comportamiento representan las caractersticas de comportamiento de un sistema o proceso de negocios y, a su vez, incluyen a los diagramas de: actividades, casos de uso, maquinas de estados, tiempos, secuencias, repaso de interacciones y comunicaciones.

Breve descripcin sobre los diagramasEn beneficio de quienes quieran seguir investigando dentro del mundo UML, en el siguiente cuadro se muestra la importancia que tiene, para un desarrollador, conocer cada una de las nuevas caractersticas del UML 2.0. Sobre esta premisa, ampliaremos la explicacin de cada diagrama en las prximas ediciones, dando ms importancia a los diagramas que figuran con mayor prioridad en el cuadro.

Diagrama Diagrama de Clases

Descripcin Prioridad Muestra una coleccin de elementos de modelado declarativo Alta (estticos), tales como clases, tipos y sus contenidos y relaciones. Diagrama de Representa los componentes que componen una aplicacin, Media Componentes sistema o empresa. Los componentes, sus relaciones, interacciones y sus interfaces pblicas. Diagrama de Estructura Representa la estructura interna de un clasificador (tal como Baja de Composicin una clase, un componente o un caso de uso), incluyendo los puntos de interaccin de clasificador con otras partes del sistema. Diagrama de Despliegue Un diagrama de despliegue fsico muestra cmo y dnde se Media Fsico desplegar el sistema. Las mquinas fsicas y los procesadores se representan como nodos y la construccin interna puede ser representada por nodos o artefactos embebidos. Como los artefactos se ubican en los nodos para modelar el despliegue del sistema, la ubicacin es guiada por el uso de las especificaciones de despliegue.

Diagrama de Objetos

Un diagrama que presenta los objetos y sus relaciones en un Baja punto del tiempo. Un diagrama de objetos se puede considerar como un caso especial de un diagrama de clases o un diagrama de comunicaciones. Diagrama de Paquetes Un diagrama que presenta cmo se organizan los elementos Baja de modelado en paquetes y las dependencias entre ellos, incluyendo importaciones y extensiones de paquetes. Diagrama de Actividades Representa los procesos de negocios de alto nivel, incluidos el Alta flujo de datos. Tambin puede utilizarse para modelar lgica compleja y/o paralela dentro de un sistema. Diagrama de Es un diagrama que enfoca la interaccin entre lneas de vida, Baja Comunicaciones donde es central la arquitectura de la estructura interna y (anteriormente: cmo ella se corresponde con el pasaje de mensajes. La Diagrama de secuencia de los mensajes se da a travs de un esquema de colaboraciones) numerado de la secuencia. Diagrama de Revisin de Los Diagramas de Revisin de la Interaccin enfocan la Baja la Interaccin revisin del flujo de control, donde los nodos son Interacciones u Ocurrencias de Interacciones. Las Lneas de Vida los Mensajes no aparecen en este nivel de revisin Diagrama de Secuencias Un diagrama que representa una interaccin, poniendo el foco Alta en la secuencia de los mensajes que se intercambian, junto con sus correspondientes ocurrencias de eventos en las Lneas de Vida. Diagrama de Mquinas Un diagrama de Mquina de Estados ilustra cmo un Media de Estado elemento, muchas veces una clase, se puede mover entre estados que clasifican su comportamiento, de acuerdo con disparadores de transiciones, guardias de restricciones y otros aspectos de los diagramas de Mquinas de Estados, que representan y explican el movimiento y el comportamiento. Diagrama de Tiempos El propsito primario del diagrama de tiempos es mostrar los Baja cambios en el estado o la condicin de una lnea de vida (representando una Instancia de un Clasificador o un Rol de un clasificador) a lo largo del tiempo lineal. El uso ms comn es mostrar el cambio de estado de un objeto a lo largo del tiempo, en respuesta a los eventos o estmulos aceptados. Los eventos que se reciben se anotan, a medida que muestran cundo se desea mostrar el evento que causa el cambio en la condicin o en el estado. Diagrama de Casos de Un diagrama que muestra las relaciones entre los actores y el Media Uso sujeto (sistema), y los casos de uso.

ConclusinA lo largo del artculo hemos analizado los objetivos y el impacto de stos en la versin 2.0 del UML. Analizamos la estructura del UML 2.0, su conformacin interna y la divisin taxonmica de sus diagramas.

Cmo sigo?Recomendamos leer el siguiente artculo, el cual es la continuacin del presente: El Poder Semntico del UML 2.0 en la Prctica donde se muestran los cambios ms importantes en el Lenguaje Unificado de Modelado, desde el punto de vista del desarrollador, mediante ejemplos.

BibliografaLibros recomendados: Hemos revisado varios libros dedicados a la superestructura del UML 2.0. Entre ellos el que parece ser ms destacable es: UML 2.0 in a Nutshell.

UML 2.0 in a Nutshell de Dan Pilone y Neil PitmanExcelente referencia para el trabajo diario. La introduccin terica es un poco superficial, debido a que el foco del libro es la superestructura. El libro puede ser til tanto a expertos UML como para quienes recin se inician.

UML 2 for Dummies de Michael J. Chonoles y James A. SchardtLibro de muy fcil lectura con una introduccin terica adecuada. El tratamiento de los temas podra ser un poco ms amplio, ya que el libro apunta a personas sin conocimiento del UML.

Fast Track UML 2.0 de Kendall Scott y ApressLibro totalmente orientado a la superestructura. La introduccin conceptual terica a los nuevos aspectos del UML 2.0 es bastante superficial y carece de un hilo conductor en cuanto a la organizacin de los temas. A pesar de esto, los distintos diagramas estn bien explicados Otros libros recomendados de Orientacin a Objetos: Para quien quiera una excelente introduccin terica al mundo del diseo orientado objetos, dejamos estas recomendaciones:

"Designing Object-Oriented? Software" de Rebecca Wirfs-Brock?, Brian Wilkerson y LaurenWiener Si le preguntan a alguien que trabaje con objetos sobre un libro de diseo orientado a objetos, seguramente les recomiende este libro

"Smalltalk Objects, and Design (Paperback)" de Chamond LiuOtro excelente libro de diseo OO. Un poco ms orientado a Smalltalk, pero conceptualmente completo.

Object-oriented Systems Analysis and Design Using UML de Simon Bennett, Steve McRobb? yRay Farmer. Un libro que combina teora de objetos y UML, con un enfoque un poco ms prctico. Herramientas A continuacin, nombramos algunas herramientas que soportan UML 2.0. Dado que no todas tienen el mismo nivel de conformidad, el nivel ms alto a la fecha lo tiene Enterprise Architect.

Enterprise Architect Altova UModel 2005 Together Rational Software Architect Embarcadero Describe

http://www.sparxsystems.com/ http://www.altova.com/umodel/ http://www.borland.com/together/designerce/index.html http://www-306.ibm.com/software/rational/ http://www.embarcadero.

El Poder Semntico del UML 2.0 en la Prctica

El Poder Semntico del UML 2.0 en la PrcticaCmo sacar provecho de las nuevas caractersticas de UML 2.0? Por: Quirn en: Vie 17 of Feb, 2006 [16:07] (37139 lecturas) Donde daremos una resea con los cambios fundamentales en el Lenguaje Unificado de Modelado desde el punto de vista del desarrollador promedio.

(20758 bytes)Tabla de Contenidos

Introduccin Nuevas caractersticas de los diagramas UML 2.0 oLa Superestructura de UML 2.0 Cambios estructurales oDiagramas de Composicin de Estructuras (Nuevo Diagrama) Diseando la Estructura Interna de Mi PC Mediante un Diagrama deClases

Cambios Particulares en los Diagramas Estructurales oDiagrama de Clases oDiagramas de Despliegue Artefactos (Artifacts) Especificaciones de Despliegue (Deployment Specifications) oDiagramas de Componentes (Components Diagram) Cambios en los Diagramas de Comportamiento oDiagramas de Caso de Uso Estructuras Compuestas Extensiones oLos Diagramas de Actividades oDiagramas de Mquina de Estados Diagramas de Interaccin oLos Diagramas de secuencias Fragmentos Combinados oOperadores de Interaccin (Interaction Operators) oDiagramas de Revisin de interacciones (Nuevo Diagrama) oDiagramas de Comunicacin (Ex diagramas de colaboracin) oDiagrama de Tiempos (Nuevo Diagrama) Lo que qued afuera Conclusin

IntroduccinEn esta entrega nos concentraremos en detallar las nuevas caractersticas de los diagramas de mayor importancia, dentro de UML 2.0, para el desarrollador comn. Haremos fuerte hincapi en los diagramas estructurales, en especial los diagramas de clases, y describiremos someramente los diagramas de actividades y de secuencia. Se recomienda primero, a modo de introduccin, leer el artculo Introduccin a lo nuevo de UML 2.0

Nuevas caractersticas de los diagramas UML 2.0Haremos mayor hincapi en aquellos diagramas que figuran como "de mayor prioridad", enumerando de manera somera los cambios en los diagramas de menor prioridad.

La Superestructura de UML 2.0La superestructura del UML es la definicin formal de los elementos que componen el UML 2.0. ste se encuentra organizado en paquetes, que definen los elementos internos del UML y de qu manera se relacionan. La figura 1 muestra esta estructura.

Figura 1: Organizacin Interna de la Superestructura

Cambios estructuralesComo puede observarse, el diseo interno del UML 2.0 se encuentra orientado a objetos. Para entender qu significado tiene esta idea, podemos hacernos preguntas tales como: Qu tienen en comn los diagramas de clases, las colaboraciones, los componentes y los paquetes? Algunas de las caractersticas en comn que podemos encontrar son: todos tienen elementos (por llamarlos de algn modo), que se asocian los unos a los otros mediante relaciones; el significado de las mismas puede depender del diagrama. Esta es una buena aproximacin. Ahora, si lo pensamos un poco ms, todos estos elementos pueden tener propiedades, estereotipos, restricciones, tagged values, etc. Si tuviramos que modelar esto, mediante un diagrama de clases, es dado a pensar que ste se vera como indica la Figura 2. Y, efectivamente, es as como se ve internamente en la superestructura de UML 2.0; slo que, los elementos, se llaman en realidad Clasificadores. Esto quiere decir que, si tenemos una Clase llamada -por ejemplo- Astronauta, sta es una instancia de un clasificador (en este caso, el clasificador clase), y no es la clase particular Astronauta un Clasificador. Basicamente un Clasificador es a una Clase, lo que una Clase es a un Objeto. Los clasificadores tienen otras caractersticas muy interesantes, tiles a los objetivos del UML 2.0. Veamos

Diagramas de Composicin de Estructuras (Nuevo Diagrama)Los diagramas de composicin de estructuras (Composite Structures Diagram) fueron especficamente diseados para la representacin de patrones de diseo, y son una de las modificaciones de mayor impacto dentro de UML 2.0. Esta modificacin al UML hace que ahora todos los Clasificadores puedan tener una estructura compuesta. Mediante una composicin de estructuras, el comportamiento de las instancias de otros Clasificadores contenidos (estructura interna) en un Clasificador determinado, puede especificarse como Colaboraciones. Los conceptos principales para describir la estructura interna son: Partes, Puertos y Conectores.

Diseando la Estructura Interna de Mi PC Mediante un Diagrama de ClasesPara describir cada uno de estos nuevos elementos tomaremos un ejemplo: Supongamos que deseamos modelar el concepto PC simplificada. Esta PC consta slamente de teclado y monitor; tambin sabemos que, internamente, una PC cuenta con una placa de video, la cual se encarga de enviar informacin al exterior a travs de la interfaz de video. En la figura 3 mostramos el diseo, utilizando la nueva notacin de UML 2.0. La misma incluye los siguientes nuevos artefactos:

Partes (parts): Una parte es una propiedad contenida en un clasificador. Una parte vive y mueresiguiendo el mismo ciclo de vida que el objeto que lo contiene. En nuestro ejemplo, la placa de Video es parte de la PC. Hay que tener en cuenta que esto implica que la placa de video no puede cambiarse, debido a que respeta el mismo ciclo de vida que la PC. Puertos (ports): Un puerto describe un punto de interaccin para un clasificador. Los puertos son conocidos, esto significa que se le pueden enviar mensajes. Un puerto puede tener una interfaz requerida (necesarias para la clase) o una interfaz provista (que brinda la clase). En nuestro ejemplo tenemos los puertos: inPCPort, outPCPort, outTecladoPort y InSalidaDeVideoPort?; las interfaces provistas (notadas con un crculo cerrado en el extremo) InterfazDeEntradaTeclado? e InterfazDeSalidaVideo?, y las interfaces requeridas (notadas con un semi-crculo abierto): InterfazDeEntradaTeclado? y InterfazDeSalidaVideo?. Conectores (Connectors): Los conectores especifican un Enlace (Link) entre Partes, que representa una instancia de asociacin. Este enlace representa la posibilidad de comunicacin entre una o ms partes. En nuestro ejemplo la placa de video se comunica con el procesador. Si bien estas modificaciones afectan a todos los Clasificadores, tienen mayor impacto y utilidad en Clases, Componentes y Colaboraciones.

Figura 3: Diagramas de clase compuesto para el ejemplo mi PC

La nueva notacin permite mostrar claramente que la Placa de Video y el Procesador forman parte de la PC. Esta relacin es an ms fuerte que la relacin de composicin, debido a que una placa de video no puede ser utilizada por otro objeto. Formalmente hablando, ninguna otra instancia en el dominio puede tener una asociacin con esa instancia de la PlacaDeVideo?. Los diagramas de composicin de estructuras permiten, potencialmente, documentar arquitecturas de software de manera un poco ms clara que en versiones anteriores del UML 2.0.

Cambios Particulares en los Diagramas EstructuralesYa hemos enumerado cambios que afectan de manera transversal a varios de los diagramas del UML 2.0. Ahora nos enfocaremos en los cambios particulares de algunos de los diagramas de UML.

Diagrama de ClasesUno de los cambios que seguramente ser muy utilizado es la notacin Lollipop: Mediante esta notacin, las dependencias de un clasificador a una interfase pueden mostrarse mediante un semicrculo abierto, que significa "interfaz requerida". Las interfaces implementadas por un clasificador se muestran con un crculo, cuyo significado es "interfaz provista". Ejemplos de interfaces requeridas y provistas pueden verse en la figura 3 de estructuras compuestas. En La figura 4 mostramos un ejemplo detallando cmo se representara la notacin Lollipop mediante clases e interfaces (a la manera tradicional).

Interfaz Provista e Interfaz Requerida

Figura 4: Ejemplo de

Diagramas de DespliegueSegn la especificacin de la OMG (UML 2.0 Superestructura, p. 8), se establece que: es un diagrama que representa la arquitectura de ejecucin de un sistema. ste, representa los artefactos del sistema como nodos, los cuales son conectados a travs de caminos de comunicacin para crear redes de sistemas de complejidad arbitraria. Al antiguo diagrama de despliegue, se le agregaron los siguientes elementos:

Artefactos (Artifacts)Tpicamente los artefactos eran utilizados para representar la versin compilada de un componente; el UML 2.0 permite representar cualquier elemento empaquetable (por ejemplo un jar). Los artefactos pueden tener atributos, como se muestra en la figura 5.

Figura 5: Un artefacto con atributos

Especificaciones de Despliegue (Deployment Specifications)Las especificaciones de despliegue son una coleccin de propiedades (properties) que especifican cmo un artefacto ser desplegado. A travs de ste, pueden especificarse, por ejemplo, el archivo web.xml, para desplegar una aplicacin web en java (cuya correspondencia en .NET sera el archivo web.config). Este ejemplo se ve en la figura 6.

Figura Especificacin de despliegue.

6:

Un

Ejemplo

de

Diagramas de Componentes (Components Diagram)Segn la especificacin de la OMG (UML 2.0 Superestructura, p. 7), se afirma que: "es un diagrama que muestra la organizacin y dependencias entre componentes." Las modificaciones ms importantes realizadas al diagrama de componentes son: El cambio en la notacin de los componentes. Ahora se notan como muestra la figura 7: Con un estereotipo, en vez de los dos rectngulos pequeos cruzados Antigua notacin

Nueva notacin

Figura 7: Antigua y nueva notacin de componentes respectivamente Otro cambio importante, dentro de los diagramas de componentes, son los conectores de ensamblado (assembly connectors) que se utilizan para representar las interfaces provistas y requeridas por un componente. La representacin del mismo puede verse en la figura 8.

Componente con interfaces provistas e Interfaces requeridas

Figura

8:

Cambios en los ComportamientoDiagramas de Caso de Uso

Diagramas

de

Segn la especificacin de la OMG (UML 2.0 Superestructura, p. 17), los diagramas de casos de uso son diagramas que muestran las relaciones entre actores y el sistema.

Estructuras CompuestasAhora que ya conocemos la nocin de clasificador, podemos notar que un Caso de Uso puede ser parte de (estar compuesto en) cualquier clasificador (no solamente packages). Por ejemplo, un caso de uso puede ser parte de una clase. Ver Figura 9.

Figura 9: Caso de uso como parte de un clasificador.

ExtensionesLas condiciones para una Extensin pueden ser especificadas adjuntando una nota a la relacin de extensin.

Figura 10: Casos de Uso y puntos de extensin Los casos de Uso pueden ser representados como clases (notacin de clasificador) y se nota con una elipse en la parte superior derecha (Estereotipo)

Figura 11: Caso de Uso representado como una Clase con su estereotipo Tambin utilizando el concepto de estereotipos (stereotypes), los actores pueden ser representados mediante distintos conos, tales como computadoras o relojes.

Los Diagramas de ActividadesMuchos cambios fueron realizados en los diagramas de actividad. Mostraremos solamente los ms importantes, aunque muchos nuevos aspectos quedarn fuera. Los cambios realizados son tendientes a:

Dar soporte en la definicin de procesos de negocio. Brindar una semntica similar al de las redes de petri. Permitir una mayor y ms flexible representacin de paralelismo.Si va a trabajar con diagramas de actividades, es conveniente repasarlos debido a que los cambios producidos, tanto semnticos como sintcticos, son muy profundos. En la figura 12 puede verse un ejemplo de un diagrama de actividades con alguno de los nuevos elementos que lo componen.

Figura 12: Ejemplo Diagrama de Actividades En el ejemplo podemos ver alguno de los nuevos elementos tales como: entradas, parmetros y regiones e interrupciones.

Diagramas de Mquina de EstadosUn diagrama de Mquina de Estados ilustra cmo un elemento, muchas veces una clase, se puede mover entre estados que clasifican su comportamiento, de acuerdo con disparadores de transiciones,

guardias de restricciones y otros aspectos de los diagramas de Mquinas de Estados, que representan y explican el movimiento y el comportamiento. Al igual que los diagramas de secuencia, las Mquinas de Estados permiten un mejor rehso, a travs del agregado de Puntos de Entrada y Puntos de Salida (Entry / Exit Points). Las mquinas de estados son ahora generalizables y soportan una vista centrada en la transicin. Las capacidades de generalizacin incluyen: agregar estados y transiciones, extender estados, reemplazar transiciones, reemplazar maquinas compuestas, etc. Lo que permite que, por ejemplo, dada una clase que hereda de otra, especificar ambas clases mediante mquinas de estados que heredan funcionalidad.

Diagramas de InteraccinComo dijimos anteriormente, el UML 2.0 se encuentra diseado de manera Orientada a Objetos, dentro de la nueva organizacin interna, y cuenta con los llamados Diagramas de Interacciones, que son una subcategora de los diagramas de comportamiento. Estos diagramas muestran la interaccin entre distintos clasificadores de un modelo desde distintos puntos de vista, es decir, haciendo foco en distintos aspectos de la interaccin. Esto hace que todos los diagramas de interaccin tengan ciertas caractersticas compartidas, como por ejemplo la capacidad de crear Diagramas de descripcin de interaccin y la utilizacin de fragmentos combinados. Dichos conceptos sern descriptos a continuacin utilizando los diagramas de secuencias.

Los Diagramas de secuenciasLas modificaciones de los diagramas de secuencias tienden bsicamente a permitir la reutilizacin de los diagramas, agregando los elementos de tipos Fragmento Combinado.

Fragmentos CombinadosUn Fragmento combinado describe una interaccin reutilizable. En la figura 13 se muestra la sintaxis de ste, y en la figura 15 mostramos cmo pueden ser reutilizados en un fragmento combinado.

Figura 13: Sintaxis de un Fragmento Combinado

Operadores de Interaccin (Interaction Operators)Los operadores de interaccin contienen un cierto nmero de operandos y un identificador en el pentgono superior izquierdo del Operador (ver figura 14). Mediante los operadores, pueden definirse: Alternativas, Opciones, Quiebres de secuencia (breaks), ejecuciones paralelas, ciclos (loops) y varios ms.

Operadores de Interaccin loop (ciclo) y alt (alternativa)

Figura 14: Ejemplos de

Diagramas Diagrama)

de

Revisin

de

interacciones

(Nuevo

Es un diagrama que muestra cmo interactan varios diagramas de interacciones. Este tipo de diagramas es muy til para mostrar de qu manera distintos escenarios se combinan. En el ejemplo de la figura 15, se muestra la interaccin de un cliente con un cajero ATM, separado en cuatro fragmentos:

Secuencia de login: la cual pedir un usuario y una clave a un cliente. (la secuencia supone quela clave y usuario ingresados son vlidos).

Secuencia de seleccionar una operacin. Las operaciones permitidas por este cajero son cancelaro extraer dinero.

Si cancela, se ejecutar la secuencia de deslogueo del cliente. Luego finalizar la operatoria.Si seleccionar 'extraer dinero' se ejecutar la secuencia de extraccin. Luego finalizar la operatoria.

Figura 15: Diagramas descripcin de interaccin, ejemplo cajero ATM.

Diagramas de colaboracin)

Comunicacin

(Ex

diagramas

de

Quizs el cambio ms profundo en los diagramas de comunicacin es que anteriormente tenan el nombre de Diagramas de Colaboracin. Por ser las colaboraciones un diagrama de interaccin, al igual que los diagramas de secuencias, heredan la misma capacidad de soportar fragmentos combinados.

Diagrama de Tiempos (Nuevo Diagrama)El propsito primario de los diagramas de tiempos (o temporizados) es mostrar los cambios en el estado, o la condicin, de una lnea de vida de una instancia (de un Clasificador o un Rol de un clasificador), a lo largo del tiempo y de manera lineal. El uso ms comn es mostrar el cambio de estado de un objeto a lo largo del tiempo, en respuesta a los eventos o estmulos aceptados. Un diagrama de tiempos se ve tal y como lo muestra la figura 16. No resulta trivial leer un diagrama de tiempos; si no se lo conoce, puede resultar poco intuitivo.

Figura 16: Diagrama de Tiempos

Lo que qued afueraPor una cuestin de espacio, varios temas muy interesantes relativos a UML 2.0 quedaron sin abordar. Entre los temas ms destacados encontramos:

Nuevas caractersticas en los diagramas: hay muchas nuevas caractersticas en UML 2.0 quehemos pasado por alto; algunos ejemplos son: templates, restricciones para las relaciones, varios nuevos elementos en los diagramas de secuencias y mquinas de estados, diagramas de paquetes, etc. MDD (Model Driven Development) y MDA (Model Driven Architecture)

Perfiles: un tema bastante relevante y que qued fuera, es el de Perfiles (Profiles), porqueexplicarlo debidamente requiere un espacio considerado. 2.0.

Diagramas de Arquitectura: analizar cmo realizar Diagramas de Arquitecturas utilizando UML OCL: la utilizacin de OCL ser sin dudas una de las tcnicas de mayor crecimiento dentro de laIngeniera de Software. As como hubo un tiempo en que los casos de uso no eran siquiera conocidos, y hoy son moneda de uso corriente, con OCL es dado a pensar que pasar algo similar, debido, en gran parte, al poder de expresividad que brinda sobre los modelos. MOF, del ingls: Meta Object Facility. Representa el diseo interno del UML con las estructuras necesarias para dar soporte a la automatizacin (MDA y MDD)

ConclusinEn esta entrega hemos analizado los cambios en el UML 2.0 desde un punto de vista bastante amplio, teniendo en cuenta principalmente aquellos cambios de mayor impacto para el desarrollador promedio. Sin duda, muchos de los conceptos aqu vistos no podrn faltar en la caja de herramientas de cualquier desarrollador en el corto plazo. Diagramas de estructura compuesta, as como las modificaciones en la mayora de los diagramas de comportamiento, sern de uso comn, debido al gran poder de expresividad que stos brindan. Sin embargo, sin perder de vista el trabajo cotidiano, es importante recordar, siempre que hablemos del UML 2.0, las dos premisas que rigen su estructura: (1) Hacer el lenguaje de modelado mucho ms extensible. (2) Permitir la validacin y ejecucin de modelos creados mediante el UML. Ejercicio Puede ser un ejercicio interesante, modelar este mismo ejemplo utilizando la versin anterior del UML (1.5)y analizando cules son sus implicancias. Recomendacines Si piensa trabajar con UML 2.0, nuestra recomendacin es capacitarse adecuadamente sobre el diagrama que est por modelar y utilizar una herramienta que cumpla con el nivel de conformidad ms alto posible; esto le permitir sacar un mayor provecho del libro. Nuestros recomendados

UML 2.0 in a Nutshell de Dan Pilone y Neil Pitman

Excelente referencia para el trabajo diario. La introduccin terica es un poco superficial debido a que el foco del libro es la superestructura. El libro puede ser til tanto a expertos UML como para quienes recin se inician.

Enterprise Architect La herramienta recomendada.

Temario1. Tecnologa de Objetos 1.1. Diferencia entre Anlisis 1.2. Anlisis y Diseo Orientado 1.3. Objetos y 1.4. Prctica Inicial de Anlisis y Diseo 2. El ciclo de vida y el plan de trabajo con base en el Proceso Unificado 2.1. El Ciclo de 2.2. Fases e 2.3. Artefactos y UML en el Proceso 2.4. Responsabilidades y a Diseo Objetos Clases Vida Iteraciones Unificado (trabajadores)

2.5.

Disciplinas

(flujos

de

trabajo)

de

ingeniera

y

de

soporte

NOTA: A lo largo del curso los diferentes artefactos se van relacionando con su correspondiente(s) fase(s) dentro del Proceso Unificado para reafirmar la relacin entre UML y el Proceso Unificado. 3. La Importancia del Modelado Visual 4. Antecedentes de UML 5. Modelo de Casos de Uso 5.1. Actores 5.2. Casos de Uso 5.3. Diagrama de Casos de Uso 5.4. Paquetes de Casos de Uso 5.5. Relaciones y 5.6. Puntos de extensin 5.7. Paquetes de Casos de Uso 6. Especificacin de Casos de Uso (Flujos de Eventos) 6.1. Documentacin de un Caso de Uso 6.2. Caso de Uso de Alto Nivel 6.3. Flujos Primarios, Alternos y Excepcionales 6.4. Precondiciones y postcondiciones 6.5. Requerimientos especiales del caso de uso 6.6. Escenarios 6.7. Las Pruebas y los Casos de Uso 7. Modelo Conceptual 7.1. Conceptos 7.2. Atributos 7.3. Relacin de Asociacin 7.4. Diagrama del Modelo Conceptual 7.5. Identificacin de conceptos mediante un anlisis de Casos de Uso 8. Diagramas de Secuencia 8.1. Clases y Objetos 8.2. Lnea de Vida 8.3. Foco de Control 8.4. Mensajes y Operaciones 8.5. Diagrama de Secuencia 8.6. Diagrama de Colaboracin 8.7. Diferencias entre el Diagrama de Colaboracin y de Secuencia 8.8. Impacto del Diagrama de Interaccin en el Diagrama de Clases 9. Patrones de Asignacin de Responsabilidades 9.1. Qu son los patrones 9.2. Patrones para la Asignacin de Responsabilidades 9.3. Alta Cohesin y Bajo Acoplamiento 9.4. Diseo en 3 Capas 10. Diagramas de Clases 10.1. Clases 10.2. Atributos 10.3. Operaciones 10.4. Alcance de Atributos y Operaciones 10.5. Relaciones de Asociacin, Agregacin y Dependencia 10.6. Generalizacin: la implementacin de la herencia 10.7. Visibilidad entre Clases 10.8. Navegabilidad 10.9. Multiplicidad 10.10. Completando el diagrama de clases mediante el diagrama de interaccin 10.11. Paquetes de clases 11. Diagramas de Componentes 11.1. Componentes 11.2. Interfases 11.3. La interfase en el diagrama de clases 11.4. La interfase en el diagrama de componentes 11.5. Relacin de Realizacin 11.6. Tipos de Componentes 11.7. Dependencias 12. Diagramas de Distribucin 12.1. Nodos 12.2. Asociaciones entre Nodos 12.3. Dispositivos 12.4. Diagrama de Distribucin 13. Implementacin en el lenguaje seleccionado 13.1. Interpretacin del Diagrama de Clases 13.2. Interpretacin del Diagrama de Secuencia 13.3. Interpretacin del Diagrama de Componentes 14. Generacin de Cdigo 14.1. Uso de herramientas CASE para la Generacin de Cdigo 14.2. Generacin de Cdigo

14.3. Ingeniera Inversa 14.4. Round Trip Engineering 15. Segundo Caso Prctico 15.1. Segundo Caso Prctico para Repasar los Conceptos Aprendidos en una simulacin de proyecto y donde adems se incluyen nuevos artefactos de UML: 15.2. Planeacin del caso prctico bajo RUP: Identificacin de fases, actividades y planeacin de tiempos 15.3. Entrevista de requerimientos 15.4. Modelado de negocios 15.5. Modelo de casos de uso (a partir de los procesos analizados en el diagrama de actividad) 15.6. Modelo Conceptual 15.7. Diagrama de estados 15.8. Diagrama de interaccin 15.9. Diagrama de clases 15.10. Diagrama de componentes 15.11. Diagrama de despliegue 15.12. Codificacin 15.13. Generacin de cdigo e ingeniera inversa 16. Diagramas de Actividad (Visto dentro del segundo caso prctico para modelar el negocio) 16.1. Actividades 16.2. Transiciones 16.3. Decisiones 16.4. Carriles y responsabilidades dentro del proceso 16.5. Trabajo en paralelo (barras de sincronizacin) 16.6. Paso de las actividades al modelo de casos de uso 16.7. Modelado de casos de uso con diagramas de actividad 16.8. Modelado de procesos de negocio con diagramas de actividad 17. Diagramas de Estado (Visto dentro del segundo caso prctico) 17.1. Estados 17.2. Transiciones 17.3. Eventos 17.4. Acciones 17.5. Condiciones de guardia 17.6. Superestados 17.7. Historia 17.8. Modelado de anlisis y diseo con un diagrama de estados

http://www.osmosislatina.com/lenguajes/uml/basico.htm

Porque es importante UML ?Hoy en da, UML ("Unified Modeling Language") esta consolidado como el lenguaje estndar en el anlisis y diseo de sistemas de computo. Mediante UML es posible establecer la serie de requerimientos y estructuras necesarias para plasmar un sistema de software previo al proceso intensivo de escribir cdigo. En otros trminos, as como en la construccin de un edificio se realizan planos previo a su construccin, en Software se deben realizar diseos en UML previa codificacin de un sistema, ahora bien, aunque UML es un lenguaje, ste posee ms caractersticas visuales que programticas, mismas que facilitan a integrantes de un equipo multidisciplinario participar e intercomunicarse fcilmente, estos integrantes siendo los analistas, diseadores, especialistas de rea y desde luego los programadores.

Complejidad / ObjetosEntre ms complejo es el sistema que se desea crear ms beneficios presenta el uso de UML ("Unified Modeling Language"), las razones de esto son evidentes, sin embargo, existen dos puntos claves : El primero se debe a que mediante un plano/visin global resulta ms fcil detectar las dependencias y dificultades implcitas del sistema, y la segunda razn radica en que los cambios en una etapa inicial (Anlisis) resultan ms fciles de realizar que en una etapa final de un sistema como lo seria la fase intensiva de codificacin. Puesto que UML es empleado en el anlisis para sistemas de mediana-alta complejidad, era de esperarse que su base radica en otro paradigma empleado en diseos de sistemas de alto nivel que es la orientacin a objetos, por lo que para trabajar en UML puede ser considerado un pre-requisito tener experiencia en un lenguaje orientado a objetos. Hoy en da, entre los lenguajes orientados a objetos ms utilizados se encuentran Java y C#, adems de otros ms antiguos como C++ y SmallTalk, aunque el programar en todos estos lenguajes requiere experiencia previa sobre la sintaxis y bloques especficos, el paradigma empleado en todos ellos es el mismo : Objetos. Lo el anterior Sistema permite que un anlisis en misma UML sea realizado que

independiente del lenguaje en el que finalmente sea implementando (Java,C#,C++,SmallTalk), caracterstica permite a personal no familiarizado en lenguajes de programacin participen en el anlisis y diseo de un sistema.

Conceptos / DiagramasEntre los conceptos fundamentales de orientacin a objetos se encuentran los siguientes :Un Un Un

modelo es una abstraccin del problema que se intenta resolver. dominio es el mundo de donde proviene el problema . modelo consiste de objetos que interactan entre s envindose

mensajes.

Cada

objeto posee caractersticas propias (atributos) y operaciones

que puede realizar (mtodos); las valores asignados a un objeto en determinado momento determinan su estado.Una

clase es un molde para describir un objeto que agrupa

caractersticas (atributos) y comportamientos (mtodos).Los

objetos son instancias de Clases.

A continuacin se enumeran los 9 diagramas que forman la base de UML, y dictan la manera en que es diseado un sistema :Uso-Caso De Clases Actividad Objetos Componentes Secuencia Ejecucin Colaboracin

Estado (Statechart)

(Deployment)

El uso y diseo de estos diagramas es tema del resto de esta guia para UML.

diagrama Uso-Caso Definicin y UsosUn diagrama Uso-Caso describe lo que hace un sistema desde el punto de vista de un observador externo, debido a esto, un diagrama de este tipo generalmente es de los ms sencillos de interpretar en UML, ya que su razn de ser se concentra en un Que hace el sistema, a diferencia de otros diagramas UML que intentan dar respuesta a un Como logra su comportamiento el sistema. Un Uso-Caso esta muy relacionado con lo que pudiera ser considerado un escenario en el sistema, esto es, lo que ocurre cuando alguien interacta con el sistema: "Acude un mesero a colocar la orden, la orden es tomada por el cocinero, y posteriormente se abona a la cuenta del cliente el cargo".

Un Uso-Caso es empleado con ms frecuencia en alguna de las siguientes etapas :Determinacin

de

Requerimientos:

Por

lo

general

nuevos

requerimientos de sistema generan nuevos usos-casos, conforme es analizado y diseado el sistema.Comunicacin

con el Cliente: Debido a la sencillez de este tipo de

diagramas, son fciles de emplear para comunicarse con el cliente final del proyecto.Generacin

de pruebas de Sistemas: A travs de los diagramas uso-

caso se pueden generar una serie de pruebas de sistema. En la siguiente seccin se describen los diversos elementos que componen un diagrama Uso-Caso.

ComposicinActor:

Un actor representa quien o que inicia una accin dentro del

sistema, en otras palabras, es simplemente un rol que es llevado acabo por una persona o cosa. Un Actor en un diagrama Uso-Caso es representado por una figura en forma de persona.Uso-Caso:

El uso-caso en s es representado por un ovalo que

describe la funcionalidad a grosso modo que se requiere por el sistema.Comunicacin:

Este elemento representa la relacin que existe

entre un Uso-Caso y un Actor, dicho elemento es representado simplemente por una linea recta que se extiende de la figura del actor hacia el ovalo del uso-caso.Limite

de Sistema (System Boundry): Empleado para delimitar

los limites del sistema, y representado por un rectngulo con color de fondo distintivo.Generalizacin

: Una generalizacin indica que un uso-caso (ovalo) padre-hijo, donde el hijo puede ser suplido

es un caso especial de otro caso, en otros trminos, representa una relacin directamente por el padre en cualquier momento. Este elemento es

representado por una linea con flecha que se extiende del uso-caso hijo hacia el uso caso padre (general).Inclusin

: Una inclusin es utilizada para indicar que un uso-caso

(ovalo) depende de otro caso, dicho de otra manera, significa que la funcionalidad de determinado caso se requiere para realizar las tareas de otro. Este elemento es representado por una linea punteada con flecha y comentario que se extiende del uso-caso base hacia el uso caso de inclusin.Extensin

: Una extensin representa una variacin de un uso-caso una dependencia especifica, mientras una

a otro, aunque similar a una generalizacin, una extensin representa generalizacin no implica que los usos-casos dependen uno del otro. Este elemento es representado por una linea punteada con flecha y comentario que origina del uso-caso base hacia el uso caso de extensin.

Ilustracin

diagrama de Actividad

Definicin y UsosUn diagrama de Actividad demuestra la serie de actividades que deben ser realizadas en un uso-caso, as como las distintas rutas que pueden irse desencadenando en el uso-caso. Es importante recalcar que aunque un diagrama de actividad es muy similar en definicin a un diagrama de flujo (tipicamente asociado en el diseo de Software), estos no son lo mismo. Un diagrama de actividad es utilizado en conjuncin de un diagrama uso-caso para auxiliar a los miembros del equipo de desarrollo a entender como es utilizado el sistema y como reacciona en determinados eventos.Lo anterior, en contraste con un diagrama de flujo que ayuda a un programador a desarrollar codigo a travs de una descripcin lgica de un proceso. Se pudiera considerar que un diagrama de actividad describe el problema, mientras un diagrama de flujo describe la solucin. En la siguiente seccin se describen los diversos elementos que componen un diagrama de Actividad.

ComposicinInicio:

El inicio de un diagrama de actividad es representado por un

crculo de color negro slido.Actividad

: Una actividad representa la accin que ser realizada

por el sistema la cual es representada dentro de un ovalo.Transicin:

Una transicin ocurre cuando se lleva acabo el cambio

de una actividad a otra, la transicin es representada simplemente por una linea con una flecha en su terminacin para indicar direccin.

Ramificacin

(Branch) : Una ramificacin ocurre cuando existe la

posiblidad que ocurra ms de una transicin (resultado) al terminar determinada actividad.Este elemento es representado a travs de un rombo.

Unin

(Merge) : Una unin ocurre al fusionar dos o ms

transiciones en una sola transicin o actividad.Este elemento tambin es representado a travs de un rombo.Expresiones

Resguardadas (Guard Expressions) : Una expresi

resguardada es utilizada para indicar una descripcin explicita acerca de una transicin. Este tipo de expresin es reprsentada mediante corchetes ([...] y es colocada sobre la linea de transicin.Fork

: Un fork representa una necesidad de ramificar una transicin

en ms de una posibilidad. Aunque similar a una ramificacin (Branch) la diferencia radica en que un fork representa ms de una ramificacin obligada, esto es, la actividad debe proceder por ambos o ms caminos, mientras que una ramificacin (Branch) representa una transicin u otra para la actividad (como una condicional). Un fork es representado por una linea negra solida, perpendicualar a las lineas de transicin .Join

:

Una

join

ocurre

al

fusionar

dos

o

ms

transiciones

provenientes de un fork, y es empleado para dichas transiciones en una sola,tal y como ocurria antes de un fork .Un fork es representado por una linea negra solida, perpendicualar a las lineas de transicin .Fin

: El fin de un diagrama de actividad es representado por un

crculo, con otro circulo concentrico de color negro slido.Canales

(Swimlanes) : En determinadas ocasiones ocurre que un

diagrama de actividad se expanda a lo largo de ms de un entidad o actor, cuando esto ocurre el diagrama de actividad es particionada actividad. en canales (swimlines), donde cada canal representa la entidad o actor que esta llevando acabo la

Diagramas de Clases : Definicin y UsosUn diagrama de Clases representa las clases que sern utilizadas dentro del sistema y las relaciones que existen entre ellas.

Los diagramas de Clases por definicin son estticos, esto es, representan que partes interactan entre s, no lo que ocurre cuando.

Ilustracin

http://docs.kde.org/stable/es/kdesdk/umbrello/index.html

Manual de Umbrello UML ModellerUmbrello UML Modeller AutoresTraductor: Marcos Fouces Lago revisin 1.2 (2003-10-15) Copyright 2001 Paul Hensgen Copyright 2002, 2003 Umbrello UML Modeller Autores Umbrello UML Modeller ayuda en el proceso de desarrollo de software usando el estndar 'Unified Modelling Language' (UML) que le permitir crear diagramas para disear y documentar sus sistemas.

Tabla de contenidos 1. Introduccin 2. Introduccin a UML Acerca de UML Elementos de UML Diagrama de casos de uso Diagrama de clases Diagramas de secuencia Diagramas de colaboracin Diagrama de estado Diagrama de actividad Elementos de ayuda Diagramas de componentes Diagramas de implementacin Diagramas de relacin de entidad 3. Trabajando con Umbrello UML Modeller Interfaz de usuario Ttulo Ventana de documentacin rea de trabajo Crear, cargar y guardar proyectos Nuevo proyecto Guardar modelo Cargar modelo Editar modelo Aadir y eliminar diagramas Crear diagramas Eliminar diagramas Renombrar diagramas Editar diagramas Insertar diagramas Borrar elementos Editar elementos Editar clases

Asociaciones Notas, textos y cajas 4. Importacin y generacin de cdigo Generacin de cdigo Generacin de cdigo Importacin de cdigo 5. Otras caractersticas Otras caractersticas de Umbrello UML Modeller Copia de objetos como imgenes PNG Exportar como imagen Impresin Carpetas lgicas 6. Autores e historia 7. Copyright

Captulo 1. IntroduccinUmbrello UML Modeller es una herramienta de diagramas que ayuda en el proceso del desarrollo de software. Umbrello UML Modeller le facilitar la creacin de un producto de alta calidad, especialmente durante fases de anlisis y diseo del proyecto. UML tambin puede usarse para documentar sus diseos de software para ayudarle a usted y al resto de desarrolladores. Tener una buena maqueta del software es la mejor forma de comunicarse con otros desarrolladores que participen en el proyecto, as como con sus clientes. Una buena maqueta de extremadamente importante para los proyectos de mediano o gran tamao, pero tambin resulta til para los ms pequeos. Aunque trabaje en un pequeo proyecto personal, podr beneficiarse de una buena maqueta porque esta le proporcionar una visin global que le ayudar en la creacin de un mejor cdigo. UML es el lenguaje de diagramas que se utiliza para la descripcin de tales maquetas. Es posible representar las ideas en UML utilizando diversos tipos de diagramas. Umbrello UML Modeller 1.2 soporta los siguientes tipos:Diagrama de Diagrama de Diagrama de Diagrama de Diagrama de Diagrama de Diagrama de Diagrama de

clase secuencia colaboracin caso de uso estado actividad colaboracin secuencia

Puede encontrar ms informacin sobre UML en la pgina web de OMG, http://www.omg.org. quien cre el estndar UML. Esperamos que disfrute de Umbrello UML Modeller y que este le sirva en la creacin de software de gran calidad. Umbrello UML Modeller es una herramienta libre, y lo nico que le pedimos es que informe a los desarrolladores de Umbrello UML Modeller de fallos, problemas o sugerencias en la direccin de correo electrnico (uml-devel AT lists.sourceforge.net).

Captulo 2. Introduccin a UML

Tabla de contenidos Acerca de UML Elementos de UML Diagrama de casos de uso Diagrama de clases Diagramas de secuencia Diagramas de colaboracin Diagrama de estado Diagrama de actividad Elementos de ayuda Diagramas de componentes Diagramas de implementacin Diagramas de relacin de entidad

Acerca de UMLEste captulo proporciona una introduccin rpida a las caractersticas bsicas de UML. Tenga en cuenta que no se trata de un manual de referencia de UML sino de una breve introduccin. Si desea ms informacin sobre UML, o sobre el anlisis y diseo del software en general, le recomendamos que lea cualquier de los libros publicados sobre el tema. Tambin hay una buena cantidad de tutoriales en Internet, que puede utilizar como punto de partida. El lenguaje unificado de diagrama o notacin (UML) sirve para especificar, visualizar y documentar esquemas de sistemas de software orientado a objetos. UML no es un mtodo de desarrollo, lo que significa que no sirve para determinar qu hacer en primer lugar o cmo disear el sistema, sino que smplemente le ayuda a visualizar el diseo y a hacerlo ms accesible para otros. UML est controlado por el grupo de administracin de objetos (OMG) y es el estndar de descripcin de esquemas de software. UML est diseado para su uso con software orientado a objetos, y tiene un uso limitado en otro tipo de cuestiones de programacin. UML se compone de muchos elementos de esquematizacin que representan las diferentes partes de un sistema de software. Los elementos UML se utilizan para crear diagramas, que representa alguna parte o punto de vista del sistema. Umbrello UML Modeller soporta los siguientes tipos de diagramas:Diagrama

de casos de uso que muestra a los actores (otros usuarios del sistema), los casos de uso (las situaciones que se producen cuando utilizan el sistema) y sus relaciones. Diagrama de clases que muestra las clases y la relaciones entre ellas. Diagrama de secuencia muestra los objetos y sus mltiples relaciones entre ellos. Diagrama de colaboracin que muestra objetos y sus relaciones, destacando los objetos que participan en el intercambio de mensajes. Diagrama de estado muestra estados, cambios de estado y eventos en un objeto o en parte del sistema. Diagrama de actividad que muestra actividades, as como los cambios de una a otra actividad junto con los eventos que ocurren en ciertas partes del sistema. Diagrama de componentes que muestra los componentes de mayor nivel de la programacin (cosas como Kparts o Java Beans). Diagrama de implementacin que muestra las instancias de los componentes y sus relaciones.

Diagrama

de relaciones de entidad que muestra los datos y las relaciones y restricciones entre ellos.

Elementos de UMLDiagrama de casos de usoLos diagramas de casos de uso describen las relaciones y las dependencias entre un grupo de casos de uso y los actores participantes en el proceso. Es importante resaltar que los diagramas de casos de uso no estn pensados para representar el diseo y no puede describir los elementos internos de un sistema. Los diagramas de casos de uso sirven para facilitar la comunicacin con los futuros usuarios del sistema, y con el cliente, y resultan especialmente tiles para determinar las caractersticas necesarias que tendr el sistema. En otras palabras, los diagramas de casos de uso describen qu es lo que debe hacer el sistema, pero no cmo.

Umbrello UML Modeller mostrar un diagrama de casos de uso

Caso de usoUn caso de uso describe, desde el punto de vista de los actores, un grupo de actividades de un sistema que produce un resultado concreto y tangible. Los casos de uso son descriptores de las interacciones tpicas entre los usuarios de un sistema y ese mismo sistema. Representan el interfaz externo del sistema y especifican qu requisitos de funcionamiento debe tener este (recuerde, nicamente el qu, nunca el cmo).

Cuando se trabaja con casos de uso, es importante tener presentes algunas secillas reglas:Cada Cada Cada

caso de uso est relacionado como mnimo con un actor. caso de uso es un iniciador (es decir, un actor) caso de uso lleva a un resultado relevante (un resultado con valor intrnseco)

Los casos de uso pueden tener relaciones con otros casos de uso. Los tres tipos de relaciones ms comunes entre casos de uso son:

que especifica una situacin en la que un caso de uso tiene lugar dentro de otro caso de uso que especifica que en ciertas situaciones, o en algn punto (llamado punto de extensin) un caso de uso ser extendido por otro. Generalizacin que especifica que un caso de uso hereda las caractersticas del super caso de uso, y puede volver a especificar algunas o todas ellas de una forma muy similar a las herencias entre clases.

ActorUn actor es una entidad externa (de fuera del sistema) que interacciona con el sistema participando (y normalmente iniciando) en un caso de uso. Los actores pueden ser gente real (por ejemplo, usuarios del sistema), otros ordenadores o eventos externos. Los actores no representan a personas fsicas o a sistemas, sino su papel. Esto significa que cuando una persona interacciones con el sistema de diferentes maneras (asumiendo diferentes papeles), estar representado por varios actores. Por ejemplo, una persona que proporciona servicios de atencin al cliente telefnicamente y realiza pedidos para los clientes estara representada por un actor equipo de soporte y por otro actor representante de ventas.

Descripcin de casos de usoLas descripciones de casos de uso son reseas textuales del caso de uso. Normalmente tienen el formato de una nota o un documento relacionado de alguna manera con el caso de uso, y explica los procesos o actividades que tienen lugar en el caso de uso.

Diagrama de clasesLos diagramas de clases muestran las diferentes clases que componen un sistema y cmo se relacionan unas con otras. Se dice que los diagramas de clases son diagramas estticos porque muestran las clases, junto con sus mtodos y atributos, as como las relaciones estticas entre ellas: qu clases conocen a qu otras clases o qu clases son parte de otras clases, pero no muestran los mtodos mediante los que se invocan entre ellas.

Umbrello UML Modeller mostrando un diagrama de clases

ClaseUna clase define los atributos y los mtodos de una serie de objetos. Todos los objetos de esta clase (instancias de esa clase) tienen el mismo comportamiento y el mismo conjunto de atributos (cada objetos tiene el suyo propio). En ocasiones se utiliza el trmino tipo en lugar de clase, pero recuerde que no son lo mismo, y que el trmino tipo tiene un significado ms general. En , las clases estn representadas por rectngulos, con el nombre de la clase, y tambin pueden mostrar atributos y operaciones de la clase en otros dos compartimentos dentro del rectngulo.

Representacin visual de una clase en UML

AtributosEn UML, los atributos se muestran al menos con su nombre, y tambin pueden mostrar su tipo, valor inicial y otras propiedades. Los atributos tambin pueden ser mostrados visualmente:

+ # -

Indica atributos pblicos Indica atributos protegidos Indica atributos privados

OperacionesLa operaciones (mtodos) tambin se muestan al menos con su nombre, y pueden mostrar sus parmetros y valores de retorno. Las operaciones, al igual que los atributos, se pueden mostrar visualmente:+ # -

Indica operaciones pblicas Indica operaciones protegidas Indica operaciones privadas

PlantillasLas clases pueden tener plantillas, un valor usado para una clase no especificada o un tipo. El tipo de plantilla se especifica cuando se inicia una clase (es decir cuando se crea un objeto). Las plantillas existen en C++ y se introducirn en Java 1.5 con el nombre de Genricos.

Asociaciones de clasesLas clases se puede relaciones (estar asocionadas) con otras de diferentes maneras:

GeneralizacinLa herencia es uno de los conceptos fundamentales de la programacin orientada a objetos, en la que una clase recoge todos los atributos y operaciones de la clase de la que es heredera, y puede alterar/modificar algunos de ellos, as como aadir ms atributos y operaciones propias. En UML, una asociacin de generalizacin entre dos clases, coloca a estas en una jerarqua que representa el concepto de herencia de una clase derivada de la clase base. En UML, las generalizaciones se representan por medio de una lnea que conecta las dos clases, con una flecha en el lado de la clase base.

Representacin visual de una generalizacin en UML

AsociacionesUna asociacin representa una relacin entre clases, y aporta la semntica comn y la estructura de muchos tipos de conexiones entre objetos.

Las asociaciones son los mecanismos que permite a los objetos comunicarse entre s. Describe la conexin entre diferentes clases (la conexin entre los objetos reales se denomina conexin de objetos o enlace). Las asociaciones pueden tener una papel que especifica el propsito de la asociacin y pueden ser unidireccionales o bidireccionales (indicando si los dos objetos participantes en la relacin pueden intercambiar mensajes entre s, o es nicamente uno de ellos el que recibe informacin del otro). Cada extremo de la asociacin tambin tiene un valor de multiplicidad, que indica cuntos objetos de ese lado de la asociacin estn relacionados con un objeto del extremo contrario. En UML, las asociaciones se representan por medio de lneas que conectan las clases participantes en la relacin, y tambin pueden mostrar el papel y la multiplicidad de cada uno de los participantes. La multiplicidad se muestra como un rango [mn...mx] de valores no negativos, con un asterisco (*) representando el infinito en el lado mximo.

Representacin visual de una asociacin en UML

AcumulacinLas acumulaciones son tipos especiales de asociaciones en las que las dos clases participantes no tienen un estado igual, pero constituyen una relacin completa. Una acumulacin describe cmo se compone la clase que asume el rol completo de otras clases que se encargan de las partes. En las acumulaciones, la clase que acta como completa, tiene una multiplicidad de uno. En UML, las acumulaciones estn representadas por una asociacin que muestra un rombo en uno de los lados de la clase completa.

Representacin visual de una relacin de acumulacin en UML

ComposicinLas composiciones son asociaciones que representan acumulaciones muy fuertes. Esto significa que las composiciones tambin forman relaciones completas, pero dichas relaciones son tan fuertes que las partes no pueden existir por s mismas. nicamente existen como parte del conjunto, y si este es destruido las partes tambin lo son. En UML, las composiciones estn representadas por un rombo slido al lado del conjunto.

Otros cmopnentes de los diagrama de clasesLos diagramas de clases pueden contener ms componentes aparte de clases.

InterfacesLas interfaces son clases abstractas, esto es, instancias que no pueden ser creadas directamente a partir de ellas. Pueden contener operaciones, pero no atributos. Las clases pueden heredarse de las interfaces pudiendo as realizarse instancias a partir de estos diagramas.

Tipo de datosLos tipo de datos son primitivas incluidas en algunos lenguajes de programacin. Algunos ejemplos son: bool y float. No pueden tener relacin con clases, pero las clases s pueden relacionarse con ellos.

EnumeracionesLas enumeraciones son simples listas de valores. Un ejemplo tpico de esto sera una enumeracin de los das de la semana. Al igual que los tipos de datos, no pueden relacionarse con las clases, pero las clases s pueden hacerlo con ellos.

PaquetesLos paquetes, en lenguajes de programacin, representan un espacio de nombres en un diagrama se emplean para representar partes del sistema que contienen ms de una clase, incluso cientos de ellas.

Diagramas de secuenciaLos diagramas de secuencia muestran el intercambio de mensajes (es decir la forma en que se invocan) en un momento dado. Los diagramas de secuencia ponen especial nfasis en el orden y el momento en que se envan los mensajes a los objetos. En los diagramas de secuencia, los objetos estn representados por lneas intermitentes verticales, con el nombre del objeto en la parte ms alta. El eje de tiempo tambin es vertical, incrementndose hacia abajo, de forma que los mensajes son enviados de un objeto a otro en forma de flechas con los nombres de la operacin y los parmetros.

Umbrello UML Modeller mostrando un diagrama de secuencia

Los mensajes pueden ser o bien sncronos, el tipo normal de llamada del mensaje donde se pasa el control a objeto llamado hasta que el mtodo finalize, o asncronos donde se devuelve el control directamente al objeto que realiza la llamada. Los mensajes sncronos tienen una caja vertical en un lateral del objeto invocante que muestra el flujo del control del programa.

Diagramas de colaboracinLos diagramas de colaboracin muestran las interacciones que ocurren entre los objetos que participan en una situacin determinada. Esta es ms o menos la misma informacin que la mostrada por los diagramas de secuencia, pero destacando la forma en que las operaciones se producen en el tiempo, mientras que los diagramas de colaboracin fijan el inters en las relaciones entre los objetos y su topologa. En los diagramas de colaboracin los mensajes enviados de un objeto a otro se representan mediante flechas, mostrando el nombre del mensaje, los parmetros y la secuencia del mensaje. Los diagramas de colaboracin estn indicados para mostrar una situacin o flujo programa especficos y son unos de los mejores tipos de diagramas para demostrar o explicar rpidamente un proceso dentro de la lgica del programa.

Umbrello UML Modeller mostrando un diagrama de colaboracin

Diagrama de estadoLos diagramas de estado muestran los diferentes estados de un objeto durante su vida, y los estmulos que provocan los cambios de estado en un objeto. Los diagramas de estado ven a los objetos como mquinas de estado o autmatas finitos que pueden estar en un conjunto de estados finitos y que pueden cambiar su estado a travs de un estmulo perteneciente a un conjunto finito. Por ejemplo, un objeto de tipo NetServer puede tener durante su vida uno de los siguientes estados:Listo Escuchando Trabajando Detenido

y los eventos que pueden producir que el objeto cambie de estado sonSe crea el objeto El objeto recibe un mensaje de escucha Un cliente solicita una conexin a travs de Un cliente finaliza una solicitud La solicitud se ejecuta y ser termina El objeto recibe un mensaje de detencin etc

la red

Umbrello UML Modeller mostrando un diagrama de estado

EstadoLos estados son los ladrillos de los diagramas de estado. Un estado pertenece a exactamente una clase y representa un resumen de los valores y atributos que puede tener la clase. Un estado UML describe el estado interno de un objeto de una clase particular Tenga en cuenta que no todos los cambios en los atributos de un objeto deben estar representados por estados, sino nicamente aquellos cambios que pueden afectar significativamente a la forma de funcionamiento del objeto Hay dos tipos especiales de estados: inicio y fin. Son especiales en el sentido de que no hay ningn evento que pueda devolver a un objeto a su estado de inicio, y de la misma forma no hay ningn evento que pueda sacar a un objeto de su estado de fin.

Diagrama de actividadLos diagramas de actividad describen la secuencia de las actividades en un sistema. Los diagramas de actividad son una forma especial de los diagramas de estado, que nicamente (o mayormente) contienen actividades.

Umbrello UML Modeller mostrando un diagrama de actividad

Los diagramas de actividad son similares a los diagramas de flujo procesales, con la diferencia de que todas las actividades estn claramente unidas a objetos. Los diagramas de actividad siempre estn asociados a una clase, a una operacin o a un caso de uso. Los diagramas de actividad soportan actividades tanto secuenciales como paralelas. La ejecucin paralela se representa por medio de iconos de fork/espera, y en el caso de las actividades paralelas, no importa en qu orden sean invocadas (pueden ser ejecutadas simultneamente o una detrs de otra).

ActividadUna actividad es un nico paso de un proceso. Una activa es un estado del sistema que actividad interna y, al menos, una transicin saliente. Las actividades tambin pueden tener ms de una transicin saliente, si tienen diferentes condiciones. Las actividades pueden formar jerarquas, lo que significa que una actividad puede estar formada de varias actividades de detalle, en cuyo caso las transiciones entrantes y salientes deberan coincidir con las del diagrama de detalle.

Elementos de ayuda

Existen unos pocos elementos en UML que no tiene un valor semntico real en la maqueta, pero que ayudan a clarificar partes del programa. Estos elementos sonLnea de texto Notas de texto Cajas

y enlaces

Las lneas de texto son tiles para aadir informacin textual a un diagrama. Es texto es libre y no tiene ningn significado para la maqueta. Las notas son tiles para aadir informacin ms detallada de un objeto o una situacin especfica. Tienen la gran ventaja de que se pueden anclar a los elementos UML para mostrar que una nota pertenece a un objeto o situacin especficos Las cajas son rectngulos repartidos libremente que pueden usarse para juntar objetos haciendo los diagramas ms legibles. No tienen significado lgico en la maqueta

Diagramas de componentesLos diagramas de componentes muestran los componentes del software (ya sea las tecnologas que lo forman como Kparts, componentes CORBA, Java Beans o simplemente secciones del sistema claramente distintas) y los artilugios de que est compuesto como los archivos de cdigo fuente, las libreras o las tablas de una base de datos. Los componentes pueden tener interfaces (es decir clases abstractas con operaciones) que permiten asociaciones entre componentes.

Diagramas de implementacinLos diagramas de implementacin muestran las instancias existentes al ejecutarse as como sus relaciones. Tambin se representan los nodos que identifican recursos fsicos, tpicamente un ordenador as como interfaces y objetos (instancias de las clases).

Diagramas de relacin de entidadLos diagramas de relaciones de entidad (diagramas ER) muestran el diseo conceptual de las aplicaciones de bases de datos. Representan varias entidades (conceptos) en el sistema de informacin y las relaciones y restricciones existentes entre ellas. Una extensin de los diagramas de relaciones de entidad llamado diagramas de relaciones de entidad extendida o diagramas de relaciones de entidad mejoradas (EER), se utiliza para incorporar las tcnicas de diseo orientadas a objetos en los diagramas ER.

Umbrello mostrando un diagrama de relaciones de entidad

EntidadUna Entidad es cualquier concepto del mundo real con una existencia independiente. Puede ser un objeto con una existencia fsica (ejemplo, mquina, robot) o puede ser un objeto con una existencia conceptual (p. ej.: Curso de universidad). Cada entidad tiene un conjunto de atributos que describen las propiedades de la entidad. Nota: No existen notaciones estndar para representar los diagramas ER. Los diferentes textos sobre este asunto utilizan diferentes notaciones. Los conceptos y notaciones para los diagramas EER utilizados en Umbrello provienen del siguiente libro: Elmasri R. y Navathe S. (2004). Fundamentals of Database Systems 4 ed. Addison Wesley (Fundamentos de los sistemas de bases de datos) En un diagrama ER, las entidades se representan como rectngulos, con el nombre de la clase, y tambin pueden mostrar atributos y operaciones de la clase en otros dos compartimentos dentro del rectngulo.

Representacin visual de una entidad en un diagrama ER

Atributos de la entidadEn los diagramas ER, los atributos de la entidad se muestra con su nombre en un compartimento diferente de la entidad a la que pertenecen.

RestriccionesLas restricciones en los diagramas ER especifican las restricciones de los datos en el esquema de informacin. Existen cuatro tipos de restricciones soportadas por Umbrello:Clave

primaria: El conjunto de atributos declarados como clave primaria es nica para la entidad. Solo puede haber una clave primaria en una entidad y ninguno de los atributos que la componen puede ser NULL. Clave nica: El conjunto de atributos declarados como nica son nicos para la entidad. Pueden haber muchas restricciones nicas en una entidad. Los atributos que lo componen pueden tener el valor NULL. Las claves nicas y primarias identifican de forma nica una fila de una tabla (entidad) Clave externa: Una clave externa es una restriccin referencia entre dos tablas. La clave externa identifica una columna o un conjunto de columnas en un tabla (referenciada) que referencia una columna o conjunto de columnas en otra tabla (referenciada). Las columnas en la tabla referenciada deben formar una clave primaria o una clave nica. Restriccin de comprobacin: Una restriccin de comprobacin (tambin conocida como restriccin de comprobacin de tabla) es una condicin que define los datos vlidos cuando se aaden o actualizan datos en una tabla de la base de datos relacional. Se aplicar una restriccin a cada fila de la tabla. La restriccin debe ser un predicado. Puede referirse a una o varias columnas de la tabla. Ejemplo: precio >= 0

Conceptos del diagrama de relaciones de entidades extendido (EER)EspecializacinLa especializacin es una manera de formar nuevas entidades utilizando entidades que ya se hayan definido. Las entidades nuevas, conocidas como entidades derivadas, asumir (o heredar) atributos de las entidades que ya existan, y que se refieren a las entidades base. Se pretende ayudar a reutilizar datos con pequeas o ninguna modificaciones. En Umbrello, se puede especificar la especializacin de separacin y de solapamientoLa especializacin de separacin

La especializacin de separacin especifica que las subclases de la especializacin se pueden separar. Esto significa que una entidad puede ser miembro de ms de una de las entidades derivadas de la especializacin

Representacin visual de una especializacin de separacin en un diagrama EEREspecializacin de solapamiento

Cuando las entidades derivadas no tienen restricciones para separarse, el conjunto de entidades se dice que estn en una especializacin de solapamiento. sto significa que al igual que en el mundo real la entidad puede ser miembro de ms de una entidad entidad derivada de la especializacin

Representacin visual de la especializacin de solapamiento en un diagrama EERCategora

Una entidad derivada se dice que es una Categora cuando representa una coleccin de objetos que es un subconjunto de unin de distintos tipos de entidades. Una categora se modela cuando se necesita relaciones de superclase/subclase sencillas con ms de una superclase, donde las superclases representan diferentes tipos de entidad (similar a la herencia mltiple en la programacin orientada a objetos).

Representacin visual de una categora en un diagrama EER

Captulo 3. Trabajando con Umbrello UML ModellerTabla de contenidos Interfaz de usuario Ttulo Ventana de documentacin rea de trabajo Crear, cargar y guardar proyectos Nuevo proyecto Guardar modelo Cargar modelo Editar modelo Aadir y eliminar diagramas Crear diagramas Eliminar diagramas Renombrar diagramas

Editar diagramas Insertar diagramas Borrar elementos Editar elementos Editar clases Asociaciones Notas, textos y cajas Este captulo presentar el interfaz de usuario de Umbrello UML Modeller y le informar de todo lo que necesita saber para iniciar su primer esquema. Todas las acciones de Umbrello UML Modeller son accesibles a travs del men y de las barras de herramientas, pero Umbrello UML Modeller tambin hace un constante uso del botn derecho del ratn. Puede utilizar el botn derecho en la prctica totalidad de los elementos del rea de trabajo o de la vista en rbol de Umbrello UML Modeller para abrir un men con las funciones ms tiles aplicables al elemento en particular sobre el que est trabajando. Algunos usuarios encuentran el manejo de estos mens un tanto confuso inicialmente, porque estn ms acostumbrados a trabajar con el men o las barras de herramientas, pero una vez que se acostumbre al botn derecho, ver que puede acelerar enormemente su trabajo.

Interfaz de usuarioLa ventana principal de Umbrello UML Modeller est dividida en tres reas que le ayudarn a mantener una visin general de todo el sistema y a acceder rpidamente a los diferentes diagramas mientras trabaja en su proyecto. Esas reas reciben el nombre de:Vista en rbol rea de trabajo Ventana de documentacin

Interfaz de usuario de Umbrello UML Modeller

TtuloLa vista en rbol est situada en la parte superior izquierda de la ventana, muestra todos los diagramas, clases, actores y casos de uso de los que est compuesto su esquema. Le permite tener una perspectiva de los elementos que componen su esquema. La vista en rbol tambin le proporciona una forma rpida de pasar de un diagrama a otro de su esquema as como de introducir elementos de su esquema en el diagrama actual. Si est trabajando en un modelo con bastantes clases y diagramas, la vista en rbol le puede ayudar a controlarlo todo organizando los elementos de su esquema en carpetas. Puede crear nuevas carpetas seleccionando la opcin adecuada en el men contextual (botn derecho

Ventana de documentacinLa ventana de documentacin es esa venta