UML

CAPITULO I

El porque de modelar.- un modelo es una representación que capta los aspectos importantes de lo que estamos modelando (un edificio, un software, etc.) es un medio adecuado para un trabajo.

Un modelo de un sistema software seta construido en un leguaje de modelado como UML, con el modelo se pretende hacer más fácil el uso de ciertos propósitos que el sistema final.

La importancia de modelar.- los modelos se usan para muchos propósitos

· Para captar y enumerar exhaustivamente los requisitos y el dominio de conocimiento, forma que todos los implicados puedan entenderlos y estar de acuerdo con ellos.

· Para capturar decisiones del diseño en una forma mutable a partir de los requisitos

· Para generar productos aprovechables para el trabajo

· Para organizar, encontrar, filtrar, recuperar, examinar, y corregir la información en grandes sistemas.

· Para explorar económicamente múltiples soluciones.

· Para domesticar los sistemas complejos.

Niveles de los modelos.- la cantidad de detalle del modelo debe adaptarse a uno de los siguientes propósitos.

· Guías al proceso de pensamiento.

· Descripciones completas o parciales de sistemas

¿Qué hay en un modelo?

En un modelo existen dos aspectos importantes.-

La información semántica.- es el significado de una aplicación como una red de construcciones lógica, los elementos semánticos del modelo llevan el significado del modelo, es decir, transportan la semántica, y se utilizan para la generación del código

La presentación visual.- es la que muestra la información semántica de modo que las personas puedan corregirlas la presentación visual del modelo es la que lleva el significado del modelo (llevan la semántica transportan el significado) estos se usan para generar el código, la comprobación de la validez, las métricas de complejidad, etc.

¿Cuál es el significado de un modelo?

Es un generador de potenciales configuraciones del sistema. Un modelo es siempre una abstracción a un cierto nivel, captura los aspectos esenciales de un sistema y omite algunos de los detalles. En los modelos hay que considerar 4 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

· La elección de que modelos crear tiene una profunda influencia sobre como se acomete un problema y como se da forma a una solución.

· Todo modelo puede ser expresado a diferentes niveles de presión

· Los mejores modelos están ligados a la realidad

· Un único modelo no es suficiente. Cualquier sistema no trivial se aborda mejor a través de un pequeño conjunto de modelos casi independientes

Modelos orientados a objetos.-

En este enfoque, el principal bloque de construcción de todos los sistemas es el objeto o clase.

Elementos en UML.-

Elementos estructurales

Elementos de comportamiento

Elementos de agrupación

Elementos de notación

Relaciones en UML.-

Dependencia

Asociación

Generalización

Realización

CAPITULO II

Clases y objetos.-

Una clase es una asociación de objetos que tienen los mismos atributos, guardan las mismas relaciones y comportamientos.

Una clase es la descripción con nombre tanto de la estructura de datos, como del comportamiento de un conjunto de objetos.

Diagramas de UML

Es la presentación grafica de un conjunto de elementos, estos se utilizan para visualizar un sistema desde diferentes perspectivas.

Diagramas estructurales.- existen 4 diagramas estructurales de UML para visualizar, especificar, construir y documentar los aspectos estáticos de un sistema:

Diagramas de clase

Diagramas de objetos

Diagramas de componentes

Diagramas de despliegue

Diagramas de comportamiento.- estos se emplean para visualizar, especificar, construir y documentar los aspectos dinámicos de un sistema.

Diagramas de casos de uso

Diagramas de secuencia

Diagramas de colaboración

Diagramas de estados

Diagramas de actividades

Vista de UML

Vista estática.- no describe el comportamiento del sistema dependiente del tiempo, que se describe en otras vistas.

Vista de los casos de uso.- esta modela la funcionalidad del sistema según actúen los usuarios externos llamados actores. Es la transacción que existe entre los usuarios y el sistema.

Vista de interacción.- proporciona una vista integral del comportamiento de un sistema, es decir, muestra el flujo de control a través de muchos objetos.

Vista de la maquina de estados.- una maquina de estados modela las posibles historias de la vista de un objeto de una clase.

Vista de actividades.- es una variantes de la maquina de estado, que muestra las actividades implicadas en la ejecución de un calculo.

Vista de implementación.- esta vista es una vista física, modela los componentes de un sistema, así como la dependencia entre componentes, para poder determinar el impacto de un cambio propuesto.

Vista de gestión del modelo.- modela la organización del modelo en si mismo, puede haber varios modelos de un sistema desde distintos puntos de vista.

Relaciones.-

En un modelo orientado a objetos existen tres tipos de relaciones especialmente impotentes:

· Dependencia.- 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 necesariamente a la inversa.

· Generalización.- es una relación entre un elemento general y un caso mas especifico de ese elemento, los objetos hijos se pueden emplear en cualquier lugar donde puede aparecer el padre, pero no a la inversa.

· Asociación.- relación estructural que especifica que los objetos de un elemento están conectados con los objetos de otro.

CAPITULO III – CASOS DE USO

Introducción.- descripción de un conjunto de secuencias de acciones que ejecuta un sistema para producir un resultado observable y que tiene valor para un actor.

Términos y conceptos.-

Nombre.- expresiones verbales (validar usuario, hacer pedido, etc.)

Actores.- es la representación de un conjunto de roles.

Casos de uso y flujo de eventos.- es la descripción del comportamiento del caso de uso.

Casos de uso y escenarios.- es una secuencia especifica de acciones que ilustra un comportamiento.

Casos de uso y colaboración.- es la sociedad de clases y otros elementos que colaboraran para llevar a cabo el comportamiento del caso de uso.

Organización de casos de uso.- pueden organizarse agrupándolos en paquetes, de lamisca manera que se organizan las clases.

Propiedades comunes.-

Un diagrama de casos de uso es un tipo especial de diagrama y comparte las propiedades comunes al resto de los diagramas. Lo que distingue a estos diagramas es su contenido particular.

Contenido

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

Cuando emplear casos de uso.-

Es lo primero q se debe hacer para la elaboración de la captura de requerimientos, la planificación, o el control de proyectos iterativos.

Modelación de caso de uso

Modelado del comportamiento de un elemento.- para modelar el comportamiento de un elemento hay que.-

· identificar los actores que interactúan con el elemento

· Organizar a los actores identificando tanto los roles mas generales como los mas especializados.

· Considerar las formas mas 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.- para modelar el contexto de un sistema:

· Identificar los actores en torno al sistema

· Organizar los actores similares en jerarquías de generalización

· Proporcionar un estereotipo para cada uno de esos actores.

· Introducir 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

· Considerar el comportamiento que cada actor espera del sistema o requiere que este le proporcione

· 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 esos 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.