Documentos de Académico
Documentos de Profesional
Documentos de Cultura
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 Referencias
7
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
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
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
CASE que cuenta con una versin gratuita denominada Community Edition (enlace externo)
UML.
Referencias [editar]
Martin
(En Castellano
http://www.epidataconsulting.com/tikiwiki/tiki-read_article.php?articleId=15
Introduccin a UML 2.0
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
Introduccin
Al 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
Lenguaje: el UML es, precisamente, un lenguaje. Lo que implica que ste cuenta con una
sintaxis 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.
Superestructura: Es la especificacin que usamos todos los das. Aqu se encuentran todos los
diagramas que la mayora de los desarrolladores conocen.
OCL: Lenguaje de restriccin. De utilidad para especificar conceptos ambiguos sobre los distintos
elementos del diagrama.
:: 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.
OCL
OCL 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.
Infraestructura
En 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.
Superestructura
La 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.
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, Diagramas
de Componentes y Diagramas de despliegue.
Completo (L3): Representa la especificacin del UML 2.0 completa, como por ejemplo: las
Acciones, 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 superestructura
El 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.
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.
Conclusin
A 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.
Bibliografa
Libros 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.
Object-oriented Systems Analysis and Design Using UML de Simon Bennett, Steve McRobb? y
Ray 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
(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 de
Clases
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
Introduccin
En 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
Cambios estructurales
Como 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
Partes (parts): Una parte es una propiedad contenida en un clasificador. Una parte vive y muere
siguiendo 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.
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.
Diagrama de Clases
Uno 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).
Figura 4: Ejemplo de
Diagramas de Despliegue
Segn 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.
6:
Un
Ejemplo
de
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.
Figura
8:
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 Compuestas
Ahora 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.
Extensiones
Las 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.
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.
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 Interaccin
Como 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.
Fragmentos Combinados
Un 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.
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 que
la clave y usuario ingresados son vlidos).
Secuencia de seleccionar una operacin. Las operaciones permitidas por este cajero son cancelar
o extraer dinero.
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.
Nuevas caractersticas en los diagramas: hay muchas nuevas caractersticas en UML 2.0 que
hemos 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), porque
explicarlo 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 la
Ingeniera 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)
Conclusin
En 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
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.
Temario
1. 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
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 <<include>> y <<extend>> 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
Complejidad / Objetos
Entre 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 / Diagramas
Entre 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
que puede realizar (mtodos); las valores asignados a un objeto en determinado momento determinan su estado.
Una
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.
de
Requerimientos:
Por
lo
general
nuevos
diagramas, son fciles de emplear para comunicarse con el cliente final del proyecto.
Generacin
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.
Composicin
Actor:
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:
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
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
(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 <<include>> 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 <<extend>> que origina del uso-caso base hacia el uso caso de extensin.
Ilustracin
diagrama de Actividad
Definicin y Usos
Un 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.
Composicin
Inicio:
de una actividad a otra, la transicin es representada simplemente por una linea con una flecha en su terminacin para indicar direccin.
Ramificacin
posiblidad que ocurra ms de una transicin (resultado) al terminar determinada actividad.Este elemento es representado a travs de un rombo.
Unin
transiciones en una sola transicin o actividad.Este elemento tambin es representado a travs de un rombo.
Expresiones
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
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
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
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
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
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. Introduccin
Umbrello 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
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).
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 UML
Este 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 UML
Diagrama de casos de uso
Los 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.
Caso de uso
Un 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:
<<include>>
que especifica una situacin en la que un caso de uso tiene lugar dentro de otro caso de uso <<extends>> 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.
Actor
Un 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.
Diagrama de clases
Los 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.
Clase
Una 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.
Atributos
En 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:
+ # -
Operaciones
La 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:
+ # -
Plantillas
Las 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 clases
Las clases se puede relaciones (estar asocionadas) con otras de diferentes maneras:
Generalizacin
La 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.
Asociaciones
Una 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.
Acumulacin
Las 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.
Composicin
Las 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.
Interfaces
Las 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 datos
Los 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.
Enumeraciones
Las 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.
Paquetes
Los 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 secuencia
Los 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.
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 colaboracin
Los 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.
Diagrama de estado
Los 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 son
Se 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
Estado
Los 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 actividad
Los 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.
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).
Actividad
Una 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 son
Lnea 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 componentes
Los 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 implementacin
Los 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).
Entidad
Una 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.
Atributos de la entidad
En los diagramas ER, los atributos de la entidad se muestra con su nombre en un compartimento diferente de la entidad a la que pertenecen.
Restricciones
Las 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
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
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
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).
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 usuario
La 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
Ttulo
La 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 documentacin
La ventana de documentacin es esa ventana pequea situada al fondo a la izquierda de Umbrello UML Modeller, le permite previsualizar rpidamente la documentacin para el objeto seleccionado. Esta ventana es bastante pequea debido a que su propsito es darle una rpida nocin del elemento en cuestin sin acaparar mucho espacio en la pantalla. Si desea ver la documentacin ms detalladamente puede abrir las propiedades del objeto.
rea de trabajo
El rea de trabajo es el la ventana principal de Umbrello UML Modeller y donde todo se lleva a cabo la parte importante del trabajo. Aqu es donde editar y ver los diagramas de
su esquema. El rea de trabajo muestra el diagrama sobre el que se est trabajando en cada momento, slo es posible mostrar uno cada vez.
Nuevo proyecto
Si en algn momento necesita crear un nuevo esquema, hgalo seleccionando (NuevoArchivo o pinchando sobre el icono Nuevo en la barra de herramientas. Si est trabajando en un esquema que ha sido modificado, Umbrello UML Modellerle preguntar si quiere o no guardar sus cambios antes de cargar el nuevo esquema.
Guardar modelo
Puede guardar su esquema en cualquier momento seleccionando Guardar desde el men Archivo o pulsando sobre el botn Guardar en la barra de herramientas de la aplicacin. Si necesita guardar su modelo con un nombre diferente puede usar la opcin Guardar como desde el men Archivo. Umbrello UML Modeller tambin le permite ir guardando su trabajo automticamente cada cierto tiempo. Puede indicar si desea o no esta opcin as como el intervalo de tiempo en preferencias.
Cargar modelo
Para cargar un esquema ya existente puede seleccionar la opcin Abrir desde el men Archivo o pulsar sobre el icono Abrir de la barra de herramientas. Puede acceder a los esquemas usados recientemente en el submen Abrir reciente en el men Archivo. Umbrello UML Modeller slo puede trabajar en un slo esquema al mismo tiempo, esto hace que si intenta cargar un nuevo esquema en el programa cuando ha realizado alguna modificacin sobre el que est trabajando, Umbrello UML Modeller le preguntar si quiere guardar sus cambios antes de cerrarlo y abrir el nuevo. Puede iniciar dos o ms instancias de Umbrello UML Modeller al mismo tiempo, tambin puede copiar y pegar entre dos instancias.
Editar modelo
En Umbrello UML Modeller existen bsicamente dos formas de editar los elementos de su modelo.
Editar los elementos del esquema directamente Editarlos a travs de un diagrama.
Usando el men contextual de los distintos elementos de la vista en rbol podr aadir, eliminar y modificar casi todos los elementos de su esquema. Pinchando con el botn derecho del ratn sobre las carpetas en la vista en rbol tambin podr crear diferentes tipos
de diagramas dependiendo si la carpeta en cuestin es vista de caso de uso o vista lgica, actores, casos de uso, clases, etc... Una vez que ha aadido algn elemento a su modelo, podr editarlo mediante su dilogo de propiedades al que podr acceder seleccionando la opcin Propiedades en el men contextual que aparece al pinchar con el botn derecho en los objetos de la vista en rbol. Tambin puede editar su esquema creando o modificando sus elementos por medio de los diagramas. En la siguiente seccin tiene ms detalles de como hacer esto.
Crear diagramas
Para crear un nuevo diagrama en su esquema seleccione el tipo de diagrama que necesita en Nuevo del men Diagrama y asgnele un nombre. Se crear el diagrama y podr verlo en la vista de rbol Recuerde que Umbrello UML Modeller emplea a menudo mens contextuales, tambin puede pulsar botn derecho sobre una carpeta de la vista en rbol y seleccionar el tipo de diagrama que desee desde la opcin Nuevo del men contextual. Observe que puede crear diagramas de caso de uso slo desde las carpetas de vista de casos de uso y los otros tipos de diagramas slo pueden ser creados en las carpetas de vista lgica.
Eliminar diagramas
Si desea eliminar un diagrama de su esquema, puede hacerlo activndolo y seleccionando Borrar desde el men Diagrama. Tambin puede eliminarlo seleccionado Borrar desde el men contxtual del diagrama en la vista en rbol. Dado que el borrado de diagramas es algo delicado porque se puede perder mucho trabajo si se hace accidentalemente, Umbrello UML Modeller le pedir confirmacin antes de eliminar cualquier diagrama. Una vez que un diagrama ha sido borrado y el archivo ha sido guardado, ya no ser posible recuperarlo.
Renombrar diagramas
Si quiere cambiar el nombre de un diagrama ya existente, puede hacerlo seleccionando Renombrar desde el men que le aparece al botn derecho sobre la vista de rbol. Otra forma de renombrar un diagrama es hacerlo a travs de su dilogo de propiedades que puede ver seleccoinado 'Propiedades' desde el men contextual o haciendo doble click sobre la vista de rbol.
Editar diagramas
Cuando est trabajando en un diagrama, Umbrello UML Modeller tratar de ayudarle indicndole algunas sencillas reglas sobre qu elementos son vlidos en los distintos tipos de diagramas as como las relaciones que pueden existir entre ellos. Si usted es un experto
en UML seguramente ni se d cuenta, pero si est empezando le ayudar a crear correctamente diagramas que cumplan el estndar. Una vez que ha creado sus diagramas, es hora de editarlos. Algn novato observador habr observado la diferencia entre editar un diagrama y editar el esquema. Como ya sabr, los diagramas son vistas de su esquema. Por ejemplo, si crea una clase editando un diagrama de clases estar editando el diagrama y el modelo, pero si cambia el color o otra opcin visual en un diagrama de clases, estar editando slo el diagrama sin modificar el esquema.
Insertar diagramas
Una de las primeras cosas que har cuando edite un nuevo diagrama es insertar elementos en ellos (clases, actores, casos de uso,etc.). Existen bsicamente dos formas de hacer esto:
Arrastrando elementos ya existentes en su esqumas desde la vista en rbol. Crear nuevos elementos en su modelo y aadirlos a su diagrama al mismo
tiempo
usando alguna de las herramientas de ediccin de la barra de herramientas. Para introducir elementos ya existentes en su esquema, simplemente arrstrelos desde la vista en rbol y sultelos en el lugar del diagrama donde quiere situarlos. Siempre podr mover elementos en los diagramas empleando la herramienta 'Seleccionar'. la segunda forma de aadir elementos a su diagrama es usando las herramientas de ediccin de la barra de herramientas principal (observe que esto tambin aadir los elementos a su esquema). La barra de herramientas principal est situada, por omisin, en la parte derecha de la ventana de la aplicacin. Desde Umbrello UML Modeller 1.2 se situa en la parte superior de la ventana. Puede situarla en cualquier otra parte o anclarla en otro punto. Las herramientas que contiene (es decir, lo botones que ve sobre ella) cambiarn segn el modelo de diagrama sobre el que est trabajando en cada momento. El botn de la herramienta que est seleccionada en cada momento aparece activado. Podr pasar a la herramienta de seleccin pulsando Esc. Una vez que ha seleccionado una herramienta de edicin en la barra de herramientas de trabajo (por ejemplo la herramienta para insertar clases) el puntero del ratn adopta forma de cruz, ahora puede insertar elementos en su esquema haciendo click en su diagrama. Observe que los elemtos en UML deben tener un nombre nico as que si tiene una clase llamada claseA en un diagrama y utiliza la herramienta insertar para introducir otra clase en otro diagrama, no podr llamarla claseA. Dado que se supone que se trata de elementos diferentes, sus nombres tambin debern serlo. Si lo que quiere hacer es aadir el mismo elemento en su diagrama la herramienta insertar clase no es adecuada para esto, lo que debe hacer es arrastar y soltar la clase desde la vista en rbol.
Borrar elementos
Podr borrar cualquier elemento seleccionando la opcin Borrar desde su men contextual. De nuevo hay una gran diferencia entre eliminar un objeto de un diagrama y eliminarlo de todo el esquema. Si borra un objeto de un diagrama, nicamente lo eliminar de ese diagrama concreto, seguir formando parte de su esquema y si otros diagramas lo usan seguir estando ah. En cambio, si borra el elemento desde la vista en rbol s que lo eliminar completamente de su esquema, con lo que desaparecer de todos los diagramas donde apareca.
Editar elementos
Puede editar la mayora de los elementos de UML de sus esquemas y diagramas abriendo su dilogo de propiedades y seleccionando las opciones pertinentes. Para editar las propiedades de un objeto, seleccione Propiedades desde su men contextual (haciendo botn derecho). Cada elemento tiene un dilogo de varias pginas donde configurar las opciones correspondientes a estos elementos. En algunos elementos, como los actores, slo disponen de un par de opciones como el nombre del objeto y su documentacin mientras que para otros como las clases puede editar sus atributos y operaciones, seleccionar lo que quiere que se vea en el diagrama, incluso los colores. Para la mayora de los elementos UML, si usa la herramienta seleccin (la flecha) puede abrir el dilogo de propiedades haciendo doble click sobre ellos. La exepcin a esto son las asociaciones en cuyo caso un doble click creara un punto de anclaje, para ello tiene que emplear el men contextual (haciendo botn derecho) e ir al dilogo de propiedades. Observe que tambin puede seleccionar la opcin de propiedades desde el men contextual de los elementos en la vista en rbol. Esto tambin le permite editar las propiedades de los diagramas como seleccionar si la rejilla debe o no verse.
Editar clases
Aunque la edicin de propiedades de todos los objetos ya haya sido tratada en la seccin anterior, las clases merecen una explicacin adicional debido a su mayor complejidad y a que poseen ms opciones que la mayora de los elementos de UML. En el dilogo de propiedades de una clase es posible configurar cualquier parmetro, desde el color que emplea hasta sus atributos y operaciones.
Asociaciones
Las asociaciones relacionan dos objetos UML entre si. Normalemente, las asociaciones se definen entre dos clases, sin embargo algunos tipos de asociacin tambin pueden darse entre casos de uso y actores. Para crear una asociacin seleccione la herramienta adecuada en la barra de herramientas de trabajo (asociacin genrica, generalizacin, agregacin, etc.) y pinche primero sobre el primer elemento de la asociacin y luego sobre el segundo. Observe que lo que hacemos son dos clicks, no arrastrar el click de un objeto a otro. Si intenta crear una asociacin que no se ajuste a las especificaciones de UML, Umbrello UML Modeller no aceptar crearla y le mostrar un mensaje de error. Un ejemplo de esto sera si exixtiera una generalizacin desde la clase A hasta la B y tratase de crear otra desde B hasta A. Pulsando con el botn derecho del ratn sobre una asociacin ver un men contextual con las acciones que pueden realizarse. Si quiere borrar una asociacin, simplemente seleccione
la opcin Borrar en ese men contextual. Tambin puede seleccionar la opcin propiedades y, segn el tipo de asociacin, editar los atributosque posea.
Puntos de anclaje
por omisin, las asociaciones se representan mediante una lnea recta que conecta los dos objetos de un diagrama. Podr aadir puntos de anclaje haciendo doble click en cualquier parte de la lnea de asociacin.Esto puntos de anclaje se representan mediante un punto azul cada vez que se selecciona la lnea, podr moverlo a su antojo hasta dar la forma deseada a la (ex)recta de asociacin. Si desea eliminar puntos de anclaje, haga doble click sobre ellos. Observe que el nico modo de editar las propiedades de una asociacin es a travs del men contextual. Si trata de hacer doble click sobre l como hara con cualquier otro objeto UML, se insertar un punto de anclaje.
Anclajes
Los anclajes sirven para unir una nota con otro elemento UML. P. ej. si suele usar una determinada nota para explicar o realizar algn comentario sobre una clase o una asociacin en concreto, puede usar los anclajes para dejar claro que la nota pertenece a esa clase o asociacin y no a otras. Para anclar una nota con otro elemento UML, utilice la herramienta anclaje de la barra de herramientas de trabajo. Primero deber pinchar sobre la nota y luego sobre el elemento UML al que quiere asociar la nota.
crear una maqueta de su sistema a partir del cdigo fuente realizando un anlisis del cdigo e importando las clases encontradas en el.
Generacin de cdigo
Umbrello UML Modeller puede generar cdigo fuente en varios lenguajes de programacin, a partir de la maqueta UML para ayudar a comenzar la implementacin de su proyecto. El cdigo generado consta de declaraciones de clases con sus mtodos y atributos, de forma que usted pueda rellenar los espacios en blanco proporcionando la funcionalidad de las operaciones de sus clases. Umbrello UML Modeller 1.2 viene provisto con soporte para la generacin de cdigo en ActionScript, Ada, C++, CORBA IDL, Java, JavaScript, PHP, Perl, Python, SQL y XMLSchema.
Generacin de cdigo
Para generar cdigo con Umbrello UML Modeller, en primer lugar hay que crear o cargar una maqueta que contenga al menos una clase. Una vez que este listo para comenzar a escribir el cdigo, seleccione el Asistente de generacin de cdigo en el men Cdigo para iniciar un asistente que le guiar a travs del proceso de generacin de cdigo. El primer paso es seleccionar las clases para las que desea generar cdigo fuente. De forma predeterminada se seleccionan todas las clases de la maqueta, y usted puede eliminar aquellas para las que no desea generar cdigo eliminndolas de la lista de la izquierda. El siguiente paso del asistente le permite modificar los parmetros que el generador de cdigo utilizar en el proceso. Las opciones disponibles son las siguientes:
Opciones de generacin
Comentado del Cdigo
La opcin Escribir comentarios de documentacin an si est vaca instruye al Generador de cdigo a escribir comentarios del tipo /** blah */ an cuando el bloque de comentarios se encuentre vaco. Si usted ya agreg documentacin a sus clases, mtodos o atributos en su Maqueta, el Generador de cdigo escribir estos comentarios como documentacin Doxygen sin importar lo que haya definido aqu, pero si selecciona esta opcin Umbrello UML Modeller escribir comentarios para todas sus clases, mtodos y atributos an cuando no exista documentacin en la Maqueta, en cuyo caso usted deber documentar sus clases ms tarde editando directamente el cdigo fuente. Escribir comentarios para las secciones incluso si la seccin est vaca producir que Umbrello UML Modeller escriba comentarios en el cdigo fuente para delimitar las diferentes secciones de una clase. Por ejemplo Mtodos pblicos o Atributos antes de la seccin correspondiente. Si selecciona esta opcin Umbrello UML Modeller escribir los comentarios para todas las secciones de las clases an si la seccin est vaca. Por ejemplo, escribir un comentario diciendo Mtodos protegidos an si no existen mtodos protegidos en su clase.
Carpetas
Escribir todos los archivos generados a la carpeta. Aqu debe seleccionar la carpeta donde desea que Umbrello UML Modeller guarde los archivos fuente generados. La opcin Incluir archivos de cabecera desde la carpeta le permite insertar un encabezado al comienzo de cada archivo generado. Los archivos de encabezado pueden contener informacin acerca del copyright o la licencia, y contener variables que son evaluadas al momento de generacin. Usted puede puede mirar a modo de ejemplo los archivos de encabezamiento distribuidos con Umbrello UML Modeller para ver como se utilizan estas variables para reemplazar su nombre o la fecha y hora del momento de generacin.
Poltica de sobreescritura
Esta opcin le dice a Umbrello UML Modeller qu hacer si el archivo que desea crear ya existe en la carpeta de destino. Umbrello UML Modeller no puede modificar archivos fuente existentes, por lo que debe elegir entre sobreescribir el existente, saltar la generacin de ese archivo en particular, o dejar que Umbrello UML Modeller elija un nombre diferente para el archivo. Si uste elije la opcin de utilizar un nombre diferente, Umbrello UML Modeller agregar un sufijo al nombre del archivo.
Lenguaje
Umbrello UML Modeller generar por omisin cdigo fuente en el lenguaje que usted haya seleccionado como Lenguaje activo, pero con el Asistente para la generacin de cdigo usted tiene la opcin de cambiar esto a otro idioma.
Importacin de cdigo
Umbrello UML Modeller puede importar cdigo fuente de sus pryectos actuales para ayudarle a crear los esquemas de sus sistemas. Umbrello UML Modeller 1.2 slo puede hacerlo con C++ aunque en el futuro estar disponible para ms lenguajes. Para importar clases en su esquema seleccione la entrada Importar clases desde el men Cdigo. Una vez ah, seleccione los archivos que contengan las declaraciones de clases de C++ y pulse aceptar. Se importaran las clases y pasarn a ser parte de su esquema en la vista en rbol. Recuerde que Umbrello UML Modeller no crear ningn tipo de diagrama para mostrar sus clases, slo las importar a su esquema para que pueda usarlas luego en cualquier diagrama.
Impresin
Umbrello UML Modeller le permite imprimir diagramas individuales. Pulse el botn Imprimir en la barra de herramientas de aplicacin o seleccione la opcin Imprimir en el men Archivo para obtener un dilogo de impresin estndar de KDE donde podr imprimir los diagramas.
Carpetas lgicas
Para organizar mejor la maqueta, especialmente en los proyectos grandes, es posible crear carpetas lgicas en la vista de rbol. Basta con que seleccione la opcin Nueva->Carpeta en el men contextual de la carpeta predeterminada en la vista de rbol. Las carpetas se pueden anidar, puede mover objetos de una a otras por el procedimiento normal de arrastrar y soltar.
en ponerse en contacto con los desarrolladores. Hay muchas formas para ayudar en el desarrollo de Umbrello UML Modeller
Informando de fallos o sugerencias Arreglando fallos o aadiendo funcionalidad Escribiendo buena documentacin o traducindola Y, por supuesto... programando con nosotros
a otros idiomas
Como puede ver, hay muchas formas en las que puede contribuir. Todas ellas son muy importantes y todo el mundo es bienvenido. Puede contactar con los desarrolladores de Umbrello UML Modeller en (uml-devel AT lists.sourceforge.net).