UNIVERSIDA NACIONAL DE CHIMBORAZO

FACULTAD DE INGENIERIA
ESCUELA DE SISTEMAS Y COMPUTACION
Integrantes: Nancy cantua,Alex Asitimbay,Alexis Santos
Fecha: 18-12-2015
Semestre: 6to
Tema: Diagramas
Modelo de Clases
Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el
sistema, las cuales pueden ser asociativas, de herencia, de uso y de consentimiento.
Un diagrama de clases est

compuesto por los siguientes elementos:

Clase: atributos, mtodos y visibilidad.

Relaciones: Herencia, Composicin, Agregacin, Asociacin y Uso.

Elementos

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.).
En UML, una clase es representada por un rectngulo que posee tres divisiones:

En donde:
o Superior: Contiene el nombre de la Clase
o Intermedio: Contiene los atributos (o variables de instancia) que caracterizan
a la Clase (pueden ser private, protected o public).
o Inferior: Contiene los mtodos u operaciones, los cuales son la forma como
interacta el objeto con su entorno (dependiendo de la visibilidad: private,
protected o public).
Ejemplo:
Una Cuenta Corriente que posee como caracterstica:
o Balance
Puede realizar las operaciones de:
o Depositar
o Girar
o y Balance

El diseo asociado es:

Atributos y Mtodos:
o Atributos:
Los atributos o caractersticas de una Clase pueden ser de tres tipos, los que
definen el grado de comunicacin y visibilidad de ellos con el entorno, estos
son:

public (+,

): Indica que el atributo ser visible tanto dentro

como fuera de la clase, es decir, es accsesible desde todos lados.

private (-,

): Indica que el atributo slo ser accesible desde

dentro de la clase (slo sus mtodos lo pueden accesar).

protected (#,

): Indica que el atributo no ser accesible desde

fuera de la clase, pero si podr ser accesado por mtodos de la clase

adems de las subclases que se deriven (ver herencia).
o Mtodos:
Los mtodos u operaciones de una clase son la forma en como sta
interacta con su entorno, stos pueden tener las caractersticas:

public (+,

): Indica que el mtodo ser visible tanto dentro como

fuera de la clase, es decir, es accsesible desde todos lados.

private (-,

): Indica que el mtodo slo ser accesible desde

dentro de la clase (slo otros mtodos de la clase lo pueden accesar).

protected (#,

): Indica que el mtodo no ser accesible desde

fuera de la clase, pero si podr ser accesado por mtodos de la clase

adems de mtodos de las subclases que se deriven (ver herencia).

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:
o uno o muchos: 1..* (1..n)
o 0 o muchos: 0..* (0..n)
o nmero fijo: m (m denota el nmero).
o Herencia (Especializacin/Generalizacin):
Indica que una subclase hereda los mtodos y atributos especificados por
una Super Clase, por ende la Subclase adems de poseer sus propios
mtodos y atributos, poseer las caractersticas y atributos visibles de la
Super Clase (public y protected), ejemplo:

En la figura se especifica que Auto y Camin heredan de Vehculo, es decir,

Auto posee las Caractersticas de Vehculo (Precio, VelMax, etc) adems
posee algo particular que es Descapotable, en cambio Camin tambin
hereda las caractersticas de Vehiculo (Precio, VelMax, etc) pero posee como
particularidad propia Acoplado, Tara y Carga.
Cabe destacar que fuera de este entorno, lo nico "visible" es el mtodo
Caracteristicas aplicable a instancias de Vehculo, Auto y Camin, pues tiene
definicin publica, en cambio atributos como Descapotable no son visibles
por ser privados.
o 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 esta condicionado por el tiempo de vida del que
lo incluye. Este tipo de relacin es comunmente llamada
Composicin (el Objeto base se contruye 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 comunmente llamada Agregacin (el objeto base
utiliza al incluido para su funcionamiento).

Un Ejemplo es el siguiente:

En donde se destaca que:

Un Almacen posee Clientes y Cuentas (los rombos van en el objeto

que posee las referencias).

Cuando se destruye el Objeto Almacen 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

refereniado. Cuando no existe este tipo de particularidad la flecha se
elimina.
o 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 Ordenes de Compra, en cambio

una orden de compra solo puede tener asociado un cliente.
o 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 esta condicionado a la
instanciacin proveniente desde el objeto Aplicacion):

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).
ii.

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.

DIAGRAMAS DE CASOS DE USO.

Un caso de uso es una descripcin de los pasos o las actividades que debern realizarse para
llevar a cabo algn proceso. Los personajes o entidades que participarn en un caso de uso
se denominan actores. En el contexto de ingeniera del software, un caso de uso es una
secuencia de interacciones que se desarrollarn entre un sistema y sus actores en respuesta a
un evento que inicia un actor principal sobre el propio sistema. Los diagramas de casos de
uso sirven para especificar la comunicacin y el comportamiento de un sistema mediante su
interaccin con los usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra
la relacin entre los actores y los casos de uso en un sistema. Una relacin es una conexin
entre los elementos del modelo, por ejemplo la especializacin y la generalizacin son
relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del
sistema al mostrar cmo reacciona a eventos que se producen en su mbito o en l mismo.
Los ms comunes para la captura de requisitos funcionales, especialmente con el desarrollo
del paradigma de la programacin orientada a objetos, donde se originaron, si bien puede
utilizarse con resultados igualmente satisfactorios con otros paradigmas de programacin.

TIPOS DE RELACIONES

Comunica (<<communicates>>): Relacin (asociacin) entre un actor y un caso de

uso que denota la participacin del actor en dicho caso de uso.

Usa (<<uses>>) (o <<include>> en la nueva versin de UML): Relacin de

dependencia entre dos casos de uso que denota la inclusin del comportamiento de
un escenario en otro.

Extiende (<<extends>>): Relacin de dependencia entre dos casos de uso que

denota que un caso de uso es una especializacin de otro. Por ejemplo, podra
tenerse un caso de uso que extienda la forma de pedir azcar, para que permita
escoger el tipo de azcar (normal, diettico o moreno) y adems la cantidad en las
unidades adecuadas (cucharadas o bolsas).

Se utiliza una relacin de tipo <<extends>> entre casos de uso cuando nos encontramos con
un caso de uso similar a otro pero que hace algo ms que ste (variante). Por contra,
utilizaremos una relacin tipo <<uses>> cuando nos encontramos con una parte de

comportamiento similar en dos casos de uso y no queremos repetir la descripcin de dicho

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

ID

NOMBRE

REFERENCIAS CRUZADAS

CREADO POR

ULTIMA ACTUALIZACIN POR

FECHA DE CREACIN

FECHA DE ULTIMA ACTUALIZACIN

ACTORES

DESCRIPCIN

TRIGGER

PRE-CONDICIN

POST-CONDICIN

FLUJO NORMAL

FLUJOS ALTERNATIVOS

INCLUDES

FRECUENCIA DE USO

REGLAS DE NEGOCIO

REQUERIMIENTOS ESPECIALES

NOTAS Y ASUNTO

DIAGRAMAS DE ACTIVIDAD
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.

Un ejemplo de un diagrama de actividades se muestra a continuacin

Las siguientes secciones describen los elementos que constituyen un diagrama de

actividades.
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

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

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

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.

DIAGRAMA DE SECUENCIA

Un diagrama de secuencia es una forma de diagrama de interaccin que muestra los objetos
como lneas de vida a lo largo de la pgina y con sus interacciones en el tiempo
representadas como mensajes dibujados como flechas desde la lnea de vida origen hasta la
lnea de vida destino. Los diagramas de secuencia son buenos para mostrar qu objetos se
comunican con qu otros objetos y qu mensajes disparan esas comunicaciones. Los
diagramas de secuencia no estn pensados para mostrar lgicas de procedimientos
complejos.
Lnea

de

Vida

Una lnea de vida representa un participante individual en un diagrama de secuencia. Una

lnea de vida usualmente tiene un rectngulo que contiene el nombre del objeto. Si el
nombre es self entonces eso indica que la lnea de vida representa el clasificador que posee
el diagrama de secuencia.

Algunas veces un diagrama de secuencia tendr una lnea de vida con un smbolo del
elemento actor en la parte superior. Este usualmente sera el caso si un diagrama de
secuencia es contenido por un caso de uso. Los elementos entidad, control y lmite de los
diagramas de robustez tambin pueden contener lneas de vida.

Mensajes
Los mensajes se muestran como flechas. Los mensajes pueden ser completos, perdidos o
encontrados; sncronos o asncronos: llamadas o seales. En el siguiente diagrama, el
primer mensaje es un mensaje sncrono (denotado por una punta de flecha oscura),
completo con un mensaje de retorno implcito; el segundo mensaje es asncrono (denotado
por una punta de flecha en lnea) y el tercero es un mensaje de retorno asncrono (denotado
por una lnea punteada).

Ocurrencia

de

ejecucin

Un rectngulo fino a lo largo de la lnea de vida denota la ocurrencia de ejecucin o

activacin de un foco de control. En el diagrama anterior hay tres ocurrencias de ejecucin.
El primero es el objeto origen que enva dos mensajes y recibe dos respuestas, el segundo
es el objeto destino que recibe un mensaje asncrono y retorna una respuesta, y el tercero es
el objeto destino que recibe un mensaje asncrono y retorna una respuesta.

Mensaje

Self

Un mensaje self puede representar una llamada recursiva de una operacin, o un mtodo
llamando a otro mtodo perteneciente al mismo objeto. Este se muestra como cuando crea
un foco de control anidado en la ocurrencia de ejecucin de la lnea de vida.

Mensajes

perdidos

encontrados

Los mensajes perdidos son aquellos que han sido enviados pero que no han llegado al
destino esperado, o que han llegado a un destino que no se muestra en el diagrama actual.
Los mensajes encontrados son aquellos que llegan de un remitente no conocido, o de un
remitente no conocido en el diagrama actual. Ellos se denotan yendo o llegando desde un
elemento de punto final.

Inicio

final

de

lnea

de

vida

Una lnea de vida se puede crear o destruir durante la escala de tiempo representada por un
diagrama de secuencia. En el ltimo caso, la lnea de vida se termina por un smbolo de
detencin, representado como una cruz. En el primer caso, el smbolo al inicio de la lnea
de vida se muestra en un nivel ms bajo de la pgina que el smbolo del objeto que caus la
creacin. El siguiente diagrama muestra un objeto que fue creado y destruido.

Restricciones

de

tiempo

duracin

En forma predeterminada, un mensaje se muestra como una lnea horizontal. Ya que la lnea
de vida representa el pasaje de tiempo hacia abajo, cuando se modela un sistema en tiempo
real, o incluso un proceso de negocios en tiempo lmite, puede ser importante considerar el
tiempo que toma realizar las acciones. Al configurar una restriccin de duracin para un
mensaje, el mensaje se mostrar como una lnea inclinada.

Fragmentos combinados
Se estableci anteriormente que no se espera que los diagramas de secuencia muestren
lgicas de procedimientos complejos. Siendo este el caso, hay un nmero de mecanismos
que permiten agregar un grado de lgicas de procedimientos a los diagramas y que a la vez
vienen bajo el encabezado de fragmentos combinados. Un fragmento combinado es una o
ms secuencias de procesos incluidas en un marco y ejecutadas bajo circunstancias
nombradas especficas. Los fragmentos disponibles son:

El fragmento Alternative (denotedo alt) modela estructuras ifthenelse.

El fragmento Option (denotado opt) modela estructuras switch.

El fragmento Break modela una secuencia alternativa de eventos que se procesa en

lugar de todo del resto del diagrama.

El fragmento Parallel (denotado par) modela procesos concurrentes.

El fragmento de secuenciado Weak (denotado seq) incluye un nmero de

secuencias para las cuales todos los mensajes se deben procesar en un segmento
anterior, antes de que el siguiente segmento pueda comenzar, pero que no impone
ningn secuenciado en los mensajes que no comparten una lnea de vida.

El fragmento de secuenciado Strict (denotado strict) incluye una serie de

mensajes que se deben procesar en el orden proporcionado.

El fragmento Negative (denotado neg) incluye una serie de mensajes invlidos.

El fragmento Critical incluye una seccin crtica.

El fragmento Ignore declara un mensaje o mensajes que no son de ningn inters si

este aparece en el contexto actual.

El fragmento Consider es el opuesto del fragmento Ignore: cualquier mensaje que

no se incluya en el fragmento Consider se debera ignorar.

El fragmento Assertion (denotado assert) designa que cualquier secuencia que no

se muestra como un operando de la asercin es invlida.

El fragmento Loop incluye una serie de mensajes que estn repetidos.

El siguiente diagrama muestra un fragmento loop.

Tambin hay una ocurrencia de interaccin, que es similar a un fragmento combinado. Una
ocurrencia de interaccin es una referencia a otro diagrama que tiene la palabra ref en la
esquina izquierda arriba del marco, y tiene el nombre del diagrama referenciado que se
muestra en el medio del marco
Puerta
Una puerta es un punto de conexin para conectar un mensaje dentro de un fragmento con
un mensaje fuera del fragmento. EA muestra una puerta como un cuadro pequeo en un
marco del fragmento.

Descomposicin

en

parte

Un objeto puede tener ms de una lnea de vida que viene de sta. Esto permite mensajes de
entre e intra objetos para que se muestren en el mismo diagrama.

Continuaciones

Invariantes

de

Estado

Una invariante de estado es una restriccin ubicada en una lnea de vida que debe ser
verdadera en el tiempo de ejecucin. Esta se muestra como un rectngulo con los extremos
en semi-circulos.

Una continuacin tiene la misma notacin que una invariante de estado pero se usa en
fragmentos combinados y puede extenderse a travs de ms de una lnea de vida.