66

3.2.4 Arquitectura de referencia para sistemas de informacin

Una arquitectura de sistemas de informacin consta de los sistemas de informacin bsicos requeridos por las organizaciones para coordinar el comercio mundial y otras actividades. La figura 3.21 ilustra el razonamiento que seguimos e ilustra las principales dimensiones de una arquitectura de sistemas de informacin internacionales.

FIGURA 3.21. Arquitectura de sistemas de informacin Las aplicaciones empresariales suelen tener datos complejos y la perdida de estos para trabajar, junto con las reglas del negocio que rompen todas las pruebas de razonamiento lgico. Aunque algunas tcnicas y patrones son pertinentes para todo tipo de software, muchos son pertinentes slo para una rama en particular. Las aplicaciones empresariales suelen referirse a datos persistentes. Los datos son persistentes porque deben ser ms o menos utilizados entre varias ejecuciones de programas. Durante ese tiempo habr muchos cambios en la estructura de los datos para almacenar piezas de informacin sin alterar las piezas antiguas. Incluso si hay un cambio fundamental y la empresa instala una aplicacin completamente nueva para manejar un proceso, los datos tienen que migrar a la nueva aplicacin. Por lo general hay una gran cantidad de datos hasta el punto de que su gestin es una parte importante del sistema. Los sistemas ms antiguos utilizan estructuras de archivos indexados como VSAM IBM y ISAM. Los sistemas modernos suelen utilizar bases de datos relacionales en su mayora. 66

67 Por lo general, muchas personas acceden a los datos simultneamente. Para muchos sistemas esto puede ser menos de un centenar de personas, pero para sistemas basados en Web esto va por rdenes de magnitud. Incluso sin muchas personas, todava hay problemas en asegurarse de que dos personas no tienen acceso a los mismos datos al mismo tiempo de manera que provoque errores. Herramientas de gestin de transacciones debe manejar parte de esta carga. Las aplicaciones empresariales rara vez viven en una isla. Por lo general necesitan integrar con otras aplicaciones empresariales alrededor de la empresa. Luego est la cuestin de lo que viene bajo el trmino "lgica del negocio". Esto parece curioso ya que hay pocas cosas que son menos lgicas que la lgica de negocio. Hay que tratar con una matriz fortuita de condiciones extraas que a menudo interactan entre s de manera sorprendente. En esta situacin hay que organizar la lgica de negocios tan efectivamente como sea posible, porque lo nico cierto es que la lgica va a cambiar con el tiempo. Gran parte del desafo en el diseo de sistemas de informacin es en conocer acerca de las alternativas y juzgar las ventajas y desventajas de utilizar una alternativa sobre otra.. La divisin en capas es una de las tcnicas ms comunes que los diseadores de software utilizan para separar un sistema de software complicado. Las tres capas de Principales Presentacin: Prestacin de servicios, visualizacin de la informacin (por ejemplo, en Windows o HTML, manejo de solicitud de usuario (clics del mouse, teclado), las solicitudes HTTP, invocaciones de lnea de comandos, API) Dominio: Lgica que es el verdadero punto del sistema Datos fuente: Comunicacin con bases de datos, sistemas, administradores de transacciones, otros paquetes de mensajera Capas lgicas: dividir un sistema en piezas separadas para reducir el acoplamiento entre las diferentes partes de un sistema. Separacin entre capas es til incluso si las capas estn ejecutando en un equipo fsico. Sin embargo, hay lugares donde la estructura fsica de un sistema de marca la diferencia. En la organizacin lgica de dominio se puede separar en tres patrones principales: Un script de transaccin: organiza toda esta lgica ante todo como un nico procedimiento, por lo que llama directamente a la base de datos a travs de una envoltura delgada de base de datos. Cada transaccin tendr su propio script de transaccin, a pesar de las subtareas comunes se pueden dividir en subprocedimientos como se muestra en la figura 3.21. 67

68

Figura 3.22 Transaction Script; Organiza la lgica empresarial por procedimientos donde cada procedimiento controla una sola solicitud de la presentacin Modelo de dominio La lgica negocio puede ser muy compleja. Reglas y lgica describen muchos casos diferentes y modos de comportamiento ya que esta complejidad es para la cual los objetos fueron diseados para trabajar. Un modelo de dominio crea una red de objetos interconectados, donde cada objeto representa a algo significativo, ya sea tan grande como una corporacin o tan pequeo como una sola lnea en un formulario de pedido.

Figura 3.23 Un modelo de objetos del dominio que incorpora datos y comportamiento. Mdulo tabla Uno de los principales mensajes de orientacin a objetos es empaquetar los datos con el comportamiento que lo utiliza. El enfoque orientado a objetos tradicional se basa en objetos con identidad, a lo largo de las lneas del modelo de dominio. As, si tenemos una clase empleado, cualquier instancia de la 68

69 misma corresponde a un empleado en particular. Este plan funciona bien porque una vez que tengamos una referencia a un empleado, podemos ejecutar las operaciones, seguir las relaciones y recopilar datos sobre l..

Figura 3.23 Una sola instancia que controla la lgica empresarial de todas las filas de una tabla de base de datos o vista. Un mdulo tabla organiza la lgica de dominio con una clase por cada tabla en la base de datos, y una nica instancia de una clase contiene los diversos procedimientos que actuarn en los datos. La principal distincin con el modelo de dominio es que, si tiene muchos pedidos, un modelo de dominio tendr un objeto de pedido por orden mientras que un mdulo de tabla tendr un objeto para controlar todos los pedidos. A menudo necesitar comportamiento de varios mdulos tabla para hacer un trabajo til. Muchas veces ves varios mdulos de tabla que operan en el mismo registro conjunto (figura 3.24).

69

70

Figura 3.24. Mdulos tabla colaborar con un conjunto nico de registro