Tipos de diagramas UML
ALUMNO : Miguel Macip Contreras
CARRERA : Ing. En Sistemas computacionales
2º semestre grupo “A”
DIAGRAMA DE CLASE
Diagrama de clase
Es el más utilizado y más conocido de los
diagramas orientados a objetos. Es la fuente
de generación de código.
El diagrama de clase representa clases, sus
partes y la forma en la que las clases de los
objetos están relacionados con otro.
Una clase es una definición de un tipo de
objeto.
Partes del diagrama de clases
Atributos: describe las características de una clase
de objetos.
Operaciones: define el comportamiento de una
clase de objetos
Estereotipos: ayuda a entender este tipo de objeto
en el contexto de otras clases de objetos con roles
similares dentro del diseño del sistema.
Asociación: es un término formal para un tipo de
relación.
Herencia: permite organizar las definiciones de la
clase para simplificar y facilitar su implementación
Clases
Las clases son descripciones de un juego de objetos
con características, comportamiento, relaciones y
semánticas comunes. Se usan para modelar un juego
de conceptos o entidades.
› Se denotan con un rectángulo con compartimentos.
› En ellos se ponen el nombre, los atributos, las operaciones y
además se pueden usar para anotar otras propiedades del
modelo como son (reglas del negocio, responsabilidades,
excepciones, etc.)
› Pueden tener interfaces para especificar conjuntos de
operaciones proporcionadas a su ambiente. Todas las
operaciones deben estar asociadas a métodos.
› Pueden tener relaciones de generalización con otras clases.
de un juego de
Atributos
Son descripciones de características, se usan para
modelar información asociada con una entidad,
sintaxis:
Nombre atributo[multiplicidad]:Tipo = Valor inicial
La multiplicidad es opcional e indica el número de
atributos por instancia de la clase.
Operaciones
Son descripciones del
comportamiento, se usan para
modelar los servicios u operaciones
asociados con una entidad, esto es,
lo que una entidad puede hacer,
sintaxis:
Nombre operación[parámetros:tipo]:Valor_retorno:tipo
Interfaces
Son clases que definen un juego de operaciones
externas accesibles pero sin métodos. Se usan
para modelar una serie de operaciones que definen
un servicio que puede ser ofrecido por diferentes
clases.
Se representan como clases pero con el
estereotipo <<interface>>.
Solo contienen operaciones públicas
Todos los diagramas soportan el Diagrama de
Clase
Casos de
Diagrama
Uso
de Objetos
Diagrama
de Clase Diagrama
Diagrama de Secuencia
de Actividades
Diagrama
Diagrama
de Estados
de Colaboración
Modelando Clases
La representación de una clase es un rectángulo con 3
divisiones:
El del nombre define la clase, (un tipo de objeto).
El de los atributos contiene la definición de los datos.
El de las operaciones contiene la definición de cada
comportamiento soportado por este tipo de objeto.
Ejemplo
La siguiente figura muestra un vuelo de una aerolínea
modelado como una clase UML.
Nombre
Atributos Atributo: tipo de dato
Operaciones Operación(parámetros:
Tipo de dato):valor de
retorno
Modelando un atributo
Un atributo describe una pieza de información que un
objeto tiene o conoce de sí mismo. Para poder usar esta
información se debe asignar un nombre y especificar el
tipo de dato.
El tipo de dato puede ser primitivo o tipo de dato
abstracto (definido)
Cada atributo puede tener reglas que limiten los valores
asignados a éste. Se puede usar un valor de default
para protegerlo.
Visibilidad de un atributo
La definición de un atributo debe especificar
que otros objetos los pueden ver. La visibilidad
puede ser:
› Public (+) permite el acceso a objetos de las otras
clases.
› Private (-) limita el acceso a la clase, solo
operaciones de la clase tienen acceso.
› Protected (#) permite el acceso a subclases. En el
caso de generalización (herencia), las subclases
deben tener acceso a los atributos y operaciones de
la superclase, sino no pueden heredar.
› Package (~) permite el acceso a los otros objetos en
el mismo paquete.
Ejemplo Especificación de un atributo
Elemento
Ejemplo
Nombre del atributo
compañía
Tipo de dato
compañía:character
Valor de default (si hay)
compañía:character = espacios
Restricciones
compañía:character = espacios {1 a 30}
Caracteres
compañía:character = espacios{1 a 30 alfabéticos, espacios, puntuación, no especiales}
Visibilidad
- compañía:character = espacios {1 a 30 alfabéticos, …….
Modelando una Operación
Los objetos tienen comportamientos, cosas que puedan
hacer y que se les puedan dar a éstos.
Las operaciones requieren un nombre, argumentos y a
veces un valor de retorno.
Las reglas de privacidad se aplican en la misma forma que
para los atributos: Private, Public, Protected y Package.
Ejemplo Especificación de una operación
Elemento
Ejemplo
Nombre
totalOrderAmount
Definir argumentos/
Parámetros, corresponden a una instancia de Order
totalOrderAmount (order: integer)
Definir el tipo de dato de retorno
totalOrderAmount (order: integer) : Dollar
Identificar y describir restricciones
totalOrderAmount (order: integer) : {El total es la suma de cada item (p.u. x
cantidad)
Visibilidad
+ totalOrderAmount (order: integer) : {El total es la suma ….
Diagrama de Clases: Asociaciones
El propósito de la asociación puede
expresarse en un nombre, verbo o frase
que describa como los objetos de un
tipo (clase) se relacionan con objetos
de otro tipo (clase). Por ejemplo:
Una persona tiene un coche
Una persona maneja un coche
Multiplicidad: cuantos objetos van a
participar en la relación
Asociaciones
Se indica el rol y la multiplicidad.
Un vuelo está asociado con un avión y un avión
puede tener asociados ninguno ó varios números
de vuelo.
Pasos para el diagrama de clases
Identificar las clases.
Mostrar los atributos y operaciones (posteriormente)
Dibujar asociaciones
Etiquetar asociaciones y en caso necesario los roles
Indicar multiplicidad
Dibujar fechas de dirección
Asociación Reflexiva
Una clase puede asociarse con sí misma. Una clase
Empleado puede relacionarse con sí misma a través del
rol gerente/dirige.
No significa que una instancia está relacionada consigo
misma, sino que una instancia de la clase está relacionada
con otra instancia de la misma clase.
Una instancia de Employee puede ser el gerente de otras
instancias de Employee. Como el rol manages tiene una
multiplicidad de 0…*, significa que puede no tener otros
empleados a quien dirigir.
Una instancia de Employee tiene 1 sólo gerente ó un solo
director
Asociación Cualificada
Un cualificador es un atributo de la clase en el lado
opuesto de la asociación, que permite hacer una
búsqueda en función a su valor. Por ejemplo “El cliente
usa el numOrden para buscar una orden”.
Un tipo de objeto usa el cualificador para accesar el otro
tipo de objeto.
cliente numOrden:int orden
Diagrama de Clase: Agregación y
Composición
Cada agregación es un tipo de asociación.
Cada composición es una forma de agregación.
Asociación
Agregación
Composción
AGREGACIÓN BASICA
Es un tipo especial de asociación utilizado para modelar
una relación “whole to its parts”.
Por ejemplo, Coche es una entidad “whole” y Llanta es
una parte del Coche.
Una asociación con una agregación indica que una clase
es parte de otra clase.
En este tipo de asociación, la clase hijo puede sobrevivir
sin su clase padre.
Generalización
Son asociaciones entre elementos más generales y
elementos más específicos, en los cuales éstos últimos
son consistentes totalmente con los primeros, por lo que
heredan las características proporcionadas por lo
elementos generales y además pueden aumentar
información.
Este tipo de relación también se conoce como herencia.
En una generalización no hay multiplicidad ni roles. Una
(Asociación define las reglas de cómo los objetos se
pueden relacionar entre ellos.)
La visibilidad “protected” permite que solo objetos de la
misma clase ó subclase vean el elemento.
Elementos de la generalización
Para dibujarla, hay que definir:
Superclase: es una clase que contiene alguna combinación
de atributos, operaciones y asociaciones que son comunes
a dos o más tipos de objetos que comparten el mismo
propósito.
Subclase: es una clase que contiene una combinación de
atributos, operaciones y asociaciones que son únicas a un
tipo de objeto definido por una superclase.
La superclase es reutilizada por la subclase.
Herencia
Perro
Collie Boxer Dalmata
Paquetes
Es un elemento organizador que proporciona UML al
dividir el sistema en paquetes lo hace más fácil de
entender.
Ejemplo interface
En el diagrama anterior las clases Professor y Student
implementan a la interface Person y no heredan de ésta,
podemos deducirlo a partir de:
1) El objeto Person de acuerdo a la simbología del diagrama
está como una interface y Professor y Student están
como clases.
2) No se trata de herencia ya que la línea con la flecha está
punteada y no sólida.
Instancias
Cuando se modela la estructura de un sistema, a veces es
útil mostrar ejemplos de las instancias de las clases.
UML proporciona el elemento instance especification,
que muestra información importante utilizando un
ejemplo.
La notación es la misma que la de una clase, solo que en
el espacio superior el nombre se forma con:
nombre de la instancia : nombre de la clase
Roles
Se puede incluir el rol de las clases, el siguiente ejemplo
de los roles jugados por la clase Employee (de la
asociación reflexiva), mostramos que la relación es entre
un Employee jugando el papel de gerente y un Employee
jugando el rol de miembro del equipo.
DIAGRAMAS DE CLASES
¿Qué es una Clase?
Artefacto de modelado que Describe un
conjunto de objetos que comparten los
mismos:
• Atributos (conocimiento)
• Operaciones (responsabilidad)
• Relaciones (entrelazamiento)
• Semántica (relevancia)
Un diagrama de clases es un tipo de diagrama
estático que describe la estructura de un
sistema mostrando sus clases, atributos y las
relaciones entre ellos.
Los diagramas de clases son utilizados
durante el proceso de análisis y diseño de los
sistemas, donde se crea el diseño conceptual
de la información que se manejará en el
sistema, y los componentes que se
encargaran del funcionamiento y la relación
entre uno y otro
Para qué usamos un diagrama
de Clases
Modelar los
aspectos • Realizar la abstracción de un
estáticos de dominio
• Formalizar el análisis de
un sistema conceptos
• Definir una solución de diseño
• Construir componentes de
software
• Muestra un conjunto de elementos que son
estáticos, como las clases y tipos, junto con
sus contenidos y relaciones
• Es un grafo de elementos clasificadores
conectados por varias relaciones estáticas
Relaciones en un diagrama de clases
Los diagramas de clases están compuestos
por clases y por relaciones entre ellas. Las
relaciones que se pueden usar son:
• Relación de asociación
Una asociación es una conexión entre clases,
una conexión semántica (enlace) entre los
objetos de dichas clases. Un tipo especial de
asociación es la relación de agregación.
• Relación de dependencia
Una dependencia es una relación entre elementos,
uno independiente y otro dependiente. Un cambio en
el elemento independiente afectará al elemento
dependiente.
• Relación de generalización
Una generalización es una relación entre un elemento
más general y otro más específico. El elemento más
específico puede contener sólo información adicional.
Una instancia (un objeto es una instancia de una
clase) del elemento más específico se puede usar si
el elemento más general lo permite.
DIAGRAMA DE CLASES
DEFINICIÓN
Un diagrama de clases es un tipo de diagrama estático
que describe la estructura de un sistema mostrando sus
clases, atributos y las relaciones entre ellos.
ELEMENTOS
Un diagrama de clases esta compuesto por los siguientes
elementos:
Clase: atributos, métodos y visibilidad.
Relaciones: Herencia, Composición, Agregación,
Asociación y Uso.
CLASE
Es la unidad básica que encapsula toda la información de
un Objeto (un objeto es una instancia de una clase). A
través de ella podemos Modelar el entorno en estudio.
Una clase es representada por un rectángulo que posee
tres divisiones:
ATRIBUTO
Los atributos o características de una Clase pueden ser de tres
tipos, los que definen el grado de comunicación 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 accesesible desde todos lados.
private (-,): Indica que el atributo sólo será accesible desde
dentro de la clase (sólo sus métodos lo pueden accesar).
protected (#,): Indica que el atributo no será accesible desde
fuera de la clase, pero si podrá ser accesado por métodos de la
clase además de las subclases que se deriven (ver herencia).
METODOS
Los métodos u operaciones de una clase son la forma en como
ésta interactúa con su entorno, éstos pueden tener las
características:
public (+,): Indica que el método será visible tanto dentro como
fuera de la clase, es decir, es accsesible desde todos lados.
private (-,): Indica que el método sólo será accesible desde dentro
de la clase (sólo otros métodos de la clase lo pueden accesar).
protected (#,): Indica que el método no será accesible desde fuera
de la clase, pero si podrá ser accesado por métodos de la clase
además de métodos de las subclases que se deriven (ver herencia).
RELACIÓN ENTRE CLASES
HERENCIA: Indica que una subclase hereda los métodos y
atributos especificados por una Súper Clase, por ende la
Subclase además de poseer sus propios métodos y
atributos, poseerá las características y atributos visibles
de la Súper Clase (public y protected).
ASOCIACIÓN: La relación entre clases conocida como
Asociación, permite asociar objetos que colaboran entre
si.
Cabe destacar que no es una relación fuerte, es decir, el
tiempo de vida de un objeto no depende del otro.
DEPENCDENCIA O INSTANCIA: Representa un tipo de
relación muy particular, en la que una clase es instanciada
(su instanciación es dependiente de otro objeto/clase).
EJEMPLO
DIAGRAMA DE OBJETOS
Los diagramas de objetos son utilizados durante el
proceso de Análisis y Diseño de los sistemas
informáticos en la metodología UML
Se puede considerar un caso especial de un diagrama de
clases en el que se muestran instancias específicas 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 notación es similar a los diagramas de clase. Estos no
muestran nada diferente en su
arquitectura a los diagramas de secuencia, pero reflejan
multiplicidad y roles.
Los diagramas de objetos modelan las instancias de
elementos contenidos en los diagramas de clases. Un
diagrama de objetos muestra un conjunto de objetos y
sus relaciones en un momento concreto.
Los diagramas de objetos modelan las instancias de
elementos contenidos en los diagramas de clases. Un
diagrama de objetos muestra un conjunto de objetos y
sus relaciones en un momento concreto.
DIAGRAMA DE COMPONENTES
Un diagrama de componentes es un diagrama tipo del
Lenguaje Unificado de Modelado.
Un diagrama de componentes representa cómo un sistema
de software es dividido en componentes y muestra las
dependencias entre estos componentes.
Un diagrama de componentes es un diagrama tipo del
Lenguaje Unificado de Modelado.
Un diagrama de componentes representa cómo un sistema
de software es dividido en componentes y muestra las
dependencias entre estos componentes.
Los diagramas de componentes se pueden
clasificar en:
Componentes de despliegue: necesarios y suficientes
para formar un sistema ejecuta. Por ejemplo: bibliotecas
dinámicas (dll), ejecutables (exe).
Componentes productos de trabajo: surgen durante el
proceso de desarrollo y queda al final del [Link]
ejemplo: [Link], [Link].
Componentes de ejecución: se crean como consecuencia
de un sistema de ejecución Por ejemplo: objetos que se
instancian a partir de una dll.
Componentes de despliegue: necesarios y suficientes
para formar un sistema ejecuta. Por ejemplo: bibliotecas
dinámicas (dll), ejecutables (exe).
Componentes productos de trabajo: surgen durante el
proceso de desarrollo y queda al final del [Link]
ejemplo: [Link], [Link].
Componentes de ejecución: se crean como consecuencia
de un sistema de ejecución Por ejemplo: objetos que se
instancian a partir de una dll.
Conclusión
Podemos concluir que los diagramas de componentes son
una herramienta muy útil para conocer la manera que se
desarrolla el sistema pero incluyendo sus componentes
físicos y estos a la vez relacionados con las clases que nos
muestran proporcionan una perspectiva estática del
sistema.
DIAGRAMA DE SECUENCIA
CONCEPTO
Es un tipo de diagrama usado para modelar la
interacción entre objetos en un sistema según
UML. En inglés se pueden encontrar como
"sequence diagram", "event-trace diagrams",
"event scenarios" o "timing diagrams” .
UTILIDAD
Muestra la interacción de un conjunto de
objetos en una aplicación a través del tiempo
y se modela para cada caso de uso.
Contiene detalles de implementación del
escenario, incluyendo los objetos y clases que
se usan para implementar el escenario, y
mensajes intercambiados entre los objetos.
Muestra los objetos que intervienen en el
escenario con líneas discontinuas verticales, y
los mensajes pasados entre los objetos como
flechas horizontales.
TIPOS DE MENSAJES
Existen dos tipos de mensajes:
Sincrónicos: corresponden con llamadas a
métodos del objeto que recibe el mensaje. El
objeto que envía el mensaje queda bloqueado
hasta que termina la llamada. Este tipo de
mensajes se representan con flechas con la
cabeza llena.
Existen dos tipos de mensajes:
Sincrónicos: corresponden con llamadas a
métodos del objeto que recibe el mensaje. El
objeto que envía el mensaje queda bloqueado
hasta que termina la llamada. Este tipo de
mensajes se representan con flechas con la
cabeza llena.
Pueden ser usados en dos formas:
De instancia: describe un escenario especifico
(un escenario es una instancia de la ejecución
de un caso de uso).
Genérico: describe la interacción para un caso
de uso; Utiliza ramificaciones ("Branches"),
condiciones y bucles.
ESTRUCTURA
Los mensajes se dibujan cronológicamente
desde la parte superior del diagrama a la
parte inferior; la distribución horizontal de los
objetos es arbitraria. Durante el análisis
inicial, el modelador típicamente coloca el
nombre “business” de un mensaje en la línea
del mensaje.
Más tarde, durante el diseño, el nombre
“business” es reemplazado con el nombre del
método que está siendo llamado por un objeto
en el otro. El método llamado, o invocado,
pertenece a la definición de la clase
instanciada por el objeto en la recepción final
del mensaje.
Diagramas de
Actividades
Definición
Demuestra la serie de actividades que deben ser
realizadas en un uso-caso, así como las distintas rutas que
pueden irse desencadenando en el uso-caso.
Utilidad
Es utilizado en conjunción de un diagrama uso-caso para
auxiliar a los miembros del equipo de desarrollo a
entender como es utilizado el sistema y como reacciona
en determinados eventos.
Se pudiera considerar que un diagrama de actividad
describe el problema, mientras un diagrama de flujo
describe la solución.
Composición
Inicio: El inicio de un diagrama de actividad es
representado por un círculo de color negro sólido.
Actividad : Una actividad representa la acción que será
realizada por el sistema la cual es representada dentro de
un ovalo.
Transición: Una transición ocurre cuando se lleva acabo
el cambio de una actividad a otra, la transición es
representada simplemente por una línea con una flecha
en su terminación para indicar dirección.
Elementos
Elementos
DIAGRAMAS DE CASOS DE USO
CONCEPTO:
Un diagrama de casos de uso es una especie de
diagrama de comportamiento.
COMPONENTES DE UN DIAGRAMA DE
CASOS DE USO
RELACIONES DE CASOS DE USO
INCLUSION (INCLUDE O USE)
EXTENSION (EXTEND)
GENERALIZACION
INCLUSION (INCLUDE O USE)
Es una forma de interacción o creación, un caso de uso
dado puede "incluir" otro. El primer caso de uso a
menudo depende del resultado del caso de uso incluido.
Esto es útil para extraer comportamientos
verdaderamente comunes desde múltiples casos de uso a
una descripción individual, desde el caso El estándar de
Lenguaje de Modelado Unificado de OMG define una
notación gráfica para realizar diagramas de casos de uso,
pero no el formato para describir casos de uso.
EXTENSION
(EXTEND)
Es otra forma de interacción, un caso de uso dado, (la
extensión) puede extender a otro. Esta relación indica que
el comportamiento del caso de la extensión se utiliza en
casos de uso, un caso de uso a otro caso siempre debe
tener extensión o inclusión.
"La extensión, es el conjunto de objetos a los que se
aplica un concepto. Los objetos de la extensión son los
ejemplos o instancias de los conceptos."
GENERALIZACION
"Entonces la Generalización es la actividad de identificar
elementos en común entre conceptos y definir las
relaciones de una superclase (concepto general) y
subclase (concepto especializado). Es una manera de
construir clasificaciones taxonómicas entre conceptos
que entonces se representan en jerarquías de clases. Las
subclases conceptuales son conformes con las
superclases conceptuales en cuanto a la intención y
extensión."
EJEMPLO DE DIAGRAMA DE CASOS DE
USO:
El diagrama de la derecha describe la
funcionalidad de un Sistema Restaurante muy
simple. Los casos de uso están representados por
elipses y los actores están, por ejemplo, los casos
de uso se muestran como parte del sistema que
está siendo modelado, los actores no.
Diagramas DE emplazamiento
Es aquel que muestra las relaciones físicas entre los componentes
de software y de hardware en el sistema entregado. Así, el
diagrama de emplazamiento es un buen sitio para mostrar cómo
se enrutan (se refiere a la selección del camino en una red de
computadoras por donde se envían datos) y se mueven los
componentes y los objetos, dentro de un sistema distribuido.
Cada nodo de un diagrama de emplazamiento representa
alguna clase de unidad de cómputo; en la mayoría de los casos
se trata de una pieza de hardware. El hardware puede ser un
dispositivo o un sensor simple, o puede tratarse de un
mainframe (Computadora grande, poderosa y costosa utilizada
principalmente en empresas que necesitan procesar gran
cantidad de datos o soportar gran cantidad de usuarios.).
Los componentes en un diagrama de emplazamiento
representan módulos físicos de código y corresponden
exactamente a los paquetes de un diagrama de paquetes de tal
modo que el diagrama de emplazamiento muestra dónde se
ejecuta cada paquete en el sistema.
Las dependencias entre los componentes deben ser las
mismas que las dependencias de paquetes. Estas
dependencias muestran cómo se comunican los
componentes con otros componentes. La dirección de
una dependencia dada indica el conocimiento en la
comunicación.
Así, en el diagrama, la IU de la unidad de hígado depende
de la Fachada de cliente de unidad de hígado, ya que
llama a métodos específicos en la fachada. A pesar de
que la comunicación es en ambas direcciones, en el
sentido de que la Fachada devuelve datos, la Fachada no
sabe quién la llama y, por tanto, no depende de la IU . En
la comunicación entre ambos componentes del Dominio
de atención a la salud, ambos saben que están hablando
con otro componente de Dominio de atención a la salud,
así que la dependencia de la comunicación es en dos
sentidos.
Así, en el diagrama, la IU de la unidad de hígado depende
de la Fachada de cliente de unidad de hígado, ya que
llama a métodos específicos en la fachada. A pesar de
que la comunicación es en ambas direcciones, en el
sentido de que la Fachada devuelve datos, la Fachada no
sabe quién la llama y, por tanto, no depende de la IU . En
la comunicación entre ambos componentes del Dominio
de atención a la salud, ambos saben que están hablando
con otro componente de Dominio de atención a la salud,
así que la dependencia de la comunicación es en dos
sentidos.
En la práctica, no he visto que se use mucho este tipo de
diagramas. La mayoría de la gente dibuja diagramas para
mostrar este tipo de información, pero se trata de
bocetos informales. En general, no tengo problemas con
este tipo de diagramas, ya que cada sistema tiene sus
propias características físicas que se querrán subrayar. A
medida que se tiene que lidiar cada vez más con los
sistemas distribuidos, estoy seguro de que se requerirá
mayor formalidad, según se vaya entendiendo mejor
cuáles son los asuntos que se deben resaltar en los
diagramas de emplazamiento.
DIAGRAMA DE ESTADO
¿QUE ES EL DIAGRAMA DE ESTADO ?
es un diagrama utilizado para identificar cada una de las
rutas o caminos que puede tomar un flujo de información
luego de ejecutarse cada proceso.
MAQUINA DE ESTADO
Una MÁQUINA DE ESTADO es un comportamiento que especifica las
secuencias de estados por las que pasa un objeto a lo largo de su vida en
respuesta a eventos, junto con sus respuestas a estos eventos.
REPRESENTACION GRAFICA DE UNA MAQUINA DE ESTADOS
Las maquinas de estados se visualizan por medio de diagramas de
estado.
Representación grafica de
Estados: condición o situación
Nombre
Efectos de entrada/salida
Transiciones Internas
Subestados
Eventos diferidos
Permite identificar bajo qué argumentos se ejecuta cada
uno de los procesos y en qué momento podrían tener
una variación.
El diagrama de estados permite visualizar de una forma
secuencial la ejecución de cada uno de los procesos.
Un Diagrama de Estados muestra la secuencia de estados
por los que pasa bien un caso de uso, bien un objeto a lo
largo de su vida, o bien todo el sistema. En él se indican
qué eventos hacen que se pase de un estado a otro y
cuáles son las respuestas y acciones que genera.
En cuanto a la representación, un diagrama de estados es
un grafo cuyos nodos son estados y cuyos arcos dirigidos
son transiciones etiquetadas con los nombres de los
eventos.
Un estado se representa como una caja redondeada con
el nombre del estado en su interior. Una transición se
representa como una flecha desde el estado origen al
estado destino.
Un diagrama de estados puede representar ciclos
continuos o bien una vida finita, en la que hay un estado
inicial de creación y un estado final de destrucción
(finalización del caso de uso o destrucción del objeto). El
estado inicial se muestra como un círculo sólido y el
estado final como un círculo sólido rodeado de otro
círculo. En realidad, los estados inicial y final son
pseudoestados, pues un objeto no puede “estar” en esos
estados, pero nos sirven para saber cuáles son las
transiciones inicial y final(es).
ELEMENTOS DE LOS DIAGRAMAS DE ESTADO
Estado
Identifica un periodo de tiempo del objeto (no instantáneo) en el cual el objeto está esperando
alguna operación, tiene cierto estado característico o puede recibir cierto tipo de estímulos. Se
representa mediante un rectángulo con los bordes redondeados, que puede tener tres
compartimientos: uno para el nombre, otro para el valor característico 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 transición de un estado a otro de un objeto. Esta
ocurrencia puede ser una de varias cosas:
· Condición que toma el valor de verdadero o falso
· Recepción de una señal de otro objeto en el modelo
· Recepción de un mensaje
· Paso de cierto período de tiempo, después 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.
Transición a estados anidados
Una transición 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 duración.
· La actividad de espera se interrumpe cuando el evento esperado
tiene lugar.
· Este evento desencadena una transición que permite salir del
estado que alberga la actividad de espera. El flujo de control se
transmite entonces a otro estado.