República Bolivariana de Venezuela

Universidad Bicentenaria de Aragua

Facultad de Ingeniería

Escuela de Sistemas

Integrantes:

Arencibia, Sosiree V- 14.741.783

Guerra, Briceida V-15.648.865

Mata, Leonardo V-20.451.242

Morales Luis V-19.516.118

Turmero, 12 Julio de 2015

INTRODUCCION

Un proyecto de software con éxito es aquél que produce un software de calidad,

consistente y sobre todo que satisface las necesidades de los usuarios que van a

utilizar el producto resultante. El modelado es una parte fundamental en el desarrollo

de sistemas, debido a que se construyen modelos para visualizar el comportamiento

del sistema y controlar su arquitectura. Incluso al producir software de sistemas

pequeños se hace necesario realizar un análisis y un modelado ya que se producirían

con una mejor calidad. Por lo tanto, mientras mas más grande y complejos son los

sistemas más importante es hacer un buen modelado para que ayude a entender el

comportamiento del sistema en su totalidad.

El Lenguaje de Modelamiento Unificado (UML - Unified Modeling Language) es un

lenguaje gráfico para visualizar, especificar y documentar cada una de las partes que

comprende el desarrollo de software. UML entrega una forma de modelar cosas

conceptuales como lo son procesos de negocio y funciones de sistema, además de

cosas concretas como lo son escribir clases en un lenguaje determinado, esquemas de

base de datos y componentes de software reusables. Tiene como objetivo principal

entregar un material de apoyo que le permita al lector poder definir diagramas propios

como también poder entender el modelamiento de diagramas ya existentes.

En todo proceso de software donde se utilice una metodología orientada a objetos y la

notación UML no pueden faltar los diagramas, para representar las diferentes vistas

del producto final. Los diagramas de UML se pueden dividir en estáticos (aportan una

visión estática del sistema) y dinámicos (aportan una visión dinámica del sistema).

Entre los diagramas estáticos se observan: Diagrama de casos de uso, Diagrama de

clases, Diagrama de objetos, Diagrama de componentes, Diagrama de despliegue;

mientras que los diagramas dinámicos son: Diagrama de estados, Diagrama de

actividad, Diagramas de interacción o Diagrama de secuencia o Diagrama de

colaboración.

En este sentido, es de gran importancia identificar al momento del modelado de

sistemas cuales de los diagramas son necesarios para el proyecto a ejecutar. En tanto,

será la práctica y experiencia y el tipo de sistema a desarrollar lo que determinará este

proceso. Por ejemplo, se puede decir que en aplicaciones “cliente” el diseñador suele

utilizar los diagramas de casos de uso, de clase y de colaboración o de secuencia, para

aplicaciones donde sean importantes los eventos será necesario utilizar el diagrama de

estados, para aplicaciones cliente-servidor además de los diagramas de casos de uso,

clases y objetos puede ser conveniente utilizar los diagramas de despliegue y

componentes, y para aplicaciones complejas cliente-servidor es recomendable utilizar

todos los diagramas de UML debido a que dará una visión más amplia de cómo será

el sistema final.

DIAGRAMA DE CLASES

El diagrama de clases recoge las clases de objetos y sus asociaciones. En este

diagrama se representa la estructura y el comportamiento de cada uno de los objetos

del sistema y sus relaciones con los demás

temporal.

Con el fin de facilitar la comprensión del diagrama, se pueden incluir paquetes como

elementos del mismo, donde cada uno de ellos agrupa un conjunto de clases.

Este diagrama no refleja los comportamientos temporales de las clases, aunque para

Los elementos :

1. Clases

. Los objetos son instancias de las clases.

No existe un procedimiento inmediato que permita localizar las clases del diagrama

de clases. Estas suelen corresponderse con sustantivos que hacen referencia al ámbito

del sistema de información y que se encuentran en los documentos de las

especificaciones de requisitos y los casos de uso.

Dentro de la estructura de una clas

:

Los atributos de una clase representan los datos asociados a los objetos

instanciados por esa clase.

los objetos de una clase, caracterizando a dichos objetos.

Las clases y en general todos los elementos de los diagramas, pueden estar

clasificados de acuerdo a varios criterios, como por ejemplo su objetivo dentro de un

programa. Esta clasificación adicional se expresa mediante un Estereotipo

pueden aparecer en un modelo. Los tipos son:

Objetos Entidad.

.

Objetos de control.

2. Relaciones

Los tipos más importantes de relaciones estáticas entre clases son los siguientes:

es general, y denota

básicamente una dependencia semántica. Por ejemplo, una Persona trabaja

para una Empresa.

:

o Rol, o nombre de la asociación, que describe la semántica de la

relación en el sentido indicado. Por ejemplo, la asociación entre

Persona y Empresa recibe el nombre de trabaja para, como rol en ese

sentido.

o Multiplicidad, específica cuantas instancias de una clase están

asociadas a una instancia de la otra clase. Los tipos de multiplicidad

son: Uno a uno, uno a muchos y muchos a muchos.

Herencia. Herencia es el mecanismo que permite a una clase de objetos

incorporar atributos y métodos .

Con la herencia se refleja u . La clase de la cual se

hereda se denomina superclase, y la que hereda subclase.

jerárquica entre un objeto

que representa la totalidad de ese objeto y las partes que lo componen.

Permite el agrupamiento físico de estructuras relacionadas lógicamente. Los

“ -parte- ” P motor, ruedas,

carrocería son parte de automóvil.

Composición. La composición

de propiedad es más fuerte, e incluso coinciden los tiempos de vida del objeto

completo y las partes que lo componen.

Dependencia de dependencia se utiliza entre dos clases o entre

una clase y una interfaz, e indica que una clase requiere de otra para

proporcionar alguno de sus servicios.

3. Interfaces

e

una clase o paquete que son visibles desde otras clases o paquetes. Normalmente, se

corresponde con una parte del comportamiento del elemento que la proporciona.

4. Paquetes

Los paquetes se usan para dividir el modelo de clases del sistema de información,

agrupando clases u otros paquetes según los criterios que sean oportunos. Las

dependencias entre ellos se definen a partir de las relaciones establecidas entre los

distintos elementos que se agrupan en estos paquetes.

SIMBOLOGIA

Una clase se representa como una caja, separada en tres zonas por líneas horizontales.

En la zona superior se muestra el nombre de la clase y propiedades generales como el

estereotipo. El nombre de la clase aparece centrado y si la clase es abstracta se

representa en cursiva. El estereotipo, si se muestra, se sitúa sobre el nombre y entre el

símbolo:

<< .... >>.

La zona central contiene una lista de atributos, uno en cada línea. La notación

utilizada para representarlos incluye, dependiendo del detalle, el nombre del atributo,

su tipo y su valor por defecto, con el formato:

visibilidad nombre : tipo = valor-inicial { propiedades }

(+), privada (-) o protegida (#

.

:

visibilidad nombre - - ): tipo-devuelto { propiedad

}

(+), privada (-) o protegida (#

:

nombre : tipo = valor-por-defecto

La notación especificada se puede simplificar según el nivel de detalle con el que se

quiera trabajar en un momento dado.

Relaciones

con la misma clase, indicando que una instancia d

instancias de la misma clase, lo que se conoce como .

. Los estereotipos permiten

clasificar las relaciones en familias y se escribirán : << ... >>.

Las diferen

:

Multiplicidad

‘n ‘*

.

Orden: Se puede especificar si las instancias guardan un orden con la palabra

‘{ordered}

.

Navegabilidad

.

Rol o

está unida a una clase, para expresar como esa cla

.

Además, existen notaciones específicas para los otros tipos de relación, como son:

Agregación: Se representa con un rombo hueco en la clase cuya instancia es

una agregación de las instancias de la otra.

Composición: Se representa con un rombo lleno en la clase cuya instancia

contiene las instancias de la otra clase.

Dependencia: Una línea discontinua con una flecha apuntando a la clase

cliente. La relación puede tener un estereotipo que se coloca junto a la línea, y

entre el símbolo: << ... >>.

Herencia

hueca en el extremo que apunta a la superclase.

EJEMPLO:

DIAGRAMA DE COLABORACION

Los diagramas de colaboración muestran las interacciones que ocurren entre los

objetos que participan en una situación determinada. Esta es más o menos la misma

información que la mostrada por los diagramas de secuencia, pero destacando la

forma en que las operaciones se producen en el tiempo, mientras que los diagramas

de colaboración fijan el interés en las relaciones entre los objetos y su topología.

En los diagramas de colaboración los mensajes enviados de un objeto a otro se

representan mediante flechas, mostrando el nombre del mensaje, los parámetros y la

secuencia del mensaje. Los diagramas de colaboración están indicados para mostrar

una situación o flujo programa específicos y son unos de los mejores tipos de

diagramas para demostrar o explicar rápidamente un proceso dentro de la lógica del

programa.

Simbología del Diagrama de Colaboraciones.

EJEMPLO: LA MAQUINA DE GASEOSAS

Las cosas se hacen más interesantes cuando aplica las condiciones a una situación

real, como lo hizo en la hora anterior con la máquina de gaseosas. Iniciemos con la

“ ”

1. El cliente inserta el dinero en la alcancía que se encuentra en la fachada de la

máquina.

2. El cliente hace su elección.

3. El dinero viaja hacia el registrador.

4. El registrador verifica si la gaseosa elegida está en el dispensador.

5. Dado que es mejor situación, asumimos que si hay gaseosas, y el registrador

actualiza su reserva de efectivo.

6. El registrador hace que el dispensador entregue la gaseosa en la fachada de la

máquina.

M “ ”

SIMBOLOGIA

DIAGRAMA DE SECUENCIAS:

Los diagramas de secuencia ilustran la interacción entre objetos y el orden secuencial

en el que ocurren dichas interacciones, es decir cómo se comunican los objetos entre

sí. Este tipo de esquema 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. El diagrama de

secuencia contiene detalles de implementación del escenario, incluyendo los objetos y

clases que se usan para implementar el escenario y mensajes intercambiados entre

ellos.

Los objetos están representados por líneas intermitentes verticales, con el nombre del

objeto en la parte más alta. El eje de tiempo también es vertical, incrementándose

hacia abajo, de forma que los mensajes son enviados de un objeto a otro en forma de

flechas con los nombres de la operación y los parámetros

Se Caracteriza principalmente por:

Mostrar la secuencia de mensajes entre objetos durante un escenario concreto.

Cada objeto viene dado por una barra vertical.

El tiempo transcurre de arriba abajo.

Cuando existe demora entre el envío y la atención se puede indicar usando

una línea oblicua.

Se prepara durante la fase de análisis de un ciclo de desarrollo.

Su creación depende de la formulación previa de los casos de uso.

El comportamiento del sistema es una descripción de lo que hace y no de

cómo lo hace.

Entre sus Ventajas tenemos:

Da la posibilidad de representar los mensajes en función del tiempo.

La separación de los mensajes no indica intervalos o cantidades de tiempo,

solo ordenación temporal.

Es posible añadir restricciones temporales.

Desventajas del Diagrama de Secuencia:

Una representación de un diagrama de secuencia demasiado largo, puede ser

difícilmente entendido por alguien ajeno al sistema.

La Simbología utilizada en este Diagrama es la siguiente:

Línea de vida de un objeto:

La línea de vida de un objeto representa la vida del objeto durante la interacción. En

un diagrama de secuencia un objeto se representa como una línea vertical punteada

con un rectángulo de encabezado y con rectángulos a través de la línea principal que

denotan la ejecución de métodos (activación).

Activación:

Muestra el período de tiempo en el cual el objeto se encuentra desarrollando alguna

operación, bien sea por sí mismo o por medio de delegación a alguno de sus atributos.

Se denota como un rectángulo delgado sobre la línea de vida del objeto.

Mensaje:

El envío de mensajes entre objetos se denota mediante una línea sólida dirigida, desde

el objeto que emite el mensaje hacia el objeto que lo ejecuta.

Tiempos de transición:

En un entorno de objetos concurrentes o de demoras en la recepción de mensajes, es

útil agregar nombres a los tiempos de salida y llegada de mensajes.

Caminos alternativos de ejecución y concurrencia:

En algunos casos sencillos los caminos alternativos pueden expresarse en un

diagrama de secuencias alternativas de ejecución. Estas alternativas pueden

representar condiciones en la ejecución o diferentes hilos de ejecución

Destrucción de un objeto

Se representa como una X al final de la línea de ejecución del objeto.

Ejemplo:

Modelar sistemas medianos o grandes conlleva manejar una cantidad considerable de

elementos de modelado (clases, interfaces, componentes, nodos, relaciones,

diagramas); en la medida en que estos sistemas se hacen más grandes, se vuelve más

difícil comprenderlos, así como entender sus cambios. A su vez, los métodos

estructurados se valieron de la descomposición funcional, en la cual el sistema en su

conjunto se correlacionaba como función y se dividía en subfunciones, que a su vez

se dividían en otras subfunciones, y así sucesivamente. Dicho esto, las funciones eran

como los casos de uso en un sistema orientado a objetos, en el que las funciones

representaban algo que hacía el sistema como un todo.

Dentro de la misma idea, el proceso y los datos llegaron a manejarse de modo en que

se entendían como elementos separados. De tal modo que, además de una

descomposición funcional, también había una estructura de datos. Esta última

ocupaba el segundo lugar, aunque ciertas técnicas de ingeniería de información

agrupaban los registros de datos en áreas temáticas y producían matrices que

mostraban la interrelación entre las funciones y los registros de datos.

Es desde este punto de vista que puede apreciarse el gran cambio que han significado

los objetos. Ha desaparecido la separación entre el proceso y los datos, y la

descomposición funcional. Una idea es agrupar las clases en unidades de nivel más

alto. Esta idea aparece, aplicada de manera muy libre, en muchos métodos orientados

a objetos. En el UML, a este mecanismo de agrupamiento se le llama paquete o las

abstracciones que organizan un modelo.

Paquete

Un paquete es un mecanismo de propósito general para organizar un modelo de

manera jerárquica. También posee la funcionalidad de organizar los elementos

modelados con UML, facilitando de ésta forma el manejo de los modelos de un

sistema complejo. Es también importante, que define un espacio de nombres: dos

elementos de UML pueden tener el mismo nombre, con tal y estén en paquetes

distintos.

Características

Son completamente diferentes a las clases, ya que las clases son abstracciones de

aspectos del problema o la solución, y los paquetes son mecanismos para organizar,

pero no tienen identidad (no puede haber instancias de paquetes).

Un paquete puede contener elementos como clases, interfaces, componentes, nodos,

colaboraciones, casos de uso e incluso otros paquetes. De esta forma, cuando se

muestran los elementos del paquete, el nombre se coloca en la pestaña de la carpeta.

También, entre un paquete y sus elementos existe una relación de composición a

saber, un elemento del modelo se declara en un sólo paquete, aunque puede ser

referenciado desde otros. Por lo que, si el paquete se destruye, el elemento también es

destruido.

A su vez, y respecto al contenido, un paquete forma un espacio de nombres

(namespace). Dicho de otra forma, no puede haber dentro de un paquete dos

elementos del mismo tipo – si de tipos diferentes – con el mismo nombre.

Por otra parte, los paquetes pueden controlar la visibilidad de los elementos que

contienen:

+ Público: Elemento disponible a otros elementos del paquete contenedor o

uno de sus paquetes anidados, y a paquetes que importan el paquete

contenedor.

- Privado:No disponibles fuera del paquete contenedor.

Por lo anteriormente expuesto, los paquetes pueden contener a otros paquetes (se

forman jerarquías de paquetes). Con esto los paquetes anidados tienen acceso al

espacio de nombres del paquete que los contiene, sin embargo no recomendable más

de 3 niveles.

La generalización entre paquetes es muy parecida a la generalización entre clases. !

Un paquete especializado puede usarse en sustitución de un paquete más general, del

cual hereda.

Las dependencias entre paquetes denotan que algún elemento de un paquete depende

de los elementos en otro paquete. Entre paquetes puede haber tres tipos de relaciones

de dependencia:

Importación: modelado como una dependencia estereotipada con <<Import>>

Exportación: modeladas indicando la visibilidad pública en los elementos de

un paquete. No se exporta explícitamente a algún paquete. Se pone público,

para que cualquier otro paquete pueda importarlo.

Acceso: modelado como una dependencia estereotipada con <<Access>>.

Es importante que una relación de fusión (merge) entre dos paquetes especifique que

el contenido del paquete origen (receptor) se extiende con el contenido del paquete

destino. Por lo anteriormente comentado se identifica necesario un mecanismo para

fusionar los contenidos de ambos paquetes, ya que resuelve los conflictos de nombres

mediante especialización y redefinición, es bastante complicado y se define mediante

restricciones (precondiciones) y transformaciones (post-condiciones).

Diagrama de Paquetes

Es un diagrama de estructura cuyo contenido es, principalmente, paquetes y sus

relaciones. La distinción entre los diversos tipos de diagramas de estructura (clases,

objetos y paquetes) es relativa y todos pueden incluir: como nodos del grafo clases,

Interfaces, Instancias o Paquetes; y como arcos o relaciones agregaciones,

asociaciones, composiciones, dependencias, generalizaciones, realizaciones,

dependencias de uso, y fusiones, importaciones y accesos entre paquetes.

Dicho de otra forma, presentan cómo se organizan los elementos de modelado en

paquetes y las dependencias entre ellos, incluyendo importaciones y extensiones de

paquetes; dividiendo un modelo para agrupar y encapsular sus elementos en unidades

lógicas individuales

Características

Cohesivo: proporciona un límite bien definido alrededor de un grupo de elementos

relacionados

Poco acoplado: exportando sólo los elementos que otros paquetes necesitan ver

realmente e importando sólo aquellos elementos necesarios y suficientes para que los

elementos del paquete hagan su trabajo

Agrupación: seccionamiento de elementos con un objetivo común o relaciones

conceptuales fuertes, pertenecientes a un mismo árbol de herencia o a mismo caso de

uso

Simbología

Elementos del diagrama de

paquetes

Conectores del diagrama de

paquetes

Ejemplo práctico: considere el sistema de control de una franquicia de comida

rápida y cree un diagrama de paquetes del mismo, haciendo referencia a una vista

funcional

Anexos

DIAGRAMAS DE ESTADO

Los diagramas de estado muestran el conjunto de estados por los cuales pasa un

objeto durante su vida en una aplicación en respuesta a eventos (por ejemplo,

mensajes recibidos, tiempo rebasado o errores), junto con sus respuestas y acciones.

También ilustran qué eventos pueden cambiar el estado de los objetos de la clase.

Normalmente contienen: estados y transiciones.

En el diagrama de estados o dinámico tenemos que distinguir los siguientes

elementos:

Las diferentes situaciones en que se puede encontrar un objeto(los estados).

Qué cambios de estado son posibles (transiciones).

Cuál es el hecho que los produce (acontecimiento).

COMPONENTES DEL DIAGRAMA DE ESTADO:

Eventos

Un evento es una ocurrencia que puede causar la transición de un estado a otro de un

objeto. Esta ocurrencia puede ser una:

• Condición que toma el valor de verdadero (normalmente descrita como una

expresión booleana). Es un EventoCambio.

• Recepción de una señal explícita de un objeto a otro. Es un EventoSeñal.

• Recepción de una llamada a una operación. Es un EventoLlamada.

• Paso de cierto período de tiempo, después de entrar al estado actual, o de cierta hora

y fecha concretas. Es un EventoTiempo.

Acciones

Una acción es una operación atómica, que no se puede interrumpir por un evento y

que se ejecuta hasta su finalización. Una acción puede ser:

• Una llamada a una operación (al objeto al cual pertenece el diagrama de estado o

también a otro objeto visible),

• La creación o la destrucción de otro objeto,

• El envío de una señal a un objeto.

Actividades

Cuando un objeto está en un estado, generalmente está esperando a que suceda algún

evento. Sin embargo, a veces, queremos modelar una actividad que se está

ejecutando. Es decir, mientras un objeto está en un estado, dicho objeto realiza un

trabajo que continuará hasta que sea interrumpido por un evento. Por lo tanto, una

acción contrasta con una actividad, ya que ésta última puede ser interrumpida por

otros eventos.

Estados

Un estado identifica una condición o una situación en la vida de un objeto durante la

cual satisface alguna condición, ejecuta alguna actividad o espera que suceda algún

evento. Un objeto permanece en un estado durante un tiempo finito (no instantáneo).

Un estado se representa gráficamente por medio de un rectángulo con los bordes

redondeados y con tres divisiones internas. Los tres compartimentos alojan el nombre

del estado, el valor característico de los atributos del objeto en ese estado y las

acciones que se realizan en ese estado, respectivamente. En muchos diagramas se

omiten los dos compartimentos inferiores.

¿POR QUÉ SON IMPORTANTES LOS DIAGRAMAS DE ESTADOS?

El diagrama de estados proporciona una gran cantidad de símbolos y abarca varias

ideas. Los desarrolladores, deben saber la forma en que los objetos se supone se

comportarán, ya que son ellos quienes tendrán que establecer tales comportamientos

en el software.

Los diagramas de estado se aseguran que no tendrán que adivinar lo que se supone

que harán los objetos, con una clara representación de un objeto aumenta la

probabilidad de que el equipo de desarrollo produzca un sistema que cumpla con los

requerimientos.

SIMBOLOGIA

Rectángulo de vértices redondeados que representa a un estado, junto con una línea

continua y una punta de flecha, que representa una transición. Ejemplo:

EJEMPLO

CONCLUSION

El Lenguaje de Modelado Unificado es, sin lugar a duda una de las mejores

alternativas para el diseño y desarrollo de sistemas mediante el empleo de sus

notaciones gráficas e iconos en el diseño de diagramas que hacen más comprensible

el desarrollo del sistema. Este lenguaje unificado de notación (UML) sirve para

especificar, visualizar y documentar esquemas de sistemas de software orientado a

objetos. UML no es un método de desarrollo, lo que significa que no sirve para

determinar qué hacer en primer lugar o cómo diseñar el sistema, sino que

simplemente le ayuda a visualizar el diseño y a hacerlo más accesible para otros. Está

controlado por el grupo de administración de objetos (OMG) y es el estándar de

descripción de esquemas de software.

Se compone de muchos elementos de esquematización que representan las diferentes

partes de un sistema de software. Entre los elementos que se utilizan para crear

diagramas, que representa alguna parte o punto de vista del sistema tenemos los

siguientes:

-Diagrama de casos de uso, que muestra a los actores (otros usuarios del sistema) los

casos de uso (las situaciones que se producen cuando utilizan el sistema) y sus

relaciones.

-Diagrama de clases, que muestra las clases y las relaciones entre ellas.

-Diagrama de secuencia, muestra los objetos y sus múltiples relaciones entre ellos.

-Diagrama de Paquetes, muestra cómo un sistema está dividido en agrupaciones

lógicas mostrando las dependencias entre esas agrupaciones.

-Diagrama de colaboración, que muestra objetos y sus relaciones, destacando los

objetos que participan en el intercambio de mensajes.

-Diagrama de estado, muestra estados, cambios de estado y eventos en un objeto o en

parte del sistema.

-Diagrama de actividad, que muestra actividades, así como los cambios de una a otra

actividad junto con los eventos que ocurren en ciertas partes del sistema.

-Diagrama de componentes, que muestra los componentes de mayor nivel de la

programación (cosas como Kparts o Java Beans).

-Diagrama de implementación, que muestra las instancias de los componentes y sus

relaciones.

-Diagrama de relaciones de entidad, que muestra los datos y las relaciones y

restricciones entre ellos.

UML como todo producto de mercado, ha sido criticado por su falta de semántica

precisa, sin embargo, lo más importante de este lenguaje es su capacidad de

desarrollar, interpretar y diseñar un buen software, indicando las ventajas y

desventajas del mismo. Cada uno de los diagramas de UML son útiles, dependiendo

del objetivo del software; muchos se parecen entre sí, pero cada quien tienen sus

propias cualidades.

BIBLIOGRAFIA

http://www.ecured.cu

https://docs.kde.org

UML diagrama de colaboraciones.pdf

Libro PDF: UML_clase_06_UML_secuencia

http://es.wikipedia.org/wiki/.

http://jams001.blogspot.com/2012/09/diagrama-de-secuencia-y-colaboracion.html

http://www.codecompiling.net/files/slides/UML_clase_05_UML_paquetes.pdf

http://es.slideshare.net/carlosmercado92372/diagrama-de-paquete?next_slideshow=1

http://ocw.unican.es/ensenanzas-tecnicas/ingenieria-del-software-i/materiales-de-

clase-1/is1_t09_trans.pdf

http://analisisydiseoiii.blogspot.com/2011/05/diagrama-de-paquetes.html

http://datateca.unad.edu.co/contenidos/204023/Otero_M._s.f._._Diagramas_De_Estad

o.pdf

http://ingsoftwaremartin.blogspot.com/2011/11/ejemplo-de-diagramas-de-

estado.html