ING.

FABIAN GARCIA CARRILLO

TEMA:

DIAGRAMAS

DIAGRAMAS:
Los diagramas son las grficas que describen el contenido de una vista. UML tiene nueve tipos de diagramas que son utilizados en combinacin para proveer todas las vistas de un sistema: Diagramas de caso de uso * Diagrama de clases *

Diagrama de objetos
Diagrama de estados Diagrama de secuencia * Diagrama de colaboracin * Diagrama de actividad Diagrama de componentes Diagrama de distribucin.

DIAGRAMAS DE CASO DE USO:

Los diagramas de casos de uso documentan el comportamiento de un sistema desde el punto de vista del Usuario. Por tanto los casos de uso determinan los requisitos funcionales del sistema: Representan las funciones que un sistema puede ejecutar.

Los diagramas de uso se suelen utilizar en el modelado del sistema desde el punto de vista de sus usuarios para representar las acciones que realiza cada tipo de usuario.

DIAGRAMAS DE CASO DE USO:

Su ventaja principal es la facilidad para interpretarlos, lo que hace que sean especialmente tiles en la comunicacin con el cliente. Un modelo de casos de uso es descrito en UML como un diagrama de casos de uso (diagrama use-case) y dicho modelo puede ser dividido en varios diagramas de caso de uso. Un diagrama de casos de uso contiene elementos de modelo para el sistema, los actores y los casos de uso y muestra las diferentes relaciones tales como generalizacin, asociacin y dependencia entre estos elementos. El diagrama de caso de uso debe ser fcil de entender por el usuario final

ELEMENTOS BASICOS DE UN DIAGRAMAS DE CASO DE USO:

ACTORES CASOS DE USO ASOCIACIONES

ACTORES:
Los actores representan un tipo de usuario del sistema en los diagramas de casos de uso, los actores se dibujan como una silueta humana. Un actor es alguien o algo que interacta con el sistema; es quien utiliza el sistema.

Por la frase "interacta con el sistema" se debe entender que el actor enva a o recibe del sistema unos mensajes o intercambia informacin con el sistema. En pocas palabras, el actor lleva a cabo los casos de uso. Un actor puede ser una persona u otro sistema que se comunica con el sistema a modelar.

ACTORES:
Es posible obtener a los actores de un diagrama de casos de uso a travs de las siguientes preguntas: Quin utilizar la funcionalidad principal del sistema (actores primarios)?

Quin necesitar soporte del sistema para realizar sus actividades diarias?
Quin necesitar mantener, administrar y trabajar el sistema (actores secundarios)? Qu dispositivos de hardware necesitar manejar el sistema?

ACTORES:
Con qu otros sistemas necesitar interactuar el sistema a desarrollar?
Quin o qu tiene inters en los resultados (los valores) que el sistema producir? EJEMPLO:

CASOS DE USO
Un caso de uso representa la funcionalidad completa tal y como la percibe un actor. Un caso de uso en UML es definido como un conjunto de secuencias de acciones que un sistema ejecuta y que permite un resultado observable de valores para un actor en particular. Grficamente se representan con una elipse y tiene las siguientes caractersticas: Un caso de uso siempre es iniciado por un actor. Un caso de uso provee valores a un actor. Un caso de uso es completo.

CASOS DE USO
El proceso para encontrar casos de uso inicia encontrando al actor o actores previamente definidos. Por cada actor identificado, hay que realizar las siguientes preguntas:
Qu funciones del sistema requiere el actor? Qu necesita hacer el actor? El actor necesita leer, crear, destruir, modificar o almacenar algn tipo de informacin en el sistema? El actor debe ser notificado de eventos en el sistema o viceversa? Qu representan esos eventos en trminos de funcionalidad?

CASOS DE USO
El trabajo diario del actor podra ser simplificado o hecho ms eficientemente a travs de nuevas funciones en el sistema? (Comnmente, acciones actuales del actor que no estn automatizadas) EJEMPLO:

ASOCIACIONES
Hay una asociacin entre un actor y un caso de uso si el actor interacta con el sistema para llevar a cabo el caso de uso. EJEMPLO:

ASOCIACIONES
Existen tres tipos de asociaciones o relaciones en los diagramas de casos de uso: Extiende Incluye Generaliza INCLUDE (INCLUYE) Se puede incluir una relacin entre dos casos de uso de tipo include si se desea especificar comportamiento comn en dos o ms casos de uso En el diagrama, se indica mediante una flecha a trazos y abierta, como en este ejemplo:

ASOCIACIONES

ASOCIACIONES
EXTEND (EXTIENDE) Se puede incluir una relacin entre dos casos de uso de tipo extend si se desea especificar diferentes variantes del mismo caso de uso. Dicho de otra forma, la relacin extend implica que el comportamiento de un caso de uso es diferente dependiendo de ciertas circunstancias, en principio, esas variaciones pueden tambin mostrarse como diferentes descripciones de escenarios asociadas al mismo caso de uso.

ASOCIACIONES
EJEMPLO:

ASOCIACIONES
GENERALIZA

En un diagrama de casos de uso tambin pueden mostrarse generalizaciones (relaciones de herencia) para mostrar que diferentes elementos estn relacionados como tipos de otros.
Son aplicables a actores o casos de uso, pero para estos ltimos la semntica es muy similar a las relaciones extend

LIMITES DEL SISTEMA:

Es til dibujar los lmites del sistema cuando se pretende hacer un diagrama de casos de uso para parte del sistema. EJEMPLO:

DIAGRAMA DE CLASES

Para la realizacin del diagrama de clases se toman como base los diagramas de secuencia y de colaboracin por lo que se manejarn los objetos que ah se consideraron pero ahora a nivel de clases. Adems, se pueden agregar nuevas clases que no se haban considerado y este paso deber ser realizado por expertos en el dominio del problema. Para poder definir las clases, UML sugiere seis caractersticas selectivas que debe utilizar el analista para considerar una clase candidato en el modelo de anlisis:

DIAGRAMA DE CLASES
1. Informacin retenida. La clase ser til durante el anlisis slo si la informacin sobre el mismo ha de ser almacenada, transformada, analizada o manejada en algn otro modo. La informacin puede referirse a conceptos que debern estar siempre registrados en el sistema, eventos o transacciones que ocurren en un momento especfico. 2. Sistema externo. Si se tiene un sistema externo a este sistema, entonces es de inters en la etapa de modelado. Los sistemas externos debern ser vistos como clases que el sistema contendr o con los cuales interactuar. 3. Patrones, libreras de clases o componentes. Si se tienen patrones, libreras de clases o componentes, generalmente stos son clases candidatos.

DIAGRAMA DE CLASES

4. Dispositivos que el sistema maneja. Dispositivos tcnicos que maneja el sistema se convertirn en clases que manejarn esos dispositivos. 5. Partes organizacionales. Especialmente en modelos de negocio, todas las partes que representan a la organizacin, sern clases candidatos. 6. Roles de actores. Los roles de actores sern vistos como clases, por ejemplo, usuario, operador del sistema, administrador, cliente, etc

DIAGRAMA DE CLASES
Grficamente, las clases se representan en una caja rectangular dividida en 3 compartimentos: en la parte superior se encuentra el nombre de la clase, en la parte media se encuentran los atributos y en la parte inferior se encuentran las operaciones o mtodos de la clase. Las clases se relacionan entre s a travs de las relaciones que son las lneas rectas entre dos clases y constan de roles y cardinalidad. Los roles son las frases que se encuentran en la relacin y sirven para definir la cardinalidad de la relacin, siempre considerando la unidad en la clase origen.

DIAGRAMA DE CLASES
Adems, tanto los atributos como los mtodos cuentan con una sintaxis. Para los atributos la sintaxis es la siguiente: visibilidad nombre : tipo = valor_inicial y para los mtodos, la sintaxis es la siguiente: visibilidad nombre (lista_parmetros) : tipo_de_retorno donde la lista de parmetros consta de la siguiente sintaxis: nombre : tipo = valor_default

DIAGRAMA DE CLASES

donde los parmetros van separados por comas y la visibilidad tanto para los atributos como para los mtodos, puede ser pblico o privado y se puede representar grficamente con un signo + para pblico y un signo para privado.

DIAGRAMA DE CLASES

DIAGRAMA DE SECUENCIA
El diagrama de secuencia describe la dinmica del sistema. A menos que se modele un sistema muy pequeo, resulta difcil representar toda la dinmica de un sistema en un nico diagrama. Por tanto, la dinmica completa se representar mediante un conjunto de diagramas de secuencia, cada uno de ellos vinculado generalmente a una subfuncin del sistema. El diagrama de secuencia describe las interacciones entre un grupo de objetos mostrando de forma secuencial los envos de mensajes entre objetos. El diagrama puede asimismo mostrar los intercambiados durante el envo de mensajes. flujos de datos

DIAGRAMA DE SECUENCIA
Los diagramas de secuencia muestran objetos o clases y mensajes entre ellos, estan compuestos por la linea de vida de un objeto y el envio de mensajes. REPRESENTACION:

DIAGRAMA DE SECUENCIA
Lnea de vida de un objeto
Dado que representa la dinmica del sistema, el diagrama de secuencia hace entrar en accin las instancias de clases que intervienen en la realizacin de la subfuncin a la que est vinculado.

A cada instancia se asocia una lnea de vida que muestra las acciones y reacciones de la misma, as como los periodos durante los cuales sta est activa, es decir, durante los que ejecuta uno de sus mtodos.

DIAGRAMA DE SECUENCIA

DIAGRAMA DE SECUENCIA
Envo de mensajes Los envos de mensajes se representan mediante flechas horizontales que unen la lnea de vida del objeto emisor con la lnea de vida del objeto destinatario. EJEMPLO:

DIAGRAMA DE SECUENCIA
En ejemplo, el objeto de la izquierda enva un mensaje al objeto de la derecha. El mensaje da lugar a la ejecucin del mtodo mensaje del objeto de la derecha, lo que provoca su activacin. Los mensajes se numeran secuencialmente a partir de uno. Si un mensaje se enva antes de que concluya el tratamiento del precedente, es posible utilizar una numeracin compuesta en la que el envo del mensaje 2 se produzca durante la ejecucin del mensaje 1. EJEMPLO:

DIAGRAMA DE SECUENCIA
Existen diferentes tipos de envos de mensajes: Mensaje sincrnico. Mensaje asincrnicos. Mensajes de retorno.

DIAGRAMA DE SECUENCIA
El mensaje sincrnico es el utilizado con mayor frecuencia. Su uso significa que el expedidor del mensaje espera que la activacin del mtodo mencionado por el destinatario finalice antes de continuar su actividad. En los mensajes asincrnicos, el expedidor no espera el trmino de la activacin invocada por el destinatario. Esto se produce al modelar sistemas en los que los objetos pueden funcionar en paralelo (es el caso de los sistemas multi-thread, donde los tratamientos se efectan en paralelo).

El mensaje de retorno a la llamada a un mtodo no es sistemtico, ya que no todos los mtodos devuelven un resultado.

DIAGRAMA DE SECUENCIA
REPRESENTACION GRAFICA:

DIAGRAMA DE SECUENCIA

DIAGRAMA DE COLABORACION
El diagrama de colaboracin, el cual se centra tanto en las interacciones y las ligas entre un conjunto de objetos colaborando entre ellos (una liga es una instancia de una asociacin). Ambos, el diagrama de secuencia y el diagrama de colaboracin, muestran interacciones, pero el diagrama de secuencia se centra en el tiempo mientras que el diagrama de colaboracin se centra en el espacio. Las ligas muestran los objetos actuales y cmo ellos se relacionan unos con otros. As como los diagramas de secuencia, los diagramas de colaboracin pueden ser utilizados para ilustrar la ejecucin de una operacin, una ejecucin de un use-case o simplemente un escenario de interaccin dentro del sistema. En este diagrama tambin se representa a los objetos en cajas rectangulares y con el nombre subrayado. Las ligas se dibujan con lneas y se puede agregar una etiqueta para un mensaje y un nmero que define la secuencia de las ligas.

DIAGRAMA DE COLABORACION

DIAGRAMA DE ESTADOS
El diagrama de estados, el cual captura el ciclo de vida de los objetos, subsistemas y sistemas. Dicho diagrama determina los estados que un objeto puede tener y cmo los eventos afectan esos estados a travs del tiempo. Un diagrama de estado debe abarcar todas las clases que tengan estados y conducta definidos claramente. Todos los objetos tienen un estado y ste es el resultado de actividades previas ejecutadas por el objeto. Ese estado est determinado por los valores de los atributos de este objeto y sus relaciones con otros objetos. Una clase puede tener un atributo que especifique el estado, o el estado puede ser determinado por los valores de los atributos "normales" del objeto.

DIAGRAMA DE ESTADOS
Grficamente, los estados se representan en rectngulos con esquinas redondeadas y las lneas entre dos estados se llaman transiciones.

Las transiciones constan de una sintaxis, la cual es la siguiente:

nombre_evento (parmetros) [ condicin ] / accin_o_consecuencia donde los parmetros van separados por comas. La condicin es una expresin que tiene que considerarse para que el evento se genere y la accin o consecuencia es una expresin que se debe efectuar despus del evento y puede ser un incremento o un decremento.

DIAGRAMA DE ESTADOS

DIAGRAMA DE OBJETOS
Est relacionado de cerca con un diagrama de Clases, con la diferencia de que ste describe las instancias de los objetos de clases en un punto en el tiempo. Esto podra parecer similar al diagrama de Estructura Compuesta, que modela el comportamiento en tiempo de ejecucin; la diferencia es que el diagrama de Objetos ejemplifica al diagrama de Clases esttico, mientras que los diagramas de Estructura Compuesta refleja las arquitecturas diferentes de sus contrapartes estticas. Los diagramas de Objetos no presentan arquitecturas que varen de sus correspondientes diagramas de Clases, pero reflejan la multiplicidad y los roles a los que las clases instanciadas podran servir. Ellos son muy tiles en la comprensin de diagramas de Clases complejos, al crear diferentes casos en los que se aplican las relaciones y las clases.

DIAGRAMA DE OBJETOS
Un diagrama de Objetos puede ser tambin un tipo de diagrama de Comunicaciones, el cual modela tambin las conexiones entre pares de objetos y adems las secuencias de eventos a lo largo de cada camino. Ejemplo:
El siguiente ejemplo primero muestra un diagrama de Clases simple, con dos elementos clase conectados.

DIAGRAMA DE OBJETOS
Las clases de arriba se instancian abajo como objetos en un diagrama de Objetos. Hay dos instancias de Computadora en este modelo, lo que puede probar su utilidad por considerar las relaciones y las interacciones que las clases juegan en la prctica, como objetos.

DIAGRAMA DE ACTIVIDADES

Es un diagrama de UML (Lenguaje Unificado de Modelado) Tcnica para describir la lgica de los procedimientos, los procesos del negocio y el flujo de trabajo Detalla los procesos que se llevan a cabo dentro del entorno donde el sistema va a interactuar

Permite modelar los aspectos dinmicos de un sistemaA

DIAGRAMA DE ACTIVIDADES
Actores

Pasos

Concurrencia: fork y join

Flujos

Condiciones

DIAGRAMA DE ACTIVIDADES
PASAJERO VENDEDOR AEROLNEA

Solicitar Pasaje

Verificar existencia del vuelo

Dar Detalles del vuelo

Seleccionar vuelo

Informar alternativas y precios

Solicitar Pago Pagar pasaje

Reservar plazas

Confirmar plaza reservada

Emitir Tiquete

DIAGRAMA DE COMPONENTES
Un diagrama de Componentes ilustra los fragmentos de software, controladores embebidos, etc. que conformarn un sistema. Un diagrama de componentes tiene un nivel de abstraccin ms elevado que un diagrama de clase - usualmente un componente se implementa por una o ms clases (u objetos) en tiempo de ejecucin. Estos son bloques de construccin, como as eventualmente un componente puede comprender una gran porcin de un sistema.

DIAGRAMA DE COMPONENTES

Los componentes pueden ser:

Archivos Cdigo fuente + Cabeceras Libreras compartidas (DLLs) Ejecutables

Paquetes

DIAGRAMA DE COMPONENTES

agentefraudes.dll agente.java Realiza AgenteFraudes PoliticaFraudes BuscarPatrones

Ej:

system::dialog.dll
{version = 2.0.1}

Componentes y clases Las clases representan abstracciones lgicas. Los componentes son elementos fsicos del mundo real. Un componente es la implementacin fsica de un conjunto de otros elementos lgicos, como clases y colaboraciones. Ejemplo de un componente y las clases que implementa:
agentefraudes.dll

AgenteFraudes PoliticaFraudes

BuscarPatrones

DIAGRAMA DE COMPONENTES
Dependencias entre componentes

La dependencia entre dos componentes se muestra como una flecha punteada. La dependencia quiere decir que una componente necesita de la otra para completar su definicin.

Ejemplos:

DIAGRAMA DE COMPONENTES
<<page>> home.html

<<file>> animlogo.java

<<file>> animator.java

DIAGRAMA DE DISTRIBUCION
Diagramas de despliegue Describen la arquitectura fsica del sistema durante la ejecucin, en trminos de: procesadores dispositivos componentes de software Describen la topologa del sistema: la estructura de los elementos de hardware y el software que ejecuta cada uno de ellos.

DIAGRAMA DE DISTRIBUCION
Los nodos son objetos fsicos que existen en tiempo de ejecucin, y que representan algn tipo de recurso computacional (capacidad de memoria y procesamiento): Computadores con procesadores Otros dispositivos impresoras lectoras de cdigos de barras dispositivos de comunicacin
mquina1: Dell Pentium 466 MMX

Ventas
Despliega pos.exe contactos.exe

Dell Pentium 466 MMX

DIAGRAMA DE DISTRIBUCION
Dispositivos
Los dispositivos del sistema tambin se representan como nodos. Generalmente se usan estereotipos para identificar el tipo de dispositivo.

<<printer>> HP LaserJet 5MP

<<router>> Cisco Router X2000

 Los nodos se conectan mediante asociaciones de comunicacin. Estas asociaciones indican: Algn tipo de ruta de comunicacin entre los nodos Los nodos intercambian objetos o envan mensajes a travs de esta ruta

El tipo de comunicacin se identifica con un estereotipo que indica el protocolo de comunicacin o la red.

DIAGRAMA DE DISTRIBUCION

clienteA: Compaq Pro PC

Servidor de Aplicaciones:
Silicon Graphics O2
clienteB: Compaq Pro PC

Servidor de Base de Datos: VAX

<<DecNet>>