resumen de UML

Capítulo I

¿Por qué modelamos?
Para captar los aspectos más importantes de lo que estamos modelando, desde cierto punto de vista que simplifica u omite el resto. Un modelo de sistemas se software está construido en un lenguaje modelado como UML el modelo tiene semántica y notación y puede adoptarse varios formatos que incluyen texto y grafico.

Importancia de modelar

Su importancia se basa en captar o enumerar los requisitos y el dominio del conocimiento de forma que todos los implicados puedan entenderlo y estar de acuerdo con ellos; para pensar el diseño de un sistema; para capturar decisiones de diseño en una forma mutable a partir de los requisitos; para generar productos aprovechables para el trabajo.

Niveles de un modelo
Ø Guías de procesos 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?
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?
Es un generador de potenciales y de sistemas. Todas las configuraciones consistentes deberían ser posibles. Se debe considerar los siguientes aspectos:
Ø Abstracción frente a detalle.
Ø Especificación frente a implementación.
Ø Descripción frente a instancia.
Ø Variaciones en la interpretación.

Principios del modelado

Hay cuatro tipos básicos de modelaje: la elección de que modelos crear tiene una profunda influencia sobre cómo se acomete un problema y como se va dar la solución, todo modelo puede ser expresado a diferentes modelos de precisión, los mejores modelos están ligados a la realidad y un único modelo no es suficiente. Cualquier sistema no trivial se aborda mejor a través de un pequeño conjunto de modelos independientes.

Modelo orientado a objetos
El principal bloque de construcción de todos los sistemas software es el objeto o clase. Proporciona la base fundamental para ensamblar sistemas a partir de componentes usando tecnologías como Java, Veans o COM.
Perspectiva General de UML:Visión general de UML:
UML es un lenguaje para:
Ø Visualizar.
Ø Especificar.
Ø Construir.
Ø Documentar.
Bloques de construcción de UML:
Ø Elementos
Ø Relaciones
Ø Diagramas
Ciclos de Vida del desarrollo de Software
Ø Dirigido por los casos de uso.
Ø Centrado en la arquitectura.
Ø Iterativo e incremental.
Objetivos de UML
Ø El más importante, UML es un lenguaje de modelado de propósito general que pueden usar todos los modeladores.
Ø No pretende ser un método de desarrollo completo.
Ø Pretende trabajar correctamente con todos.
Ø Ser lo más simple posible manteniendo la capacidad de modelar cualquier tipo de sistema que necesite construir.
Áreas conceptuales de UML
Ø Estructura estática.
Ø Comportamiento dinámico.
Ø Construcción de implementación.
Ø Organización del modelo.
Ø Mecanismos de extensión.
Capítulo II
Conceptos de UMLClases y ObjetosUna clase es un descriptor de un conjunto de objetos que comparten los mismos atributos, operaciones, métodos, relaciones y comportamientos, una clase consta de un nombre de una lista de atributos y una lista de operaciones. Un objetivo que es un valor de una variable debe tener una clase compatible con el tipo declarado para esa variable..DiagramasSon representaciones graficas de un conjunto de elementos. Y pueden ser: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 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.
Vista Estática: Modela los conceptos del dominio de la aplicación, así como los conceptos internos inventados como parte de la implementación.
Vista de los Casos de Uso: Modela la funcionalidad del sistema según actúen los usuarios externos llamados actores.
Vista de Interacción: Describe secuencias de intercambio de mensajes entre los roles que implementan los comportamientos de un sistema.
Ø Diagrama de secuencia: Muestra un conjunto de mensajes, dispuestos en una secuencia temporal.
Ø Diagrama de colaboración: Modela los objetos y los enlaces significativos dentro de una interacción.
Vista de la Maquina de Estados: Modela las posibles historias de vida de un objeto de una clase.
Vista de Actividades: Es una variante de una máquina de estados, que muestra las actividades implicadas en la ejecución de un cálculo.
Vistas de Implementación: Proporciona una oportunidad de establecer correspondencias entre las clases y los componentes de implementación y nodos.Vista de Gestión del Modelo: Modela la organización del modelo en sí mismo.Relaciones
Ø Dependencia: Declara que un cambio en la especificación de un elemento puede afectar a otro elemento que lo utiliza.
Ø Generalización: Relación entre un elemento general y un caso más específico de ese elemento.
Ø Asociación: Relación estructural que específica que los objetos de un elemento están conectados con los objetos de otro.
Capítulo III
Casos de usos
Es una descripción de un conjunto de secuencias de acción, incluyendo variantes, que ejecute un sistema para producir un resultado observable de valor para un actor, gráficamente un caso de uso se representa como una elipse.
Casos de usos y actores
Un actor representa un conjunto coherente de roles que los usuarios de los casos que uso juegan al interactuar con estos. Normalmente representa a un sistema, persona o dispositivo de hardware.
Casos de uso y flujo de evento
El comportamiento de un caso de uso se puede especificar describiendo un flujo de eventos de forma textual o suficientemente claro para que para que alguien ajeno al sistema los entienda fácilmente.
Casos de uso y escenarios
El flujo principal separar por los flujos alternativos, porque un caso de uso describe un conjunto de secuencias, no una única secuencia y sería imposible expresar todo los detalles de un caso de uso trivial.
Caso de uso y colaboraciones
El objetivo de la arquitectura de un sistema es encontrar el conjunto mínimo de colaboraciones bien estructuradas que satisfacen el flujo de eventos.
Organización de los casos de uso
La organización de los casos de uso considerando la extracción de comportamientos comunes y la distinción de variantes y es muy importante para la creación de un conjunto de casos de uso del sistema que sea sencillo equilibrado y comprensible.
Modelación de los casos de usos
Modelación del comportamiento: se utilizan para el modelado del comportamiento de un elemento, ya sea un sistema completo, un subsistema o una clase.
Modelación del contexto de un sistema: en UML ase puede modelar al contexto de un sistema con un diagrama de caso de uso destacando los actores en torno al sistema.
Modelos de los requisitos de un sistema: un requisito es una característica de diseño, una propiedad o un comportamiento de un sistema.Ingeniera directa e inversa: es el proceso de trasformar un modelo en código a través de un lenguaje de implementación.