Otros Links:

Diseño Físico

[STU99] Hasta esta etapa del diseño lo que se ha hecho es modelar los requerimientos de la aplicación por medio de sus especificaciones funcionales hasta encontrar distintos aspectos de cómo trabaja la aplicación por fuera. Ahora es necesario considerar como la aplicación trabaja por dentro, o más precisamente como las tecnologías y arquitecturas que se han elegido van a impactar en el diseño.

Revisión de los requerimientos técnológicos

Se debe hacer un análisis o revisión de las tecnologias que se escogieron para utilizar dentro de la aplicación, de esta manera es posible ya comenzar a diseñar los elementos tomando en cuenta estas restricciones utilizando diagramas UML.

Distributed Internet Aplications (DNA)

En esta parte daremos una breve explicación de porque se escogio como requerimiento tecnológico que la aplicación se base en el modelo Windows DNA.

DNA es una arquitectura prácticamente nueva, no es realmente nada más que una arquitectura de tres capas, que algunas veces es llamada n- capas, excepto porque hace enfasis en el tema de Internet.

Ya se explico anteriormente que una de las capas se coloca en el cliente, que en el caso de la aplicación “X” es la interfaz que manejaran los empleados encargados de realizar las ventas. La segunda capa se encuentra en el servidor que contiene la lógica de negocios, que es la que se encarga de lidiar con las transacciones (editar, actualizar,adicionar, recuperar registros ) de la base de datos. La tercera capa en la que contiene la base de datos. El esquema se vería de la siguiente manera. 

A primera vista, no parece haberse ganado demasiado. Se ha removido la logica de negocios que estaba en los procedimientos junto con la interfaz, y se la ha colocado dentro de componentes en la capa del medio. De todas maneras si se analiza con mayor profundidad  se pueden encontrar muchos beneficios importantes de esta arquitectura.

·        La capa del medio

A diferencia de un procedimiento almacenado SQL, un componente Visual Basic en la capa del medio maneja las transacciones de la lógica de negocios. Tiene código que es facil de leer, escribir y depurar , además de tener pocas limitaciones. Se puede además crear un componente que puda trabajar con una multitud de bases de datos en diferentes servidores. Se pueden contruir componentes muy poderosos que pueden realizar manipulaciones muy complejas de datos. Las actividades extremadamente complejas , que son realizadas por el cliente pueden ser  ejecutadas en la capa del medio. Esto hace al cliente mas pequeño, liviano y mejor para trabajar en Internet.

La capa del medio trabaja  como un intermediario, tomando los requerimientos del cliente para un conjunto particular de información formateado de acuerdo a un conjunto de reglas de negocios. La capa del medio consigue los datos , los transforma de acuerdo a las reglas de negocios y los devuelve al cliente. El cliente no tiene porque preocuparse acerca de las conexiones a la base de datos, tablas o transformación de los datos. El cliente simplemente solicita la información que necesita y la capa del medio se la devuelve.

·        Trabajar con Componentes

Combinado la arquitectura Dna con Programación Orientada a Objetos, se pueden crear proyectos muy poderosos. Si se crean componentes que realizan ciertas tareas, se pueden luego construir aplicaciones basadas en dichos componentes. Usar estos componentes para construir nuestra aplicación “X”  de tres capas permite colocar los componentes en las diferentes capas, y en distintas ubicaciones dentro de las capas, dependiendo de las necesidades particulares de la aplicación.

Usar DNA y OOP(Object Oriented Programming) ofrecen otra ventaja. Si por alguna razón la lógica de negocios cambia, seguramente uno o dos componentes tendrán que ser cambiados. Estos componentes deberían estar en la capa del medio , lo que significa que solamente habrá que actualizar el servidor. En el caso de una empresa que utilice la aplicación que cuente con cientos de usuarios es mejor actualizar uno o dos servidores que cientos de clientes.

 Activex Data Objects (ADO)

La tecnología de acceso a los datos escogida para la aplicación “X” es ADO , el motivo principal para haberla escogido es que al ser un conjunto de controles Activex , es neutral al lenguaje , esto quiere decir que puede ser usado desde Visual Basic, Delphi, Visual C++, Java , Java Script  ó VBScript.

·        Diagramas de Actividad ADO y MTS

Las restricciones tecnológicas más importantes en el caso del diseño de esta aplicación son el modelo de acceso a datos ADO (Activex Data Object) y MTS(Microsoft Transaction Server) para hacer el diseño físico se utilizaron Diagramas de Actividad para mostrar como manejar las conexiones a los datos , además de cómo manejar el contexto de los objetos dentro de MTS.

Diagrama de Componentes

[KIR99]Para continuar con el diseño Físico, ahora que ya se han diseñado las clases y se les ha aplicado las restricciones tecnológicas, se deben seguir los siguientes pasos:

·        Agrupar las clases en componentes

·        Agrupar los componentes en paquetes y procesos MTS

·        Asignar los paquetes y procesos a las distintas máquinas con las que se va a trabajar.

Agrupar las clases en componentes

La gran mayoría de las clases usadas en MTS, son faciles de agrupar en componentes. Cada clase COM es implementada en un componente in-process.

Si se tienen una clase que solamente puede ser instanciada vía otra clase , probablemente se necesite crear un componente con ambas clases.

Agrupar los componentes en Paquetes y procesos

MTS usa los paquetes como unidades de confianza y unidades de implementación. Un paquete es simplemente un conjunto de componentes que desempeñan funciones que tienen algo en común. Un componente puede ser instalado en solamente un paquete en una máquina. Existen dos tipos de paquetes:  paquetes de librería y  paquetes de servidor. Un paquete de librería corre en el proceso  del cliente que lo creó. Un paquete de servidor corre en un proceso separado.

Asignar paquetes y procesos a las máquinas

La mayoría de las decisiones a cerca de donde los paquetes y procesos deberían correr  se deben postegar hasta el final. Si es que se identifica algun requerimiento especifico de implementación  que se aplique a ciertos componentes debería ser documentado. En el caso de este proyecto no existe ningun requerimiento especial, de manera que todos los componentes pueden correr en una sola máquina.

Diagramas utilizados en el diseño Físico

En el diseño Físico se utilizan diagramas de componentes para describir como las clases se agrupan en componentes y paquetes. Se utilizan diagramas de implementación para describir como los paquetes y procesos  son distribuidos entre las máquinas del sistema.

Diagrama de Implementación

Diseño de los paquetes

Para poder diseñar los paquetes se deben tomar en consideración los siguientes puntos:

·        Activación

·        Compartición de recursos

·        Aislamiento de fallas

·        Seguridad

Activación

Se pueden activar los componentes de la aplicación de dos maneras: en el proceso del cliente o en un proceso de manejo especifico de paquetes administrado por MTS. Los paquetes de librería no soportan seguridad declarativa, ni ofrecen los beneficios de los procesos de aislamiento. Estos paquetes son usados más comunmente para componentes utilitarios que van a ser utilizados por múltiples aplicaciones.Son también útiles cuando no se desea la sobrecarga de un proceso separado y no se requiere chequeo de autorización.

Los paquetes de servidor se usan para correr componentes en procesos separados administrados por MTS. Estos soportan seguridad declarativa, pooling de recursos además de otras características.

Decidir cuantos paquetes son necesarios en una aplicación es un acto de balanceo. Si se tienen muchos paquetes el administrador del sistema tendrá gran flexibilidad durante la implementación de la aplicación. Sin embargo ,cada proceso de servidor requiere cierta cantidad de trabajo para administrar el pooling de recursos,las propiedades compartidas,etc.Adicionalmente las llamadas interproceso COM son mucho más caras que las llamadas in-process (dentro del proceso) .

Compartición de Recursos

Los componentes que usan los mismos recursos, así como bases de datos,deberían ser agrupados en un solo paquete servidor. Recuerdese que MTS administra el pooling de recursos basándose en los procesos. Cada paquete de servidor consigue su propio pool de hilos de proceso, pool de conexiones a la base de datos. Si dos componentes utilizan la misma base de datos y son colocados en paquetes de servidor separados no pueden hacer pooling de conexiones a la base de datos. Si los componentes están localizados en el mismo paquete servidor, si pueden utilizar el pool de conexiones. Esta capacidad puede mejorar enormemente el desempeño y la escalabilidad de la aplicación de la misma manera los componentes que comparten propiedades deben localizarse en el mismo paquete para asegurar una operación correcta de la aplicación.

También se debería considerar la localización de los recursos cuando se están diseñando los paquetes. En general, los componentes deberían estar tan cerca como sea posible de los recursos que utilizan, particularmente repositorios de datos, para ayudar a reducir el trafico de red dentro de la aplicación.

Aislamiento de Fallas

Se debe considerar separar los componentes en diferentes paquetes para asegurar que una falla en uno de los componentes no cause que otros componentes fallen tambien ya que MTS termina un proceso si es que detecta corrupción interna. Las excepciones dentro de un componente pueden tambien forzar a un proceso servidor a terminar y cualquier estado de objeto que se estuviera manteniendo se perderá. Si la aplicación tiene componentes que mantienen su estado , se debe considerar colocar dichos componentes en paquetes de servidor separados.

Seguridad

Como ya se dio ,los paquetes de servidor son las unidades de confianza de MTS. Las llamadas dentro de un paquete deben ser seguras. Por esto es que los requerimientos de seguridad de la aplicación tienen un gran impacto en el diseño de los paquetes. Si las llamadas dentro de un componente deben ser autorizadas, los clientes y el componente deben estar localizados en diferentes paquetes. Solo los componentes que puden de manera segura llamar a otros componentes sin requerir autorizacion deberían estar localizados en el mismo paquete.