UNIDAD 3 MODELO DE ANALISIS

UNIDAD 3

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 sóla dimensión. Si aplicamos el concepto de dimensión a los métodos estructurados, podemos ver que estos consisten de dos dimensiones, correspondientes a funciones y datos. Las funciones representan un eje de comportamiento que no guarda información, mientras que los datos se ubican en un eje de información que no contiene comportamiento. En general, ejes de funcionalidad pueden corresponder a distintos tipos de funcionalidades, como se ve al contrastar funciones y datos versus manejo de interfaces y bases de datos. Sin embargo, la pregunta más importante que uno se hace respecto al número y tipo de dimensiones es: ¿Si se diseña un sistema con múltiples dimensiones, se obtendría un sistema más robusto y sensible a modificaciones? Ante todo esta pregunta se relaciona con el concepto de modularidad, siendo muy aceptado que cuanto mayor sea la modularidad de un sistema mayor es su robustez y extensibilidad. La respuesta particular a la pregunta tiene que ver con qué tan independiente sea un eje de funcionalidad del otro, ya que en el caso de los métodos estructurados, usualmente se debe modificar las funciones cada vez que se modifica la estructura de información, lo cual no es algo deseable. Si logramos ejes de funcionalidad ortogonales, el efecto de cambios en una dimensión no debe afectar a las otras dimensiones. Y 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 arquitectua 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)

 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.

Considerando que habría interacción entre los diferentes tipos de objetos, existiría cierto traslape en la funcionalidad que los objetos ofrecen. como se menciono anteriormente, este traslape deberá minimizarse para asegurar una buena extensibilidad, donde típicamente, cada tipo de objeto captura por lo menos dos de las tres dimensiones. sin embargo, cada uno de ellos tiene cierta inclinación hacia una de estas dos dimensiones.

3.3 clases

Una clase es una construcción que se utiliza como un modelo (o plantilla) para crear objetos de ese tipo. El modelo describe el estado y el comportamiento que todos los objetos de la clase comparten. Un objeto de una determinada clase se denomina una instancia de la clase. La clase que contiene (y se utilizó para crear) esa instancia se puede considerar como del tipo de ese objeto. Por ejemplo, una instancia del objeto de la clase "Persona" sería del tipo "Persona".

Una clase por lo general representa un sustantivo, como una persona, lugar o (posiblemente bastante abstracta) cosa - es el modelo de un concepto dentro de un programa de computadora. Fundamentalmente, encapsula el estado y el comportamiento del concepto que representa. Encapsula el estado a través de marcadores de datos llamados atributos (o variable miembro o variables de instancia), y encapsula el comportamiento a través de secciones de código reutilizables llamados métodos.

Más técnicamente, una clase es un conjunto coherente que consiste en un tipo particular de metadatos. Una clase tiene una interfaz y una estructura. La interfaz describe cómo interactuar con la clase y sus instancias con métodos, mientras que la estructura describe cómo los datos se dividen en atributos dentro de una instancia. 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. En el diseño orientado a objetos, una clase es el tipo más específico de un objeto en relación con una capa específica.

Los lenguajes de programación que soportan clases difieren sutilmente en su soporte para diversas características relacionadas con clases. La mayoría soportan diversas formas de herencia. Muchos lenguajes también soportan características para proporcionar encapsulación, como especificadores de acceso.

3.4  Diagramas de secuencias

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"

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

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. Esta para atrás

3.5 Diccionario de clases según módulos

·         Como última etapa del modelo de análisis, se actualiza el diccionario de clases organizada según módulos, para incluir todas las clases identificadas durante el modelo de análisis.

·         Las clases se separan en diferentes módulos con el fin de lograr una mejor organización y correspondencia entre clases y casos de uso.

·         Aquellas clases que participan en varios casos de uso se pueden asignar a módulos adicionales

MODULOS O PAQUETES PRINCIPALES

InterfaceUsuario

Principal

Registros

Servicios

InterfaceUsuario

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

InterfaceUsuario: Clase Borde. Toda la interacción con el usuario se hace por medio del borde deusuario.

Principal

Está compuesto por clases comunes a la funcionalidad general del sistema:

PantallaPrincipal- Clase Borde

ManejadorPrincipal- Clase Control

Registro

El modulo registro se divide en los siguientes módulos:

Usuario: PantallaCrearRegistroUsuario, PantallaObtenerRegUsuario, RegistroUsuario yManejadorRegistroUsuario.

Tarjeta: PantallaCrearRegTarjeta, PantallaObtenerRegTarjeta, RegistroTarjeta y ManejadorRegistroTarjeta.

InterfaceBD: Está compuesto por la clase encargada de interactuar con la base de datos. InterfaceBaseDatosRegistro.Donde BD corresponde a la base de datos.

Servicios

Se divide en los siguientes módulos (MODULOS ADICIONALES):

DOMINIO: Vuelo, reservación, horario, aerolínea, aeropuerto, tarifa, asiento, pasajero, avión y viajeroFrecuente.

INTERFACEBD: incluye una clase para el acceso a la base de datos.InterfaceBaseDatosReserva.

CONSULTAS: PantallasConsultas, ManejajadorConsultas.

HORARIOS: PantallaConsultaHorarios, PantallaResultadoHorarios yManejadorConsultaHorarios.

 TARIFAS: PantallaConsultaTarifas, PantallaResultadoTarifas yManejadorConsultaTarifas.

 ESTADO: PantallaConsultaEstado, PantallaResultadoEstado yManejadorConsultaEstado

PAGOS: PantallaPagarRegTarjeta, PantallaReembolsarRegTarjeta y ManejadorPagos.

3.6. Herramientas CASE para el análisis

Las herramientas CASE (Computer Aided Software Engineering,Ingeniería de Software Asistida por Computadora) son diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el costo de las mismas en términos de tiempo y de dinero. Estas herramientas pueden ayudar en 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 costos,

·         Implementación de parte del código automáticamente con el diseño dado,

·         Compilación automática,

·         Documentación o detección de errores entre otras.

OBJETIVOS

·         Mejorar la productividad en el desarrollo y mantenimiento del software.

·         Aumentar la calidad del software.

·         Reducir el tiempo y costo de desarrollo y mantenimiento de los sistemas informáticos.

·         Mejorar la planificación de un proyecto

·         Aumentar la biblioteca de conocimiento informático de una empresa ayudando a la búsqueda de soluciones para los requisitos.

·         Automatizar el desarrollo del software, la documentación, la generación de código, las pruebas de errores y la gestión del proyecto.

·         Ayuda a la reutilización del software, portabilidad y estandarización de la documentación

·         Gestión global en todas las fases de desarrollo de software con una misma herramienta.

·         Facilitar el uso de las distintas metodologías propias de la ingeniería del software.