UNIDAD EDUCATIVA VICENTE ANDA AGUIRRE SECCIN DIURNA LA DOLOROSA

MANUAL DE DIAGRAMAS DE UML

NOMBRE: DANIEL ROJAS ORDOEZ

CURSO: 3RO INFORMTICA

ING: JORGE SARMIENTO

AO LECTIVO 2011 - 2012

DIAGRAMAS DE UML INTRODUCCIN En este manual daremos un recorrido por las partes ms importantes de los diagramas de UML e intentaremos. El Lenguaje Unificado de Modelado (Unified Modeling Languaje, UML) es el lenguaje estndar para realizar el modelado de los sistemas de software y es independiente del lenguaje de programacin utilizado. 1. DIAGRAMAS ESTTICOS. Un diagrama de estructura esttica muestra el conjunto de clases y objetos importantes que hacen parte de un sistema, junto con las relaciones existentes entre estas clases y objetos. Muestra de una manera esttica la estructura de informacin del sistema y la visibilidad que tiene cada una de las clases, dada por sus relaciones con las dems en el modelo. Supongamos el modelamiento de una mquina de caf. Un diagrama de estructura esttica inicial podra ser:

Elementos: Clase Representada por un rectngulo con tres divisiones internas, son los elementos fundamentales del diagrama.

Una clase describe un conjunto de objetos con caractersticas y comportamiento idntico. En el ejemplo se encuentran las clases Ingrediente, Producto, Maquina, Deposito Monedas y Deposito Monedas Iguales. Los tres compartimientos estndares alojan el nombre de la clase, sus atributos y sus mensajes, respectivamente. Atributo Identifican las caractersticas propias de cada clase. Generalmente son de tipos simples, ya que los atributos de tipos compuestos se representan mediante asociaciones de composicin con otras clases. La sintaxis de un atributo es visibility name : type-expression = initial-value { property-string } Donde visibility es uno de los siguientes: + public visibility

# protected visibility private visibility

type-expression es el tipo del atributo con nombre name. Puede especificarse como se ve un valor inicial y un conjunto de propiedades del atributo. En el caso del ejemplo, la clase Ingrediente tiene dos atributos: uno denominado cantidad, de tipo float y con

valor inicial 0; y el atributo nombre de tipo string sin valor inicial. En este caso, la herramienta utilizada ha cambiado la representacin de la visibilidad, utilizando el smbolo para indicar visibilidad privada, el smbolo para visibilidad protegida y el smbolo para indicar visibilidad pblica. Operacin El conjunto de operaciones describen el comportamiento de los objetos de una clase. La sntaxis de una operacin en UML es visibility name ( parameter-list ) : return-typeexpression { property-string } Cada uno de los parmetros en parameter-list se denota igual que un atributo. Los dems elementos son los mismos encontrados en la notacin de un atributo. Asociacin (rol, multiplicidad, cualificador) Una asociacin en general es una lnea que une dos o ms smbolos. Pueden tener varios tipos de adornos, que definen su semntica y caractersticas. Los tipos de asociaciones entre clases presentes en un diagrama esttico son: 1. 2. 3. 4. 5. Asociacin binaria Asociacin n-aria Composicin Generalizacin Refinamiento

Cada asociacin puede presentar algunos elementos adicionales que dan detalle a la relacin, como son: Rol: Identificado como un nombres al los finales de la lnea, describe la semntica de la relacin en el sentido indicado. Por ejemplo, la asociacin de composicin entre Maquina e Ingrediente recibe el nombre de existencias, como rol en ese sentido Multiplicidad: Describe la cardinalidad de la relacin. En el ejemplo anterior se utilizan 1, 1 ..*, 5, *, como indicadores de multiplicidad. Asociacin binaria Se identifica como una lnea slida que une dos clases. Representa una relacin de algn tipo entre las dos clases, no muy fuerte ( es decir, no se exige dependencia existencial ni encapsulamiento). En posible ejemplo es la relacin entre una compaa y sus empleados

en este caso la relacin recibe el nombre genrico Trabaja Para, la compaa tiene uno o ms instancias de la clase Persona denominadas empleado y cada empleado conoce su empleador (en este caso nico). Composicin

Es una asociacin fuerte, que implica tres cosas

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

Se denota dibujando un rombo relleno del lado de la clase que contiene a la otra en la relacin. En el ejemplo inicial de esta hoja se presentan varios ejemplos de relaciones de composicin entre Maquina y Producto, Maquina y DepositoMonedas y Maquina y DepositoMonedasIguales. Existe tambin una relacin de composicin menos fuerte (no se exige dependencia existencial, por ejemplo) que es denotada por una un rombo sin rellenar en uno de los extremos. Un ejemplo puede encontrarse entre Producto e Ingrediente. Generalizacin La relacin de generalizacin denota una relacin de herencia entre clases. Se representa dibujando un tringulo sin rellenar en el lado de la superclase. La subclase hereda todos los atributos y mensajes descritos en la superclase. En el ejemplo se encuentra una generalizacin entre DepositoMonedas (superclase) y DepositoMonedasIguales (subclase).

Clase paramtrica Una clase paramtrica representa el concepto de clase genrica en los conceptos bsicos OO o de template en C++. Se dibuja como una clase acompaada de un rectngulo en la esquina superior derecha, con los parmetros del caso. Por ejemplo, la clase Lista que utiliza un parmetro formal Tipo se vera de la siguiente manera

Paquete Un paquete es una forma de agrupar clases (u otros elementos en otro tipo de diagramas) en modelos grandes. Pueden tener asociaciones de dependencia o de generalizacin entre ellos. Un ejemplo puede ser el siguiente

En este caso existen tres paquetes (que se muestran vacios en este caso, con su contenido encapsulado), con dos de ellos dependiendo del Modelo del Mundo Dependencia Denota una relacin semntica entre dos elementos (clases o paquetes, por el momento) del modelo. Indica que cambiar el elemento independiente puede requerir cambios en los dependientes. Se muestra como una lnea punteada direccional, indicando el sentido de la dependencia. Puede tener por medio de estereotipos una explicacin del tipo de dependencia presentada. En el ejemplo anterior pueden verse dos relaciones de dependencia hacia el paquete Modelo del Mundo.

Nota Es un comentario dentro de un diagrama. Puede estar relacionado con uno o ms elementos en el diagrama mediante lneas punteadas. Pueden representar aclaraciones al diagrama o restricciones sobre los

elementos relacionados (cuando el texto se encuentra entre '['y ']'). Se representa mediante un rectngulo con su borde superior derecho doblado. En el ejemplo inicial de esta hoja se encuentran dos notas: Una relacionada con la clase mquina y otra con el depsito de monedas iguales. DIAGRAMAS DE CLASES Un diagrama de clases es un tipo de diagrama esttico que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los Jdiagramas de clases son utilizados durante el proceso de anlisis y diseo de los sistemas, donde se crea el diseo conceptual de la informacin que se manejar en el sistema, y los componentes que se encargarn del funcionamiento y la relacin entre uno y otro. Elementos: Clases: Se pueden definir como la descripcin de un conjunto de objetos con las mismas propiedades. Puede ser un concepto del mundo real, se puede decir que es una plantilla para crear objetos. Relaciones: Las relaciones pueden ser de distintos tipos asociacin, agregacin, herencia (generalizacin, especializacin).

DIAGRAMA DE OBJETOS. Los diagramas de objetos son utilizados durante el proceso de Anlisis y Diseo de los sistemas informticos en la metodologa UML. Se puede considerar un caso especial de un diagrama de clases en el que se muestran instancias especficas de clases (objetos) en un momento particular del sistema. Los diagramas de objetos utilizan un subconjunto de los elementos de un diagrama de clase. Los diagramas de objetos no muestran la multiplicidad ni los roles, aunque su notacin es similar a los diagramas de clase. Una diferencia con los diagramas de clase es que el compartimiento de arriba va en la forma Nombre de objeto: Nombre de clase. Clase Es la unidad bsica que encapsula toda la informacin de un Objeto (un objeto es una instancia de una clase). A travs de ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.). Como se representa En UML, una clase es representada por un rectngulo que posee tres divisiones:

Casos Particulares:
o

Clase Abstracta:

Una clase abstracta se denota con el nombre de la clase y de los mtodos con letra "itlica". Esto indica que la clase definida no puede ser instanciada pues posee mtodos abstractos (an no han sido definidos, es decir, sin implementacin).

La nica forma de utilizarla es definiendo subclases, que implementan los mtodos abstractos definidos.
o

Clase parametrizada:

Una clase parametrizada se denota con un subcuadro en el extremo superior de la clase, en donde se especifican los parmetros que deben ser pasados a la clase para que esta pueda ser instanciada. El ejemplo ms tpico es el caso de un Diccionario en donde una llave o palabra tiene asociado un significado, pero en este caso las llaves y elementos pueden ser genricos. La genericidad puede venir dada de un Template (como en el caso de C++) o bien de alguna estructura predefinida (especializacin a travs de clases). En el ejemplo no se especificaron los atributos del Diccionario, pues ellos dependern exclusivamente de la implementacin que se le quiera dar. Ejemplo: Supongamos que tenemos un el caso del Diccionario implementado mediante un rbol binario, en donde cada nodo posee:

key: Variable por la cual se realiza la bsqueda, puede ser genrica. item: Contenido a almacenar en el diccionario asociado a "key", cuyo tipo tambin puede ser genrico.

Para este caso particular hemos definido un Diccionario para almacenar String y Personas, las cuales pueden funcionar como llaves o como item, solo se mostrarn las relaciones para la implementacin del Diccionario:

RELACIONES ENTRE CLASES:

Ahora ya definido el concepto de Clase, es necesario explicar cmo se pueden interrelacionar dos o ms clases (cada uno con caractersticas y objetivos diferentes). Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en cada extremo de la relacin y stas pueden ser:

uno o muchos: 1..* (1..n)

0 o muchos: 0..* (0..n) nmero fijo: m (m denota el nmero).

Asociacin:

La relacin entre clases conocida como Asociacin, permite asociar objetos que colaboran entre si. Cabe destacar que no es una relacin fuerte, es decir, el tiempo de vida de un objeto no depende del otro. Ejemplo:

Un cliente puede tener asociadas muchas rdenes de Compra, en cambio una orden de compra solo puede tener asociado un cliente. Dependencia o Instanciacin (uso): Representa un tipo de relacin muy particular, en la que una clase es instanciada (su instanciacin es dependiente de otro objeto/clase). Se denota por una flecha punteada. El uso ms particular de este tipo de relacin es para denotar la dependencia que tiene una clase de otra, como por ejemplo una aplicacin grafica que instancia una ventana (la creacin del Objeto Ventana est condicionado a la instanciacin proveniente desde el objeto Aplicacin):

Cabe destacar que el objeto creado (en este caso la Ventana grfica) no se almacena dentro del objeto que lo crea (en este caso la Aplicacin). Generalizacin La relacin de generalizacin denota una relacin de herencia entre clases. Se representa dibujando un tringulo sin rellenar en el lado de la superclase. La subclase hereda todos los atributos y mensajes descritos en la superclase. En el ejemplo se encuentra una generalizacin entre Deposito Monedas (superclase) y Deposito Monedas Iguales (subclase).

Agregacin: Para modelar objetos complejos, n bastan los tipos de datos bsicos que proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollador de la aplicacin, tenemos dos posibilidades:

Por Valor: Es un tipo de relacin esttica, en donde el tiempo de vida del objeto incluido est condicionado por el tiempo de vida del que lo incluye. Este tipo de relacin es comnmente llamada Composicin (el Objeto base se

construye a partir del objeto incluido, es decir, es "parte/todo"). Por Referencia: Es un tipo de relacin dinmica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. Este tipo de relacin es comnmente llamada Agregacin (el objeto base utiliza al incluido para su funcionamiento).

Un Ejemplo es el siguiente:

En donde se destaca que:

Un Almacn posee Clientes y Cuentas (los rombos van en el objeto que posee las referencias). Cuando se destruye el Objeto Almacn tambin son destruidos los objetos Cuenta asociados, en cambio no son afectados los objetos Cliente asociados. La composicin (por Valor) se destaca por un rombo relleno. La agregacin (por Referencia) se destaca por un rombo transparente.

La flecha en este tipo de relacin indica la navegabilidad del objeto referenciado. Cuando no existe este tipo de particularidad la flecha se elimina.

Composicin: La composicin es un tipo de relacin esttica, en donde el tiempo de vida del objeto incluido est condicionado por el tiempo de vida del que lo incluye (el objeto base se construye a partir del objeto incluido, es decir, es parte/todo). En la siguiente figura podr observar un ejemplo de este tipo de relacin:

Ejemplo diagrama de clases

DIAGRAMA DE COMPONENTES Un diagrama de componentes es un diagrama tipo del Lenguaje Unificado de Modelado. Un diagrama de componentes representa cmo un sistema de software es dividido en componentes y muestra las dependencias entre estos componentes. Los componentes fsicos incluyen archivos, cabeceras, bibliotecas compartidas, mdulos, ejecutables, o paquetes. Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser

usados para modelar arquitectura de sistema. Elementos: Componente

documentar

cualquier

Elemento de funcionalidad del sistema reutilizable. Un componente proporciona y utiliza el comportamiento a travs de las interfaces y puede hacer uso de otros componentes. Los elementos internos de un componente se pueden mostrar u ocultar con el control de expandir y contraer (9). Un componente es un tipo de clase.

Is Indirectly Instantiated. Si es true (valor predeterminado), el componente solo existe como artefacto de diseo. Solo existen sus elementos en tiempo de ejecucin.

Puerto de interfaz proporcionada Representa un grupo de mensajes o llamadas que un componente implementa y que otros componentes o sistemas externos pueden utilizar. Un puerto es una propiedad de un componente que tiene una interfaz como tipo.

Puerto de interfaz necesaria Representa un grupo de mensajes o llamadas que el componente enva a otros componentes o sistemas externos. El componente est diseado para que se acople a los componentes que proporcionan al menos estas operaciones. El puerto tiene una interfaz como tipo. Dependencia Se puede utilizar para indicar que una interfaz necesaria de un componente se puede satisfacer mediante una interfaz proporcionada de otro. Las dependencias tambin se pueden utilizar con ms frecuencia entre los elementos del modelo para mostrar que el diseo de uno depende del diseo del otro. Parte Atributo de un componente cuyo tipo normalmente es otro componente. Los elementos se utilizan en el diseo interno de su componente primario. Los elementos se muestran de forma grfica, anidados dentro del componente primario. Para crear un elemento de un tipo del componente existente, arrastre el componente del Explorador de modelos UML al componente propietario. Para crear un elemento de un nuevo tipo, haga clic en la herramienta Componente y, a continuacin, en el componente propietario.

Por ejemplo, un componente Car tiene los elementos engine:CarEngine, backLeft:Wheel, frontRight:Wheel, etc. Varios elementos pueden tener el mismo tipo y varios componentes distintos pueden tener elementos del mismo tipo.

Tipo. Tipo del elemento, que se define en otra parte del modelo. Normalmente, el tipo es otro componente. Multiplicity. El valor predeterminado es 1. Puede establecerse en 0..1 para indicar que el elemento puede tener el valor null, en * para indicar que el elemento es una coleccin de instancias del tipo especificado, o en cualquier expresin que se pueda evaluar como un intervalo de nmeros.

Ensamblado de elementos Conexin entre los puertos de la interfaz necesaria de un elemento y los puertos de la interfaz proporcionada de otro. La implementacin de un ensamblado de elementos puede variar de un componente a otro. Los elementos conectados deben tener el mismo componente primario. Delegacin Vincula un puerto a una interfaz de uno de los elementos del componente. Indica que los mensajes enviados al componente se administran en el elemento o que los mensajes enviados desde el elemento se envan fuera del componente primario.

Generalizacin Indica que un componente hereda de otro componente. Los elementos y las interfaces se heredan. Control de expandir y contraer Utilice este control para mostrar u ocultar los elementos internos de un componente. (no se muestra) Comentario Se utiliza para agregar notas adicionales. Puede vincular un comentario a cualquier nmero de elementos del diagrama mediante la herramienta Conector.

DIAGRAMA DE DESPLIEGUE El Diagrama de Despliegue es un tipo de diagrama del Lenguaje Unificado de Modelado que se utiliza para modelar el hardware utilizado en las implementaciones de sistemas y las relaciones entre sus componentes. Los elementos usados por este tipo de diagrama son nodos (representados como un prisma), componentes (representados como una caja rectangular con dos protuberancias del lado izquierdo) y asociaciones. En el UML 2.0 los componentes ya no estn dentro de nodos. En cambio, puede haber artefactos u otros nodos dentro de un nodo. Este tipo de diagrama debemos tambin aadir que no van a existir actores para relacionarse con los nodos (no es un diagrama de casos de uso) si no que las relaciones que pueda haber siempre sern entre los nodos y por ejemplo con una base de datos. Elementos: Nodo Un nodo es un objeto fsico en tiempo de ejecucin que representa un recurso computacional, generalmente con memoria y capacidad de procesamiento. Un Nodo es un elemento de hardware o software. Instancia de nodo Una instancia se puede distinguir desde un nodo por el hecho de que su nombre esta subrayado y tiene dos

puntos antes del tipo de nodo base. Una instancia puede o no tener un nombre antes de los dos puntos. Estereotipo de nodo Estereotipo, son cosas u objetos q se repiten sin variacin. El estereotipo de un nodo es la manera de poder verificar que tipo de nodo es el que se est observando. Artefactos Un artefacto es un producto del proceso de desarrollo de software, que puede incluir los modelos del proceso (modelos de Caso de uso, modelos de Diseo, etc.), archivos fuente, ejecutables, documentos de diseo, reportes de prueba, prototipos, manuales de usuario etc. Donde un artefacto es un conjunto de componentes. Asociacin Una asociacin representa una ruta de comunicacin entre los nodos. Donde esta asociacin va incluida con misma dependencia del diagrama de componentes. Ejemplo Diagrama de Despliegue

DIAGRAMAS DINAMICOS. El modelo dinmico se usa para expresar y modelar el comportamiento del sistema a lo largo del tiempo, con el que describe las relaciones temporales entre objetos. Muestran las interacciones entre objetos ocurridas en un escenario del sistema. DIAGRAMAS DE CASOS DE USO En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una especie de diagrama de comportamiento. UML mejorado El Lenguaje de Modelado Unificado define una notacin grfica para representar casos de uso llamada modelo de casos de uso. UML no define estndares para que el formato escrito describa los casos de uso, y as mucha gente no

entiende que esta notacin grfica define la naturaleza de un caso de uso; sin embargo una notacin grfica puede solo dar una vista general simple de un caso de uso o un conjunto de casos de uso. Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras los dos conceptos estn relacionados, los casos de uso son mucho ms detallados que los diagramas de casos de uso. Elementos Actor: Un actor representa quien o que inicia una accin dentro del sistema, en otras palabras, es simplemente un rol que es llevado a cabo 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 lnea recta que se extiende de la figura del actor hacia el ovalo del uso-caso. Limite de Sistema (System Boundry): Empleado para delimitar los lmites del sistema, y representado por un rectngulo con color de fondo distintivo. Generalizacin: Una generalizacin indica que un usocaso (ovalo) es un caso especial de otro caso, en otros trminos, representa una relacin padre-hijo, donde el hijo puede ser suplido directamente por el padre en

cualquier momento. Este elemento es representado por una lnea 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 lnea 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 a otro, aunque similar a una generalizacin, una extensin representa una dependencia especifica, mientras una generalizacin no implica que los usos-casos dependen uno del otro. Este elemento es representado por una lnea punteada con flecha y comentario <<extend>> que origina del usocaso base hacia el uso caso de extensin. RELACIONES DE CASOS DE USO Las tres relaciones principales entre los casos de uso son soportadas por el estndar UML, el cual describe notacin grfica para esas relaciones. Veamos una revisin de ellas a continuacin: Inclusin (include o use) Es una forma de interaccin o creacin, un caso de uso dado puede "incluir" otro caso de uso. El primer caso de uso a menudo depende del resultado del caso de uso incluido. Esto es til para extraer comportamientos verdaderamente comunes desde mltiples casos de uso a

una descripcin individual, desde el caso de uso. El estndar de Lenguaje de Modelado Unificado de OMG define una notacin grfica para realizar diagramas de casos de uso, pero no el formato para describir casos de uso. Mucha gente sufre la equivocacin pensando que un caso de uso es una notacin grfica (o es su descripcin). Mientras la notacin grfica y las descripciones esto no sirve.. Extensin (Extend) Es otra forma de interaccin, un caso de uso dado (la extensin) puede extender a otro. Esta relacin indica que el comportamiento del caso de la extensin se utiliza en casos de uso, un caso de uso a otro caso siempre debe tener extensin o inclusin. El caso de uso extensin puede ser insertado en el caso de uso extendido bajo ciertas condiciones. La notacin, es una flecha de punta abierta con lnea discontinua, desde el caso de uso extensin al caso de uso extendido, con la etiqueta extend. Esto puede ser til para lidiar con casos especiales, o para acomodar nuevos requisitos durante el mantenimiento del sistema y su extensin. "La extensin, es el conjunto de objetos a los que se aplica un concepto. Los objetos de la extensin son los ejemplos o instancias de los conceptos." Generalizacin "Entonces la Generalizacin es la actividad de identificar elementos en comn entre conceptos y definir las relaciones de una superclase (concepto general) y subclase (concepto especializado). Es una manera de construir clasificaciones taxonmicas entre

conceptos que entonces se representan en jerarquas de clases. Las subclases conceptuales son conformes con las superclases conceptuales en cuanto a la intencin y extensin." En la tercera forma de relaciones entre casos de uso, existe una relacin generalizacin/especializacin. Un caso de uso dado puede estar en una forma especializada de un caso de uso existente. La notacin es una lnea slida terminada en un tringulo dibujado desde el caso de uso especializado al caso de uso general. Esto se asemeja al concepto orientado a objetos de sub-clases, en la prctica puede ser til factorizar comportamientos comunes, restricciones al caso de uso general, describirlos una vez, y enfrentarse a los detalles excepcionales en los casos de uso especializados. ESTEREOTIPOS ESTNDAR PARA MODELOS UML Los estereotipos siguientes se pueden usar para especializar el significado de los elementos del modelo UML, a menos que el vnculo al perfil se haya quitado del modelo. El significado exacto de estos estereotipos est determinado por las convenciones locales y por las herramientas que pueden usarse para procesar el modelo.

Los estereotipos siguientes se pueden usar para especializar el significado de los elementos del modelo UML, a menos que el perfil se haya desvinculado del modelo. El significado exacto de estos estereotipos est determinado por las convenciones locales y por las herramientas que pueden usarse para procesar el modelo.

DIAGRAMAS DE SECUENCIA.

Los diagramas de secuencia se usan para mostrar la interaccin entre los usuarios, las pantallas y las instancias de los objetos en el sistema. Proveen un mapa secuencial del paso de los mensajes entre los objetos a lo largo del tiempo. Frecuentemente, estos diagramas se ubican bajo los casos de uso o los componentes en el modelo para ilustrar un escenario -cmo interacta un usuario con el sistema y qu sucede internamente para que el trabajo se lleve a cabo-. Muchas veces, los objetos se representan utilizando conos especialmente estereotipados, como en el ejemplo de abajo. El objeto etiquetado "PantallaDeIngreso" (Login Screen) se muestra empleando el cono de interfaz. El objeto etiquetado "AdministradorDeSeguridad" (SecurityManager) se muestra usando el cono controlador. El objeto etiquetado "Usuarios" (Users) se muestra usando el cono entidad. Elementos: Lnea de vida

Una lnea vertical que representa la secuencia de eventos que se producen en un participante durante una interaccin, mientras el tiempo avanza. Este participante puede ser una instancia de una clase, componente o actor. Actor Un participante que es externo al sistema que est desarrollando. Puede hacer que aparezca un smbolo de actor en la parte superior de una lnea de vida estableciendo su propiedad Actor. Mensaje sincrnico El remitente espera una respuesta a un mensaje sincrnico antes de continuar. El diagrama muestra la llamada y el retorno. Los mensajes sincrnicos se utilizan para representar llamadas de funcin ordinarias dentro de un programa, as como otros tipos de mensaje que se comportan de la misma manera. Mensaje asincrnico Un mensaje que no requiere una respuesta antes de que el remitente contine. Un mensaje asincrnico muestra slo una llamada del remitente. Se utiliza para representar la comunicacin entre subprocesos diferentes o la creacin de un nuevo subproceso.

Incidencia de ejecucin Un rectngulo sombreado vertical que aparece en la lnea de la vida de un participante y representa el perodo durante el que el participante est ejecutando una operacin. La ejecucin comienza donde el participante recibe un mensaje. Si el mensaje inicial es un mensaje sincrnico, la ejecucin finalizar con una flecha de devolucin al remitente. Mensaje de devolucin de llamada Un mensaje que vuelve a un participante que est esperando la devolucin de una llamada anterior. La aparicin de ejecucin resultante aparece encima de la existente. Auto mensaje Un mensaje de un participante a s mismo. La aparicin de ejecucin resultante aparece encima de la ejecucin de envo. Crear mensajes Un mensaje que crea un participante. Si un participante recibe un mensaje de creacin, este debe ser el primer mensaje que recibe.

Mensaje encontrado Un mensaje asincrnico de un participante desconocido o no especificado. Mensaje perdido Un mensaje asincrnico a un participante desconocido o no especificado. Comentarios Un comentario se puede adjuntar a cualquier punto de una lnea de vida. Uso de interaccin Agrega una secuencia de mensajes que se definen en otro diagrama. Para crear un Uso de interaccin, haga clic en la herramienta y arrastre por las lneas de vida que desee incluir. Fragmento combinado Una coleccin de fragmentos. Cada fragmento puede agregar uno o ms mensajes. Existen distintos tipos de fragmentos combinados. Para obtener ms informacin, vea Describir el flujo de control con fragmentos de diagramas de secuencia de UML.

Para crear un fragmento, haga clic con el botn secundario en un mensaje, elija Rodear con y, a continuacin, haga clic en un tipo de fragmento. Proteccin de fragmentos Se puede utilizar para enunciar una condicin relativa a si el fragmento se producir. Para establecer la proteccin, seleccione un fragmento, seleccione despus la proteccin y escriba un valor. Interaccin La coleccin de mensajes y lneas de vida que se muestra en el diagrama de secuencia. Para ver las propiedades de una interaccin, debe seleccionarla en el Explorador de modelos UML. Diagrama de secuencia Diagrama en el que se muestra una interaccin. Para ver sus propiedades, haga clic en una parte vaca del diagrama.

DIAGRAMA DE COLABORACIN. Un diagrama de colaboracin en las versiones de UML 1.x es esencialmente un diagrama que muestra interacciones organizadas alrededor de los roles. A diferencia de los diagramas de secuencia, los diagramas de colaboracin, tambin llamados diagramas de comunicacin, muestran explcitamente las relaciones de los roles. Por otra parte, un diagrama de

comunicacin no muestra el tiempo como una dimensin aparte, por lo que resulta necesario etiquetar con nmeros de secuencia tanto la secuencia de mensajes como los hilos concurrentes.

Muestra cmo las instancias especficas de las clases trabajan juntas para conseguir un objetivo comn. Implementa las asociaciones del diagrama de clases mediante el paso de mensajes de un objeto a otro. Dicha implementacin es llamada "enlace".

DIAGRAMA DE ACTIVIDADES. En UML un diagrama de actividades se usa para mostrar la secuencia de actividades. Los diagramas de actividades muestran el flujo de trabajo desde el punto de inicio hasta el punto final detallando muchas de las rutas de decisiones que existen en el progreso de eventos contenidos en la actividad. Estos tambin pueden usarse para detallar situaciones donde el proceso paralelo puede ocurrir en la ejecucin de algunas actividades. Los Diagramas de Actividades son tiles para el Modelado de Negocios donde se usan para

detallar el proceso involucrado en las actividades de negocio. Elementos: Actividades Una actividad es la especificacin de una secuencia parametrizada de comportamiento. Una actividad muestra un rectngulo con las puntas redondeadas adjuntando todas las acciones, flujos de control y otros elementos que constituyen la actividad.

Acciones Una accin representa un solo paso dentro de una actividad. Las acciones se denotan por rectngulos con las puntas redondeadas.

Restricciones de Accin Las restricciones se pueden adjuntar a una accin. El siguiente diagrama muestra una accin con pre y post condiciones locales.

Flujo de Control Un flujo de control muestra el flujo de control de una accin a otra. Su notacin es una lnea con una punta de flecha.

Nodo Inicial Un nodo inicial o de comienzo se describe por un gran punto negro, como se muestra a continuacin.

Nodo Final Hay dos tipos de nodos finales: nodos finales de actividad y de flujo. El nodo final de actividad se describe como un crculo con un punto dentro del mismo.

El nodo final de flujo se describe como un crculo con una cruz dentro del mismo.

La diferencia entre los dos tipos de nodos es que el nodo final del flujo denota el final de un solo flujo de control, y el nodo final de actividad denota el final de todos los flujos finales dentro de la actividad.

Flujos de Objetos y Objeto Un flujo de objeto es la ruta a lo largo de la cual pueden pasar objetos o datos. Un objeto se muestra cmo un rectngulo.

Un flujo de objeto se muestra como un conector con una punta de flecha denotando la direccin a la cual se est pasando el objeto.

Un flujo de objeto debe tener un objeto en por lo menos uno de sus extremos. Una notacin de acceso rpido para el diagrama de arriba sera usar los pins de salidas y entradas.

Un almacn de clave se muestra como un objeto con las clave datastore.

Nodos de Decisin y Combinacin Los nodos de decisin y combinacin tienen la misma notacin: una forma de diamante. Los dos se pueden nombrar. Los flujos de control que provienen de un nodo de decisin tendrn condiciones de guarda que permitirn el control para fluir si la condicin de guarda se realiza. El siguiente diagrama muestra el uso de un nodo de decisin y un nodo de combinacin.

Nodos de Bifurcacin y Unin Las bifurcaciones y uniones tienen la misma notacin: tanto una barra horizontal como vertical (la orientacin

depende de si el flujo de control va de derecha a izquierda o hacia abajo y arriba. Estos indican el comienzo y final de hilos actuales de control. El siguiente diagrama muestra un ejemplo de su uso.

Una unin es diferente de una combinacin ya que la unin sincroniza dos flujos de entrada y produce un solo flujo de salida. El flujo de salida desde una unin no se puede ejecutar hasta que todos los flujos se hayan recibido. Una combinacin pasa cualquier flujo de control directamente a travs de esta. Si dos o ms flujos de entrada se reciben por un smbolo de combinacin, la accin a la que el flujo de salida apunta se ejecuta dos o ms veces. Regin de Expansin Una regin de expansin es una regin de actividad estructurada que se ejecuta muchas veces. Los nodos de expansin de salida y entrada se dibujan como un grupo de tres casillas representando una seleccin mltiple de tems. La clave reiterativa, paralelo, o flujo se muestra en la esquina izquierda arriba de la regin.

Gestores de Excepcin Los gestores de Excepcin se pueden modelar en diagramas de actividad como en siguiente ejemplo.

Regin de Actividad Interrumpible Una regin de actividad interrumpible rodea un grupo de acciones que se pueden interrumpir. En un ejemplo simple como el siguiente, la accin Procesar Orden se ejecutar hasta su cumplimiento cuando pase control a la accin Cerrar Orden, a menos que una interrupcin Cancelar Pedido se reciba, la cual pasar el control a la accin Cancelar Orden.

Particin Una particin de una actividad se muestra como calles horizontales o verticales. En el siguiente diagrama, las particiones se usan para separar acciones dentro de una actividad en aquellas realizadas por el departamento de contabilidad y aquellas realizadas por el cliente.

DIAGRAMAS DE ESTADOS Los diagramas de estado son una tcnica conocida para describir el comportamiento de un sistema. Describen todos los estados posibles en los que puede entrar un objeto particular y la manera en que cambia el estado del objeto, como resultado de los eventos que llegan a el. Los diagramas de estado muestran el conjunto de estados por los cuales pasa un objeto durante su vida en una aplicacin en respuesta a eventos (por ejemplo, mensajes recibidos, tiempo rebasado o errores), junto con sus respuestas y acciones. En la mayor parte de las tcnicas Orientadas a Objetos, los diagramas de estado se dibujan para una sola clase, mostrando el comportamiento de un solo objeto durante todo su ciclo de vida. Elementos: Estado Identifica un periodo de tiempo del objeto (no instantneo) en el cual el objeto est esperando alguna operacin, tiene cierto estado caracterstico o puede recibir cierto tipo de estmulos. Se representa mediante un rectngulo con los bordes redondeados, que puede tener tres compartimientos: uno para el nombre, otro para el valor caracterstico de los atributos del objeto en ese estado y otro para las acciones que se realizan al entrar, salir o estar en un estado (entry, exit o do, respectivamente).

Eventos Es una ocurrencia que puede causar la transicin de un estado a otro de un objeto. Esta ocurrencia puede ser una de varias cosas: Condicin que toma el valor de verdadero o falso Recepcin de una seal de otro objeto en el modelo Recepcin de un mensaje Paso de cierto perodo de tiempo, despus de entrar al estado o de cierta hora y fecha particular El nombre de un evento tiene alcance dentro del paquete en el cual est definido, no es local a la clase que lo nombre. Envo de mensajes Adems de mostrar y transicin de estados por medio de eventos, puede representarse el momento en el cual se envan mensajes a otros objetos. Esto se realiza mediante una lnea punteada dirigida al diagrama de estados del objeto receptor del mensaje. Transicin simple Una transicin simple es una relacin entre dos estados que indica que un objeto en el primer estado puede entrar al segundo estado y ejecutar ciertas operaciones, cuando un evento ocurre y si ciertas condiciones son satisfechas. Se representa como una lnea slida entre dos estados, que puede venir acompaada de un texto con el siguiente formato:

event-signature "[" guard-condition] "/" actionexpression "^"send-clause event-signature es la descripcin del evento que da lugar la transicin, guard-condition son las condiciones adicionales al evento necesarias para que la transicin ocurra, action-expression es un mensaje al objeto o a otro objeto que se ejecuta como resultado de la transicin y el cambio de estado y send-clause son acciones adicionales que se ejecutan con el cambio de estado, por ejemplo, el envo de eventos a otros paquetes o clases. Transicin interna Es una transicin que permanece en el mismo estado, en vez de involucrar dos estados distintos. Representa un evento que no causa cambio de estado. Se denota como una cadena adicional en el compartimiento de acciones del estado. Acciones: Podemos especificar la solicitud de un servicio a otro objeto como consecuencia de la transicin. Se puede especificar el ejecutar una accin como consecuencia de entrar, salir, estar en un estado, o por la ocurrencia de un evento. Generalizacin de Estados: Podemos reducir la complejidad de estos diagramas usando la generalizacin de estados. Distinguimos as entre superestado y subestados. Un estado puede contener varios subestados disjuntos.

 Los subestados heredan las variables de estado y las transiciones externas. La agregacin de estados es la composicin de un estado a partir de varios estados independientes. La composicin es concurrente por lo que el objeto estar en alguno de los estados de cada uno de los subestados concurrentes. La destruccin de un objeto es efectiva cuando el flujo de control del autmata alcanza un estado final no anidado. La llegada a un estado final anidado implica la subida al superestado asociado, no el fin del objeto. Subestados Un estado puede descomponerse en subestados, con transiciones entre ellos y conexiones al nivel superior. Las conexiones se ven al nivel inferior como estados de inicio o fin, los cuales se suponen conectados a las entradas y salidas del nivel inmediatamente superior. Transaccin Compleja Una transicin compleja relaciona tres o ms estados en una transicin de mltiples fuentes y/o mltiples destinos. Representa la subdivisin en threads del control del objeto o una sincronizacin. Se representa como una lnea vertical de la cual salen o entran varias lneas de transicin de estado. Transicin a estados anidados Una transicin de hacia un estado complejo (descrito mediante estados anidados) significa la entrada al estado inicial del subdiagrama. Las transiciones que

salen del estado complejo se entienden como transiciones desde cada uno de los subestados hacia afuera (a cualquier nivel de profundidad). Transiciones temporizadas Las esperas son actividades que tienen asociada cierta duracin. La actividad de espera se interrumpe cuando el evento esperado tiene lugar. Este evento desencadena una transicin que permite salir del estado que alberga la actividad de espera. El flujo de control se transmite entonces a otro estado.

Diagrama de Robustez (Administracin de usuarios).

El formato es A5 Todo el texto de 1,0 de espaciado Grficos cuadrar que queden centrados!