UML (Lenguaje Unificado de Modelado)

El Lenguaje Unificado de Modelado (UML) es, tal como su nombre lo indica, un lenguaje de
modelado y no un método o un proceso. El UML está compuesto por una notación muy específica
y por las reglas semánticas relacionadas para la construcción de sistemas de software.

Describe la notación para clases, componentes, nodos, actividades, flujos de trabajo, casos de uso,
objetos, estados y cómo modelar la relación entre esos elementos. Permite organizar el proceso de
diseño de tal forma que los analistas, clientes, desarrolladores y otras personas involucradas en el
desarrollo del sistema lo comprendan.

El UML está compuesto por diversos elementos gráficos que se combinan para conformar
diagramas.

Los diagramas tienen como objetivo presentar diversas perspectivas de un sistema. A esto se le
llama Modelo. Tenemos que tener en cuenta que un modelo UML describe lo que supuestamente
hará un sistema, pero no dice cómo implementar dicho sistema.

UML permite documentar las especificaciones de todas las decisiones de análisis, diseño e
implementación.

UML no es un lenguaje de programación visual, pero sus modelos pueden conectarse de forma
directa a lenguajes de programación orientados a objetos

Es posible establecer una correspondencia desde un modelo UML y una implementación en un

lenguaje de programación como JAVA o C++, mediante generación de código e ingeniería inversa

Documentar sistemas:

✓ Requisitos
✓ Diseño
✓ Estructura estática
✓ Interacciones
✓ Implementaciones

DIAGRAMAS DE UML

✓ Diagramas de Clases: para modelar la estructura estática de las clases en el sistema.

✓ 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 Componentes: para modelar componentes.
✓ Diagramas de Implementación: para modelar la distribución del sistema.
 ✓ Diagramas de Actividad: para modelar el comportamiento de los Casos de Uso, objetos u
operaciones.
✓ Diagramas de Objetos: para modelar la estructura estática de los objetos en el sistema.

Elementos de un modelo de casos de uso: Actores, Casos de uso, Relaciones

1. Diagrama de casos de uso

Un caso de uso es una descripción de las acciones de un sistema desde el punto de vista del usuario.

Actores: Un actor es un usuario del sistema. Esto incluye usuarios humanos y otros
sistemas computacionales. Un actor usa un Caso de Uso para ejecutar una porción de
trabajo de valor para el negocio

Caso de Uso: La especificación formal de un Caso de Uso incluye 3 elementos básicos:

✓ Requisitos: Son los requisitos funcionales formales que el Caso de Uso debe proveer al
usuario final.
✓ Restricciones: son las reglas formales y las limitaciones bajo las que opera un Caso de Uso
e incluyen pre-condiciones, post-condiciones.

Una precondición especifica qué debe haber ocurrido o estar cumplido antes de que el Caso de Uso
pueda iniciarse.

Una post-condición documenta qué será verdadero una vez que el Caso de Uso se complete.

✓ Escenarios: Son descripciones formales del flujo de eventos que ocurre durante una
instancia de un Caso de Uso. Usualmente se describen con texto y corresponden a una
representación textual del diagrama de secuencia.

Relaciones

➢ Relaciones de Uso

Es común que la misma funcionalidad del sistema sea accedida a partir de varios casos de uso. Por
ejemplo, la funcionalidad de buscar un producto puede ser accedida desde el ingreso de pedidos,
desde las consultas de productos, o desde los reportes de ventas por producto.

Este tipo de relaciones se llama relaciones de uso y se representa por una línea punteada desde el
caso que ‘usa a’ al caso que es ‘usado’.
Las características de las relaciones de uso son:

1) Aparecen como funcionalidad común, luego de haber especificado varios casos de uso.
2) Los casos usados son casos de uso en sí mismos.
3) El caso es usado siempre que el caso que lo usa es ejecutado. Esto marca la diferencia con las
extensiones, que son opcionales.

➢ Relaciones de Extensión

Muchas veces, la funcionalidad de un caso de uso incluye un conjunto de pasos que ocurren sólo en
algunas oportunidades. La excepción consiste en interrumpir el caso de uso y pasar a ejecutar el
caso de uso.

Las extensiones tienen las siguientes características:

1) Representan una parte de la funcionalidad del caso que no siempre ocurre.

2) Son un caso de uso en sí mismas.
3) No necesariamente provienen de un error o excepción.

La pregunta que surge claramente es ¿cuál es la diferencia entre una alternativa y una extensión?
La respuesta puede derivarse de las características de cada uno:
• Una extensión es un caso de uso en sí mismo, mientras que una alternativa no.
• Una alternativa es un error o excepción, mientras que una extensión puede no serlo
Definición de actores

Este apartado contiene los diferentes actores que se han identificado, especificados mediante la
plantilla para actores de casos de uso.

ACT–01 Socio

Descripción Este actor representa a los socios del vídeo–club

Comentarios ninguno

ACT–02 Empleado del vídeo–club

Descripción Este actor representa a los empleados del vídeo–club

Comentarios ninguno