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.