RESUMEN DE UML

CAPÍTULO I

Un modelo es una representación de algo en el mismo u otro medio. El modelo capta los aspectos importantes de lo que estamos modelando y simplifica el resto, un modelo de sistema de software esta construido en un lenguaje de modelado como UML ya que es un lenguaje de modelado de software.

IMPORTANCIA DE MODELAR
Los modelos se usan para:

- Para captar y enumerar los requisitos y el dominio de conocimiento.
- Para pensar el diseño de un sistema
- Para capturar decisiones del diseño en una forma mutable a partir de los requisitos.
- Para generar productos aprovechables para el trabajo.
- Para filtrar, organizar, encontrar, recuperar, examinar y corregir la información en grandes sistemas.
- Para explorar económicamente múltiples soluciones.
- Para domesticar sistemas complejos

NIVELES DE MODELOS
La cantidad de detalle del modelo debe adaptarse a los siguientes propósitos:
- Guías al proceso de pensamiento.
- Especificaciones abstractas de la estructura esencial de un sistema.
- Especificaciones completa de un sistema final.
- Ejemplos de sistemas típicos o posibles.
- Descripciones completas o parciales de un sistema.

CONTENIDO DE UN MODELO
Consta de 2 aspectos como:

- El aspecto semántico: Que capta el significado de una aplicación, estos llevan el significado del modelo.
- El aspecto visual: Que muestra la información semántica tal que pueda ser considerada, hojeada y corregida por los seres humanos.

SIGNIFICADO DE UN MODELO
Es un generador de potenciales configuraciones de sistemas, también es una descripción de la estructura genérica y del significado de un sistema.En los modelos debemos considera estos aspectos:
- Abstracción frente a detalle.
- Especificación frente a implementación.
- Descripción frente a instancia.

PRINCIPIOS DEL MODELADO

Los principio son:
- La elección de que modelos crear tiene una profunda influencia sobre cómo se acomete un problema y cómo 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.

MODELO ORIENTADO A OBJETOS
El enfoque orientado a objetos forma parte de la tendencia principal para el desarrollo de software porque ha demostrado ser válido en la construcción de sistemas en toda clase de dominio de problemas, abarcando todo el abanico de tamaños y complejidades.


PERSPECTIVA GENERAL DE UML
Detrás de cada símbolo de la notación de UML hay una semántica bien definida. De esta manera, un desarrollador puede escribir un modelo en UML, y otro desarrollador, o incluso otra herramienta puede interpretar esa herramienta sin ambigüedad.

Bloques de construcción de UML

Existen 3 bloques de construcción:
- Elementos
- Relaciones
- Diagramas

existe 4 tipos de elementos:
- Elementos estructurales
- Elementos de comportamiento
- Elementos de agrupación
- Elementos de notación

existe 4 tipos de relaciones:
- Dependencia
- Asociación
- Generalización
- Realización

UML incluye 9 diagramas:

- Diagrama de clases
- Diagrama de objetos
- Diagrama de casos de usos.
- Diagrama de secuencias
- Diagrama de colaboración
- Diagrama de estados
- Diagrama de actividades
- Diagrama de componentes
- Diagrama de despliegue

CICLO DE VIDA DEL DESARROLLO DE SOFTWARE

- Dirigido por los casos de uso significa que los casos de uso se utilizan como un artefacto básico para establecer el comportamiento deseado del sistema, para verificar y validar la arquitectura del sistema, para las pruebas y para la comunicación entre las personas involucradas en el proyecto.
- Centrado en la arquitectura significa que la arquitectura del sistema se utiliza como un artefacto básico para conceptuar, construir, gestionar y hacer evolucionar el sistema en desarrollo.
- Un proceso iterativo es aquel que involucra la gestión de un flujo de ejecutables del sistema.

HISTORIA DE UML LOS MÉTODOS DE DESARROLLO ORIENTADO A OBJETOS

surgieron en los 70 y fueron difundidos y promovidos en los 80. lograron cierta penetración en el área de los grandes sistemas.El primer lenguaje fue el orientado a objetos es Simula 67, desarrollado en 1967. El movimiento de orientación de objetos se hizo popular en los 80’s.

ESFUERZOS DE UNIFICACIÓN
El primer intento exitoso se dio en 1995 cuando se creo el (UML)

ESTANDARIZACIÓN
UML fue adoptado de igual manera por los miembros de OMG como estándar en 1997.

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.

AREAS CONCEPTUALES
- Estructura estática
- Comportamiento dinámico.
- Construcciones de implementación.
- Organización del modelo.
- Mecanismos de extensión.

CAPÍTULO II

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 y un objeto es el valor de una variable.

DIAGRAMAS DE UML
Es la representación gráfica de un conjunto de elementos

DIAGRAMAS ESTRUCTURALES
son:
- Diagramas de clases.
- Diagramas de objetos.
- Diagramas de componentes.
- Diagramas de despliegue.

DIAGRAMAS DE COMPORTAMIENTO

son:
- Diagramas de casos de uso
- Diagramas de secuencia.
- Diagramas de colaboración.
- Diagramas de estados.
- Diagramas de actividades.

VISTAS DE UML
Es un subconjunto de UML que modela construcciones que representan un aspecto del sistema.

VISTA ESTÁTICA
aqui modela los conceptos del dominio de la aplicación tambien 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.
Se exhibe en dos programas.

- 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 MÁQUINA DE ESTADOS
Modela historias de vida de un objeto de una clase.

VISTA DE ACTIVIDADES
Muestra las actividades implicadas en la ejecución de un cálculo.

VISTA 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
las relacones se da entre los objetos.

DEPENDENCIA
Relación de uso que declara que un cambio en la especificación de un elemento puede afectar a otro elemento que lo utiliza.

ASOCIACIÓN
Relación estructural que especifica que los objetos de un elemento están conectados con los objetos de otro.

CAPÍTULO III

CASOS DE USOTÉRMINOS Y CONCEPTOS
Un caso de uso es una descripción de una secuencia de acciones que ejecuta un sistema para producir un resultado observable de valor para un actor.

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

CASOS DE USO Y ACTORES
Un actor representa un conjunto de roles que los usuarios de los casos de uso juegan al interactuar con éstos.

CASOS DE USO Y FLUJO DE EVENTOS
El comportamiento de un caso de uso se puede especificar describiendo un flujo de eventos de forma textual, lo suficientemente claro para que alguien ajeno al sistema lo atienda fácilmente.

CASOS DE USO Y COLABORACIONES
Un casos de uso debe implementarse al fin y al cabo, y esto se hace creando una sociedad de clases y otros elementos que colaborarán para llevar a cabo el comportamiento del caso de uso.

ORGANIZACIÓN DE CASOS DE USO
Pueden agruparse especificando relaciones de generalización, inclusión y extensión entre ellos.

OTRAS CARACTERÍSTICAS
Los casos de uso son clasificadores, Tal que podrian tener operaciones y atributos que se pueden representar igual que en las clases.

CONTENIDOS
Un diagrama de casos de uso contiene.
- Casos de uso.
- Actores.
- Relaciones de dependencia, generalización y asociación.

USOS COMUNES
son dos:
- Para modelar el contexto de un sistema.
- Para modelar los requisitos de un sistema.

OBJETIVOS DEL USUARIO E INTERACIONES CON EL SISTEMA
Los objetivos del usuario se describirán con términos como “garantizar el formateo consistente de un documento” y “hacer que el formato de un documento sea igual que el de otro”.

MODELADO DE CASOS DE USO MODELADO DEL COMPORTAMIENTO DE UN ELEMENTO

- Identificar los actores que interactúan con el elemento.
- Organizar los actores.
- Considerar las formas más importantes que tiene cada actor de interactuar con el elemento.
- Considerar las formas excepcionales en las que cada actor puede interactuar con el elemento.
- Organizar estos comportamientos como casos de uso, utilizando las relaciones de inclusión y extensión.

MODELADO DEL CONTEXTO DE UN SISTEMA
- Identificar los actores en torno al sistema.
- Organizar los actores similares en jerarquías de generalización/especialización.
- Introducir esos actores en un diagrama de casos de uso y especificar las vías de comunicación de cada actor con los casos de uso del sistema.

MODELADO DE LOS REQUISISTOS DE UN SISTEMA
- Establecer el contexto del sistema.
- Considerar el comportamiento de cada actor.
- Nombrar esos comportamientos comunes como casos de uso.
- Factorizar el comportamiento común en nuevos casos de uso que puedan ser utilizados por otros.
- Modelar los casos de uso, actores y relaciones en un diagrama de casos de uso.
- Adornar esos casos de uso con notas que enuncien los requisitos no funcionales.

RESUMEN DE UML

Introducción a UML:
UML es un lenguaje de modelado de software:
Ø Proporciona un vocabulario y reglas para crear modelos software.
Ø Suficientemente expresivo para cubrir distintas vistas de la arquitectura del software a lo largo del ciclo de vida.
Ø Mayor nivel de abstracción que un lenguaje de programación.
UML es un lenguaje para visualizar los elementos de un gran sistema software, facilitando:
Ø la comunicación entre los participantes (incluidas herramientas) en el desarrollo,
Ø la comprensión de las soluciones (notación gráfica),
Ø el mantenimiento de las soluciones conceptuales a lo largo del tiempo (documentación).
UML es un lenguaje para especificar software:
Ø Se pueden construir modelos precisos, no ambiguos y completos.
Ø Cubre las decisiones de análisis, diseño e implementación.
UML es un lenguaje para construir software:
Ø No es un lenguaje de programación visual, pero sus modelos se pueden conectar de forma directa a una gran variedad de ellos.
Ø Correspondencias entre UML y lenguajes: Java, C++, etc.
Ø Ingeniería directa: generación de código.
Ø Ingeniería inversa: reconstrucción de modelos.
UML es un lenguaje para documentar:
Ø requisitos, arquitectura, diseño, código fuente, pruebas, ...
El modelo conceptual está compuesto por 3 bloques de construcción básicos:
Elementos
• Abstracciones básicas a partir de las que se construyen los modelos
Relaciones
• Entre los elementos
Diagramas
• Grupo consistente de elementos y sus relaciones
La documentación con UML se basa en el uso de los diagramas:
Ø Diagrama de clases
Ø Diagrama de casos de uso
Ø Diagrama de secuencia
Ø Diagrama de colaboración
Ø Diagrama de estados
Ø Diagrama de actividades
Ø Diagrama de componentes
Ø Diagrama de despliegue
Definiciones:
Caso de uso; 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. Un caso de uso es realizado por una colaboración.
En relación con los escenarios, un caso de uso es un conjunto de escenarios, siendo un escenario una secuencia de acciones que ilustra un comportamiento, con lo cual un caso de uso describe un conjunto de comportamientos.
Un caso de uso captura el comportamiento esperado de un sistema, subsistema, clase o interface que se está desarrollando, sin tener que especificar cómo se implementa ese comportamiento.
Esto es importante porque el análisis del sistema no debería estar influenciado mientras sea posible por cuestiones de implementación, el qué frente al cómo. Lo que implica el diseño funcional, el qué, frente al diseño detallado, el cómo.
Un caso de uso, a la hora de implementarse, se realizará a través de una colaboración entre clases y otros elementos que colaboran entre si para llevar a cabo ese comportamiento. Esta sociedad de elementos, tanto su estructura estática como dinámica, se modela en UML como una colaboración.
Un caso de uso sigue normalmente cuatro fases:
Ø El actor envía al sistema una petición y los datos necesarios para llevarla a cabo
Ø El sistema valida la petición y los datos
Ø El sistema altera su estado interno
Ø El sistema devuelve el resultado al actor
Actor; conjunto coherente de roles que juegan los usuarios de los casos de usos cuando interactúan con estos. Normalmente representan a una persona, un dispositivo hardware u otro sistema al interactuar con el nuestro
Se pueden definir categorías generales de actores y especializarlos a través de la relaciones de generalización
Los actores se conectan a los casos de uso mediante asociaciones.
Diagrama de casos de uso; muestra un conjunto de casos de uso y actores junto con sus relaciones.
El objetivo es lograr claridad sobre lo que desea el usuario y la forma en la que se va a presentar la solución que se está buscando.
Muestra las operaciones que se esperan de la aplicación y sus relaciones con el entorno (usuarios u otras aplicaciones).
Los elementos que intervienen son:
Ø Los actores
Ø Los Casos de Uso
Ø Relaciones de dependencia, generalización y asociación
Se utilizan para especificar el comportamiento deseado del un sistema o subsistema:
Describe el conjunto de secuencias de acciones que lleva a cabo el sistema para
Producir un resultado para un actor.
Capturan el comportamiento deseado del sistema, sin especificar como se lleva a cabo dicho comportamiento.
Principalmente son un medio de comunicación para que los desarrolladores y los usuarios lleguen a un consenso en la especificación Ayudan a validar el sistema durante el desarrollo
Los casos de uso son principalmente descripciones textuales
Clase; descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. Describe estructura de los objetos de un sistema:
- identidad,
- relaciones con otros objetos,
- atributos y operaciones
Es el más característico del Diseño O.O.
Gráficamente se representan en los diagramas de clases
Las clases se representan mediante un rectángulo con tres divisiones internas.
La primera de ellas especifica el nombre de la clase, la segunda los atributos de la misma y la tercera los
Métodos asociados.
Diagrama de clases; diagrama que muestra un conjunto de clases, interfaces y colaboraciones y sus
Relaciones. Muestra una colección de elementos declarativos estáticos del modelo.
El objetivo es mostrar el conjunto de clases que componen el sistema, junto con las relaciones que existen entre estas.
Se utilizan para modelar el diseño estático de un sistema
Los elementos que intervienen son:
Ø Clases
Ø Relaciones de dependencia, generalización y asociación.
Ø Paquetes
Ø Interfaces
Interacción. Una interacción es un comportamiento que implica un intercambio de mensajes entre varios objetos en un contexto determinado con un objetivo determinado
Secuencia de mensajes que implementan un comportamiento dentro de una colaboración. Un mensaje es la especificación de una comunicación entre objetos que transmite información con el fin de desencadenar una actividad; la recepción de una instancia de un mensaje se considera normalmente una instancia de un evento. Comunicación unidireccional entre dos objetos, un flujo de objeto con la información de un remitente a un receptor.
Su objetivo es el establecimiento de prototipos de colaboración. Estos prototipos son los escenarios. Un Escenario es secuencia específica de acciones que ilustra un comportamiento. Se puede utilizar para ilustrar la interacción o la ejecución de una instancia de un caso de uso.
Las interacciones se llevan a cabo entre objetos no entre clases
Un enlace es una conexión semántica entre objetos
Elementos que intervienen en las interacciones:
Objetos: instancias concretas de clases
Enlaces: enlazan instancias y soporte al envío de mensajes
Mensajes: desencadenan operaciones
Funciones: implementadas por los extremos de los enlaces
Diagrama de interacción; muestra una interacción, que consta de un conjunto de objetos y sus relaciones, incluyendo los mensajes que se pueden enviar entre ellos. El término genérico de interacción abarca los diagramas de colaboración, de secuencia y de actividades.
Complementan los modelos obtenidos de los casos de uso iniciales y los diagramas de clase
Son útiles para modelar aspectos dinámicos de cualquier interacción entre cualquier instancia en cualquier vista del sistema (clases, interfaces, componentes,...)
Las interacciones se pueden “adornar” con restricciones temporales (marcas temporales)
Hay dos tipos de diagramas: de secuencia y de colaboración.
-Un diagrama de secuencia es un diagrama en el que se destaca la ordenación temporal de los eventos
Un diagrama de colaboración destaca la organización estructural de los objetos eque envían y reciben los mensajes
Ø Son semánticamente equivalentes
Ø Se puede generar uno a partir del otro, sin perdida de información
Ø Visualmente, sin embargo, esta información puede ser más difícil de percibir
Diagramas de colaboración; diagrama de interacción que resalta la organización estructural de los objetos que envían y reciben mensajes.
Destacan la organización de los objetos que participan en una interacción
Es un grafo en el que los nodos son los objetos y los arcos los enlaces
Los arcos se etiquetan con los mensajes que envían y reciben los objetos
Dan una visión del flujo de control en el contexto de la organización de los objetos que colaboran
Ø Permiten indicar que objetos actúan como atributos de otros.
Ø Permiten indicar que objetos son temporales y cuales no.
Ø Permite indicar que relaciones estructurales actúan en una colaboración
Hay dos características que los distinguen de los diagramas de secuencia: o El camino: Para indicar como se enlazan los objetos se utilizan estereotipos en los extremos de los enlaces El número de secuencia: Para indicar la ordenación de los mensajes se utiliza la numeración decimal de
Diagrama de secuencia; diagrama de interacción que destaca la ordenación temporal de mensajes.
Un diagrama de secuencia muestra la interacción de un conjunto de objetos de una aplicación a través del tiempo. Posibilita la representación de la secuencia temporal de envío de mensajes entre los objetos pertenecientes a las clases diseñadas en el contexto de una operación. El concepto de mensaje en el contexto de los diagramas de secuencia, materializa y unifica todas las formas de comunicación entre objetos.
Los Objetos se representan mediante un rectángulo que encabeza una línea discontinua, que representa la línea de vida del objeto.
Los Mensajes se denotan mediante una flecha dirigida desde el objeto que emite el mensaje hasta el objeto que lo ejecuta.
Los tipos de mensajes posibles son los siguientes:
- Simple
- Síncrono
- Abandono
- Time-Out
- Asíncrono
Los diagramas de secuencia se suelen asociar a los casos de uso, mostrando como estos se realizan a través de interacciones entre sociedades de objetos
Diagrama de estados; permiten la representación del ciclo de vida de los objetos.
El comportamiento de los objetos puede describirse de manera formal en términos de estados y eventos.
Los objetos que no representan un comportamiento reactivo muy marcado pueden considerarse como objetos que se encuentran siempre en el mismo estado.
Cuando un objeto muestra un comportamiento se dice que tiene asociado un autómata
Elementos:
Estado: condición o situación de un objeto durante la cual:
Ø Se satisface alguna condición
Ø Se realiza alguna actividad
Ø Se espera algún evento
Evento: especificación de un acontecimiento significativo que ocupa un lugar en el tiempo y en el espacio
- Transición: relación entre dos estados que indica como los objetos cambian de estado
(Eventos + condiciones)
- Actividad: ejecución no atómica en curso dentro de una máquina de estados
- Acción: computación atómica ejecutable que produce un cambio de estado en el modelo devuelve un valor