Lenguaje Unificado de Modelado (UML)

El Lenguaje Unificado de Modelado (UML, por sus siglas en inglés, Unified Modeling Language), es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). UML es un lenguaje porque proporciona un vocabulario y las reglas para utilizarlo; además, es un lenguaje de modelado lo que significa que el vocabulario y las reglas del que está compuesto se utilizan para la representación conceptual y física del sistema. Es decir ofrece una notación estándar y semánticas esenciales para describir un modelo o plano del sistema, incluyendo aspectos conceptuales tales como procesos de negocios y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes de software reutilizables.

Este lenguaje comenzó a gestarse en el año de 1994, cuando Rumbaugh se unió a la compañía Rational fundada por Booch (dos reputados investigadores en el área de la metodología del software). El objetivo de ambos era unificar dos métodos que habían desarrollado: el método Booch y el OMT (Object Modelling Tool), obteniendo como resultado una primera propuesta en 1995. En esa misma época otro reputado investigador, Jacobson, se unió a Racional, y se incluyeron ideas suyas. Estas tres personas son conocidas como los “tres amigos”. Su trabajo conjunto fue llamado Lenguaje Unificado de Modelado (UML). Además, este lenguaje se abrió a la colaboración de otras empresas para que aportaran sus ideas.

Todas estas colaboraciones condujeron a la definición de la primera versión de UML. Esta primera versión se ofreció a la OMG para convertirlo en un estándar. Este grupo, llamado OMG, que gestiona estándares relacionados con la tecnología orientada a objetos (metodologías, bases de datos objetuales, CORBA, etc.), propuso una serie de modificaciones y una nueva versión de UML (la 1.1), que fue adoptada por el OMG como estándar en noviembre de 1997. Desde ese entonces, UML atravesó varias revisiones y refinamientos hasta llegar a la versión actual: UML 2.0.

Los objetivos de UML son muchos, pero se pueden sintetizar sus funciones:

a. Visualizar: UML permite expresar de una forma gráfica un sistema de manera que otro lo pueda entender.

b. Especificar: UML permite especificar cuáles son las características de un sistema antes de su construcción.

c. Construir: A partir de los modelos especificados se pueden construir los sistemas diseñados.

d. Documentar: Los propios elementos gráficos sirven como documentación del sistema desarrollado que pueden servir para su futura revisión.

Diagrama UML

Un Diagrama es la representación gráfica de un conjunto de elementos con sus relaciones. UML ofrece una amplia variedad de diagramas para visualizar el sistema desde varias perspectivas.

Los Diagramas de Estructura enfatizan en los elementos que deben existir en el sistema modelado.

a. Diagrama de clases

b. Diagrama de componentes c. Diagrama de objetos

d. Diagrama de estructura compuesta e. Diagrama de despliegue

f. Diagrama de paquetes

Los Diagramas de Comportamiento enfatizan en lo que debe suceder en el sistema modelado.

a. Diagrama de actividades b. Diagrama de casos de uso c. Diagrama de estados

Los Diagramas de Interacción son un subtipo de diagramas de comportamiento, que enfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado están:

a. Diagrama de secuencia

b. Diagrama de comunicación, que es una versión simplificada del Diagrama de colaboración

c. Diagrama de tiempos

d. Diagrama global de interacciones o Diagrama de vista de interacción [Documento en línea] Disponible: http://resumenuml.bloggratis.es/.

Para términos de esta investigación se definirán los siguientes diagramas:

Diagrama de Actividad

En el Lenguaje de Modelado Unificado, un diagrama de actividades representa los flujos de trabajo paso a paso de negocio y operacionales de los componentes en un sistema. Un Diagrama de Actividades muestra el flujo de control general. El diagrama de actividades es una forma especial de diagrama de estado usado para modelar una secuencia de acciones y condiciones tomadas dentro de un proceso. La especificación del Lenguaje de Modelado Unificado OMG define un diagrama de actividad como: “… una variación de una máquina estados, lo cual los estados representan el rendimiento de las acciones o subactividades y las transiciones se provocan por la realización de las acciones o subactividades.”El propósito del diagrama de actividad es modelar un proceso de flujo de trabajo (workflow) y/o modelar operaciones. Una Operación es un servicio proporcionado por un objeto, que está disponible a través de una interfaz. Una Interfaz es un grupo de operaciones relacionadas con la semántica.

Cuadro 1. Elementos del Diagrama de Actividad.

Nombre Símbolo Descripción

Acción Nodo de actividad

Nodo de Inicio

Indica el inicio de un flujo de control cuando se invoca una actividad.

Nodo de Fin Indica el fin de todos los flujos

dentro de una actividad

Decisión Nodo de control que selecciona

entre dos o más flujos de salida. Fuente: Autor (2010).

Cuadro 2. Elementos del Diagrama de Actividad (Cont…).

Nombre Símbolo Descripción

Flujo de Control

Conecta dos acciones para

indicar la secuencia para flujos de control.

Flujo de Objetos Conecta acciones con nodos de

objetos para flujos de objetos.

Nodo de Concurrencia Nodo de control que sincroniza

múltiples flujos.

Nodo de Sincronización

Nodo de control que divide un flujo en dos o más flujos concurrentes (paralelos).

Fuente: Autor (2010).

Diagrama de Casos de Uso

El Lenguaje de Modelado Unificado define una notación gráfica para representar casos de uso llamada modelo de casos de uso. UML no define estándares para que el formato escrito describa los casos de uso, y así mucha gente no entiende que esta notación gráfica define la naturaleza de un caso de uso; sin embargo una notación gráfica puede solo dar una vista general simple de un caso de uso o un conjunto de casos de uso. Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras los dos conceptos están relacionados, los casos de uso son mucho más detallados que los diagramas de casos de uso. [Documento en línea] Disponible: http://wapedia.mobi/es/Diagrama_de_casos_de_uso.

Un Diagrama de Casos de Uso es una representación gráfica de los actores y casos de uso del sistema, incluyendo sus interacciones. En

dondeel entorno del sistema representan sus actores y su funcionalidad principal los casos de uso. Los diagramas de casos de usos contribuyen a la representación de los requisitos funcionales que se esperan de un sistema y como este se relaciona con su entorno. Los elementos de un Diagrama de Casos de Uso son: actores, casos de uso y relaciones entre casos de uso.

1. Actor:

Un actor representa una persona o cosa que inicia una acción dentro del sistema. El actor es representado por una figura en forma de persona como se muestra a continuación.

A ctor

Figura 11. Actor. Fuente: Autor (2010).

2. Casos de Uso:

Permite describir la Funcionalidad que se requiere por el sistema es decir, expresa una unidad coherente de funcionalidad del sistema. Los casos de usos en un diagrama de casos de usos se encuentran representados por un ovalo.

Caso de Uso

Figura 12. Caso de uso. Fuente: Autor (2010). 3. Comunicación o Asociación:

Actor, dicho elemento es representado simplemente por una línea recta que se extiende de la figura del actor hacia el ovalo del uso-caso.

4. Relaciones entre Casos de Uso

Las relaciones entre estos y los casos de uso ordinarios pueden ser de los siguientes tipos: [Documento en línea] Disponible:

http://wapedia.mobi/es/Diagrama_de_casos_de_uso.

Cuadro 3. Tipos de Relaciones en Diagramas de Casos de Uso.

Tipo de Relación Símbolo Descripción

Asociación Comunica a un actor con un caso

de uso, o con otro actor.

Inclución <<include>>

Utilizada para indicar que un uso- caso depende de otro caso, es decir, que la funcionalidad de determinado caso se requiere para realizar las tareas del otro.

Extensión <<extend>>

Representa una variación de un

uso-caso a otro.Describe un

comportamiento opcional del

sistema. Fuente: Autor (2010).

Diagrama de Secuencia

Un diagrama de secuencia muestra la interacción de un conjunto de objetos de una aplicación a través del tiempo, es decir, muestra los objetos participantes y los mensajes que se intercambian entre ellos a lo largo del tiempo. El diagrama de secuencia permite observar la perspectiva

cronológica de las interacciones, muestra la secuencia explícita de mensajes y son mejores para especificaciones de tiempo real y para escenarios complejos. [Documento en línea] Disponible:

http://wapedia.mobi/es/Diagrama_de_secuencia.

Cuadro 4.Elementos del Diagrama de Secuencia.

Símbolo Descripción

La línea vertical representa la existencia de un objeto a lo largo de un tiempo determinado

Un objeto se represnta como una línea vertical punteada, línea de vida, con un rectágulo de encabezado

Activación, periodo de tiempo en el cual el objeto se encuentra desarrollando alguna operación.

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

Fuente: Autor (2010).

Diagrama de Clases

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

a. Privado (-): Indica que el atributo sólo será accesible desde dentro de la clase (sólo sus métodos lo pueden accesar).

b. Publico (+): Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados.

c. Protegido (#): 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. Documento en línea] Disponible: http://wapedia.mobi/es/Diagrama_de_clases.

Cuadro 5. Tipos de Relaciones entre Clases.

Nombre Símbolo Descripción

Asociación Asociación bidireccional entre

clases con roles y multiplicidad.

Agregación Relación de subordinación.

Composición Relación es parte de.

Dependencia Relación de dependencia

Generalización Relación es un (a)