Modelado de Sistemas con UML

Cap. I Introducción

¿Porque Modelamos?

Un modelo es una representación, que puede captar aspectos importantes de lo que se está modelando. Un modelo de un sistema de software está construido en el lenguaje de modelado UML.

La Importancia de modelar:

- Nos sirven para obtener y captar los requisitos y el dominio del conocimiento.
- Para pensar sobre el diseño de un sistema.
- Para obtener decisiones del diseño en una forma mutable a través de los requisitos.
- Para generar productos aprovechables para el trabajo.
- Para organizar, encontrar, filtrar, grandes sistemas.
- Para explorar económicamente múltiples soluciones.
- Para domesticar los sistemas complejos

Niveles de los Modelos:

Los modelos tienes diferentes propósitos y aparecen en diferentes niveles de abstracción. Los detalles del modelado se adaptan a los siguientes propósitos:

- Guías al proceso de pensamiento
- Especificaciones abstractas de la estructura de un sistema.
- Especificaciones completas de un sistema final.
- Ejemplos de sistemas típicos o posibles
- Descripciones completas o parciales de sistemas.

¿Qué hay en un modelo?:

Los modelos tienes dos aspectos, la información semántica (semántica) y prestación visual (notación). El aspecto semántico capta el significado de una aplicación como una red de construcciones como clases asociaciones, estados, casos de uso y mensajes. El aspecto visual es irrelevante para las herramientas que procesan modelos.
¿Cuál es el significado de 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 cómo 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 ligado a la realidad.
- Un 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:

Existen varias de enfocar un modelo en un software, las dos formas más comunes son la perspectiva orientada a objetos y la perspectiva algorítmica. En esta última, el bloque principal de construcción de todo software es el procedimiento o función. La visión actual del desarrollo de software toma una perspectiva orientada a objetos, en este enfoque el bloque de construcción de todos los sistemas de software es el objeto o clase.

Perspectiva General de UML:
Visión 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

Diagramas de UML:

UML incluye nueve diagramas:

-Diagrama de clases
-Diagrama de objetos
-Diagrama de casos de uso
-Diagrama de secuencia
-Diagrama de colaboración
-Diagrama de estados
-Diagrama de actividades
-Diagrama de componentes
-Diagrama de despliegue

Historia de UML:

Los Métodos de Desarrollo Orientado a Objetos:

Emergieron en los años 70 y fueron difundidos en los 80. Alcanzaron cierta penetración en el área de los grandes sistemas. El primer lenguaje que es generalmente reconocido como orientado a objetos es Simula 67, desarrollado en 1967. El movimiento de orientación de objetos se hizo popular en los 80’s. Aparecieron muchos libros cuyos temas estaban enfocados en el modelaje orientado a objetos.

Esfuerzos DE Unificación:

El primer intento exitoso se dio en 1995 cuando se creó el Lenguaje Unificado de Modelado (UML)

Estandarización:

El Lenguaje Unificado de Modelado fue adoptado unánimemente por los miembros de OMG como estándar en noviembre de 1997.

¿Qué significa unificado?:

- A través de los métodos históricos y notaciones.

-A través de los dominios de aplicación.

-A través de los lenguajes de implementación y plataformas.

-A través de procesos de desarrollo.-A través de los conceptos internos.

Objetivos de UML:

-UML es un lenguaje de propósito general que pueden utilizar todos los programadores.-basado en el común acuerdo.

-Pretende abordar los problemas actuales de desarrollo de software.-UML pretende trabajar correctamente con todos.

-UML incluye todos los conceptos que consideramos necesarios para utilizar un proceso moderno iterativo.

-Ser tan simple como fuera posible.

Áreas Conceptuales:

-Estructura estática

-Comportamiento dinámico.

-Construcciones de implementación.

-Organización del modelo.

-Mecanismos de extensión.

Cap. 2: Conceptos de UML

Clases y Objetos:

Una clase es un descriptor de un conjunto de objetos que comparten los mismos atributos, operaciones, métodos, relaciones y comportamiento. Una clase representa un concepto dentro del sistema que se está modelando. Un objeto que es el valor de una variable debe tener una clase compatible con el tipo declarado para esa variable.

Diagramas:

Es una representación grafica de un conjunto de elementos, se utilizan para visualizar un sistema desde diferentes perspectivas.

Vistas de UML:

Una vista es un subconjunto de UML que modela construcciones que representan un aspecto de un sistema. Una o dos clases de diagramas proporcionan una notación visual para los conceptos de cada vista. Las vistas se puedes dividir en tres aéreas: clasificación estructural, comportamiento dinámico y gestión del modelo.

Vista Estática:

La vista estática modela los componentes del dominio de la aplicación, así como los componentes internos inventados como parte de la implementación. Es estática por qué no describe el comportamiento del sistema dependiente del tiempo que se describe en otras vistas, los componentes principales de la vista estática son sus clases y relaciones.

Vista de los casos de uso:

Esta vista moldea la funcionalidad del sistema según actúen los usuarios externos llamados actores .Un caso de uso es una unidad coherente de funcionalidad expresada con transacción entre los actores y el sistema.

Vista de interacciona:

La vista de interacción describe secuencias de intercambio de mensajes entre los roles que implementan el comportamiento de un sistema. Un rol de clasificador, o simplemente "rol", es la descripción de un objeto, que desarrolla un determinado papel dentro de una interacción, distinto de los otros objetos de la misma clase.

Vista de máquina de estados:

Una maquina de estados modela las posibles historias de vida de un objetos de una clase. Una maquina de estados contiene los estados conectados por transiciones, cada estado modela un periodo de tiempo, durante la vida de un objeto, en el que satisface ciertas condiciones.

Vista de Actividades:

Un grafico de actividades es una variante de una maquina de estados, que muestra las actividades implicadas en la ejecución de un cálculo. Un estado de actividades representa una actividad un paso en el flujo de trabajo o en la ejecución de un operación.

Vista de Implementación:

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

Vista de gestión o modelo:

La vista de gestión del modelo modela la organización 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, los paquetes pueden contener otros paquetes, por lo tanto, un modelo señala una raíz que contiene indirectamente todo el contenido del modelo.

Relaciones:

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

Dependencia:

Una dependencia es una relación de uso que declara que un cambio en la especificación de un elemento puede afectar a otro elemento que la utiliza, pero no necesario a la inversa.

Generalización:

Una generalización es una relación entre un elemento general (superclase o padre), y un caso más específico y un caso más específico de elemento (subclase hijo). Las generalizaciones se llaman a veces relación, la generalización significa que los objetivos hijos se puedan emplear en cualquier lugar donde pueda aparecer el padre, pero no a la inversa.

Asociación:

Una asociación es una relación estructural que específica que los elementos de los objetos están conectados con los objetos de otro. Dada una asociación entre dos clases, se puede navegar desde un objeto de una clase hasta un objeto de otra clase, y viceversa.

Cap. 3 Casos de Uso

Introducción:

Durante mucho tiempo las personas se auxiliaban de escenarios típicos que les ayudaban a comprender los requerimientos, pero trataban de modo informal y pocas veces se documentaban. Ivar Jacobson cambio todo esto con su método Objetory, lo que elevo la visibilidad del caso de uso.

Conceptos:

Nombres:

Cada caso debe tener un nombre que los distinga de otros casos de uso.

Actores:

Representan un conjunto coherente de roles que los usuarios de los casos de uso juegan al interactuar con estos, representan un rol que es jugado por un persona.

Flujo de Eventos:

Cuando se moldea es importante tener clara la separación de objetivos entre las vistas externa e interna.

Escenarios:

Normalmente primero se escribe el flujo de eventos de un caso de uso mediante texto. Sin embargo conforme se mejora la comprensión de los requisitos del sistema estos flujos se pueden especificar gráficamente mediante diagramas de interacción.

Caso de uso y colaboraciones:

Un caso de uso captura el comportamiento esperado del sistema (subsistema, clase o interfaz) que se está desarrollando, sin tener que especificar cómo se implementa este comportamiento.

Otras características:

Los casos de uso son también clasificadores, de forma que pueden tener operaciones y atributos que se pueden representar igual que en las clases.

Propiedades comunes:

Un diagrama de casos de uso es u tipo especial de diagrama y comparte las propiedades comunes al resto de los diagramas.

Contenidos:

Un diagrama de casos de uso contiene:

-Casos de uso.

-Actores.

-Relaciones de dependencia, generalización y asociación.

Usos Comunes:

-Para modelar el contexto de un sistema.

-Para modelar los requisitos de un sistema.