UML

CapI

¿Por qué modelamos?

El modelo capta los aspectos mas importantes de lo que estamos modelando, desde cierto punto de vista que simplifica u omite el resto.

La importancia de modelar

• Para capturar y enumerar los requisitos y el dominio del conocimiento.
• Para pensar del diseño de un sistema.
• Para capturar desiciones del diseño de una forma mutable apartir de los requisitos.
• El modelo de un sistema de software puede capturar el comportamiento externo de un sistema la informacion del dominio del mundo real representado por el sistema.
• Para generar productos aprovechables para el trabajo.
• Para explorar economicamente soluciones.
• Para domesticar los sistemas complejos.

Niveles de los modelos

• Guias 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.

¿Que hay en un modelo?
Informacion semantica e presentacion visual.

¿Cual es el significado de un modelo?

• Es un generador de potenciales generadoreds de sistemas. Todas las configuraciones consistentes deberian der posibles. Se debe considerar los diguientes aspectos:
• Abstraccion frente a detalle.
• Especificacion frente a implementacion.
• Descripción frente a instancia.
• Variaciones en la interpretación.

Principios del modelado

• Tienen 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.

Modelado orientado a objetos
El pricipal bloque de construccion de todos los ditemas software es el obheto o clase. Proporciona la base fundamental para ensamblar sistemas apartir de componentes usando tecnologias como Java Veans o COM+.

Perspectiva general de UML

Vision General
Es un lenguaje para: Visualizar, especificar, construir y documentar.

Modelo Conceptual
Bloques de construccion

• Incluyen tres clases de bloques de construccion: Elementos, relaciones y diagramas.
• Hay cuatro tipos de elementos: Estructurales, de comportamiento, de agrupacion y de notacion.
• Hay cuatro tipos de relaciones: Dependensia, asociacion, generalizacion y realizacion.
• Incluyen nueve diagramas: De clases, de objetos, de casos de usos, de secuencias, de colaboración, de estados, de actividades, de componentes y de despliegue.

Ciclos de Vida del desarrollo de Software

• Dirigido por los casos de uso.
• Centrado en la arquitectura.
• Iterativo e incremental.

Objetivos de UML

• El mas importante, UML es un lenguaje de modelado de propósito general que pueden usar todos los modeladores.
• No pretende ser un metodo de desarrollo completo.
• Pretende trabajar correctamente con todos.
• Ser lo mas 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 II

Conceptos de UML

Clases y Objetos
Una clase es un descriptor de un conjunto de objetos que comparten los mismos atributos, operaciones, metodos, relaciones y comportamiento.

Diagramas
Son representaciones graficas de un conjunto de elementos.

Diagramas Estrucrurales

• 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

Vista Estatica: 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 Interaccion: 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 Implementacion: Proporciona una oportunidad de establecer correspondencias entre las clases y los componentes de implementación y nodos.

Vista de Gestion 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.
• Generalizacion: Relación entre un elemento general y un caso más específico de ese elemento.
• Asociacion: Relación estructural que especifica que los objetos de un elemento están conectados con los objetos de otro.

CAP III

Casos de Uso

Terminos y Conceptos

Un caso de uso es una descripción de una secuencia de acciones, incluyendo variantes 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 coherente de roles que los usuarios de los casos de uso juegan al interactuar con éstos. Representa un rol jugado por una persona, un Hardware u otro sitema.

Casos deUso y Flujos de Eventos

Describe lo que hace un sistema pero no especifica lo que hace, describe el flujo de forma textual, losuficientemente claro pra que alguien ajeno lo entienda.

Caso de uso y escenarios

Especifica el flujo principal de un caso de uso y se usan variaciones de ese diagrama para especificar los flujos exepcionales del caso de uso.

Casos de Uso y Colaboraciones

Captura el comportamiento esperado del sistema sin tener que especificar como se implementa ese comportamiento. Crea una sociedad de clases y otros elementosque colaboran para llevar a cabo su comportamiento.

Organizacion de Casos de Uso

Pueden organizarse agrupándolos en paquetes. También pueden agruparse especificando relaciones de generalización, inclusión y extensión entre ellos.

Propiedades Comunes

Lo distinguen de otros programas su contenido en particular.

Contenidos

• 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.

Objetivos del Usuario e Interacciones con el Sistema

• Garantizar el formateo consistente de un documento.
• Hacer que el formato deun documento sea igual que el otro.
• Sirven mas para fines de planificacion.

Cuando Emplear Casos de Uso

Son una herramienta esencial para la captura de requerimientos, la planificacion oel control de proyectos iterativos.

Modelado de los Casos de Uso

Modelado del Comportamiento de un Elemento

• Identificar los actores que interactuan con el elemento.
• Organizar los actores identificando roles generales, como especializados.
• Considerar formas exepcionales en las que cada actor puede interactuar con el elemento.
• Organizar estos comportamientos, realizando operaciones de inclusion y extension .

Modelado del Contexto de un Sistema

• Identificar los actores entorno al sistema.
• Organizar los actores similares en jerarquías de generalización/especialización.
• Proporcionar un estereotipo para cada uno delos actores, para ayudar a entender el sistema.
• 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 Requisitos de un Sistema

• Establecer el contexto del sistema. Identificando los actores a su aalrededor.
• Considerar el comportamiento de cada actor espera del sistema.
• 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.

Ingenieria Directa e Inversa

La ingeniería directa es el proceso de transformar un modelo en código a través de una correspondencia con un lenguaje de implementacion. Para hacer un diagrama de caso de uso mediante Ing. Directa:

• Identificar el flujo de eventos de cada caso de uso y su flujo de eventos exepcional.
• Generar un guion de prueba para cada flujo.
• Generar una estructura de prueba para representar cada actor que interactua con el caso de uso.
• Usar herramientas que ehecuten estas prubas cad vez que se genere una nueva version del elemento al que se aplica el siagrama de casos de uso.

La ingeniería inversa es el proceso de transformar código en un modelo a través de una correspondencia a partir de un lenguaje de implementación específico. Para hacer un diagrama de caso de uso mediante Ing. Inversa:

• Identificar cada actor que interactuacon el sistema.
• Considerar la forma de que cada actor interactua con el sistema.
• Trazar el flujo de eventos del sistema ejecutable en relacion a cada actor.
• Agrupar los flujos relacionados declarando el correspondiente caso de uso.
• Representar a esos actores y casos de uso en un diagrama de casos de uso y establecer sus relaciones.