DIAGRAMAS UML

Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en ingls, Unified
Modeling Language) es el lenguaje de modelado de sistemas de software ms
conocido y utilizado en la actualidad; est respaldado por el OMG (Object
Management Group). Es un lenguaje grfico para visualizar, especificar, construir
y documentar un sistema. UML ofrece un estndar para describir un "plano" del
sistema (modelo), incluyendo aspectos conceptuales tales como procesos de
negocio, funciones del sistema, y aspectos concretos como expresiones de
lenguajes de programacin, esquemas de bases de datos y compuestos
reciclados.
Es importante remarcar que UML es un "lenguaje de modelado" para especificar o
para describir mtodos o procesos. Se utiliza para definir un sistema, para detallar
los artefactos en el sistema y para documentar y construir. En otras palabras, es el
lenguaje en el que est descrito el modelo.
Se puede aplicar en el desarrollo de software gran variedad de formas para dar
soporte a una metodologa de desarrollo de software (tal como el Proceso
Unificado Racional o RUP), pero no especifica en s mismo qu metodologa o
proceso usar.
Diagramas de casos de uso

En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una
especie de diagrama de comportamiento UML mejorado. El Lenguaje de
Modelado Unificado (UML), define unanotacin grfica para representar casos de
uso llamada modelo de casos de uso. UML no define estndares para que el
formato escrito describa los casos de uso, y as mucha gente no entiende que esta
notacin grfica define la naturaleza de un caso de uso; sin embargo una notacin
grfica puede solo dar una vista general simple de un caso de uso o un conjunto
de casos de uso. Losdiagramas de casos de uso son a menudo confundidos con
los casos de uso. Mientras los dos conceptos estn relacionados, los casos de uso
son mucho ms detallados que los diagramas de casos de uso.
La descripcin escrita del comportamiento del sistema al afrontar una tarea de
negocio o un requisito de negocio. Esta descripcin se enfoca en el valor
suministrado por el sistema a entidades externas tales como usuarios
humanos u otros sistemas.
La posicin o contexto del caso de uso entre otros casos de uso. Dado que es
un mecanismo de organizacin, un conjunto de casos de uso coherentes y
consistentes promueven una imagen fcil de comprender del comportamiento
del sistema, un entendimiento comn entre el cliente/propietario/usuario y el
equipo de desarrollo.
En esta prctica es comn crear especificaciones suplementarias para capturar
detalles de requisitos que caen fuera del mbito de las descripciones de los casos
de uso. Ejemplos de esos temas incluyen restricciones de diseo como:
rendimiento, temas de escalabilidad/gestin, o cumplimiento de estndares.
El diagrama de la derecha describe la funcionalidad de un Sistema
Restaurante muy simple. Los casos de uso estn representados por elipses y
los actores estn, por ejemplo, los casos de uso se muestran como parte del
sistema que est siendo modelado, los actores no.
La interaccin entre actores no se ve en el diagrama de casos de uso. Si esta
interaccin es esencial para una descripcin coherente del comportamiento
deseado, quizs los lmites del sistema o del caso de uso deban de ser re-
examinados. Alternativamente, la interaccin entre actores puede ser parte de
suposiciones usadas en el caso de uso. Sin embargo, los actores son una especie
de rol, un usuario humano u otra entidad externa pueden jugar varios papeles o
roles. As el Chef y el Cajero podran ser realmente la misma persona.
Relaciones de Casos de Uso
Las tres relaciones principales entre los casos de uso son soportadas por el
estndar UML, el cual describe notacin grfica para esas relaciones. Veamos una
revisin de ellas a continuacin:
Inclusin (include o use)
Es una forma de interaccin o creacin, un caso de uso dado puede "incluir" otro
caso de uso. El primer caso de uso a menudo depende del resultado del caso de
uso incluido. Esto es til para extraer comportamientos verdaderamente comunes
desde mltiples casos de uso a una descripcin individual (si el actor realiza el
caso de uso base tendr que realizar tambin el caso de uso incluido), desde
el caso de uso. El estndar de Lenguaje de Modelado Unificado de OMG define
una notacin grfica para realizar diagramas de casos de uso, pero no el formato
para describir casos de uso. Mucha gente sufre la equivocacin pensando que un
caso de uso es una notacin grfica (o es su descripcin). Mientras la notacin
grfica y las descripciones esto no sirve.
Extensin (extend)
Es otra forma de interaccin, un caso de uso dado (la extensin) puede extender a
otro. Esta relacin indica que el comportamiento del caso de la extensin se utiliza
en casos de uso, un caso de uso a otro caso siempre debe tener extensin o
inclusin. El caso de uso extensin puede ser insertado en el caso de uso
extendido bajo ciertas condiciones. La notacin, es una flecha de punta abierta
con lnea discontinua, desde el caso de uso extensin al caso de uso extendido,
con la etiqueta extend. Esto puede ser til para lidiar con casos especiales, o
para acomodar nuevos requisitos durante el mantenimiento del sistema y su
extensin.
"La extensin, es el conjunto de objetos a los que se aplica un concepto. Los
objetos de la extensin son los ejemplos o instancias de los conceptos."
Documentan el comportamiento de un sistema desde el punto de vista de un
usuario
En otras palabras ser utilizado cuando un caso de uso sea similar a otro pero con
ciertas variaciones, un ejemplo claro es que se necesite comprar azucar y
podemos seleccionar de entre azucar rubia,blanca o su unidad de medida bolsa ,
kilo.
Generalizacin
"Entonces la Generalizacin es la actividad de identificar elementos en comn
entre conceptos y definir las relaciones de una superclase (concepto general) y
subclase (concepto especializado). Es una manera de construir clasificaciones
taxonmicas entre conceptos que entonces se representan en jerarquas de
clases. Las subclases conceptuales son conformes con las superclases
conceptuales en cuanto a la intencin y extensin."
En la tercera forma de relaciones entre casos de uso, existe una relacin
generalizacin/especializacin. Un caso de uso dado puede estar en una forma
especializada de un caso de uso existente. La notacin es una lnea slida
terminada en un tringulo dibujado desde el caso de uso especializado al caso de
uso general. Esto se asemeja al concepto orientado a objetos de sub-clases, en la
prctica puede ser til factorizar comportamientos comunes, restricciones al caso
de uso general, describirlos una vez, y enfrentarse a los detalles excepcionales en
los casos de uso especializados.

Diagramas de secuencia

El diagrama de secuencia es un tipo de diagrama usado para modelar interaccin
entre objetos en un sistema segn UML. En ingls se pueden encontrar como
"sequence diagram", "event-trace diagrams", "event scenarios" o "timing diagrams"
Utilidad
Un diagrama de secuencia muestra la interaccin de un conjunto de objetos en
una aplicacin a travs del tiempo y se modela para cada caso de uso. Mientras
que el diagrama de casos de uso permite el modelado de una vista business del
escenario, el diagrama de secuencia contiene detalles de implementacin del
escenario, incluyendo los objetos y clases que se usan para implementar el
escenario y mensajes intercambiados entre los objetos.
Tpicamente se examina la descripcin de un caso de uso para determinar qu
objetos son necesarios para la implementacin del escenario. Si se dispone de la
descripcin de cada caso de uso como una secuencia de varios pasos, entonces
se puede "caminar sobre" esos pasos para descubrir qu objetos son necesarios
para que se puedan seguir los pasos. Un diagrama de secuencia muestra los
objetos que intervienen en el escenario con lneas discontinuas verticales, y los
mensajes pasados entre los objetos como flechas horizontales.
Tipos de mensajes
Existen dos tipos de mensajes: sincrnicos y asincrnicos. Los mensajes
sincrnicos se corresponden con llamadas a mtodos del objeto que recibe el
mensaje. El objeto que enva el mensaje queda bloqueado hasta que termina la
llamada. Este tipo de mensajes se representan con flechas con la cabeza llena.
Los mensajes asincrnicos terminan inmediatamente, y crean un nuevo hilo de
ejecucin dentro de la secuencia. Se representan con flechas con la cabeza
abierta.
Tambin se representa la respuesta a un mensaje con una flecha discontinua.
Pueden ser usados en dos formas
De instancia: describe un escenario especfico (un escenario es una instancia
de la ejecucin de un caso de uso).
Genrico: describe la interaccin para un caso de uso. Utiliza ramificaciones
("Branches"), condiciones y bucles.
Estructura
Los mensajes se dibujan cronolgicamente desde la parte superior del diagrama a
la parte inferior; la distribucin horizontal de los objetos es arbitraria. Durante el
anlisis inicial, el modelador tpicamente coloca el nombre 'business' de un
mensaje en la lnea del mensaje. Ms tarde, durante el diseo, el nombre
'business' es reemplazado con el nombre del mtodo que est siendo llamado por
un objeto en el otro. El mtodo llamado o invocado pertenece al objeto receptor
del mensaje.


Diagrama de objetos

En UML, diagrama que muestra una vista completa o parcial de los objetos de un
sistema en un instante de ejecucin especfico.
Descripcin Formal
El Object Management Group, en la especificacin UML (versiones 2.1 y
anteriores), defina al diagrama de objetos como:
"Un diagrama de objetos es un grfico de instancias, incluyendo objetos y
datos. Un diagrama de objetos es una instancia de un diagrama de clases;
muestra una 'foto' del estado de un sistema en un punto de tiempo
determinado."
Los diagramas de objeto estn ligados a los diagramas de clase y comparten
virtualmente los mismos smbolos para la notacin. Los diagramas de objetos
pertenecen a la categora de diagramas estructurales en UML.
Generacin y Uso
Los diagramas de objetos se generan en las disciplinas de Arquitectura y
diseo. Se utilizan para mostrar estructuras de datos y las interacciones que
existen entre objetos en tiempo de ejecucin.

Diagramas de clases

Un diagrama de clases es un tipo de diagrama esttico que describe la estructura
de un sistema mostrando sus clases, orientados a objetos.

Definiciones
Propiedad de objetos que tienen propiedades y/u operaciones que contienen
un contexto y un dominio, los primeros dos ejemplos son clases de datos y el
tercero clase de lgica de negocio, dependiendo de quin disee el sistema se
pueden unir los datos con las operaciones.
El diagrama de clases incluye mucha ms informacin como la relacin entre
un objeto y otro, la herencia de propiedades de otro objeto, conjuntos de
operaciones/propiedades que son implementadas para una interfaz grfica.
Presenta las clases del sistema con sus relaciones estructurales y de herencia.

Diagrama de estado
Los diagramas de estado muestran el conjunto de estados por los cuales pasa un
objeto durante su vida en una aplicacin en respuesta a eventos (por ejemplo,
mensajes recibidos, tiempo rebasado o errores), junto con sus respuestas y
acciones. Tambin ilustran qu eventos pueden cambiar el estado de los objetos
de la clase. Normalmente contienen: estados y transiciones. Como los estados y
las transiciones incluyen, a su vez, eventos, acciones y actividades, vamos a ver
primero sus definiciones.
Al igual que otros diagramas, en los diagramas de estado pueden aparecer notas
explicativas y restricciones.

Diagrama de actividades
El diagrama de flujo o diagrama de actividades es la representacin
grfica del algoritmo o proceso. Se utiliza en disciplinas
como programacin,economa, procesos industriales y psicologa cognitiva.
En Lenguaje Unificado de Modelado (UML), 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.
En SysML el diagrama de actividades ha sido extendido para indicar flujos entre
pasos que mueven elementos fsicos (e.g., gasolina) o energa (e.g., presin). Los
cambios adicionales permiten al diagrama soportar mejor flujos de
comportamiento y datos continuos.
Estos diagramas utilizan smbolos con significados definidos que representan los
pasos del algoritmo, y representan el flujo de ejecucin mediante flechas que
conectan los puntos de inicio y de fin de proceso.
Normas De Trabajo
Un diagrama de flujo presenta generalmente un nico punto de inicio y un nico
punto de trmino, aunque puede tener ms, siempre que cumpla con la lgica
requerida.
Las siguientes son acciones previas a la realizacin del diagrama de flujo:
Identificar las ideas principales al ser incluidas en el diagrama de flujo. Deben
estar presentes el autor o responsable del proceso, los autores o responsables
del proceso anterior y posterior y de otros procesos interrelacionados, as
como las terceras partes interesadas.
Definir qu se espera obtener del diagrama de flujo.
Identificar quin lo emplear y cmo.
Establecer el nivel de detalle requerido.
Determinar los lmites del proceso a describir.
Los pasos a seguir para construir el diagrama de flujo son:
Establecer el alcance del proceso a describir. De esta manera quedar fijado el
comienzo y el final del diagrama. Frecuentemente el comienzo es la salida del
proceso previo y el final la entrada al proceso siguiente.
Identificar y listar las principales actividades/subprocesos que estn incluidos
en el proceso a describir y su orden cronolgico.
Si el nivel de detalle definido incluye actividades menores, listarlas tambin.
Identificar y listar los puntos de decisin.
Construir el diagrama respetando la secuencia cronolgica y asignando los
correspondientes smbolos.
Asignar un ttulo al diagrama y verificar que est completo y describa con
exactitud el proceso elegido.