sábado, 29 de noviembre de 2014

4.6 HERRAMIENTAS CASE PARA EL DISEÑO

Herramientas CASE para el proceso de desarrollo de software son las Herramientas de bajo nivel,L-CASE  (Lower CASE -  CASE inferior) o back-end ,dirigidas a las ultimas fases del desarrollo: construccion e implantacion.                                           


Juegos de herramientas o toolkits , son el tipo mas simple de herramientas CASE. Automatizan una fase dentro del ciclo de vida. Dentro de este grupo se encontrarian las herramientas de reingenieria, orientadas a la fase de mantenimiento.

      Las herramientas CASE se han venido ampliando y desarrollando, existe una gran variedad de estas con caracteristicas especificas, a continuacion describiremos algunas de ellas, desde las mas actuales hasta otras ya no tanto. 
  •        Microsoft  Project
Microsoft  Project es un software de administracion de proyectos diseñado, desarrollado y comercializado por Microsoft para asistir a administradores de proyectos en el desarrollo de planes, asignacion de recursos a tareas, dar seguimiento al progreso, administrar presupuesto y analizar cargas de trabajo.

Permite el aprendizaje rapido con el planeamiento y la administracion guiados organización y seguimiento de las tareas y recursos, comprar versiones de planes de proyectos evaluar los cambios, realizar un seguimiento del rendimiento, generar informes predefinidos, compartir planes de proyecto, colaboracion entre grupos de trabajo, presenta diagramas como: Diagrama de Grant  y Diagrama de Pert (diagrama de red).

El Software Microsoft  Office Project  en todas sus versiones (la version 2007 es la mas reciente) es util para la gestion de proyectos, aplicando procedimientos descritos en el PMBoK (Management Body of Knowledge) del PMI (Project Management Institute).

La aplicación crea calendarizacion de rutas criticas, ademas de cadenas y metodologia de eventos en cadena disponibles como add-ons de terceros. Los calendarios pueden ser resourse leveled, y las graficcas visualizadas en una Grafica de Gantt. 
  •  Racional Rose
Rational Rose es una herramienta de produccion y comercializacion establecidas por Rational Software Corporation (actualmente parte de IBM). Rose es un instrumento operativo conjunto que utiliza el Lenguaje Unificado (UMI) como medio para facilitar la captura de dominio de la sematica, la arquitectura y el diseño.
Este software tiene la capacidad de:
·         Crear
·         Ver
·         Modificar
·         Manipular 

       Sus caracteristicas principales: 
  1.  No es gratuito, se debe hacer un previo pago para poder adquirir el producto.
  2. La ingenieria de codigo (directa e inversa) es posible para ANSI C++, Visual Basic 6, Java, J2EE/EJB, CORBA, Ada 83, Ada 95, Bases de datos:DB2, Oracle, SOL 92, SOL Server, Sybase, Aplicaciones WEB. 
  3. Solamente Ingenieria reversa para COM.
  4. Rational Rose habilita asistentes para crear clases y provee plantillas de codigo que pueden aumentar significativamente la cantidad de codigo fuente generado. Adicionalmente, se pueden aplicarmlos patrones de diseño, Racional Rose ha provisto 20 de los patrones de diseño  GOF para Java. 
  5.  Admite la integraacion con otras herramientas de desarrollo (IDEs). 
  • JDeveloper
Este magnifico entorno integrado desarrollado por Oracle trabaja con la ingenieria inversa, es decir primero se crea el codigo y despues el diagrama.

Es un software propietario pero gratuito desde 2005. Las primeras vesrsiones de 1998 estaban basadas en el entorno JBuilder de Borland, pero desde la version 9i de 2001 esta basado en Java, no estando ya relacionado con el codigo anterior de JBuilder.

viernes, 7 de noviembre de 2014

3.1 ARQUITECTURA DE CLASE

El modelo de análisis tiene como objetivo generar una arquitectura de objetos que sirva como base para el diseño del sistema. Dependiendo del tipo de aplicación existen diversas arquitecturas  que se pueden utilizar.

Las arquitecturas se distinguen según la organización de los objetos de acuerdo a su funcionalidad. Esto es también conocido como la dimensión de la arquitectura. Por ejemplo, si existe un grupo de objetos para el manejo de la funcionalidad de la aplicación y otro para interactuar con las entidades externas de la aplicación, como el usuario y las bases de datos, entonces se considera que la arquitectura es de dos dimensiones. Por el contrario, si existe un solo grupo de objetos que maneja de manera indistinta la funcionalidad junto con la interacción externa, entonces se considera que la arquitectura es de una sola dimensión.

Una arquitectura puede incluir cualquier número de dimensiones. Algo que depende del tipo de aplicación que desee desarrollar. En genera el planteamiento es: si se diseña un sistema con cierto número de dimensiones. ¿se obtendrá un sistema más estable y fácil de extender que con  un número menor o mayor?. La respuesta depende de que tan independiente sean los objetos de un eje de funcionalidad con los demás. Si se cuenta con ejes de funcionalidad completamente ortogonales, algo que es difícil de lograr, el efecto de cambios en una dimensión no debería afectar a las demás dimensiones. Sin embargo, si los grupos de objetos no son lo suficientemente independientes, aun se puede limitar el efecto de los posibles cambios.
En el caso de los sistemas de información, una de las arquitecturas mas utilizadas es la de Modelo, Vista, Control (MCV – Model, View, Control). Esta arquitectura se basa en tres dimensiones principales: Modelo correspondiente a la información, Vista corresponde a la presentación o interacción con el usuario y Control correspondiente alcomportamiento, como se ilustra en la siguiente figura.
  

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, donde por lo general pueden existir múltiples vistas sobre un mismo modelo. Típicamente la información representa el domino del problema y se almacena en una base de datos. Por otro lado, el control corresponde a la manipulación de la información a través de 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 se controla esta. Sin embargo cada una de ellas probablemente experimente cambios a lo largo del ciclo de vida del sistema, donde el control es el mas propenso a ser modificado, seguido de la vista y, finalmente, del modelo.
En correspondencia con el modelo MVC, la arquitectura para el modelo de análisis se basara en tres tipos o estereotipos de objetos correspondientes a las tres dimensiones anteriores. Ers importante notar que la correspondencia con la tres dimensiones utilizadas durante el modelo de requisitos.


Bibliografia:


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 como se discutió anteriormente. Para ello, se deben identificar primero las clases borde, luego las clases entidad y, finalmente, las de control. En general, se desea asignar la funcionalidad general del caso de uso. Por otro lado, los objetos entidad y borde deben contener funcionalidad local, limitando su efecto en los demás objetos. El trabajo del analista consiste en distribuir de la mejor manera posible el comportamiento específico en el modelo de requisitos entre los diferentes tipos de objetos de la arquitectura de análisis.

La asignación de funcionalidad es bastante difícil en la práctica, y afecta en gran medida de la calidad y mantenimiento del sistema. Los buenos analistas consideran desde un principio los posibles cambios futuros del sistema.
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 esta puede abarcar todos los tipos de objetos.

A continuación se describen se describirán con mayor detalle el proceso de identificación de los tres tipos de objetos, identificando las clases para cada caso de uso según sus estereotipos. El desafío principal en dicho proceso, es decidir cuantas y cuales clases deben asignarse por cada caso de uso.
Borde
Toda la funcionalidad especificada en las descripciones de los caso de uso que depende directamente de los aspectos externos del sistema, se ubica en los objetos borde, pues a través de ellos se comunican los actores con el sistema. La tarea de una clase borde es traducir los eventos generados por un actor en eventos del sistema en una presentación comprensible por 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:

 Se puede identificar con base a los actores. 

Se pueden identificar con base en las descripciones de las interfaces del sistema que acompañan al modelo de requisitos. 

 Se pueden identificar con base en las descripciones  de los casos de uso y extraer la funcionalidad específica a los objetos bordes.

 Comenzaremos utilizando la primera 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. Es evidente que los objetos no son totalmente independientes de cada uno, ya que, en ciertos casos deben saber de la existencia de los demás. Por ejemplo, el usuario debe interactuar con las clases borde de la interface de usuario que a su vez se comunican con las clases borde de las pantallas. Debe estar muy bien definida la interacción de estos dos grupos de clase borde, las pantallas e interface de usuario.

Existen dos tipos de clase borde a modelar, dependiendo del tipo de actor: borde a otros sistemas y bordes a usuarios humanos.
 En el caso de objetos borde que se comunican con otros sistemas, es muy común que la comunicación se describa mediante protocolos de comunicación. Los objetos bordes pueden traducir las señales del sistema a un protocolo de comunicación estandarizada, o simplemente enviar eventos producidos internamente sin conversiones complejas. Una ventaja de esto, es que si se cambia el protocolo, estos cambios serán locales al objeto borde. Un mayor problema ocurre cuando existen señales continuas del mundo externo, como en los sistemas de medición o control. Entonces los objetos borde deben “muestrear” la señal de entrada, ya que internamente el sistema se procesa en términos de eventos.

En el caso de los objetos borde que se comunican con usuarios humanos se utilizan diversas técnicas para el modelado de la interacción. Es fundamental que las interfaces con el usuario sean lógicas y coherentes. En general, en las aplicaciones interactivas es común que las interfaces de usuario sean un aspecto fundamental y de mayos complejidad dentro de la aplicación completa.

Aunque cada tipo de objeto tiene un propósito distinto, es evidente que los objetos borde tienen como propósito principal el manejo de las presentaciones. Sin embargo, también pueden administrar información y tener comportamiento. Debe decidirse de manera individual la cantidad de información y tener comportamiento de un objeto borde. En un extremo, el objeto borde solo debe enviar el evento que recibe del actor a otros objetos en el sistema, sin participar activamente en el curso de los eventos. En el otro extremo, el comportamiento del objeto borde puede ser muy complejo, de manera que la información se procede dentro del objeto borde, haciendo todo el procesamiento de eventos de manera local.

Para identificar que parte del flujo de un caso debe asignarse a los objetos borde,  se deben analizar las interacciones entre los actores y los casos de uso. Esto significa buscar aspectos como, información que deba presentarse al actor y funcionalidad que dependa del comportamiento del actor.
 Entidad
Se utilizan objetos entidad para modelar la información que el sistema debe manejar a corto y largo plazos. 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 casos de uso, por lo que es necesario guardarla en alguna base de datos o archivo.

Los objetos entidad se identifican principalmente a partir del dominio del problema del modelo de requisitos. Dado que es posible identificar un gran número de entidades, se deben considerar únicamente aquellos necesarios para la aplicación. Los casos de uso deben usarse como guías para identificación, y solamente aquellos objetos entidad que puedan justificarse de la descripción del caso de uso deben incluirse.


Adicionalmente, no es fácil decidir cuándo cierta información debe ser modelada como objeto entidad o atributo. Esto depende de cómo se usara la información. Si esta cuenta con cierta estructura más allá de un simple valor numérico, entonces debe modelarse como un objeto entidad. Por otro lado, información que pueda describirse mediante un simple valor, debe modelarse como un atributo de un objeto entidad. Esta decisión es algo arbitraria, ya que cierta información puede modelarse como objeto entidad en un sistema, mientras que en  otro puede representarse mediante un atributo.
También es difícil identificar que operaciones y cuales atributos serán incluidos dentro de estos objetos.
Dado que la única forma para manipular un objeto entidad es por medio de sus operaciones, se deben identificar suficientes operaciones para manipular completamente al objeto entidad. La descripción detallada de los casos de uso es de nuevo un medio extremadamente valioso para identificar estas operaciones.

Las operaciones pueden ser sencillas, sirviendo de acceso a los valores de los atributos, o complejas, como en el caso de ciertos cálculos matemáticos basados en los valores de los atributos del objeto. Sea cual sea la complejidad, estas operaciones deben depender y afectar solamente a la información local.

Durante la identificación de objetos entidad, se encontrara que objetos similares aparecen en varios casos de uso.

 Control
Hasta ahora se han identificado objetos borde y entidad a partir de cada caso de uso. En algunas situaciones, todo un caso de uso pudiera implementarse exclusivamente mediante estos dos tipos de objetos. Así no se necesitaría ningún objeto control para el respectivo caso de uso. Sin embargo, en la mayoría de los casos de uso, existe un comportamiento que no puede asignar de forma natural a ninguno de los otros dos tipos de objetos. 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. Por lo tanto, para evitar estos problemas, tal comportamiento se asigna a objetos control.

En general, 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, dependiendo de la existencia del propio caso de uso. Por lo tanto, los objetos control se especifica directamente de los casos de uso. Como primera aproximación, se especifica un objeto control para cada caso de uso. Dado que se asigna inicialmente el comportamiento a los objetos borde y entidad, el comportamiento restante se agrega a los objetos control. Una manera de asignar el comportamiento es modelar inicialmente el caso de uso sin ningún objeto control, en otras palabras, solo utilizando objetos borde y objetos entidad. Cuando tal modelo se ha desarrollado, se verá que hay ciertos comportamientos que no se asignan de forma natural, a los diversos objetos, o incluso, se distribuye a varios objetos. Estos comportamientos deberían  asignarse a los objetos control. Otra situación es que los comportamientos, después de distribuirse entre objetos borde y entidad, sea demasiado complicado. En tal caso, los comportamientos pueden ser distribuidos en varios objetos control.

En la mayoría de los sistemas, se promueve la distribución del manejo de un caso de uso en un solo objeto control. Sin embargo, la estrategia de asignación de control se debe decidir de acuerdo a cada aplicación.

Bibliografia:


jueves, 6 de noviembre de 2014

3.3 CLASES

Uno de los más comunes elementos hallados en el modelo de análisis, o algunas veces llamados objetos de análisis. Las clases de análisis son clases estereotipadas que representan responsabilidad y comportamiento. Existen tres tipos de clases de análisis y ellas son usados en todo el modelo de análisis: 

Interfaz 
Control 
Entidad


 Clase interfaz

Una clase interfaz es una clase estereotipada que modela la interacción entre uno a mas actores y el sistema. Puede usar las clases interfaz para capturar los requerimientos de una interface de usuarios. Las clases interfaz pueden ser ventanas, impresoras, sensores y terminales.


 Clase control

Una clase control modela el comportamiento específico de uno o unos pocos casos de uso. Una clase control frecuentemente controla otros objetos y encapsula el comportamiento específico del caso de uso. Las clases control coordinan el comportamiento del sistema, manejando las tareas principales y flujo de control.



       Clase entidad
Una clase entidad modela la información almacenada por el sistema y su comportamiento asociado. Una clase entidad tiene características de persistencia que son frecuentemente reusadas en otros casos de uso del sistema. Las clases entidad muestran la estructura lógica del sistema. 

Bibliografia:


3.4 DIAGRAMA DE SECUENCIAS

El diagrama de secuencias en UML muestra la forma en que los objetos se comunican entre si al transcurrir el tiempo.

El diagrama muestra:
Los objetos participando en la interacción.
 La secuencia de mensajes intercambiados.

Un diagrama de secuencias contiene:

 Objetos con sus “líneas de vida”. 
 Mensajes intercambiados entre objetos en una secuencia ordenada. 
 Línea de vida activa (opcional).

  Objetos

El diagrama de secuencias consta de objetos que se representan del usual:rectángulos  con nombres (subrayado), los mensajes entre los objetos representados por líneas continuas con una punta de flecha y el tiemporepresentado como una progresión vertical.

Los objetos se colocan cerca de la parte superior del diagrama de izquierda a derecha y se acomodan de manera que simplifiquen el diagrama.

La extensión que está debajo (y en forma descendente) de cada objeto será una línea discontinua conocida como la línea de vida de un objeto.

Junto con la línea de vida de un objeto rectángulo conocido como activación, el cual representa la operación que realiza el objeto.


 Mensajes

Un mensaje que va de un objeto a otro pasa de la línea de vida de un objeto a la de otro. Un objeto puede enviarse a un objeto a si mismo(es decir, de su línea de vida a su propia línea de vida).

Un mensaje puede ser simple, síncrono o asíncrono.
 Simple 
Es la transferencia del control de un objeto a otro.

 Síncrono

Es  aquel en el que el objeto espera la respuesta a ese mensaje antes de continuar con su trabajo.

 Asíncrono

Es aquel en el que el  objeto no espera la respuesta a ese mensaje antes de continuar.


 Tiempo
El diagrama representa al tiempo en dirección vertical. El tiempo se inicia en la parte superior y avanza hacia la parte inferior. Un mensaje que esté más cerca de la parte superior o ocurrirá antes que uno que este cerca la parte inferior.

Con ello el diagrama de secuencia tiene dos dimensiones. La dimensión horizontal es la disposición de los objeto, y la dimensión vertical muestra el paso del tiempo

A continuación se muestra el funcionamiento del tiempo; se muestra un actor que inicia la secuencia, aunque este símbolo en sentido estricto, no forma parte del conjunto de símbolos de un diagrama de secuencia.

Bibliografia:


3.5 DICCIONARIO DE CLASES SEGÚN MÓDULOS


Como última etapa del modelo de análisis, se actualiza el diccionario de datos originalmente descrito para el dominio del problema para incluir todas las clases identificadas durante el modelo de análisis. Separamos estas clases en diferentes módulos para lograr una mejor correspondencia entre clases y casos de uso. Aquellas clases que participan en varios casos de uso se pueden asignar a distintos módulos, como veremos a continuación para el sistema de reservaciones de vuelo.

Comenzamos con cuatro módulos o paquetes principales: InterfaceUsuario, Principal, Registro y Sevicios, como se muestra en la Figura.
 Módulos principales del sistema de reservaciones de vuelo.

Interface Usuario
El módulo Interface Usuario está compuesto por una sóla clase:
Interface Usuario – Clase Interface. Toda la interacción con el usuario se hace por medio de la interface de usuario.

Principal
El módulo Principal está compuesto por dos clases:

PaginaPrincipal - Clase Interface. Página principal (P-1)
ManejadorPrincipal - Clase Control. El manejador principal es el encargado de desplegar la página principal de interacción con el usuario, y luego delegar las diferentes funciones a los manejadores especializados apropiados.

Registro
El módulo Registro se divide en los siguientes módulos: RegistroPrincipal, Usuario y Tarjeta, como se muestra en la Figura.
Módulos adicionales del módulo Registro.

RegistroPrincipal
El módulo RegistroPrincipal está compuesto por una sóla clase:

InterfaceBaseDatosRegistro - Clase Interface. La información de cada usuario se almacena en la base de datos de registro la cual se accesa mediante la interface de la base de datos de registro. Esto permite validar a los distintos usuarios además de guardar información sobre la tarjeta de crédito para pagos en línea.

Usuario
El módulo Usuario está compuesto por las clases:

PaginaCrearRegUsuario - Clase Interface. Página de solicitud de registro de usuario (P-3).

PaginaObtenerRegUsuario - Clase Interface. Página de devolución con información de registro de usuario (P-4).

RegistroUsuario - Clase Entidad. Para poder utilizar el sistema de reservaciones, el usuario debe estar registrado con el sistema. El registro contiene información acerca del usuario que incluye nombre, dirección, colonia, ciudad, país, código postal, teléfono de casa, teléfono de oficina, fax, email, login y password.

ManejadorRegistroUsuario - Clase Control. El manejador de registro de usuario se encarga de todo lo relacionado con registro del usuario para poder utilizar el sistema.

Tarjeta
El módulo Tarjeta está compuesto por las clases:

PaginaCrearRegTarjeta - Clase Interface. Página de solicitud de registro de tarjeta (P-5).

PaginaObtenerRegTarjeta - Clase Interface. Página de devolución con información de registro de tarjeta (P-6).

RegistroTarjeta - Clase Entidad. Para poder hacer un pago con una tarjeta de crédito, se debe tener un registro de tarjeta. El registro contiene información acerca de la tarjeta incluyendo nombre, número, expedidor y vencimiento. LA tarjeta está ligada a un registro de usuario.

ManejadorRegistroTarjeta - Clase Control. El manejador de registro de tarjeta se encarga de todo lo relacionado con registro de la tarjeta del usuario para poder pagar las reservaciones.

Servicios
El módulo Servicio se divide en los siguientes módulos: ServicioPrincipal, Dominio, Consultas, Reservas, y Pagos, como se muestra en la Figura.
Módulos adicionales del módulo Servicios.

ServicioPrincipal
El módulo ServicioPrincipal está compuesto por las clases:

InterfaceBaseDatosReserva - Clase Interface. La información del sistema de reservaciones de vuelo se almacena en la base de datos de reservas la cual se accesa mediante la interface de la base de datos de reservas. Esto permite generar consultas, reservas y pago de reservas de manera dinámica.
PaginaServicio - Clase Interface. Página de servicios (P-2).

ManejadorServicios - Clase Control. El manejador de servicios se encarga de enviar las peticiones particulares de servicios a los manejadores espacializados para consulta, reserva y compra.

Dominio
El módulo Dominio está compuesto por las clases:

Vuelo - Clase Entidad. Se denomina por medio de un número. El vuelo tiene como origen un aeropuerto en una ciudad y tiene como destino un aeropuerto de otra ciudad. Un vuelo puede tener múltiples escalas y múltiples vuelos se relacionan por medio de conexiones. El vuelo pertenece a una aerolínea y puede operar varios días a la semana teniendo un horario de salida y otro de llegada.

Reservación - Clase Entidad. Para poder tomar un vuelo es necesario contar con una reservación previa, la cual debe pagarse antes de una fecha límite, que puede ser el propio día del vuelo. Una reservación puede hacerse para múltiples vuelos y múltiples pasajeros. La reservación cuenta con una clave identificando un récord de reservación particular.

Horario - Clase Entidad. El horario de un vuelo se determina por su hora de salida y hora de llegada durante los días que opera.

Aerolínea - Clase Entidad. La aerolínea provee servicio de múltiples vuelos entre diferentes ciudades bajo diferentes horarios. La aerolínea se identifica por un nombre.

Aeropuerto - Clase Entidad. El aeropuerto sirve como origen, destino y escalas de un vuelo. El aeropuerto se encuentra en una ciudad de un país determinado.

Tarifa - Clase Entidad. Los diferentes vuelos tienen múltiples tarifas para compra de boleto, variando según la clase de boleto, si son de ida o de ida y vuelta, y dependiendo de las diversas restricciones y ofertas existentes.

Asiento - Clase Entidad. Una reservación de vuelo puede incluir la asignación de asiento, especificada mediante una fila y un número. El número de asientos disponibles en un vuelo particular dependen del tipo de avión que opere ese día.

Pasajero - Clase Entidad. Para poder hacer una reservación se requiere dar el nombre del pasajero. Varios pasajeros pueden aparecer bajo una sola reservación.

Avión - Clase Entidad. Un vuelo en una fecha determinada se hace en un tipo de avión particular. El tipo de avión define la cantidad máxima de pasajeros que pueden viajar en ese vuelo para esa fecha.

ViajeroFrecuente - Clase Entidad. El pasajero tiene la opción de acumular millas para un vuelo particular si cuenta con una tarjeta de viajero frecuente para la aerolínea correspondiente. 

Consultas
El módulo Consultas se divide en los siguientes módulos: ConsultasPrincipal, Horarios, Tarifas y Estado, como se muestra en la Figura.

Módulos adicionales del módulo Consultas.

ConsultasPrincipal
El módulo ConsutlasPrincipal está compuesto por las clases:

PaginaConsultas - Clase Interface. Página de presentación de consultas (P-7).

ManejadorConsultas - Clase Control. El manejador de consulta se encarga de enviar las peticiones de consulta particular a los manejadores de consulta especializados.

Horarios
El módulo Horarios está compuesto por las clases:

PaginaConsultaHorarios - Clase Interface. Página de presentación de consulta de horarios (P-8).

PaginaResultadoHorarios - Clase Interface. Página de devolución de consulta de horarios (P-9).

ManejadorConsultaHorarios - Clase Control. El manejador de consulta de horarios se encarga de controlar las peticiones de consulta de horarios.

Tarifas
El módulo Tarifas está compuesto por las clases:

PaginaConsultaTarifas - Clase Interface. Página de presentación de consulta de tarifas (P-10).

PaginaResultadoTarifas - Clase Interface. Página de devolución de consulta de tarifas(P-11).

ManejadorConsultaTarifas - Clase Control. El manejador de consulta de tarifas se encarga de controlar las peticiones de consulta de tarifas. 

Estado El módulo Estado está compuesto por las clases:

PaginaConsultaEstado - Clase Interface. Página de presentación de consulta de estado (P-12).

PaginaResultadoEstado - Clase Interface. Página de devolución de consulta de estado(P-13).

ManejadorConsultaEstado - Clase Control. El manejador de consulta de estado se encarga de controlar las peticiones de consulta de estado.

Reservas
El módulo Reservas está compuesto por las clases:

PaginaClaveReservas - Clase Interface. Página de solicitud de clave de reservas (P-14).

PaginaCrearReservaVuelos - Clase Interface. Página de solicitud de reservas (P-15).

PaginaRecordReservaVuelos - Clase Interface. Página de devolución de reservas (P-16).

ManejadorReservas - Clase Control. El manejador de reserva se encarga de enviar las solicitudes de reserva a la base de datos del sistema de reservaciones.

Pagos
El módulo Pagos está compuesto por las clases:

PaginaPagoReserva - Clase Interface. Página de solicitud de pago de reservas (P-17).

PaginaReembolsoReserva - Clase Interface. Página de solicitud de reembolso de pago (P-18).

ManejadorPagos - Clase Control. El manejador de compra se encarga de enviar las solicitudes de compra de boleto a la base de datos del sistema de reservaciones.

Bibliografia:


3.6 HERRAMIENTAS CASE PARA EL ANALISIS

Estas herramientas van enfocadas al desarrollador ya que le permiten crear un modelo del sistema que se va a construir y también la evaluación de la validez y consistencia de este modelo. Proporcionan un grado de confianza en la representación del análisis y ayudan a eliminar errores con anticipación.
Entre ellas podemos encontrar:
Herramientas de análisis y diseño (Modelado).
Herramientas de creación de prototipos y de simulación.
Herramientas para el diseño y desarrollo de interfaces.
A continuación se presentan algunos ejemplos de herramientas case para el análisis:

 ERwin

PLATINUM ERwin es una herramienta de diseño de base de datos. Brinda productividad en diseño, generación, y mantenimiento de aplicaciones. 
Desde un modelo lógico de los requerimientos de información, hasta el modelo físico perfeccionado para las características específicas de la base de datos diseñada, ERwin permite visualizar la estructura, los elementos importantes, y optimizar el diseño de la base de datos. 
ERwin genera automáticamente las tablas y miles de líneas de stored procedure y triggers para los principales tipos de base de datos, ERwin hace fácil el diseño de una base de datos. Los diseñadores de bases de datos sólo apuntan y pulsan un botón para crear un gráfico del modelo E-R (Entidadrelación) de todos sus requerimientos de datos y capturar las reglas de negocio en un modelo lógico, mostrando todas las entidades, atributos, relaciones, y llaves importantes.

 EasyCASE

EasyCASE Profesional - el centro de productos para procesos, modelamiento de datos y eventos, e Ingeniería de Base de Datos- es un producto para la generación de esquemas de base de datos e ingeniería reversa - trabaja para proveer una solución comprensible para el diseño, consistencia y documentación del sistema en conjunto.

Esta herramienta permite automatizar las fases de análisis y diseño dentro del desarrollo de una aplicación, para poder crear las aplicaciones eficazmente – desde procesamiento de transacciones a la aplicación de bases de datos de cliente/servidor, así como sistemas de tiempo real.

EasyCASE permite capturar los detalles de diseño de un sistema y comunicar las ideas gráficamente, para que sean fáciles de ver y entender. Para un diseño legítimo y modelamiento de datos, procesos y eventos, permite crear y mantener diagramas de flujo de datos, diagramas de entidad-relación, mapas de estructura y más.

Posee herramientas de corrección avanzadas que permiten revisiones generales en minutos, en lugar de horas o días. Permite re-usar diagramas o partes de diagramas para economizar el diseño de un proyecto.
EasyCASE soporta una gama amplia de metodologías estructuradas, permitiendo escoger los métodos más apropiados para realizar las tareas. EasyCASE determina los tipos de esquemas según la metodología del proyecto seleccionada y notifica de errores a medida que el modelo está construyéndose.


El verdadero poder de EasyCASE se encuentra en el soporte comprensivo al modelamiento de datos, procesos y eventos. Posee desde el editor de diagramas flexible y un diccionario de los datos integrado en formato dBASE, así como una extensa cantidad de reportes y análisis.

Bibliografia: