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.
