UML - Analisis

CAPITULO 1
INTRODUCCION

PORQUE MODELAMOS
Porque un modelo es una representación en el mismo u otro medio. Un modelo capta todos los aspectos importantes de lo que estamos modelando y deja de hacer el resto. La ingeniería, la arquitectura y muchos campos creativos utilizan los modelos.

Un modelo de un sistema de software esta construido en un lenguaje modelado, como UML. El modelo tiene significado y notación y puede adoptar varios formatos que incluyen textos y graficas.

LA IMPORTANCIA DE MODELAR
· Para captar y enumerar los requisitos del conocimiento. De forma que todos puedan entenderlos y estar de acuerdo con ellos
· Para pensar del 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 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 MODELOS
Los modelos adquieren diferentes formas para diferentes propósitos y aparecen en diversos niveles de abstracción La cantidad del detalle del modelo debe adaptarse a uno de los siguientes propósitos:
· Guía al proceso de pensamiento
· Especificaciones abstractas de la estructura esencial de un sistema
· Especificaciones completas de un sistema final
· Ejemplos de sistemas típicos o posibles
· Descripciones completas o parciales de un sistema

¿QUE HAY EN UN MODELO?
Información semántica y presentación visual (notación)
Información semántica: capta la información de una aplicación como una red construcciones lógicas, la información semántica tiene una estructura sintáctica, reglas para asegurar su corrección, y dinámicas de ejecución.
Presentación visual: muestra la información semántica de modo que pueda ser aceptada, vista y corregida por el usuario

¿CUAL ES EL SIGNIFICADO DE UN MODELO?
Es un generador de potenciales configuraciones de sistemas a su vez es una descripción de la estructura genérica y del significado de un sistema.
En los modelos tenemos que 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
Primero: La elección de que modelos crear tiene una profunda influencia sobre cómo se acomete un problema y como se da forma a una solución.
Segundo: Todo modelo puede ser expresado a diferentes niveles de precisión.
Tercero: Los mejores modelos están ligados a la realidad.
Cuarto: 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.

MODELADO ORIENTADO A OBJETOS
En la visión actual del desarrollo del software tomaína perspectiva orientada a objetos, en este enfoque el principal bloque de construcción de todos los sistemas es el objeto o clase, este forma parte de la tendencia principal para el desarrollo del software porque ha demostrado ser validos en la construcción de sistemas.

PERSPECTIVA GENERAL DE UML
Visión general de UML

UML es un lenguaje para:
- Visualizar
- Especificar
- Construir
- Documentar
El vocabulario y las reglas de UML indican como crear modelos bien formados, UML es un leguaje para visualizar porque detrás de cada símbolo de la notación de UML hay una semántica bien definida.

UN MODELO CONCEPTUAL DE UML
Para comprender UML se necesita adquirir un modelo conceptual de lenguaje, y esto requiere aprender tres elementos principales:
Bloque de construcción de UML

El vocabulario de UML incluye tres clases de bloques de construcción
1. Elementos
2. Relaciones
3. Diagramas

Hay cuatro tipos de elementos en UML
1. Elementos estructurales
2. Elementos de comportamiento
3. Elementos de agrupación
4. Elementos de notación

Estos elementos son los bloques básicos de construcción orientados a Objetos de UML. Se utilizan para escribir modelos bien formados.

Elementos estructurales:Es la parte estática de un modelo y representan cosas, son conceptuales o materiales. Hay siete tipos de elementos estructurales:

Primero: describe un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. Una clase implementa una o más interfaces.
Segundo: colección de operaciones que especifican una clase o componente.
Tercero: una colaboración define una interacción, y es una sociedad de roles que colaboran para proporcionar un comportamiento colaborativo mayor que la suma de los comportamientos de sus elementos.
Cuarto: un caso de uso es una descripción de secuencia de acciones que un sistema ejecuta y que da resultado observable de interés para un actor particular.
Quinto: una clase activa es una clase en la cual sus objetos tienen uno o mas procesos de ejecución y por lo tanto pueden dar origen a actividades de control.
Sexto: un componente es una parte física y reemplazable de un sistema que conforma Un conjunto de interfaces y proporciona la implementación de dicho conjunto. se representa como un rectángulo con pestañas, incluyendo normalmente su nombre.
Séptimo: un nodo es un elemento físico que existe en tiempo de ejecución y representa un recurso computacional, dispone de algo de memoria y capacidad de procesamiento. Este se representa como un cubo incluyendo solo su nombre.

Elementos de comportamiento

Primero: una interfaz es un comportamiento que comprende un conjunto de mensajes intercambios entre un conjunto de objetos, dentro de una conexión particular.
Segundo: una maquina de estados es un comportamiento que especifica la secuencia de estados por la que pasa un objeto o una interacción durante su vida en respuestas y reacciones a eventos.
Elementos de agrupación: son las partes organizativas de los modelos de UML. Son las cajas en las que puede descomponerse un modelo. Un paquete es un mecanismo de propósito general para organizar elementos en grupos.

Elementos de notación: son las partes explicativas de los modelos UMML. Comentarios que se pueden aplicar sobre cualquier elemento de un modelo. Hay un tipo principal de elementos de anotación llamados nota.

Relaciones en UML
Hay cuatro tipos de relaciones en UML
1. Dependencia
2. Asociación
3. Generalización
4. Realización

Estas relaciones se utilizan para escribir modelos bien formados:

Primero: una dependencia en una relación semántica entre los elementos en el cual un elemento puede afectar a la semántica de otro elemento. Se representa con una línea discontinua.
Segundo: una asociación es una relación estructural que describe un conjunto de enlaces, las cuales son conexiones entre objetos. Se representa con una línea continua
Tercero: una generalización es una realización de especialización en los cuales los objetos de los elementos especializados pueden reemplazar a los objetos del elemento general.
Cuarto: una realización es una realización semántica entre clasificadores, donde un clasificador especifica un contrato que otro clasificador garantiza que cumplira.

Diagramas en UML
es la representación grafica de un conjunto de elementos, un diagrama es la representación de un sistema.

UML incluye nueve diagramas:
1. Diagrama de clases
2. Diagrama de objetos
3. Diagrama de casos de uso
4. Diagrama de secuencia
5. Diagrama de colaboración
6. Diagrama de estados (Statechart)
7. Diagrama de actividades
8. Diagrama de componentes
9. Diagrama de despliegue

CICLO DE VIDA DEL DESARROLLO DE SOFTWARE
Para obtener el máximo beneficio de UML se debería considerar un proceso que fuese:
· Dirigidos por los casos de uso
· Centrado en la arquitectura
· Iterativo e incremental

BREVE RESUMEN DE UML
El Lenguaje Unificado de Modelado (UML) Es un lenguaje de modelado visual que se usa para especificar, visualizar, construir y documentar artefactos de un sistema de software. Es el que reúne decisiones y conocimientos sobre los sistemas que se deben construir.

HISTORIA DE UML
LOS METODOS DE DESARROLLO ORIENTADO A OBJETOS

Fue desarrollado para simplificar consolidar el gran número de métodos de desarrollo a objetos que habían surgido. Emergieron en los anos 70 y llegaron a ser ampliamente difundidos en los 80. el primer lenguaje que es generalmente reconocido como orientado a objetos es Simula 67 desarrollado en 1967.

OBJETIVOS DEL UML:
UML es un lenguaje de modelado de propósito general que pueden usar todos los modeladores.
UML pretende trabajar correctamente con todos los procesos desarrollo existente.
UML es tan simple como fuera posible pero manteniendo la capacidad de modelar toda gama de sistemas que se necesita construir

AREAS CONCEPTUALES DE UML
· Estructura estática
· Comportamiento dinámico
· Construcción de implementación
· Organización del modelo
· Mecanismo de extensión



CAPITULO 2
CONCEPTOS DE UML

CLASES Y OBJETOS
Una clase es un descriptor de objetos que compartes los mismos atributos, operaciones, métodos, relaciones y comportamiento. Un objeto es el valor de una variable debe tener una clase compatible para el tipo de esta variable, es decir, debe ser de la misma clase.

DIAGRAMA DE UML

Es una presentación grafica de un conjunto de elementos que la mayoría de veces se dibuja como nodos o elementos y arcos o relaciones el cual nos sirve para visualizar un sistema desde diferentes perspectivas. Clases de diagramas:

· Diagrama de clases
· Diagrama de objetos
· Diagrama de casos de uso
· Diagrama de secuencia
· Diagrama de colaboración
· Diagrama de estados (Statechart)
· Diagrama de actividades
· Diagrama de componentes
· Diagrama de despliegue

DIAGRAMAS ESTRUCTURALES

· Diagrama de clase: representa un conjunto de clases, interfaces y colaboraciones y relación
entre ellas.
· Diagrama de objetos: conjunto de objetos y sus relaciones.
· Diagrama de componentes: conjunto de componentes y sus relaciones.
· Diagrama de despliegue: conjunto de nodos y sus relaciones.

DIAGRAMAS DE COMPORTAMIENTO

· Diagrama de casos de uso: representa un conjunto de casos de uso, actores y sus relaciones.
· Diagrama de secuencia: es un diagrama de interacción que reslata la ordenación temporal de los mensajes.
· Diagrama de colaboración: es un diagrama de interacción que resalta la organización estructural de los objetos que envían y reciben mensajes.
· Diagrama de estados: representa una máquina de estados constituida por estados, transiciones, eventos y actividades
· Diagrama de actividades: muestra el flujo de actividades de un sistema.

VISTAS DE UML
Es un subconjunto que modela un sistema que representa un aspecto de un sistema, las vistas se pueden dividir en tres áreas: clasificación estructural, comportamiento dinámico y gestión del modelo.

VISTA ESTATICA
Modela los conceptos del dominio de la aplicación así como los conceptos inventados como parte de la implementación, describe del sistema dependiente del tiempo que se describe en otras vistas. Las clases se dibujan como rectángulos, los atributos y operaciones se muestran por separado y las relaciones se muestran como líneas y se conectan a los rectángulos.

VISTAS DE CASOS DE USO
Modela la funcionalidad del sistema según actúen los usuarios externos llamados actores, es una unidad coherente expresada como transacción expresada entre los actores y el sistema.

VISTAS DE INTERACCION
Describe secuencias de intercambio de mensajes entre los roles que implementan el comportamiento del sistema el cual es el que desempeña un papel dentro de una interacción de los objetos iguales.

VISTA DE LA MAQUINA DE ESTADOS
Esta formado por un conjunto de estados y cada uno de ellos modela un periodo de tiempo durante la vida de un objeto que satisface algunas condiciones

VISTA DE ACTIVIDADES
Es una variante de una maquina de estados que muestra las actividades de una ejecución de un cálculo.

VISTA DE IMPLEMENTACION
Modelan los conceptos de la aplicación desde un punto de vista lógica esta vista es una vista física, proporciona una oportunidad de establecer correspondencia entre las clases y los componentes de implementación y nodos.

VISTA DE GESTION DEL MODELO
Modela la organización del modelo en si mismo. Abarca el conjunto de paquetes que contienen los elementos del modelo, tales como clases, maquinas de estados, casos de usos.

RELACIONES:
DEPENDENCIA
Es una relación de uso que declara que un cambio en la especificación de un elemento puede afectar a otro que lo utilice. Se representa con una línea discontinua.
Estas se utilizan cuando se quiere indicar que un elemento utiliza al otro.

GENERALIZACION
Es una relación entre un elemento general y un caso más específico de ese elemento, la generalización significa que los objetos hijo se pueden emplear en cualquier lugar donde pueda aparecer el padre pero no a la inversa. Se representa como una línea dirigida continua apuntando al padre.

ASOCIACION
Es una relación estructural que especifica que los objetos de un elemento están conectados con los objetos de otro. Se representa como una línea continua que conecta la misma o diferentes clases.

CAPITULO 3
CASOS DE USO

TERMINOS Y CONCEPTOS
En el caso de uso es una descripción de secuencias de acciones, incluyendo variantes, que se ejecuta mediante un sistema para obtener un valor de actor.

NOMBRES
Cada caso de uso debe tener su propio nombre para que se distinga de otros casos de uso. El nombre conocido como nombre simple es una cadena de texto.

CASOS DE USO Y ACTORES
El actor representa una interacción individual con el sistema de una forma específica, aunque se utilizan actores en los modelos, estos no forman parte del sistema.

CASOS DE USO Y FLUJO DE EVENTOS
El caso de uso describe un flujo de eventos de forma textual, cuando describimos el flujo de eventos se debe incluir como y cuando empieza y acaba el caso de uso.
El flujo de eventos se puede especificar de muchas formas, incluyendo texto estructurado informal, texto estructurado formal y pseudocódigo.

CASOS DE USO Y ESCENARIOS
El caso de uso describe un conjunto de secuencias, donde cada secuencia representa un posible flujo a través de todas las variaciones. Cada secuencia se denomina escenario ya que el escenario es una secuencia específica de acciones que ilustra un comportamiento.

CASOS DE USO Y COLABORACIONES
El caso de uso captura el comportamiento esperado del sistema que se esta desarrollando, sin tener que especificar como se implementa ese comportamiento. La sociedad donde se desarrolla esto debe incluir tanto una estructura estática como dinámica, se modela en UML como una colaboración.

ORGANIZACIÓN DE CASOS DE USO
Se pueden agrupar en paquetes.
Se pueden organizar especificando relaciones de generalización, inclusión u extensión entre ellos.
Estas relaciones se utilizan para factorizar el comportamiento común y para factorizar variantes.

OTRAS CARACTERISTICAS
Los casos de uso también son clasificadores, de forma que pueden tener operaciones y atributos que se pueden representar igual que en las clases.
Estos objetos y operaciones pueden utilizarse en los diagramas de interacción para especificar el comportamiento del caso de uso.

PROPIEDADES COMUNES
El caso de uso es un tipo especial de diagrama y comparte las propiedades comunes al resto de los diagramas es por eso que se distingue por su contenido particular.

CONTENIDOS
· Casos de uso
· Actores
· Relaciones de dependencia, generalización y asociación.
Los diagramas de los caso también pueden contener paquetes.

USOS COMUNES
1. Para modelar el contexto de un sistema: implica dibujar una línea alrededor de todo es sistema y asegurar que actores queden fuera del sistema e interactúan con el.

2. Para modelar los requisitos de un sistema: implica especificar que debería hacer el sistema (desde un punto de vista externo), independientemente cómo se haga.

OBJETIVOS DEL USUARIO E INTERACCIONES CON EL SISTEMA
Los verdaderos objetivos del usuario se describirían con términos como garantizar el formateo consistente de un documento y hacer que el formateo de un documento sea igual al otro.
Esta dicotomía entre objetivo del usuario e interacción con ele sistema no se presenta en todas las situaciones.

CUANDO EMPLEAR CASOS DE USO
La captura de los casos de uso es una de las tareas que primero se debe realizar ya que son una herramienta esencial en la captura de requerimientos, planificación, o de control de proyectos interactivos.

MODELADO DE CASOS DE USO
Se debe aplicar en tres razones:

MODELADO DE UN COMPORTAMIENTO DE UN ELEMENTO
La mayoría de veces, se utilizan para el modelado del comportamiento de un elemento, ya sea un sistema completo, un subsistema o una clase, debemos centrarnos en lo que hace ele elemento y no en como lo hace.
Para modelar el comportamiento de un elemento debemos tener en cuenta lo siguiente:
· Hay que identificar los actores que interactúan con el elemento.
· Hay que organizar los actores identificando tanto los roles más generales como los más especializados.
· Hay que considerar las formas más importantes que tiene cada actor de interactuar con ele elemento.
· Hay que considerar las formas excepcionales en las que cada actor puede interactuar con el elemento.
· Hay que organizar estos comportamientos como casos de uso.

MODELADO DEL CONTEXTO DE UN SISTEMA
En UML se puede modelar el contexto de un sistema con un diagrama de casos de uso, destacando los actores en torno ala sistema.
Para modelar el contexto de un sistema debemos tener en cuenta lo siguiente:
· Hay que identificar los actores en torno al sistema, considerando que grupos requieren ayuda del sistema para llevar a cabo sus tareas.
· Hay que organizar los actores similares en jerarquías de generalización/especialización.
· Hay que proporcionar un estereotipo para cada uno de estos actores.
· Hay que introducir estos actores en un diagrama de uso.
· Hay que especificar las vías de comunicación de cada actor con los casos de uso del sistema.

MODELADO DE LOS REQUISITOS DE UN SISTEMA
Un requisito es una característica de diseño, una propiedad o un comportamiento de un sistema cuando se habla de esto se esta estableciendo un contrato entre los elementos externos al sistema y el propio sistema.
Para modelar los requisitos de un sistema debemos tener en cuenta lo siguiente:
· Hay que establecer el contexto del sistema.
· Hay que considerar el comportamiento que cada actor espera del sistema.
· Hay que nombrar esos comportamientos comunes como casos de uso.
· Hay que factorizar el comportamiento común en nuevos casos de uso para que lo usen los demás.
· Hay que modelar esos casos de uso.
· Hay que adornar esos casos de uso con notas que enuncien los requisitos no funcionales.
Esta misma técnica se utiliza para el modelado de los requisitos de un subsistema.

INGENIERIA DIRECTA O 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 implementación.
Para hacer ingeniería directa con un diagrama de casos de uso se debe tener en cuenta:
· Hay que identificar el flujo de eventos de cada caso de uso.
· Hay que generar un guión de prueba para cada flujo si se desea profundizar con las pruebas.
· Hay que generar una estructura de pruebas para representar cada actor que interactúan en el caso de uso si es necesario.
· Hay que usar herramientas que ejecuten estas pruebas cada vez que se genera una nueva versión.
La ingeniería inversa es el proceso 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 casos de uso mediante ingeniería inversa debemos tener en cuenta:
· Hay que identificar cada actor que interactúa con ele sistema.
· Hay que considerar la forma en que cada actor interactué con el sistema.
· Hay que trazar el flujo de eventos del sistema ejecutable en relación a cada actor.
· Hay que los flujos relacionados declarando el correspondiente caso de uso.
· Hay que representar esos actores y casos de uso en un diagrama de casos de uso y establecer sus relaciones.