UNIDAD III

Modelo de Análisis

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.

3.1 Arquitectura de Clases

El modelo de análisis tiene como objetivo generar una arquitectura de objetos que sirva como base para el diseño posterior del sistema. Como se discutió en la introducción del libro, dependiendo del tipo de aplicación existen diversas arquitecturas que se pueden utilizar, siendo de nuestro interés aquellas arquitecturas especialmente diseñadas para el manejo de los sistemas de información, las cuales involucran ricas interfaces de usuario y accesos a base de datos como aspectos fundamentales de la arquitectura.

En término de las propias arquitecturas, éstas se distinguen según la organización de la funcionalidad que ofrecen los objetos dentro de ellas o la dimensión de los objetos. Esta dimensión corresponde a los diferentes tipos de funcionalidad que manejan los objetos dentro la arquitectura. Por ejemplo, en el caso de funcionalidad para el manejo de interfaces y base de datos, si existen tipos distintos de objetos para el manejo de cada una de estas por separado, entonces se considera que la arquitectura es de dos dimensiones. Por el contrario, si todos los objetos manejan de manera indistinta los dos tipos de funcionalidades, entonces se considera que la arquitectura es de una sola dimensión.

Aunque estas dimensiones no son del todo ortogonales, si son lo suficientemente independientes se puede limitar el efecto de posibles cambios. En relación al número de dimensiones, esto depende de la funcionalidad que la arquitectura debe manejar, algo que a su vez depende del tipo de aplicación que se está desarrollando.

En el caso de los sistemas de información, uno de las tipos de arquitecturas más importantes es la arquitectura MVC – Modelo, Vista, Control (Model, View, Control) popularizada por los ambientes de desarrollo de Smalltalk. Esta arquitectura se basa en tres dimensiones principales: Modelo (información), Vista (presentación) y Control (comportamiento).

Diagrama de tres dimensiones correspondiente a la arquitectura MVC – Modelo, Vista, Control.

La vista o presentación de la información corresponde a las interfaces que se le presentan al usuario para el manejo de la información, pueden existir múltiples vistas sobre un mismo modelo.

Por otro lado el control corresponde a la manipulación de la información a través de sus diversas presentaciones. Aunque existe cierta dependencia entre estas tres dimensiones se considera que la manera de presentar la información es independiente de la propia información y de cómo esta se controla.

En el modelo de análisis descrito aquí utilizaremos como base la arquitectura MVC para capturar estos tres aspectos de la funcionalidad.

Es importante notar la correspondencia con las tres dimensiones utilizadas durante el modelo de requisitos. La razón de ser de las tres dimensiones del modelo de requisitos realmente se deriva para lograr una rastreabilidad con la arquitectura que se desarrollará en el modelo de análisis.

Diagrama de tres dimensiones correspondiente a la arquitectura del modelo de análisis basado en el modelo de casos de uso.

 

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

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. 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 presentación comprensible 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.

Estrategia correspondiente a los actores: Cada actor necesita su propia clase borde para comunicarse con el sistema. En muchos casos un actor puede necesitar de varios objetos borde.

ENTIDAD

Utilizan objetos entidad para modelar la información que el sistema debe manejar a corto y largo plazo. 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.

La identificación de objeto entidad, se encontrara 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.

 

 

3.3 Clases

Una clase orientado a objetos encapsula atributos de los datos pero también incorpora las operaciones que manipulan los datos implicados por dichos atributos.

Las clases se manifiestan de la siguiente forma:

Entidades: Externos sucesos o eventos, cosas, papeles, unidades organizacionales, sitios y estructuras

Modelo CRC (Clase-Responsabilidad-Colaborador)

El modelo de Clase-Responsabilidad-Colaborador (CRC) proporciona un medio siempre ara identificar y organizar las clases relevantes para los requisitos del sistema o producto. Un modelo CRC es una colección de tarjetas índices estándares que representan clases el objeto es describir una presentación organizada de las clases.

Las clases tienen diferentes categorías

·         Clase de Entidad: Llamadas clases de modelos o negocios se extraen de manera directa del enunciado del problema

·         Clase de Frontera: Se utiliza para crear la interfaz que el usuario ve y con la cual interactúa cuando se utiliza el software

·         Clase de Controlador: Maneja una “unidad de trabajo” desde el inicio hasta el final

·         Responsabilidad: Son los atributos y las operaciones relevantes para la clase

·         Colaboradores: Son aquellos que se requieren para que una clase reciba la información necesaria para completar una responsabilidad

·         Agregación: Son las subclases que forman parte de una clase, se conecta a través de una relación de tipo estandarte de Modelo de Comportamiento; diagrama de estado y diagrama de secuencia.

3.4 Diagrama de 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.

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.

3.5 Diccionario de Clases de Modelo

Como última etapa del modelo de análisis se actualiza el diccionario de datos originalmente descrito para el dominio del problema para incluir (análisis) todas las clases identificadas durante el modelo que análisis separamos estas clases en diferentes modelos para lograr una mejor correspondencia entre clases y casos de uso. Aquellas clases que se participan en varios casos de usos.

MODELOS O PAQUETES PRINCIPALES

·         Interface Usuario

·         Principal

·         Registros

·         Servicios

Interface Usuario: Modulo compuesto por una clase utilizada para el manejo general de las interfaces de usuario

Interface Usuario: Clase Borde, toda la interacción con el usuario se hace por medio del borde de usuario

Principal: Está compuesto por clases comunes a la funcionalidad general del sistema: Pantalla principal- Clase borde, Manejado principal- Clase control

Registro: El modulo registros se divide en los siguientes módulos

Usuario: Pantalla Crear, Registro Usuario, Pantalla Obtener Registro Tarjeta, Registro Tarjeta y Manejador Registro con la base de datos interface Base Datos Registro donde BD corresponde a la base de datos

3.6 Herramientas Case para el Análisis

Las herramientas case (Ingeniero de Software asistida por ordenador). Son diversas aplicaciones informáticos destinados a aumentar la productividad en el desarrollo de software reduciendo el coste de las mismas en términos de tiempo y dinero.

Estas herramientas es de gran ayuda en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseño del proyecto cálculo de costes, implementación de parte del código automáticamente con el diseño dado compilación automática documentación o detención de errores entre otras.

En un sistema de software que ayuda al automatizar a las actividades del proceso de software

Para su clasificación considera los siguientes parámetros

·         Las plataformas que soportan

·         Las fases del ciclo de vida del desarrollo de sistemas que cubren

·         La arquitectura de las aplicaciones que producen su funcionalidad

CLASIFICACIÓN

·         UPPER CASE (U-CASE) Ayuda en las fases de planificación, análisis de requisitos y estrategia de desarrollo, usando entre otros diagramas UML.

·         MIDDLE CASE (M-CASE) Herramienta para utilizar tareas en el análisis y diseño de la aplicación.

·         LOWER CASE (L-CASE) Semi-automatizan la generación de código crean programas de detención de errores, soportan la depuración de programas y pruebas. Además automatizan la documentación completa de la aplicación.