CAPITULO IV: DESARROLLO DEL SISTEMA
4.1. ARQUITECTURA DE TECNOLOGÍAS DE INFORMACIÓN

El desarrollo de un sistema de información es una tarea que toma tiempo conceptualizar, diseñar, programar, probar e implementar un sistema. En esta parte del proyecto analizaremos la arquitectura tecnológica más apropiada para el desarrollo del sistema, es decir, la tecnología cliente-servidor.

4.1.1. Justificación de la Utilización de la Arquitectura Cliente-Servidor

Se ha estado utilizando activamente el desarrollo de aplicaciones cliente servidor ya que pueden cubrir una gran cantidad de arquitecturas y asimismo sus componentes se pueden crear mediante numerosas herramientas independientes relacionadas con los lenguajes de programación. El utilizar una arquitectura cliente-servidor tiene sus ventajas como: * Cuando un servidor de bases de datos procesa una consulta, la respuesta a esta petición dependerá del proceso del servidor y no del cliente. * El proceso servidor activo devuelve sólo la información solicitada. * Un proceso servidor activo puede asegurar más eficazmente la integridad de los datos. Además, se ha considerado el uso de esta arquitectura por las siguientes características: * El requerimiento de la institución de tener los datos almacenados en una ubicación central en donde los usuarios puedan acceder a ellos. * El uso de Microsoft SQL Server como motor de base de datos relacional, cuyas características revolucionan el concepto de base de datos para la empresa. * La institución cuenta con un personal muy reducido. Todas estas características nos inicia en un proceso de desarrollo de la aplicación de tal forma que nos llevan a estudiar la arquitectura cliente-servidor.

4.1.2. Arquitectura Cliente-Servidor

Este término se usa para describir una aplicación en la cual dos o más procesos separados trabajan juntos para completar una tarea. El proceso cliente solicita al proceso servidor la ejecución de alguna acción en particular. Cualquier arquitectura cliente-servidor separa los lados del cliente y del servidor estableciéndose así las funciones que le corresponden al cliente y las funciones que le competen al servidor, por lo que esto nos conduce a especificar mejor la arquitectura a usar. A continuación mencionaremos las siguientes propuestas de arquitectura de capas que existen para los sistemas de información:

* Arquitectura de dos capas

La mayoría de las aplicaciones Cliente-Servidor funcionan bajo una arquitectura de dos capas en lenguajes de cuarta generación. Esta arquitectura consiste en dos casos típicos: 1) Cuando la base de datos se encuentra en el servidor conectado a una red, mientras que la aplicación, se encuentra en el proceso cliente y es quien se encarga de la ejecución de la lógica de la aplicación (ver Figura IV.1). 2)La lógica de la aplicación se codifica en el servidor como procedimientos almacenados (ver Figura IV.2).

* Arquitectura de tres capas

En una aplicación de tres capas (ver figura IV.3) cada capa trabaja en procesos separados, es decir, la capa de la lógica de aplicación se convierte en una capa intermedia bien definida y lógica de software.

Vistos los modelos de la arquitectura cliente-servidor y aunque es obvio que el modelo de dos capas contrasta con el modelo de tres capas. Indiscutiblemente el modelo de tres capas ofrece muchas ventajas frente al modelo de dos capas, pero hay que tener en cuenta que esto requiere pagar un precio, lo cual significa una mayor complejidad y administración. Por lo tanto desde nuestro punto de vista es mucho más ventajoso utilizar el modelo de dos capas caso 2, ya que de acuerdo a las necesidades y limitaciones de la institución se podrá decir que es el modelo que más conviene usar.

4.2. IMPLEMENTACION DEL DISEÑO DE BASE DE DATOS

4.2.1. Conversión del Diagrama de Clases a una Base de Datos Relacional

Los diseños orientados a objetos son eficientes, coherentes y menos proclives los problemas de actualización que aquejan a muchas otras técnicas de diseño de bases de datos. Pero, el modelo relacional ha ganado popularidad, por lo que se han incrementado sus ventajas en lo tocante a funcionalidad y flexibilidad. Además, a pesar de que las bases de datos orientadas a objetos tienen un aspecto prometedor, todavía no han alcanzado una amplia aceptación masiva por parte del mercado. El diagrama de clases se puede usar para implementar un diseño de una base de datos relacional, pero para traducir un diagrama de clases a tablas ideales, hay que proporcionar detalles que faltan en el diagrama, como la clave primaria y los candidatos a clave para cada tabla; así como si un atributo puede ser o no ser nulo, además de asignarle a cada atributo un dominio. Transformación del Diagrama de Clases en Modelos de Tablas Esta sección se centra en la transformación de clases a tablas, donde se aplicará las reglas de correspondencia, porque el modelado de objetos no introduce nada nuevo en este sentido. La conversión es la misma para las tablas derivadas de objetos que la correspondencia a las que se derivan del enfoque tradicional. A continuación para mostrar las reglas de correspondencia que se ha seguido, se muestran algunas clases como ejemplo. * Correspondencia entre clases y tablas Toda clase se corresponde con una o más tablas; de igual manera que una clase tiene atributos, esos atributos pasan a ser atributos de la tabla, añadiendo el ID del objeto y detalles como parte de la formulación del modelo de tablas, especificando que atributos pueden ser o no nulos y asignando un dominio a cada atributo. La figura VI.4 muestra como una clase del diagrama de clases es transformada en tabla.

* Correspondencia entre asociaciones y tablas En términos generales, una asociación puede o no corresponderse con una tabla, ya que esto depende del tipo y multiplicidad de la asociación; y del criterio de quien diseña la base de datos. La figura IV.5 muestra la asociación uno-a-muchos, donde la asociación incluye una clave externa en la tabla para la clase "muchos". La figura IV.7 muestra una asociación de muchos-a-muchos, extraída del diagrama de clases. La asociación muchos-a-muchos siempre se corresponde con una tabla concreta, satisfaciendo así la tercera forma normal. Las claves primarias tanto para las clases relacionadas como para los atributos de enlace pasan a ser atributos de la tabla asociación. La figura IV.8 muestra como la asociación uno-a-uno se puede fundir y almacenar ambos objetos y asociación en una sola tabla; y al fusionarse se mejora el rendimiento, y se reduce el espacio de la base de datos y la posible violación de la tercera forma normal.

* Correspondencia de las generalizaciones a tablas. Las figuras IV.9 y IV.10 muestran un modelo de clases con herencia simple. Sin embargo, la correspondencia que muestra la figura IV.9 es la de eliminar la tabla de superclase y los atributos de la superclase se duplican para cada subclase, esto permite eliminar la navegación de superclase a subclases y así acelerar el proceso, manteniendo la tercera forma normal. En la figura IV.10, se elevan los atributos de las subclases al nivel de la superclase, esta regla es útil si hay dos o tres subclases con pocos atributos.