Diseo de Sistemas

UABC FCA
M.C. Diana C. Ruiz Alvarez

UML
Diagrama de Casos de Uso
Un caso de uso es una coleccin de situaciones respecto al uso de un sistema desde el
punto de vista de los usuarios. Cada escenario describe una serie de eventos, donde cada
secuencia se inicia por una persona, otro sistema, hardware o por el paso del tiempo. A las
entidades que inician la secuencia se les llama actores. El resultado de la secuencia debe de ser
algo utilizable ya sea por el actor que lo inicio o por otro actor.
El modelo de Casos de uso incluye los
diagramas y la secuencia de pasos en los
escenarios. Los diagramas de casos estn formados
por 5 elementos: sistema, actores, casos de uso,
asociaciones y dependencias, cada elemento tienen
su notacin propia. Este diagrama provee una
explicacin a nivel superficial de cmo interacta el
sistema con el mundo externo.
Existen dos formas en que los casos de uso se pueden relacionar las cuales son inclusin
y extensin. La inclusin es una tcnica de aprovechamiento de un caso de uso y se utiliza
cuando dos o ms casos de uso tienen pasos en
comn, lo que permite eliminar la duplicacin de
estos pasos. Esta tcnica consiste en tomar los
pasos comunes de los casos de uso y formar un
nuevo caso de uso a partir de ellos, de esta
forma este nuevo caso de uso se puede utilizar
como parte de otros casos. Para representar la
inclusin se utiliza una flecha punteada que
conecta a los dos casos de uso, la flecha apunta al caso incluido. Sobre la lnea se coloca el
estereotipo <<incluir>>. Cabe mencionar que un caso incluido nunca aparecer solo.
La extensin <<extender> se puede aplicar cuando se tiene un flujo alternativo con
cambios mayores o cuando existen pasos que son
opcionales de realizar (generalmente se aplica a la
segunda opcin). La extensin solo se puede
realizar en puntos indicados de manera especfica
dentro de la secuencia, a estos puntos se les
conoce como puntos de extensin.
La extensin se identifica colocando una
flecha desde el caso de uso excepcional al caso de
uso normal. En la flecha se indica la condicin que se debe de cumplir para realizar el caso de uso
extensin y el punto donde se aplica, en el caso de uso normal se indica dividiendo el ovalo y se
indica el punto de extensin donde se aplicar la extensin.
1

Diseo de Sistemas
UABC FCA
M.C. Diana C. Ruiz Alvarez

En ocasiones existen diferentes maneras de hacer la misma cosa, pero la meta es la

misma. En estos casos se puede utilizar el mecanismo de la generalizacin. La generalizacin se
puede implementar ya sea que el mecanismo en si es diferente pero el actor es el mismo o que
tanto el mecanismo como el actor son diferentes.

Documentacin de los casos de Uso

La secuencia de pasos se coloca por separado del diagrama e incluye: el actor que inicia
la secuencia, condiciones previas para el caso de uso, pasos en el escenario, condiciones
posteriores cuando se finaliza el escenario y el actor que se beneficia del caso de uso. De ser
necesario se puede agregar ms informacin sobre algunas conjeturas y una breve descripcin
(una lnea) del escenario. Cuando se tienen escenarios alternativos de un caso de uso estos se
pueden poner de manera separada o considerarlos como excepciones al escenario principal. Si en
el caso de uso existen relaciones de inclusin o extensin estos deben indicarse.
Informacin de la documentacin
Nombre del caso de uso:
Descripcin:
Escenario tpico: Que pasa?
Precondicin:
Poscondicin exitosa: Actor
Actor que inicia
Sistema

Actor que recibe o participa

Pasos que hace el actor

Acciones que realiza

Acciones que realiza el sistema

Escenario alternativo #1:

Precondicin:
Actor que inicia
Sistema

Actor que recibe o participa

Escenario alternativo #2: Etc.

Diseo de Sistemas
UABC FCA
M.C. Diana C. Ruiz Alvarez

Cuando se trata de casos de uso <<incluir>> o <<extender>> se utiliza

Nombre del caso de uso:
Descripcin:
Casos de uso Base: Se indica quien usa ese caso uso
Escenario tpico:
Precondicin:
Poscondicin exitosa:
Actor que inicia
Sistema

Actor que recibe o participa

Conversin de los casos de uso a operaciones en el diagrama de clases

Para mapear los casos de uso a operaciones se inician convirtiendo los casos de uso que
son accesibles a los actores en las clases correspondientes como mtodos pblicos ya que son
accesibles a los actores. Los casos de uso definidos como inclusiones o extensiones
generalmente se mapean como privados ya que son accedidos por el sistema y no por los actores
directamente.
El siguiente paso consiste en agregar de ser necesario argumentos y valores de retorno a
dichas operaciones. En ocasiones estos argumentos o valores de retorno suelen ser clases en si
que no se incluyeron en el diagrama de clases original por lo que en este punto podemos
incluirlas.

Diseo de Sistemas
UABC FCA
M.C. Diana C. Ruiz Alvarez

Diagramas de Objetos y Clases.

Diagramas de clases
El diagrama de clases se considera el mas importante ya que por medio de l se
representan los componentes del sistema con lo cual ser mas fcil despus elaborar los dems
diagramas. El diagrama de clases se puede ver como el mapa del sistema donde se representan
todas las posibles configuraciones.
Una instancia es un objeto que se crea utilizando una clase y comnmente se le llama
instancia al objeto que se crea durante la
ejecucin de un programa, aunque
algunas veces el trmino objeto e
instancia se usen indistintamente. Una
clase se puede ver como una plantilla
para objetos con caractersticas similares
(atributos), que se comportan de la
misma manera (operaciones) y que
tienen relaciones comunes con otros
objetos. As por ejemplo podramos tener
a la clase persona y sus objetos Juan, Pedro, Mara, los cuales tienen atributos comunes, como el
nombre, direccin, etc.
El primer componente del diagrama de clases es en si las clases los cuales pueden ser:
1. Entidades externas que producen o consumen informacin del sistema (otros sistemas,
dispositivos, personas)
2. Cosas que son parte del dominio de la informacin (reportes, seales, etc.)
3. Ocurrencias o eventos que ocurren dentro del contexto del sistema (movimientos de un robot,
secuencias)
4. Roles o funciones que desempean personas que interactan con el sistema
5. Unidades de la organizacin que son relevantes para el sistema (departamentos, grupos de
trabajo)
6. Lugares que forman parte del contexto del sistema o del funcionamiento del mismo.
Hay 5 caractersticas que se pueden tomar como base para decidir si un candidato a clase
debe de ser tomado en cuenta:
1. Informacin retenida: la informacin del objeto (instancia de la clase) es necesaria para que el
sistema funcione.
2. Operaciones necesarias: el objeto debe de tener funciones y operaciones identificables las
cuales cambien de alguna manera el valor de sus atributos.
3. Atributos mltiples: el objeto debe de tener ms de un atributo, de otra manera este podra ser
representado como un atributo de otro objeto.
4. Atributos y operaciones comunes: los atributos y operaciones del objeto deben de aplicarse a
todas las instancias de dicho objeto
5. Requerimientos esenciales: las entidades externas que consumen o producen informacin
esencial para el funcionamientos del sistema pueden ser definidos como objetos
4

Diseo de Sistemas
UABC FCA
M.C. Diana C. Ruiz Alvarez

Para nombrar a las clases se puede utilizar la siguiente gua:

Se puede usar un enunciado o frase
Debe ser singular y no plural
Se deben evitar los pronombres posesivos
No deben incluirse adjetivos irrelevantes
Se utilizan generalmente las negritas y se coloca centrado a la caja de texto
Se utilizan maysculas al inicio
Se eliminan los espacios entre las palabras
No se incluyen artculos
Para nombrar clases que se considere relevantes al diagrama se recomienda se utilicen
nombre representativos. Generalmente se incluye el nombre de la clase y alguna descripcin del
propsito de esta.
La definicin de las clases incluye la definicin de los atributos que los conforman y de las
funciones u operaciones que se llevan a cabo con sus objetos.
Entendemos por atributos a las caractersticas, adjetivos, propiedades, cualidades, es
decir cualquier cosa que describa al objeto. Se debe de tomar en cuenta que un objeto puede
tener muchas instancias, por lo que los atributos y funciones deben de ser comunes a todas las
instancias que dicho objeto pueda tomar.
Los atributos puede ser descriptivos, nombres o referenciales. Los atributos descriptivos
son aquellos que proveen informacin acerca de cada instancia de un objeto, los nombres son
etiquetas que se asignan a cada instancia, y los referenciales son aquellos atributos que ligan a
una instancia de un objeto con una instancia de otro objeto diferente.
Descriptivo:

Nombre

Referencial
La definicin de los atributos
incluye la visibilidad de estos para
otros objetos. Un atributo que es
pblico a otros objetos se indica con el
signo +, cuando solo es utilizado por el

Diseo de Sistemas
UABC FCA
M.C. Diana C. Ruiz Alvarez

objeto se dice que el atributo es privado y se indica con -, cuando el atributo puede ser utilizado
por el objeto y su descendencia el atributo es protegido y se indica con #, por ltimo cuando el
atributo puede ser utilizado por otros objetos pero solo dentro del mismo paquete se llama utiliza el
smbolo ~ para indicarlo.
Una operacin es una funcin o transformacin que se puede aplicar a un objeto o por un
objeto en una clase. El mtodo es la implementacin de la operacin para la clase. Cabe
mencionar que todos los objetos de la clase comparten las operaciones.
Las operaciones, mtodos o funciones deben de cambiar en cierta forma algn atributo del
objeto. Existen diferentes tipos de operaciones:
Aquellas que manipulan la informacin (atributos)
Aquellas que llevan a cabo algn clculo o procedimiento
Aquellas que monitorean al objeto por algn evento
Un objeto encapsula informacin, operaciones, otros objetos, valores constantes y otra
informacin. La Encapsulacin significa que la informacin anterior es empaquetada bajo un
nombre y puede ser utilizada como un solo componente.
Notacin:
Las clases se representan por
rectngulos. Los atributos se colocan debajo
del nombre de la clase en una segunda
divisin del rectngulo. Se coloca el nombre
del atributo seguido por su tipo de dato. Las
operaciones se colocan en una tercera divisin
por debajo de los atributos
Ligas y Asociaciones
Se le llama liga a la relacin directa que
existe entre dos instancias. A la plantilla de ligas, es
decir a aquellas relaciones que comparten todos los
objetos de una clase se le llama asociacin.
En el diagrama de clases las
asociaciones se representan con lneas las
cuales conectan a las clases relacionadas. El nombre de la asociacin puede incluirse sobre la
lnea utilizando letras itlicas. Cuando se trata de enlazar objetos los nombres de estos as como
la relacin se subrayan.
As mismo el rol que juega cada clase en la
asociacin puede incluirse en el diagrama. Los
roles ayudan a ver ms claro como se comporta
una clase cuando se asocia con otra.
6

Diseo de Sistemas
UABC FCA
M.C. Diana C. Ruiz Alvarez

Las asociaciones generalmente corresponden a verbos.

Los objetos pueden participar en varias asociaciones a la vez e
incluso puede existir una asociacin al mismo objeto en si. Al
agregarse una flecha a la asociacin se indica la direccin que se
utiliza para leerla.
Multiplicidad
La multiplicidad se refiere a cuantas instancias
de la misma clase se puede relacionar con una instancia
de otra clase. Algunas veces la multiplicad est dictada
por las restricciones de la vida real. La multiplicidad
puede ser N (solamente ese nmero), N..M (se define un
rango), N,M (define N o M), N..* (el rango solo se
restringe al inicio, no hay lmite), * (rango de 0 o ms) , 0..1 (indica que 0 o 1 solamente) .
Clases de asociacin
Ciertas asociaciones o enlaces tienen atributos
que no forman parte de ninguna de las clases que
pertenecen a la asociacin, por lo que estos atributos se
modelan por separado y se les llama clases de
asociacin. Estas se representan:
Agregacin y composicin
Una composicin es un tipo de asociacin parte de en la cual uno de los objetos llamado
componente forma parte de otro objeto. Una forma especial de la composicin es la agregacin en
la cual la composicin es dbil, esto quiere decir que las partes pueden sobrevivir si el todo se va,
de lo contrario en una composicin cada parte no existe sin el todo. La composicin se representa
con rombos negros mientras que la agregacin los rombos son sin relleno.

Diseo de Sistemas
UABC FCA
M.C. Diana C. Ruiz Alvarez

Generalizacin y Especializacin (Herencia)

La generalizacin se refiere al concepto de agrupar
clases similares dentro de una superclase la cual puede
contener atributos similares a las clases originales. Este tipo
de asociacin se le conoce como es un un tipo de .
Una subclase puede sobre escribir un mtodo de una
superclase definindolo ella misma con el mismo nombre lo
cual se puede hacer con el propsito de especificar un
comportamiento propio de la subclase o por razones de
ejecucin. Al sobrescribir se debe de preservar el tipo de
atributos, nmero de los mismos, tipo de valor regresado, etc.
La especializacin es el concepto de generalizacin pero en sentido contrario. Cuando se
modela una generalizacin se comienza con las subclases y de ah se parte para crear la
superclase, en la especializacin es al revs, se comienza de la superclase y de ah se parte para
crear las subclases, de cualquier modo la relacin terminar vindose del mismo modo.
Al introducir el concepto de generalizacin o especializacin se introduce tambin el
concepto de herencia. Cuando se tienen las relaciones anteriores las subclases heredan atributos
de la superclase.
Diagramas de Objetos.
Los diagramas de objetos puros muestran solamente como las instancias de las clases se
relacionan con otras instancias. La mayor parte del tiempo se utilizan los diagramas de clases ya
que el cdigo que se genera con UML se basa en las clases. Sin embargo en ocasiones es til
presentar los diagramas de objetos para mostrar un ejemplo de que es lo que pasa en el diagrama
de clases y como se comportara el sistema. Para ciertos sistemas es posible mezclar clases y
objetos en un mismo diagrama, siempre y cuando la complejidad del sistema lo ermita.
Los siguientes son ejemplos de cmo representar objetos en el diagrama. Para diferenciar entre
objetos y clases se utiliza el subrayado. Cuando
se representan clases el nombre puede o no ir
subrayado, mientras que cuando se representan
objetos el nombre se debe subrayar. El nombre
del objeto puede ir acompaado del nombre de
la clase o no, pero si se colocan los dos, estos
deben ir separados por dos puntos.
En un diagrama se pueden incluir tanto clase como objetos. Para indicar que un objeto es
una instancia de una clase se utiliza la flecha
punteada

Diseo de Sistemas
UABC FCA
M.C. Diana C. Ruiz Alvarez

Diagrama de estructura compuesta.

Estos diagramas son tiles para mostrar cmo estn compuestos los sistemas complejos
mediante el uso de composicin y agregacin. La forma tradicional de mostrar estas relaciones
hace que diagramas complejos sean difciles de leer, ya que existe una gran cantidad de lneas
que en ocasiones es imposible colocar sin cruzarse unas con otras. Los diagramas de estructura
compuesta permiten mostrar estas relaciones de una forma ms limpia mediante cajas:
Utilizando composicin

Estructura compuesta con cajas

Los elementos que tradicionalmente se muestran en estos diagramas son:

Clase. Para mostrar la parte de la cual se ilustra su composicin interna

Parte. Se muestra con un rectngulo, e indica los objetos que conforman al objeto principal. Si
se coloca una parte dentro de una clase significa, en un diagrama de clases, que la clase
contenedor tiene una relacin de composicin con dicho elemento.
Conector. Indica la relacin entre las parte internas de la clase que se analiza.
Puertos. Se pueden mostrar puertos para indicar la entrada o salida de una parte hacia otra
parte. Se muestran como pequeos cuadrados al final de un conector entre dos partes. No
son obligatorias, pero son recomendables si se quiere encapsular el funcionamiento de las
partes.

Un uso adicional que se puede dar a los

diagramas de estructura compuesta es para
mostrar las partes que colaboran, por ejemplo,
en un caso de uso. En este ejemplo podemos
ver que son tres las clases que colaboran en el
caso de uso Participar en curso: el estudiante, el curso y el seminario. Esta forma nos permitira
modelar patrones de diseo indicando los roles que juega cada clase en la colaboracin.
9

Diseo de Sistemas
UABC FCA
M.C. Diana C. Ruiz Alvarez

Estructura del programa a partir del diagrama de clases

Para crear el cdigo a partir del diagrama se seguir tomar las siguientes reglas:
Clases: Las clases del diagrama se conviertes en clases en el programa con sus atributos y
operaciones correspondientes.
Asociaciones: Las asociaciones se implementan como combinaciones de atributos. Cuando
la asociacin es en una direccin se colocan atributos de la segunda clase en la primera (de
donde parte la asociacin). Dependiendo de la multiplicidad de la asociacin en el tipo de
atributo que se coloca, por ejemplo si la asociacin es uno a uno el atributo ser del tipo del
objeto, si la asociacin es de muchos el tipo de dato podr se una lista o un arreglo que
contendr al conjunto de objetos.
Cuando se tienen asociaciones reflexivas los atributos se colocan dentro de la misma clase y
su nombre es el nombre del rol que juega cada punta de la asociacin.
Roles: los roles se implementan como los nombres de los atributos en la asociacin
Calificador: Los calificadores de las clases son implementados como atributos dentro de la
clase del lado opuesto. Cuando el calificador es simplemente para distinguir un objeto la
implementacin es simplemente con el atributo. Si el calificador es utilizado para bsqueda se
puede implementar como un atributo del tipo rbol B (Btree) el cual permite hacer una
bsqueda rpida de los objetos
Ejemplo:
Public class Banco{
.
}
Public class Sucursal {

Public class Cuenta{

.
Ejecutivo manejaCuenta;
Sucursal LaSucursal;
}

Public class Cliente {

.
Cuenta LasCuentas[];
Sucursal LaSucursal;
}

Public class Retiro{

.
Cuenta enCuenta[];
Cliente deCliente[];
}

Public class Tipo{

String tipo;
Cuenta LaCuenta;
Cliente ElCliente;
}

Public class Empleado{

..
Sucursal LaSucursal;
}
Public class Ejecutivo{

Empleado empleado;
}

10

Diseo de Sistemas
UABC FCA
M.C. Diana C. Ruiz Alvarez

Tipos de clases
Las clases entran en 4 categoras:
Clases entidad: las clases de entidad representan elementos de la vida real, como gente,
cosas, etc. Las clases de entidad son las entidades representadas en un diagrama
entidad-relacin. El analista necesita determinar que atributos incluir en las clases. Cada
objeto tiene muchos atributos, pero la clase debe incluir solo aquellos que utiliza la
organizacin.
Clases de lmite o de interfaz: las clases de lmite o interfaz ofrecen a los usuarios un
medio para trabajar con el sistema. Existen dos amplias categoras de clases de interfaz:
la humana y de sistema.
o Interfaz humana: medios que permiten a los usuarios interactuar con el sistema
como pueden ser una pantalla, una ventana, un formulario web, un cuadro de
dialogo, un men, un cuadro de lista u otro control de despliegue. Tambin se
pueden incluir un telfono de tonos o un cdigo de barras.
o Interfaz del sistema: implican el envo o recepcin de datos de otros sistemas.
Donde podra incluir las bases de datos de la organizacin.
Los atributos de estas clases son los que se encuentran en una pantalla o un informe. Los
mtodos son los que se requieren para trabajar con la pantalla o para producir el informe.
Clases abstractas: son las clases que no es posible instanciar directamente. Las clases
abstractas estn vinculadas a clases concretas en una relacin
Generalizacin/Especializacin. El nombre de una clase abstracta se denota en letras
cursivas.
Clases de control: las clases de control o activas s utilizan para controlar el flujo de
actividades, y funcionan como coordinadoras al implementar la clase. Para lograr clases
reutilizables, un diagrama de clases podra incluir muchas clases pequeas de control.
Con frecuencia, las clases de control se derivan durante el diseo de sistemas.
Usualmente una nueva clase de control se creara con el propsito de hacer reutilizable
otra clase.

Diagrama de Secuencias
11

Diseo de Sistemas
UABC FCA
M.C. Diana C. Ruiz Alvarez

Un diagrama de secuencias
muestra la forma en que un objeto
interacta con otros durante un caso de
uso. Las interacciones se llevan en una
secuencia establecida a travs del
tiempo. Los diagramas constan de
objetos representados por rectngulos
(con su respectiva notacin), actores,
mensajes representados por flechas y el
tiempo representado por lneas
verticales que comienzan en los objetos
a las cuales se les llama lnea de vida
del objeto. En la lnea de vida de cada objeto se coloca un pequeo rectngulo el cual representa
la ejecucin de una operacin por parte del objeto, al cual se le conoce como activacin
Los mensajes entre objetos pueden ser
simples, sincronos o asncronos. Un mensaje simple es
la transferencia de control de un objeto a otro. Un
mensaje sncrono significa que el objeto esperar la
respuesta a su mensaje para continuar con su trabajo y
el mensaje asncrono significa que el objeto no
esperar respuesta. Para el mensaje simple se utiliza
una flecha normal, para el sncrono una flecha con
punta rellena y para el asncrono la punta de la flecha
con una sola lnea.

El diagrama puede ir contenido en un marco (UML 2), el ttulo del diagrama se coloca en
la esquina izquierda. Previo al nombre del diagrama se colocan las iniciales del tipo de diagrama
que se est mostrando (sd por sequence diagram). Este marco es opcional.
Es posible mostrar los estados de los objetos en los diagramas de secuencias, para esto
se reemplazan los rectngulos (activacin) por los rectngulos redondeados (estados), para
indicar el estado en el que se encuentra el objeto.
Cuando el diagrama de secuencias solo se centra en un escenario de un caso de uso al
diagrama se le conoce como diagrama de secuencias de instancias, si por lo contraro se toman
en cuenta todos los posibles escenarios del caso de uso al diagrama se le conoce como diagrama
de secuencias genrico.
Cuando se elaboran diagramas genricos se deben de representar condiciones y
bifurcaciones en el control de la secuencia de acuerdo a la condicin. La condicin se coloca entre
corchetes. La condicin causar una bifurcacin que har que el control del mensaje se separe en
rutas distintas.
12

Diseo de Sistemas
UABC FCA
M.C. Diana C. Ruiz Alvarez

Es posible representar la creacin de un objeto durante la secuencia, para esto el objeto

aparecer en la lnea de vida en el momento en que se crea y no en la parte superior junto con los
dems objetos.
Es posible reutilizar secuencias de otros
diagramas, esto se hace insertando un marco en
donde ira la secuencia, precediendo en el titulo
con ref para indicar que es una referencia a otra
secuencia
Cuando es necesario el envo de
parmetros esto se hace en la lnea del mensaje
y se colocan entre parntesis.
Cuando se tiene una secuencia en
donde ciertas interacciones son opcionales se
puede agregar un marco que lo indique. Las
secuencias opcionales son marcadas con una
condicin que debe cumplirse para que estas se
ejecuten.
Para representar un ciclo mientras, se coloca un marco con la etiqueta loop indicando el valor de
inicio y fin del contador del ciclo y una
condicin que es probada en cada ciclo, si esta
es verdadera el ciclo termina sin importar si el
contador no ha llegado a su valor mximo. As
mismo se puede indicar una opcin que
permite romper el ciclo (break) sin que la
condicin de finalizacin se cumpla. Esto se
indica con un marco con el ttulo break y dentro
del marco se indica la secuencia que ocasiona
que el ciclo se rompa.
Cuando es necesario representar dos caminos
posibles a seguir dependiendo de si la
condicin se cumple o no se utiliza un marco
con el titulo de alt. En la parte superior se
coloca la condicin y las secuencias que se
realizan en caso de cumplirse, en la parte de
abajo, separado por una lnea punteada se
colocan las secuencias que se realizarn si la
condicin no se cumple.

13

Diseo de Sistemas
UABC FCA
M.C. Diana C. Ruiz Alvarez

Diagramas de Comunicacin (antes de colaboracin)

Los diagramas de comunicacin modelan como los objetos participan en conjunto para juntos
llegar a cumplir una meta, estos diagramas se utilizan cuando es necesario disear los detalles de
las interacciones entre objetos (los diagramas de secuencias, actividades y de tiempo tambin son
utilizados para modelar la interaccin entre objetos)
Los diagramas de comunicacin en UML 2 sustituyen a los diagramas de colaboracin de
versiones anteriores. Para diagramar la colaboracin entre objetos es necesario especificar los
objetos participantes y los enlaces entre ellos. As para cada posible escenario que tiene un caso
de uso u operacin se debe especificar la interaccin entre los participantes mediante el uso de
mensajes y sus enlaces.
Cuando se va creando el diagrama de comunicacin es necesario regresar al diagrama de
clases y realizar los cambios necesarios para mantener la consistencia entre la parte esttica y
dinmica.
Partiendo del diagrama de clases es necesario identificar la clase principal del escenario
que se utilizar para la colaboracin. En ocasiones es necesario agregar una clase que ser la
que inicie la colaboracin y organice las actividades de las clases para ejecutar el caso de uso. De
igual modo si el caso de uso genera como salida otra clase es necesario agregarla al diagrama, si
es que no se ha agregado ya.
El nombre del diagrama es generalmente el nombre del caso de uso u operacin para la
cual se mostrar la comunicacin. Como se est trabajando con el diseo cuando se hacen los
diagramas de comunicacin es conveniente documentar ms formalmente los argumentos y
valores de retorno de la interaccin. Basado en el ejemplo a mostrar el nombre del diagrama ser:
GenerateBill(rmNum:RoomNumber, out newBill:Bill). Indicando que la entrada ser el nmero de
cuarto y la salida el recibo (rmNum del tipo RoomNumber y la salida ser newBill de tipo Hill).
Cuando se va analizando el diagrama
de clases el diseador se topa con que tiene
que hacer ciertos cambios. Por ejemplo
cuando se tiene clases de asociacin esta se
tiene que convertir en una clase que se
encuentra en medio del enlace al cual estaba
ligada. En el diagrama siguiente se muestra
como debe de hacerse la conversin. Las
multiplicidades se invierten del diagrama
original al resultante y en los extremos de las
clases originales se coloca la multiplicidad 1.

14

Diseo de Sistemas
UABC FCA
M.C. Diana C. Ruiz Alvarez

Tomando el diagrama original de clases

Se transforma en agregando clase
controladora y cambiando la clase de
asociacin.

El siguiente paso es seleccionar las clases que participan en la secuencia y que

participarn o aparecern en el diagrama de comunicacin. Cuando se tienen calificadores es
necesario hacer ajustes tambin. En este caso estos pasan a ser selectores en la clase a la cual
pertenecen. Estos se colocan entre corchetes antes del nombre de la clase u objeto.
Es posible representar llamadas a funciones desde otras funciones, esto se hace
mediante una numeracin a manera de ndice en donde se va indicando que llamada es hecha
dentro de otras llamadas. La
numeracin que se utiliza es:
1
1.1
1.1.1

15

Diseo de Sistemas
UABC FCA
M.C. Diana C. Ruiz Alvarez

Diagrama de Estados
Es una forma de caracterizar los cambios de estado que los objetos de un sistema sufren
como respuesta a los sucesos o eventos (momento en el tiempo en el que algo importante ocurre)
y al tiempo. El diagrama de objetos presenta los estados en los que un objeto (solo un objeto por
diagrama) puede encontrarse, as como las transiciones entre dichos estados. El estado de un
objeto determinar como este debe reaccionar ante un evento. El diagrama adems presenta los
estados inicial y final de la secuencia. Al diagrama de estados tambin se le conoce como motor
de estados.
Los estados en los diagrama de objetos se
representan por rectngulos redondeados, las
transiciones entre estados se representan con una
flecha continua que apunta hacia el estado a
donde se da la transicin. El estado inicial se
representa por un crculo relleno y el final por una
diana (crculo relleno rodeado por otro crculo). El
rectngulo del estado se puede dividir, en la parte
superior se coloca el nombre del estado, en la
parte intermedia se colocan las variables de
estado y en la parte inferior las actividades.

Se pueden tener tres tipos de estados:

Estados de espera. El objeto simplemente
espera a que pase algo, mientras tanto no
hace nada realmente importante.
Estado de restriccin. El objeto actual de
acuerdo a los valores de sus variables o a los
enlaces que mantiene con otros estados.
Estado de procesamiento. El objeto ejecuta o
lleva a cabo una accin en proceso y deja este
estado cuando ocurre un evento importante.

Las actividades son sucesos y acciones que se realizan mientras el objeto est en ese estado,
las ms utilizadas son entrada, salida y hacer. Las
actividades dentro de un estado se muestran utilizando las
palabras do, entry o exit segn sea el caso, seguida de una
diagonal (/) y luego el nombre de la actividad a realizar. Un
evento entry ocurre justo cuando el estado entra a ese
evento, un evento exit ocurre justo antes de que el objeto
salga del estado y el evento do ocurre mientras se est en
estado. En ocaciones se quiere prevenir que ocurra un
evento cuando se est en cierto estado, en este caso se
coloca el evento seguido de la diagonal y la palabra defer para indicar que el evento se pospone
para despus.
16

Diseo de Sistemas
UABC FCA
M.C. Diana C. Ruiz Alvarez

Cuando un objeto es estimulado por un evento ocurre una transicin entre estados. A las
transiciones se les puede agregar detalle indicando el suceso que provoca la transicin o la
actividad que se ejecute y provoque que se haga la transicin (accin). Los sucesos y acciones se
colocan encima de la lnea de transicin, separados por una diagonal cuando el suceso es
desencadenado por una accin. En ocasiones pude darse una transicin sin una accin asociada.
Una accin es una tarea atmica la cual no puede ser separada en componentes ni interrumpida,
el detener una accin puede llevar a dejar un objeto en un estado indefinido.
El estado final de un objeto indica que este no puede cambiar su estado otra vez, puede que
el objeto siga existiendo pero su estado permanecer inalterable. El estado final tambin puede
indicar la destruccin del objeto.
Tambin se pueden agregar condiciones a las transiciones las cuales al cumplirse provocan el
cambio de estado, a estas condiciones se les conoce como condiciones de seguridad y se colocan
entre parntesis cuadrados expresndolas como condiciones booleanas despus del nombre del
evento.
En ocasiones los objetos envan eventos a otros objetos para notificar que algo importante ha
ocurrido. En envo del evento es tratado como cualquier otra accin. Esto se muestra colocando el
nombre del evento seguido de una diagonal y luego se coloca el nombre de la clase y la operacin
que se realizar (por ejemplo Customer.debitNotify(amount) )
Una forma de hacer que el objeto pueda recordar su estado es mediante variables. Una
tcnica es tener una variable para cada estado e inicializar estas variables a un nmero entero
diferente cada una. Adems tendremos otra variable que contendr el valor del estado actual.
Cuando haya un cambio de estado la variable del estado actual cambiar su valor al valor
correspondiente del estado que definimos con las variables. De esta forma ser fcil verificar el
estado del objeto dentro de nuestro programa simplemente comparando la variable del estado
actual con la variable del estado a comparar:
Public class CustomerAccount {
private int accInitialized = 0;
private int accValidating = 1;
private int accOnTrial = 2;
private int accEstablished = 3;
private int accRenewing = 4;
private int accArchived = 5;
private int currentState = 0;
private int beginningBalance = 0;
private float currentBalance = accInitialized;

if (currentState == accInitialized) then {

currentState = accValidating; // validating
if (myCreditCard.valid = True) then {
currentState = accOnTrial; // now on
trial
currentBalance = beginningBalance;
}}}

public Boolean open(Currency

beginningBalance) {

Se pueden utilizar otros tipos de eventos en

situaciones especiales los cuales son:

17

Diseo de Sistemas
UABC FCA
M.C. Diana C. Ruiz Alvarez

Transicin completada. Este evento se genera cuando todas las actividades del estado se
completan. Si el estado est conectado a otro estado por una transicin que no tiene etiqueta
se hace la transicin automtica al estado despus de ejecutar la accin de salir. Estas
transiciones son llamadas transiciones automticas.
El evento when se utiliza cuando el objeto requiere ser
notificado justo en un momento dado se coloca la palabra
when y entre parntesis la condicin de tiempo absoluta.
El evento after se utiliza cuando el objeto requiere ser
notificado en un momento de tiempo relativo. Se coloca la
palabra after seguida de la condicin de tiempo relativa
entre parntesis.

Un estado puede ser expresado en trminos de subestados con lo que se dice que un estado se encuentra dentro
de otro. Los sub-estados pueden ser secuenciales o
concurrentes. Como su nombre lo indica, los estados
secuenciales ocurren uno detrs de otro. Los sub-estados
concurrentes son aquellos que pueden ocurrir al mismo tiempo
que otros. Cuando se tienen sub-estados concurrentes estos se
separan con una lnea discontinua mostrando los diferentes grupos de estado que pueden ocurrir
al mismo tiempo. La concurrencia no indica que forzosamente se deben de llevar al mismo tiempo
pero que es posible.
A los estados que constan solo de sub-estados
secuenciales o una combinacin entre estados secuenciales y
concurrentes se le conoce como estado compuesto.
Los estados compuestos pueden tener la posibilidad de
recordar el sub-estado activo en el que se encontraban cuando el
objeto trasciende fuera del estado compuesto. A estos estados se
les conoce como estados histricos. Los estados histricos se
representan colocando un crculo con la letra H conectado con
una flecha al estado que se desea recordar
Los diagramas de estados pueden extraerse de los
diagramas de secuencias observando el flujo de eventos en los
objetos ms dinmicos.
Una vez desarrollado los diagramas de estados es necesario regresar al diagrama de
objetos a hacer los ajustes necesarios. Los eventos causan que los objetos ejecuten cierto
comportamiento por lo que los eventos son buenos candidatos a convertirse en operaciones de las
clases.

18

Diseo de Sistemas
UABC FCA
M.C. Diana C. Ruiz Alvarez

Diagramas de Actividades.
UML presenta una versin actualizada de los llamados
diagramas de flujo, estos son los diagramas de actividades. Estos
diagramas permiten especificar el orden en que se llevan a cabo
ciertas operaciones sin enfocarse tanto en quien es el
responsable de realizarlas. Los diagramas de actividades se
presentan con la figura de un rectngulo en el interior de este se coloca otro rectngulo con las
esquinas redondeadas.

Los diagramas de actividad tienen los siguientes elementos:

Acciones. Estas no pueden descomponerse en ms acciones a su vez, se
pueden especificar precondiciones y postcondiciones para la accin. Una
accin puede ser la asignacin de un valor a una variable o atributo, la
llamada a una funcin u operacin, la llamada a alguna otra actividad compuesta de acciones.
Una accin se representa por un rectngulo con las esquinas redondeadas con el nombre de
la actividad dentro de este.
Flujo de control el cual indica el orden en que se ejecutan las
acciones. Este flujo se especifica con flechas que indican el
orden de ejecucin.
Nodo Objeto permiten mostrar cuando un objeto es modificado o es transformado en otro
objeto. Este se representa como una clase con el nombre de la clase del objeto, se puede
incluir el estado en el que se encuentra el objeto colocndolo entre corchetes debajo del
nombre de la clase. Tambin se puede representar el almacenamiento de datos utilizando un
objeto, colocando el estereotipo <<datastore>> y el nombre del almacenamiento.
Flujo de Objeto este era conocido como flujo de datos y muestra el flujo de objetos de una
actividad o accin a otra. Para representarlo se coloca
un objeto nodo entre dos actividades o acciones para
mostrar el flujo. La primera actividad se conecta al
objeto nodo utilizando una flecha en esa direccin,
luego se conecta el objeto nodo hacia la segunda actividad utilizando una flecha en esa
direccin.
Nodo de control. Estos se usan para guiar el flujo de control a travs de un
grupo de actividades. Estos nodos pueden ser de diferentes tipos:
o Inicial el cual indica el inicio de la secuencia de actividades y se
representa con un punto grande.
o Actividad final el cual indica el trmino del grupo de actividades,
representada con el smbolo la diana.
o Flujo final para indicar el trmino de algunos de los flujos de una
actividad, se representa por un crculo pequeo con una X dentro.
o Decisin. La cual permite especificar mediante una condicin el camino
que el flujo debe seguir utilizando una decisin Si-entonces-de otro
modo. Esta se representa con un diamante el cual se conecta con las actividades

19

Diseo de Sistemas
UABC FCA
M.C. Diana C. Ruiz Alvarez

o
o

correspondientes a cada camino a seguir. El criterio

que indica el camino a seguir se coloca entre
corchetes en la flecha del flujo de control
Merge. Este sirve para juntar diferentes caminos de
decisiones separadas. Esta conjuncin se
representa igual que la decisin con un diamante
grande pero en lugar de salir los diferentes caminos en esta ocasin los caminos llegan a l.
Paralelo. Este sirve para indicar actividades o
acciones que se pueden llevar a cabo al mismo
tiempo (de forma paralela). Este se representa por
una figura similar a un tenedor, el cual es una lnea
de donde salen flujos hacia las diferentes
actividades.
Join. Este sirve para juntar de nuevo los caminos que se ejecutaron de forma paralela, se
representa por la figura contraria al paralelo.
Conector, sirve para indicar que el diagrama de actividades continua en otra pgina ya que
en la actual no hay ms espacio. Este se representa
por un pequeo crculo con una etiqueta, este se
coloca en el punto donde se divide el diagrama en
ambas hojas o secciones.

Los diagramas de secuencias se pueden particionar para

indicar quien realiza que cada actividad. Esto se hace colando
lneas divisorias con el nombre del actor que realiza la accin,
en cada particin se colocan las acciones correspondientes al
actor. Las particiones se pueden colocar ya sea de forma horizontal o vertical de acuerdo a la
conveniencia del diseador
Los diagramas de actividades se recomiendan para:
Operaciones de alto nivel en donde se tienen operaciones complejas que incluyen muchos
pasos.
Detalles de los casos de
uso en donde se tienen
grupos de actividades que
se llevan a cabo de forma
concurrente, se puede
mostrar el flujo de
acciones
entre
el
escenario principal y los
alternativos.
Procesos de negocios o
flujos de trabajo no solo operaciones de software ya que se pueden mostrar documentos que
son generados.
Modelado de procesos. Se pueden representar los pasos de los procesos como actividades
en el diagrama.
20

Diseo de Sistemas
UABC FCA
M.C. Diana C. Ruiz Alvarez

Sumarizar muchos diagramas de secuencias. Cuando se tienen muchos diagramas de

secuencias para un caso de uso se pueden utilizar los diagramas de actividades para
conjuntar dichos diagramas y asegurarse de que el flujo de control sea el adecuado.
Diagrama de Componentes.

Un diagrama de componentes modelo la implementacin fsica del sistema (software), definiendo

componentes de software y las relaciones entre ellos. Un componente puede ser una tabla, un
archivo de datos, un programa ejecutable, libreras, documentos, etc. En estos diagramas se
plantean las decisiones sobre la arquitectura, hardware, redes, interfaces de software,
componentes y bases de datos.
Un componente puede ser la implementacin de una o ms clases. El diagrama de
componentes sirve para ver la estructura del sistema finalizado, proporcionar a los desarrolladores
una estructura del sistema, facilitar la elaboracin de la documentacin tcnica, planear
componentes reusables.
Para hacer el diseo considere:
Los requerimientos funcionales de la aplicacin, los cuales puede obtener a partir de los casos
de estudio
Flexibilidad de la aplicacin, considere que en ocasiones esta estructura puede cambiar por lo
que se debe mantener lo mas flexible posible en caso de que se requieran hacer cambios
Considere escalabilidad, reliability, y disponibilidad. El diseo debe ser escalable para poder
expandirse fcilmente, trabajar sin importar por ejemplo el nmero de usuarios que se
conecten y la disponibilidad del sistema de acuerdo a las necesidades de los usuarios.
Desempeo de la aplicacin. Los componentes deben ser elegidos de acuerdo a las
necesidades de desempeo que presenta la aplicacin
De igual forma se deben considerar cuestiones de costo y calendario lo cual limita la eleccin
de los componentes a utilizar.
El primer paso al disear el sistema es hacer la
descomposicin del mismo en subsistemas, los cuales son piezas
lgicas las cuales indican como el sistema ser armado,
mostrando cmo se agrupan las clases de una forma lgica. Los
subsistemas se representan con rectngulos con el estereotipo
<<subsystem>> y un cono opcional en forma de tenedor en la
esquina superior derecha. El subsistema muestra las clases que
lo componen y las asociaciones entre ellas. Una clase no debe
estar en ms de un subsistema. De requerirse una clase en diferentes subsistemas esta se puede
exportar.
Una gua posible para la particin en subsistemas en considerar tres subsistemas bsicos:
el que se encarga de interactuar con el usuario, el que contiene la lgica de las operaciones del
negocio y el que se encarga del acceso a la informacin o BD. Otra forma de separar en

21

Diseo de Sistemas
UABC FCA
M.C. Diana C. Ruiz Alvarez

subsistemas es basndose en los casos de uso y agrupando casos de uso similares dentro de
cada subsistema.
La estructura general del sistema se puede presentar de dos formas, utilizando un
paquete que representa el sistema completo dentro del cual se colocan los subsistema, o
mediante diagramas donde se indica que subsistemas son miembros de que sistema.

Una vez definidos los subsistemas hay que

especificar las operaciones de las cuales son
responsables cada subsistema.
Un subsistema autnomo y modular se le conoce como un componente. Los componentes deben
ser reemplazables sin cambios en el sistema total, de esto modo los componentes hace que el
sistema sea ms flexible, mantenible, escalable y reusable. Un componente tambin puede ser
una clase compleja con muchas interfaces y partes internas.
Cuando se disean componentes se deben tener claros los lmites y responsabilidades del mismo
esto se hace definiendo las responsabilidades e interfaces del componente, esto aumenta la
productividad y hace que el componente sea ms fcil de reemplazar.
Para que los componentes sean reemplazables se deben seguir los siguientes criterios:
Ocultar el trabajo interno del componente. Las partes internas del componente ocultan su
funcionalidad a los objetos fuera de l, lo que permite que este pueda ser reemplazado
fcilmente.
Proveer interfaces. Estas determinan que operaciones pueden ser invocadas del componente,
sin especificar cmo se hacen. Esto es una forma de ocultar el funcionamiento interno del
componente

22

Diseo de Sistemas
UABC FCA
M.C. Diana C. Ruiz Alvarez

Hacer las partes internas independientes. Las partes internas no

deben conocer a los objetos externos ya que de otro modo el
reemplazar un componente no asegurara que los objetos
externos estuvieran disponibles para el nuevo componente.
Especificar las interfaces requeridas. En ocasiones los objetos dentro del componente
requieren de acceder objetos fuera de l, si los objetos fuera del componente presentan su
interfaz para acceder a ellos esto previene que sean accedidos
directamente.

Un componente se representa con un rectngulo con dos

pequeos rectngulos centrados en la parte izquierda, un rectngulo
con el estereotipo <<componente>> o un rectngulo con el smbolo del componente (primera
descripcin) en la parte superior derecha.
Un componente puede depender de otro componente, por ejemplo un programa
ejecutable puede requerir el uso de una librera, o un programa cliente puede requerir de una
programa servidor que a su vez requiere de
una base de Datos. La dependencia entre
componentes se muestra por medio de una
flecha punteada que se dirige hacia el
componente que es requerido o del cual
depende el otro componente. Los estereotipos
tambin se pueden utilizar en las
dependencias.
Un diagrama de componentes puede
contener clases del modelo conceptual, esto se
utiliza para indicar que un componente est
hecho o implementa un conjunto de clases.
Cada componente presenta una
interfaz la cual se puede definir como su rostro al mundo exterior la cual define el conjunto de
operaciones que el componente presenta a otros componentes, es decir las operaciones por
medio de las cuales se puede acceder al componente. Un componente solo puede ser accedido a
travs de su interfaz. La relacin entre un componente y su interfaz se le llama realizacin. La
implementacin de la interfaz de un componente est realmente implementada por las clases que
conforman al componente por lo que el componente puede tener ms de una interface. La lnea
punteada con la flecha cerrada indica realizacin (implementacin)
Una interface se puede representar utilizando una clase que represente la interface y un
enlace punteado con un tringulo entre el componente y ella, o utilizando un pequeo crculo
unido por una lnea al componente (a manera de paleta). En ocasiones es necesario presentar o
mostrar la firma de los mtodos que son presentados por la interfaz, por lo que en lugar de
presentar la interface utilizando el smbolo de la paleta se utiliza la representacin de clase
indicando los mtodos.
23

Diseo de Sistemas
UABC FCA
M.C. Diana C. Ruiz Alvarez

Por otro lado un componente tambin puede presentar una interfaz a otros componentes,
esto se hace utilizando el smbolo parecido a Y redondeada para indicar que el componente hace
uso de una interfaz provedo por otro componentes, el segundo componente debe embonar su
interfaz (paleta) dentro del smbolo Y.

Diagramas de Distribucin
El diagrama de distribucin representa a
los componentes fsicos del sistema
(hardware) mostrando la forma en que
lucen fsicamente. A cada elemento de
hardware se le conoce como nodo el cual
puede ser cualquier recuso de cmputo. El nodo puede ser un procesador o un dispositivo. Un
procesador es aquel nodo que puede ejecutar un componente, mientras que un dispositivo no
puede ejecutar el componente.
Los nodos se representan con un cubo con su respectivo nombre. Se puede utilizar un
estereotipo para indicar el tipo de nodo o recurso del que se trata. El cubo se puede dividir en
compartimentos y utilizar estos para presentar ms informacin (componentes que residen en l).
La relacin ente nodos, conocida como conexin, se representa por medio de una lnea.
Adems de la asociacin entre nodos se puede utilizar el concepto de agregacin y dependencia.
Al mostrar los componentes dentro de un nodo se puede mostrar las relaciones entre ellos e
incluso las relaciones que existen con componentes que se encuentran en otros nodos.
El tipo de nodo puede ser mostrado utilizando estereotipos, los ms comunes son:

<<device>> el cual es un nodo que tiene capacidades de procesamiento

<<servidor de aplicaciones>> el cual provee servicios para una aplicacin

<<estacin de trabajo>> la cual es una computadora de un usuario

<<dispositivo mvil>> laptops, telfonos celulares y otros dispositivos inalmbricos

<<dispositivo embebido>>

<<ambiente de ejecucin>> el cual es un nodo virtual el cual puede parecer hardware pero no
lo es ejemplo un SO o una mquina virtual de Java

24

Diseo de Sistemas
UABC FCA
M.C. Diana C. Ruiz Alvarez

Para las vas de comunicacin entre los

nodos se puede utilizar tambin
estereotipos como <<serial>> (conexin a
travs del puerto serial), <<paralelo>>
(conexin de impresora por ejemplo),
<<usb>>, <<lann>>, <<internet>>,
etc.
Este tipo de diagramas permiten
comunicar como ser el sistema que se
intenta implementar. En sistemas grandes
es muy til ya que se puede tener
mltiples componentes conectados por
diversos medios, por lo que estos
diagramas permiten por ejemplo detectar
cuellos de botella entre las aplicaciones
En UML se introduce el concepto
de <<artefacto>> el cual es un archivo fsico el cual puede ser ejecutado en diferentes nodos. El
concepto de artefacto viene a reemplazar el concepto que se tena de componente en las
versiones anteriores. Por ms extrao que parezca, ni las clases ni los componentes se ejecutan
en el hardware, ya que estos tipos de elementos carecen de manifestacin en el mundo fsico.
Para lograr la manifestacin de las clases y componentes necesitamos un artefacto.
Existen tres tipos de artefactos:
De distribucin los cuales se requieren para ejecutar el sistema (archivos ejecutables, dlls,
etc.).
Para trabajar con el producto los cuales se utilizan para crear los componentes de distribucin
(cdigo fuente, archivos de datos, etc.)
De ejecucin, los cuales se crean al ser ejecutado el sistema.
Otros como <<ejecutable>>, <<librera>>, <<tabla>>, <<archivo>>, <<documento>>.
La lnea punteada con la flecha indica dependencia de un componente o artefacto hacia otro

25

Diseo de Sistemas
UABC FCA
M.C. Diana C. Ruiz Alvarez

26