UNIDAD 3: MODELO DE ANÁLISIS

El objetivo  del modelo de análisis es comprender y generar una arquitectura de objetos para el sistema con base a lo especificado en el modelo de requisitos.

En él no se considera el ambiente de implementación y se modela al sistema bajo sus condiciones ideales, el modelo de análisis  es una representación conceptual  correspondiente al problema y al modelo  de requisitos, en términos de clases de objetos.

El modelo de análisis es la primera representación técnica de un sistema. Utiliza una mezcla de formatos en texto y diagramas para representar los requisitos del software, las funciones y el comportamiento. De esta manera se hace mucho más fácil de comprender dicha representación, ya que es posible examinar los requisitos desde diferentes puntos de vista aumentando la probabilidad de encontrar errores, de que surjan debilidades y de que se descubran descuidos.

Análisis de requisitos
    El análisis de requisitos le proporciona al diseñador de software una representación de datos, función y comportamiento que puede trasladar a diseños arquitectónicos de interfaz. Este, junto al modelo de análisis, ofrece al desarrollador y al cliente los medios para evaluar la calidad una vez construido el software.

Objetivos generales del modelo de análisis
El modelo de análisis debe cumplir tres objetivos primarios:
1.    Describir los que requiere el cliente
2.    Establecer una base para la creación de un diseño de software
3.    Definir un conjunto de requisitos que pueda validarse una vez construido el software.

ELEMENTOS DEL MODELO DE ANÁLISIS

El modelo de análisis se complementa de cuatro elementos fundamentales. Estos elementos sirven para clasificar principalmente los diferentes diagramas y otros derivados conocidos en plataformas como sistemas de información e ingeniería de software entre otros. Además estos con clasificados en elementos de escenario, elementos de flujo, elementos de clases y elementos de comportamiento.

3.1 ARQUITECTURA DE CLASES

El objetivo del modelo de análisis es crear una arquitectura de objetos que sirva como base para el diseño del sistema.

Dependiendo del tipo de aplicación existen varias arquitecturas. Ellas se distinguen  según la organización de los objetos de acuerdo a su funcionalidad. Esto es llamado dimensión de arquitectura.

Dimensión de la arquitectura

• Unidimensional: un solo grupo de objetos para manejar la funcionalidad y la interacción externa.
• Bidimensional: un grupo de objetos para manejar la funcionalidad y otros para las interacciones externas.
• Tridimensional: La más usada en los sistemas de información que siendo el Modelo-Vista-Control.

Arquitectura Modelo-Vista-Control

Es un patrón de arquitectura de software que separa los datos  de una aplicación, la interfaz del usuario y la lógica de negocio en tres componentes distintos. El modelo es el sistema de gestión de base de datos y la lógica de negocio y el controlador es el responsable de recibir los eventos de entrada desde la vista.

• Modelo .-   Correspondiente a la información
• Vista.-  Correspondiente a la presentación o interacción con el usuario
• Control  .- Correspondiente al comportamiento 

Diagrama de clases
Está compuesto por los siguientes elementos:
Clase: atributos, métodos y visibilidad.

Relaciones: Herencia, Composición, Agregación, Asociación y Uso.

En una aproximación a un Caso de Uso guiado hacia el análisis orientado a objetos, el diagrama de clases se desarrolla a través de información obtenida en los Casos de Uso.Los objetos encontrados durante el análisis son modelados en términos de la clase a la que instancian, y las interacciones entre objetos son referenciados a relaciones entre las clases instanciadas.

3.2 IDENTIFICACIÓN DE CLASES SEGÚN ESTEREOTIPOS

Para llevar a cabo la transición del modelo de requisitos al modelo de análisis se deben identificar los objetos necesarios para implementar todos los casos de uso. La arquitectura de objetos debe considerar los tres tipos de estereotipos de objetos. Para ello se deben identificar primero las clases borde, las clases entidad y finalmente las de Control.
En general, los cambios más comunes a un sistema son los de funcionalidad y bordes. Los cambios de las interfaces deben afectar solo  a los objetos borde.
Los cambios a la funcionalidad son más difíciles de administrar, ya que ésta puede abarcar todos los tipos de objetos.

BORDES:
Toda la funcionalidad especificada en las descripciones de los casos de uso que depende directamente de los aspectos externos del sistema, se ubica en los objetos borde, pues a traves de ellso se comunican los actores con el sistema. La tarea de una clase borde es traducir los eventos generados por un actor en eventos comprendidos por el sistema, y traducir los eventos del sistema en una presentacion comperensible para el actor.
Las clases borde en otras palabras , describen la comunicación bidireccional entre el sistema y los actores.
Las clases borde son bastante fáciles de identificar, donde se cuenta con al menos tres estrategias:
1.       Se pueden identificar con base a los actores.
2.       Se pueden identificar con base en las descripciones de las interfaces del sistema que acompañan al modelo de requisitos.
3.       Se pueden identificar con base en las descripciones de los casos de uso y extraer la funcionalidad específica a los objetos bordes.

Entidad
Se utilizan objetos entidad para modelar la información que el sistema debe manejar a corto y largo plazo. La información a corto plazo existe durante la ejecución de un caso de uso, mientras que la información a largo plazo trasciende los caso de uso, por lo que es necesario guardarla en alguna base de datos o archivos.
Durante la identificación de objeto entidad, se encontrar que objetos similares aparecen en varios casos de uso.

Control
En la mayoría de los casos de uso, existe un comportamiento que no se puede asignar de forma natural a ninguno de los otros dos tipos de objetos ya vistos. Una posibilidad es repartir el comportamiento entre los dos tipos de objetos, pero la solución no es buena si se considera el aspecto de extensibilidad. Un cambio en el comportamiento podría afectar varios objetos, dificultando su modificación. Para evitar estos problemas, tal comportamiento se asigna a objetos control.
Es difícil lograr un buen balance en la distribución del comportamiento del caso de uso entre los objetos entidad, borde y control. Los objetos de control normalmente proveen la administración de los demás tipos de objetos.

3.3 -CLASES

Las clases son declaraciones o abstracciones de objetos, lo que significa, que una clase es la definición de un objeto. Cuando se programa un objeto y se definen sus características y funcionalidades, realmente se programa una clase.

Las clases son lo más simple de Java. Todo en Java forma parte de una clase, es una clase o describe cómo funciona una clase. El conocimiento de las clases es fundamental para poder entender los programas Java.

Todas las acciones de los programas Java se colocan dentro del bloque de una clase o un objeto. Todos los métodos se definen dentro del bloque de la clase, Java no soporta funciones o variables globales. Esto puede despistar a los programadores de C++, que pueden definir métodos fuera del bloque de la clase, pero esta posibilidad es más un intento de no separarse mucho y ser compatible con C, que un buen diseño orientado a objetos. Así pues, el esqueleto de cualquier aplicación Java se basa en la definición de una clase.

Todos los datos básicos, como los enteros, se deben declarar en las clases antes de hacer uso de ellos. En C la unidad fundamental son los ficheros con código fuente, en Java son las clases. De hecho son pocas las sentencias que se pueden colocar fuera del bloque de una clase. La palabra clave import (equivalente al #include) puede colocarse al principio de un fichero, fuera del bloque de la clase. Sin embargo, el compilador reemplazará esa sentencia con el contenido del fichero que se indique, que consistirá, como es de suponer, en más clases

Una clase es un contenedor de uno o más datos (variables o propiedades miembro) junto a las operaciones de manipulación de dichos datos (funciones/métodos). Las clases pueden definirse como estructuras (struct), uniones (union) o clases (class) pudiendo existir diferencias entre cada una de las definiciones según el lenguaje. Además las clases son agrupaciones de objetos que describen su comportamiento.

Una clase también puede tener una representación (metaobjeto) en tiempo de ejecución, que proporciona apoyo en tiempo de ejecución para la manipulación de los metadatos relacionados con la clase.Una clase es un concepto  que encapsulalas abstracciones de datos y procedimientos que se requieren para describir el contenido y comportamiento de alguna entidad del mundo real.Por definición, todos los objetos que existen dentro de una clase heredan sus atributos y las operaciones disponibles para la manipulación de los atributos;

- Una superclase es una colección de clases.

- Un subclase esuna instancia de una clase.

Estas definiciones implican la existencia de una jerarquía de clases en la cual los atributos y operaciones de la superclase son heredados por subclases que pueden añadir, cada una de ellas, atributos «privados» y métodos.

Los métodos son el equivalente a las funciones en programación estructurada. 

3.4 - DIAGRAMA DE SECUENCIA

El diagrama de secuencia es un tipo de diagrama usado para modelar interacción entre objetos en un sistema según UML. En inglés se pueden encontrar como "sequence diagram", "event-trace diagrams", "event scenarios" o "timing diagrams".

Utilidad

Un diagrama de utilidad o secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. Mientras que el diagrama de casos de uso permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario y mensajes intercambiados entre los objetos.

Típicamente se examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si se dispone de la descripción de cada caso de uso como una secuencia de varios pasos, entonces se puede "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales.

Características:

Los objetos se comunican mediante interfaces, para poder invocar a un operación.

El diagrama de secuencias proporciona un camino a partir de los escenarios para describir las operaciones en una forma más detallada.

En los Casos de Uso se modelan las características del sistema y se desarrollan escenarios.

Tipos de mensajes:

Existen dos tipos de mensajes: sincrónicos y asincrónicos. Los mensajes sincrónicos se corresponden con llamadas a métodos del objeto que recibe el mensaje. El objeto que envía el mensaje queda bloqueado hasta que termina la llamada. Este tipo de mensajes se representan con flechas con la cabeza llena. Los mensajes asincrónicos terminan inmediatamente, y crean un nuevo hilo de ejecución dentro de la secuencia. Se representan con flechas con la cabeza abierta.

También se representa la respuesta a un mensaje con una flecha discontinua.

Pueden ser usados en dos formas:

De instancia: describe un escenario específico (un escenario es una instancia de la ejecución de un caso de uso).

Genérico: describe la interacción para un caso de uso; Utiliza ramificaciones ("Branches"), condiciones y bucles.

Estructura

Los mensajes se dibujan cronológicamente desde la parte superior del diagrama a la parte inferior; la distribución horizontal de los objetos es arbitraria. Durante el análisis inicial, el modelador típicamente coloca el nombre 'business' de un mensaje en la línea del mensaje. Más tarde, durante el diseño, el nombre 'business' es reemplazado con el nombre del método que está siendo llamado por un objeto en el otro. El método llamado, o invocado, pertenece a la definición de la clase instanciada por el objeto en la recepción final del mensaje.

3.5 –DICCIONARIO DE CLASES SEGÚN MÓDULOS

Un diccionario de clases es un catálogo, un depósito, de los elementos en un sistema. Como su nombre lo sugiere, estos elementos se centran alrededor de los datos y la forma en que están estructurados para satisfacer los requerimientos de los usuarios y las necesidades de la organización. En un diccionario de datos se encuentra la lista de todos los elementos que forman parte del flujo de datos en todo el sistema. Los elementos más importantes son flujos de datos, almacenes de datos y procesos. El diccionario guarda los detalles y descripciones de todos estos elementos.

El diccionario se desarrolla durante el análisis de flujo de datos y auxilia a los analistas que participan en la determinación de los requerimientos de sistemas.

Importancia del diccionario

Los analistas utilizan los diccionarios de datos por cinco razones importantes:

1. Para manejar los detalles en sistemas grandes.

2. Para comunicar un significado común para todos los elementos del sistema.

3. Para documentar las características del sistema.

4. Para facilitar el análisis de los detalles con la finalidad de evaluar las características y determinar dónde efectuar cambios en el sistema.

5. Localizar errores y omisiones en el sistema.

Manejo de detalles

Los sistemas grandes tienen enormes volúmenes de datos que fluyen por ellos en forma de documentos, reportes e incluso pláticas. De manera similar, se llevan a cabo muchas actividades que utilizan los datos existentes o que generan nuevos detalles. Con franqueza, es imposible que los analistas recuerden todo. Los que tratan de hacerlo cometen de manera invariable equivocaciones u olvidan elementos importantes. Los mejores analistas no intentan recordarlo todo, en lugar de hacerlo registran toda la información. Algunos lo hacen sobre hojas de papel y otros quizá sobre tarjetas indexadas. Muchos emplean para tal fin un procesador de palabras y una computadora personal por supuesto. Los analistas mejor organizados y más eficaces utilizan diccionarios de datos automatizados diseñados de manera específica para el análisis y diseño de sistemas.

Comunicación de significados

Los diccionarios de datos proporcionan asistencia para asegurar significados comunes para los elementos y actividades del sistema. Si se examina una muestra de diagramas de flujo de datos para el procesamiento de pedidos, es probable que se tengan pocas dificultades para comprender qué datos representan a la factura y al cheque. Los dos son términos comunes en el mundo de los negocios y muchas personas conocen su significado. Los diccionarios de datos registran detalles adicionales relacionados con el flujo de datos en el sistema de tal forma que todas las personas participantes puedan localizar con rapidez la descripción de flujos de datos, almacenes de datos o procesos.

3.6 HERRAMIENTAS CASE PARA EL ANÁLISIS

El término CASE (computer-aided software engineering)significa “ingeniería de software asistida por computadora”, y abarca el uso de un método asistido por computadora para organizar y controlar el desarrollo de software, especialmente en proyectos grandes o complejos, que involucran muchos componentes de software y recursos humanos.

HERRAMIENTAS CASE PARA EL ANÁLISIS:
Permiten crear y modificar diagramas Entidad-Relación, de flujo de datos, de clases, etc. Son importantes también las herramientas de prototipado. Éstas incluyen diseñadores de formularios, de menúes, de informes, y lenguajes de especificación ejecutables.

CLASIFICACIÓN DE LAS HERRAMIENTAS CASE  PARA EL ANÁLISIS:

1-. GENERACIÓN DE CÓDIGO Y DOCUMENTACIÓN:
Generan código a partir de las especificaciones de diseño. Además, soportan la generación automatizada de documentación a partir de la información almacenada.

2-.HERRAMIENTAS DE PRUEBA:
En esta etapa se lleva a cabo la prueba de escritorio para verificar el resultado de dicho trabajo o problema.

3-.HERRAMIENTAS DE GESTIÓN DE LA CONFIGURACIÓN:
En este apartado  se lleva a cabo los requerimientos y posteriormente realizar la configuración o modificación del sistema.

4-. HERRAMIENTAS DE INGENIERÍA INVERSA

Ingeniería inversa de datos: Extraen información de código fuente y construye diagramas orientados a objetos o Entidad-Relación.
Ingeniería inversa de procesos.
Reestructuración de código fuente: Modifican el formato o implantan un formato estándar.
Re documentación: Permiten generar diagramas para mejorar la comprensión del código.
Análisis de código: Generan, por ejemplo, la indentación automática.

CLASES DE HERRAMIENTAS DE DISEÑO:
Sistemas de prototipos de investigación.
Herramientas CASE comerciales específicas.

Herramientas CASE generales. Permiten aislar la lógica de las entidades y las reglas del negocio a partir del código.