• Diagramas de Casos de Uso para modelar los procesos ’business’.
• Diagramas de Secuencia para modelar el paso de mensajes entre objetos.
• Diagramas de Colaboración para modelar interacciones entre objetos.
• Diagramas de Estado para modelar el comportamiento de los objetos en el sistema.
• Diagramas de Actividad para modelar el comportamiento de los Casos de Uso, objetos u operaciones.
• Diagramas de Clases para modelar la estructura estática de las clases en el sistema.
• Diagramas de Objetos para modelar la estructura estática de los objetos en el sistema.
• Diagramas de Componentes para modelar componentes.
• Diagramas de Implementación para modelar la distribución del sistema.
UML es una consolidación de muchas de las notaciones y conceptos más usadas orientados a objetos. Empezó como una consolidación del trabajo de Grade Booch, James Rumbaugh, e Ivar Jacobson, creadores de tres de las metodologías orientadas a objetos más populares.
Clases y Diagramas de Implementación.
Conforme se van encontrando los objetos, pueden ser agrupados por tipo y clasificados en un Diagrama de Clase. Es el diagrama de clase el que se combierte en el diagrama central del análisis del diseño orientado a objetos, y el que muestra la estructura estática del sistema. El diagrama de clase puede ser dividido en capas: aplicación, y datos, las cuales muestran las clases que intervienen con la interfaz de usuario, la lógica del software de la aplicación, y el almacentamiento de datos respectivamente. Los Diagramas de Componentes se usan para agrupar clases en componentes o módulos. La distribución general del hardware del sistema se modela usando el Diagrama de Implementación.
Diagramas de estado
El comportamiento en tiempo real de cada clase que tiene comportamiento dinámico y significativo, se modela usando un Diagrama de Estado. Son especialmente importantes para describir el comportamiento de un sistema reactivo debido a los eventos.
Los Casos de Usos
Un caso de uso se modela para todos los procesos que el sistema debe llevar a cabo. Los procesos se describen dentro del caso de uso por una descripción textual o una secuencia de pasos ejecutados por un usuario. Los Diagramas de Actividad se pueden usar también para modelar escenarios gráficamente. Una vez que el comportamiento del sistema está captado de esta manera, los casos de uso se examinan y amplían para mostrar qué objetos se interrelacionan para que ocurra este comportamiento.
Notación:
Actor: toda entidad externa al sistema que guarda una relación con este y que le demanda una funcionalidad. Esto incluye a los operadores humanos pero también incluye a todos los sistemas externos así como a entidades abstractas como el tiempo.
Un caso de uso, en principio, debería describir una tarea que tiene un sentido completo para el usuario. Sin embargo, hay ocasiones en las que es útil describir una interacción con un alcance menor como caso de uso. La razón para utilizar estos casos de uso no completos en algunos casos, es mejorar la comunicación en el equipo de desarrollo, el manejo de la documentación de casos de uso. Para el caso de que queramos utilizar estos casos de uso más pequeños, las relaciones entre estos y los casos de uso ordinarios pueden ser de los siguientes tres tipos:
uses: Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica.
Incluye : Un caso de uso base incorpora explícitamente a otro caso de uso en un lugar especificado en dicho caso base. Se suele utilizar para encapsular un comportamiento parcial común a varios casos de uso.
Extiende : Cuando un caso de uso base tiene ciertos puntos (puntos de extensión) en los cuales, dependiendo de ciertos criterios, se va a realizar una interacción adicional. El caso de uso que extiende describe un comportamiento opcional del sistema (a diferencia de la relación incluye que se da siempre que se realiza la interacción descrita)
Generalización : Cuando un caso de uso definido de forma abstracta se particulariza por medio de otro caso de uso más específico. Se representa por una línea continua entre los dos casos de uso, con el triángulo que simboliza generalización en UML (usado también para denotar la herencia entre clases) pegado al extremo del caso de uso más general. Al igual que en la herencia entre clases, el caso de uso hijo hereda las asociaciones y características del caso de uso padre. El caso de uso padre se trata de un caso de uso abstracto, que no está definido completamente. Este tipo de relación se utiliza mucho menos que las dos anteriores.
El límite del sistema se representa mediante un rectángulo, el cual debe encerrar todo el diagrama de casos de usos, apartando el sistema de cualquier otro objeto que altere lo expresado.
Además las posee líneas para la relación de actores y procesos.
Diagramas de Interacción
Los diagramas de interacción muestra una interacción concreta: un conjunto de objetos y sus relaciones, junto con los mensajes que se envían entre ellos. Éstos se dividen en dos clases: Los Diagramas de Colaboración y de Secuencia.
El Diagrama de Secuencia es uno de los diagramas más efectivos para modelar interacción entre objetos en un sistema. Un diagrama de secuencia se modela para cada caso de uso. Mientras que el diagrama de caso de uso permite el modelado de una vista ’business’ del escenario, 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 pasados entre los objetos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como vectores horizontales. 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.
Muestran la secuencia de mensajes entre objetos durante un escenario concreto:
* En la parte superior aparecen los objetos que intervienen, representados por rectángulos.
*La dimensión temporal se indica verticalmente. (El tiempo transcurre hacia abajo)
*Las líneas verticales sindican el tiempo de vida de cada objeto, inician desde la parte inferior del objeto cuando se crea, y finaliza con una X cuando el objeto es destruido.
*El paso de mensajes se indica con flechas horizontales u oblicuas (cuando existe demora en el envio de respuestas).
*La realización de una acción se indica con un rectángulo vertical sobre la línea de vida del objeto que realiza la acción y del que interviene.
*A la flecha se le asocia una etiqueta con el mensaje y los argumentos. Es posible añadir a los mensajes condiciones e iteraciones. La condición se representara mediante una condición booleana entre corchetes. El mensaje será enviado si la condición es cierta. La iteración se representa mediante un asterisco y una expresión entre corchetes indicando el número de veces.
*Las puntas de flecha sólidas representan llamadas síncronas, que son las más comunes. Éstas se usan cuando la clase emisora espera una respuesta de la clase receptora, y el control se devuelve a la clase emisora cuando la clase que recibe el mensaje termina su ejecución.
*Una línea continua que une dos objetos y el cual puede contener uno o varios mensajes es un vínculo, el cual es propio de los diagramas de colaboración. Es posible indicar la navegabilidad.
Las flechas con media punta (o abiertas) representan llamadas asincronas, es decir, llamadas que se envían sin esperar a que sean devueltas a la clase que las emite. Un ejemplo podría ser el de usar un menú para ejecutar un programa. Un retorno se muestra como una flecha, a veces con una línea punteada. Los mensajes se etiquetan mediante alguno de los formatos siguientes:
El nombre del mensaje seguido por paréntesis vacíos:
nombreDelMensaje( ).
El nombre del mensaje seguido por parámetros entre paréntesis:
nombreDelMensaje(parámetrol, parámetro2...).
El nombre del mensaje seguido por el tipo del parámetro, nombre del parámetro y cualquier valor predeterminado para el parámetro entre paréntesis:
nombreDelMensaje(tipoDelParámetro:nombreDelParámetro(valorPredeterminado).
Los tipos de parámetro indican el tipo de los datos, como numérico, alfanumérico o de tipo de fecha.
El mensaje podría ser un estereotipo, como -^Créate», lo cual indica que se crea un nuevo objeto como resultado del mensaje.
Diagramas de Colaboración
Presenta una alternativa al diagrama de secuencia para modelar interacciones entre objetos en el sistema. Mientras que el diagrama de secuencia se centra en la secuencia cronológica del escenario que estamos modelando, el diagrama de colaboración se centra en estudiar todos los efectos de un objeto dado durante un escenario. Los objetos se conectan por medio de enlaces, cada enlace representa una instancia de una asociación entre las clases implicadas. El enlace muestra los mensajes enviados entre los objetos, el tipo de mensaje (sincrónico, asincrónico, simple, blanking, y ’time-out’), y la visibilidad de un objeto con respecto a los otros. Además los mensajes se enumeran para ilustrar el orden en que se emiten.
Muestran un conjunto de objetos y sus relaciones, (una situación concreta en un momento determinado); expresan la parte estática de una interacción,
Diagrama de Clase
Es el diagrama principal de diseño y análisis para un sistema. En él, la estructura de clases del sistema se especifica, con relaciones entre clases y estructuras de herencia. Durante el análisis del sistema, el diagrama se desarrolla buscando una solución ideal. Durante el diseño, se usa el mismo diagrama, y se modifica para satisfacer los detalles de las implementaciones.
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.
Elementos
- 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 Casa, un Auto, una Cuenta Corriente, etc.). En UML, una clase es representada por un rectángulo que posee tres divisiones:
En donde:
Superior: Contiene el nombre de la Clase
Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase (pueden ser private, protected o public).
Inferior: Contiene los métodos u operaciones, los cuales son la forma como interactúa el objeto con su entorno (dependiendo de la visibilidad: private, protected o public).
Atributos:
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.
- private.
- protected.
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).
- Relaciones entre Clases:
Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en cada extremo de la relación y éstas pueden ser:
uno o muchos: 1..* (1..n)
0 o muchos: 0..* (0..n)
número fijo: m (m denota el número).
Flechas de relación:
- Herencia (Especialización/Generalización):
Indica que una subclase hereda los métodos y atributos especificados por una Super Clase, por ende la Subclase además de poseer sus propios métodos y atributos, poseerá las características y atributos visibles de la Super Clase (public y protected).
Para modelar objetos complejos, n bastan los tipos de datos básicos que proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollador de la aplicación, tenemos dos posibilidades:
- Composición:
Por Valor: Es un tipo de relación estática, en donde el tiempo de vida del objeto incluido esta condicionado por el tiempo de vida del que lo incluye (el Objeto base se construye a partir del objeto incluido, es decir, es "parte/todo").
- Agregación:
- 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.
- Dependencia o Instanciación (uso):
Representa un tipo de relación muy particular, en la que una clase es instanciada (su instanciación es dependiente de otro objeto/clase). Se denota por una flecha punteada. El uso más particular de este tipo de relación es para denotar la dependencia que tiene una clase de otra, como por ejemplo una aplicación grafica que instancia una ventana (la creación del Objeto Ventana esta condicionado a la instanciación proveniente desde el objeto Aplicacion):
Diagrama de Actividad:
Diagramas de componentes:
(Componentes y dependencias entre ellos), organización lógica de la implementación de un sistema.
Diagramas de Despliegue:
(Nodos de procesamiento y componentes), configuración del sistema en tiempo de ejecución.
REFERENCIAS:
- OOP. Relaciones entre clases, Diagramas UML. pdf . Fernando Berzal.
No hay comentarios:
Publicar un comentario