UML

Capitulo I

¿Porque modelamos?
Es una representación en cierto medio, de algo en el mismo u otro medio. El modelo capta los aspectos más importantes de lo que estamos modelando, desde criterio o punto de vista y simplifica u omite el resto.

La importancia de modelar
- Para captar y enumerar exhaustivamente los requisitos, y el dominio del conocimiento, de forma que todos los implicado puedan entenderlos y estar desacuerdo con ellos.
- Para pensar en el diseño del sistema
- Para capturar decisiones del diseño mutables a partir de los requisitos
- Para generar productos aprovechables para el trabajo.
- Para organizar, encontrar, filtrar, recuperar, examinar, y corregir la información en grandes sistemas.
- Para explotar económicamente múltiples soluciones.
- Para domesticar los sistemas complejos.

Niveles de modelado
- Guías al proceso de pensamiento:
- Especificaciones abstractas de la estructura esencial de un sistema:
- Especificaciones completas de un sistema final:
- Descripciones completas o parciales de sistemas:

¿Qué hay en un modelo?
Tienen dos aspectos:
El aspecto semántico capta el significado capta el significado de una aplicación como una red de construcciones lógicas, por ejemplo clases, asociaciones, estados, casos de usos y mensajes
La presentación visual muestra la información semántica de modo se pueda ser considerada, hojeada y corregida por los seres humanos.

¿Cuál es el significado e un modelo?
Un modelo es un generador de potenciales configuraciones de un sistema; los posibles sistemas son sus extensiones, o valores. Idealmente todas las configuraciones consistentes con el modelo deberían ser posibles.

Principios del modelado
- La elección de que modelos crear tiene una profunda influencia sobre como se acomete un problema y como se da forma a una solución
- Todo modelo puede ser expresado a diferentes niveles de precisión
- Los mejores modelos están ligados a la realidad.
- Un único modelo no es suficiente. Cualquier sistema no trivial se aborda mejor a través de un pequeño conjunto de modelos casi independientes.

Modelo orientado a objetos
Actualmente el enfoque orientado a objetos forma parte de la tendencia principal para el desarrollo del software, simplemente porque ha mostrado ser valido en la construcción de sistemas en toda clase de dominio de problemas abarcando todo el abanico de tamaños y de complejidades.

Perspectiva general de UML
UML es un lenguaje para:
- Visualizar
- Especificar
- Construir
- Documentar

Bloques de construcción de UML
1. Elementos
2. Relaciones
3. Diagramas

Elementos en UML
1. Elementos estructurales
2. Elementos de comportamiento
3. Elementos de agrupación
4. Elementos de notación

Relaciones en UML
1. Dependencia
2. Asociación
3. Generalización
4. Realización

UML incluye 9 diagramas
1. Diagrama de clases
2. Diagrama de objetos
3. Diagrama de casos de uso
4. Diagrama de secuencia
5. Diagrama de colaboración
6. Diagrama de estados
7. Diagrama de actividades
8. Diagrama de componentes
9. Diagrama de despliegue

Ciclo de vida del desarrollo del software
- Dirigido por los casos de uso
- Centrado en la arquitectura
- Iterativo e incremental

Objetivos de UML
Como primer objetivo UML es un lenguaje de modelado de propósito general que pueden usar todos los modeladores.
Un objetivo final de UML era ser tan simple como fuera posible pero manteniendo la capacidad de modelar toda la gama de sistemas que se necesita construir.

Áreas conceptuales de UML
- Estructura estática
- Comportamiento dinámico
- Construcción de implementación
- Organización del modelo
- Mecanismos de extensión

Capitulo II

Clases y objetos

- Una clase es un descriptor de un conjunto de objetos.
- Un objeto es una entidad discreta, con identidad, estado y comportamiento invocable.
- Una clase tiene una multiplicidad que especifica cuantas instancias de ella pueden existir.

Diagramas
Son representaciones graficas de un conjunto de elementos, que la mayoría de las veces se dibuja como un grafo conexo de nodos y arcos. Los diagramas se utilizan para visualizar un sistema desde diferentes perspectivas.

Diagramas estructurales
- Diagramas de clases
- Diagramas de objetos
- Diagramas de componentes
- Diagramas de despliegue

Diagramas de comportamiento
- Diagramas de casos de uso
- Diagramas de secuencia
- Diagramas de colaboración
- Diagramas de estados
- Diagramas de actividades

Vistas de UML
Una vista es simplemente un subconjunto de UML el cual modela construcciones que representan un aspecto de un sistema. La división en diversas vistas es algo arbitrario, pero esperamos que sea intuitiva.

Vista estática
Modela los conceptos del dominio de la aplicación, así como los aspectos internos inventados como parte de la implementación

Vista de los casos de uso
Esta vista modela la funcionalidad del sistema según actúan los usuarios externos llamados actores.

Vista de interacción
La vista de interacción describe secuencias de intercambios de mensajes entre los roles que implementan el comportamiento de un sistema.

Vista de la maquina de estados
Una maquina de estados modela las posibles historias de vida de un objeto de una clase. Una maquina de estados contiene los estados conectados por transistores

Vista de actividades
Un grafo de actividades es una variante de un maquina de estados, que muestra las actividades implicadas en la ejecución de un calculo.

Vistas de implementación
Las vistas anteriores modelan los conceptos de la aplicación desde un punto de vista lógico. Esta es una vista física, proporciona una oportunidad de establecer correspondencias entre las clases y los componentes de implementación y nodos.

Vista de gestión del modelo
La vista de gestión del modelo la organiza del modelo en si mismo. Un modelo abarca un conjunto de paquetes que contienen los elementos del modelo, tales como clases, maquinas de estados y casos de uso.

Relaciones
En el modelo orientado a objetos hay tres tipos de relaciones importantes: dependencias que representan relaciones de uso entre clases, generalizaciones que conectan clases generales con sus especializaciones, y asociaciones que representan relaciones estructurales entre objetos.

Dependencia
Es una relación de uso que clara que un cambio en la especificación de un elemento pude afectar a otro elemento que la utiliza pero no necesariamente a la inversa.

Generalización
Es una relación entre un elemento general (súper clase o padre) y un caso mas especifico de ese elemento (subclase o hijo).

Asociación
Es una relación estructural que especifica que los objetos de un elemento están conectados con los objetos de otro.

Capitulo III

Casos de uso

Términos y concepto
Un caso de uso es una descripción de un conjunto de secuencias de acciones, incluyendo variantes, que ejecuta un sistema para producir un resultado observable de valor para un actor

Nombre
Los casos de uso deben tener un nombre que lo distinga del otro caso de uso. El nombre es una cadena de texto.

Casos de uso y actores
Un actor representa un conjunto coherente de roles que los usuarios de los casos de uso juegan al interactuar con estos. Normalmente un actor representa un rol que es jugado por una persona, un dispositivo de hardware o incluso otro sistema al interactuar con nuestro sistema.

Casos de uso y flujo de eventos
- Flujo de eventos principal
- Flujo de eventos excepcional

Caso de uso y escenarios
Describe el flujo de eventos de un caso de uso mediante texto

Caso de uso y colaboraciones
Captura el comportamiento esperado del sistema que esta desarrollando sin tener que especificar como se implementa ese comportamiento.

Organización de casos de uso
Se pueden organizar especificando las relaciones de generalización inclusión y extensión entre ellos. Estas relaciones se utilizan para factorizar el comportamiento común y para factorizar variantes.

Otras características
Los casos de uso también son clasificadores, de tal forma que estos pueden tener operaciones y atributos que se pueden representar igual que en sus clases.

Propiedades comunes
Comparte las propiedades comunes al resto de lo diagramas. Lo que distingue a un diagrama de casos de uso de los otros tipos de diagramas es su contenido particular.

Contenidos
Un diagrama contiene:
- Casos de uso
- Actores
- Relaciones de dependencia

Usos comunes
Se emplearan:
1. Para modelar el contexto de un sistema
2. Para modelar los requisitos de un sistema

Objetivos del usuario e interacción con el sistema
La interacción con el sistema permiten decir que los casos de uso incluirán cosas como: “define estilo”, y “mueva un estilo de un documento a otro”.

Cuando emplear casos de uso
La captura de los casos de uso es una de las tareas principales durante la fase de elaboración; de hecho es lo primero que se debe hacer La mayoría de los casos de uso se generaran durante esa fase del proyecto pero irán descubriendo otros a medida que avance.

Modelado de casos de uso
- Modelado del comportamiento de un elemento
- Modelado del contexto de un sistema
- Modelado de los requisitos de un sistema
- Ingeniería directa o inversa

Sugerencias
- Nombra un comportamiento simple identificable y razonablemente atómico del sistema o parte del sistema
- Factoriza el comportamiento común incorporando ese comportamiento desde otros casos de uso que incluye
- Factoriza las variantes colocando ese comportamiento en otros caos de uso que lo extienden
- Describe el flujo de eventos de forma clara para que alguien externo al sistema lo entienda con facilidad.