Page 1

República Bolivariana de Venezuela Ministerio de educación Superior Instituto universitario Tecnológico de Administración Materia: Análisis y diseño de Sistema Profesor: Naydrubys Trejo

ARQUITECTURA DE LOS SISTEMAS DE INFORMACION

Alumno: Xavier Gutiérrez C.I.:18.277.369

Guarenas, 21 de Julio del 2011


Definición de Arquitectura del Sistema de información Es la disciplina y arte encargada del estudio, análisis, organización, disposición y estructuración de la información en espacios de información, y de la selección y presentación de los datos en los sistemas de información interactivos y no interactivos. En relación con la World Wide Web el Information Architecture Institute, define la Arquitectura de la Información como: 

1. El diseño estructural en entornos de información compartida.

2. El arte y la ciencia de organizar y rotular sitios web, intranets, comunidades en línea y software para promover la usabilidad y la ubicabilidad (la característica de ser encontrado a través de las búsquedas en Internet).

3. Una comunidad emergente orientada a aplicar los principios del diseño y la arquitectura en el entorno digital.

La Arquitectura de la Información trata indistintamente del diseño de: sitios web, interfaces de dispositivos móviles o gadgets (como los lectores de mp3), CDs interactivos, videoclips digitales, relojes, tableros de instrumentos de aviones de combate o civiles, interfaces de máquinas dispensadoras, interfaces de juegos electrónicos, etc. (Laverde, A. 2005) Su principal objetivo es facilitar al máximo los procesos de comprensión y asimilación de la información, así como las tareas que ejecutan los usuarios en un espacio de información definido Definición de Arquitectura de software de sistema de informacion En los inicios de la informática, la programación se consideraba un arte y se desarrollaba como tal, debido a la dificultad que entrañaba para la mayoría de las personas, pero con el tiempo se han ido descubriendo y desarrollando formas y guías generales, con base a las cuales se puedan resolver los problemas. A estas, se les ha denominado Arquitectura de Software, porque, a semejanza de los planos de un edificio o construcción, estas indican la estructura, funcionamiento e interacción entre las partes del software. En el libro "An introduction to Software Architecture", David Garlan y Mary Shaw definen que la Arquitectura es un nivel de diseño que hace foco en aspectos "más allá de los algoritmos y estructuras de datos de la computación; el diseño y especificación de la estructura global del sistema es un nuevo tipo de problema". Estilo de arquitectura de Sistema de Información La arquitectura cliente-servidor consiste básicamente en un cliente que realiza peticiones a otro programa (el servidor) que le da respuesta. Aunque esta idea se puede aplicar a programas que se ejecutan sobre una sola computadora es más


ventajosa en un sistema operativo multiusuario distribuido a través de una red de computadoras. En esta arquitectura la capacidad de proceso está repartida entre los clientes y los servidores, aunque son más importantes las ventajas de tipo organizativo debidas a la centralización de la gestión de la información y la separación de responsabilidades, lo que facilita y clarifica el diseño del sistema. La separación entre cliente y servidor es una separación de tipo lógico, donde el servidor no se ejecuta necesariamente sobre una sola máquina ni es necesariamente un sólo programa. Los tipos específicos de servidores incluyen los servidores web, los servidores de archivo, los servidores del correo, etc. Mientras que sus propósitos varían de unos servicios a otros, la arquitectura básica seguirá siendo la misma. Una disposición muy común son los sistemas multicapa en los que el servidor se descompone en diferentes programas que pueden ser ejecutados por diferentes computadoras aumentando así el grado de distribución del sistema. La arquitectura cliente-servidor sustituye a la arquitectura monolítica en la que no hay distribución, tanto a nivel físico como a nivel lógico. La red cliente-servidor es aquella red de comunicaciones en la que todos los clientes están conectados a un servidor, en el que se centralizan los diversos recursos y aplicaciones con que se cuenta; y que los pone a disposición de los clientes cada vez que estos son solicitados. Esto significa que todas las gestiones que se realizan se concentran en el servidor, de manera que en él se disponen los requerimientos provenientes de los clientes que tienen prioridad, los archivos que son de uso público y los que son de uso restringido, los archivos que son de sólo lectura y los que, por el contrario, pueden ser modificados, etc. Este tipo de red puede utilizarse conjuntamente en caso de que se este utilizando en una red mixta Arquitectura de capas en Sistemas de Información La metodología RPM presentada por C. Larman presupone una estructura de tres capas que es típica de los Sistemas de Información. Estas tres capas son: La capa de la Presentación: Esta capa reúne todos los aspectos del software que tiene que ver con las interfaces y la interacción con los diferentes tipos de usuarios humanos Estos aspectos típicamente incluyen el manejo y aspecto de las ventanas, el formato de los reportes, menúes, gráficos y elementos multimedia en general. La capa del Dominio de la Aplicación: Esta capa reúne todos los aspectos del software que tienen que automatizan o apoyan los procesos de negocio que llevan a cabo los usuarios. Estos aspectos típicamente incluyen las tareas que forman parte de los procesos, las reglas y restricciones que aplican. Esta capa también recibe el nombre de la capa de la Lógica de la Aplicación.


La capa del Repositorio: Esta capa reúne todos los aspectos del software que tienen que ver con el manejo de los datos persistentes, por lo que también se le denomina la capa de las Bases de Datos). RPM toca muy superficialmente los problemas asociados al desarrollo de una capa de Presentación. Menciona que es conveniente usar un enfoque de prototipaje y que pueden ser útiles los casos reales de uso; sin embargo no proporciona métodos, principios o lineamientos metodológicos que apoyen el desarrollo de una metáfora de diseño para la interfaz, el diseño lógico de la presentación o su diseño físico. RPM tampoco proporciona muchas luces sobre el desarrollo de la capa del Repositorio y tiende a subestimar su complejidad. Una vez elaborado el Modelo de Uso, RPM recomiendo seguir con actividades de análisis de requerimientos. Para ello se elabora un Modelo Conceptual, en el cual se busca identificar los conceptos importantes del dominio de la aplicación, abstrayendo todo lo que puedan ser mecanismos o conceptos propios de un diseño o de una implementación. Así, en el ejemplo de un Sistema de Punto de Venta, nos interesan los conceptos como Venta, Recibo, Efectivo, Cheque, Impuesto que tienen que ver con los procesos de negocio que se están apoyando y no nos interesan conceptos como Menú, Ventana, Tabla relacional, Consulta a Base de Datos que tienen que ver con cómo mejor implementar los conceptos del negocio. La mayoría de estos elementos de un Modelo Conceptual terminan agrupándose naturalmente en la capa del Dominio de la Aplicación. Este enfoque de RPM termina por sesgar la metodología hacia el desarrollo de la capa del Dominio de la Aplicación, y en la práctica, tiende a hacer presuponer que el desarrollo de las otras capas se puede ajustar al diseño de la capa del Dominio de Aplicación, lo cual no es siempre el caso, incluso dentro del ámbito de los Sistemas de Información. Antes de estudiar el Modelo Conceptual, nos conviene aclarar qué es una arquitectura de capas, su importancia e implicaciones, para tener mayor claridad en los riesgos que corremos al adoptar una metodología como RPM. Arquitectura de Capas 

Preguntar qué conocen por arquitectura de capas (en Sistemas de Operación, Redes de Computadores...).

Nos limitaremos a manejar la noción de arquitectura como una forma de estructurar los elementos de un software.


En toda arquitectura de capa los elementos agrupados en una misma capa pueden comunicarse entre si; pero existen variantes en cuanto a las comunicaciones permitidas entre elementos de capas diferentes:

1. Arquitectura top-down de capas: Los elementos de una capa i+1 pueden enviar solicitudes de servicio a elementos de la capa inferior i. Típicamente se produce una cascada de solicitudes, es decir para satisfacer una solicitud a una capa i+2, ésta requiere enviar varias solicitudes a la capa i+1; cada una de estas solicitudes a la capa i+1 genera a su vez un conjunto de solicitudes a la capa i y así sucesivamente. Una arquitectura top-down es laxa (o no estricta) si los elementos de una capa i+1 pueden enviar solicitudes de servicio directamente a un elemento de cualquiera de las i capas inferiores. 2. Arquitectura bottom-up de capas: Cada elemento de una capa i puede notificar a elementos de la capa superior i+1 de que ha ocurrido algún evento de interés (ej. manejadores de dispositivos). La capa i+1 puede juntar varios eventos antes de notificar a su vez an elemento de la capa i+2. Una arquitectura bottom-up tambien puede ser no estricta si el elemento de la capa i puede notificar a cualquier elemento de cualquier capa superior a la capa i. 3. Arquitectura bidireccional de capas En su forma más común involucra dos pilas de N capas que se comunican entre si. El ejemplo más conocido es el de los protocolos en Redes de Computadores. 

Ventajas o

Reutilización de capas;

o

Facilita la estandarización

o

Dependencias se limitan a intra-capa

o

Contención de cambios a una o pocas capas

Desventajas o

A veces no se logra la contención del cambio y se requiere una cascada de cambios en varias capas;

o

Pérdida de eficiencia;

o

Trabajo innecesario por parte de capas más internas o redundante entre varias capas;

o

Dificultad de diseñar correctamente la granularidad de las capas.

Existen tres propuestas de arquitecturas de capas para Sistemas de Información, donde las capas a veces reciben el nombre de niveles (en Inglés tiers):


Arquitectura de dos capas;

Arquitectura de tres capas;

Arquitectura de cuatro capas.

Dos capas En la actualidad muchos sistemas de información están basados en arquitecturas de dos capas, denominadas: 

Nivel de aplicación;

Nivel de la base de datos.

Existen herramientas de amplio uso que presuponen esta estructura (p. ej. Visual Basic + Access/SQL server). Estas arquitecturas fueron las primeras en aprovecharse de la estructura cliente-servidor (aplicación en los clientes, base de datos como servidor). Las desventajas de dos niveles son bien conocidas: 

El nivel de las aplicaciones se recargan, entremezclando aspectos típicos del manejo de la interfaz con las reglas del negocio;

Las reglas del negocio quedan dispersas entre el nivel de aplicación y los "stored procedures" de la base de datos;

La aplicación queda sobrecargada de información de bajo nivel si hay que extraer los datos de varias bases de datos, posiblemente con estructuras diferentes.

El nivel de aplicación puede ser demasiado pesado para el cliente.

Tres capas Por estas razones, existe una fuerte y bien avanzada tendencia a adoptar una arquitectura de tres capas: 

Aplicación [ojo!]

Dominio de la aplicación;

Repositorio.

La mayoría de estos sistemas buscan conservar la tecnología de BD relacional para la capa del repositorio e introducir la tecnología OO para el dominio de la aplicación. Para la capa de presentación existe una pelea entre tecnología HTML (Java-enabled) vs. generadores GUI. ¿Qué contiene el dominio de la aplicación? En terminología más clásica de BD los tres niveles pueden equipararse, a grosso modo, con: 

Esquema externo;

Esquema conceptual;


Esquema interno o de almacenamiento.

La ventaja es que ahora la aplicación puede describirse únicamente en relación a la semántica de la aplicación, sin tener que preocuparse sobre cómo está implementado ese dominio (ubicación y estructura física de la data). Un punto interesante es dónde ubicar el nivel del dominio de la aplicación, ¿en el lado del cliente o en el lado del servidor? Hay ventajas y desventajas asociadas con cada alternativa, al estudiante interesado le recomiendo el excelente análisis del Fowler (sección 12.2.1, vp. 243-245). Cuatro capas Los desarrollos más recientes empiezan a experimentar con una capa adicional (para 2000 no había visto evidencia de esto en Venezuela): 

Presentación;

Aplicación;

Dominio de la aplicación;

Repositorio

La idea básica es separar todo lo que es programación GUI de la aplicación per se (y por ende tiende a usar frameworks para GUI como MFC). El nivel de la presentación no hace cálculos, consultas o actualizaciones sobre el dominio --de hecho nisiquiera tiene visibilidad sobre la capa del dominio. La capa de la aplicación es la encargada de accesar la capa del dominio, simplificar la información del dominio convirtiéndolo a los tipos de datos que entiende la interfaz: enteros, reales, cadenas de caracteres, fecha y clases contenedoras (container, collection). Una forma de organizar esta nueva capa de la aplicación es considerarla una fachada al dominio. Cada aplicación presenta una fachada diferente (y simple) del dominio a la interfaz. Las ventajas de las cuatro capas se encuentra nuevamente en el texto de Fowler(sección 12.3.1, vp. 249-250). En la sección siguiente del mismo texto se argumenta que el patrón Proxy puede aplicarse a la capa de la aplicación, de forma de tener una parte de la capa en el cliente y otra en el servidor. Los detalles pueden consultarse allí. Finalmente resulta interesante discutir el acoplamiento entre la capa del dominio y la capa del repositorio. Por falta de tiempo, prefiero posponer este acoplamiento hasta la próxima clase.


***De hecho, en el libro de Larman el diagrama de clases que se presenta como parte del modelo conceptual es el diagrama conceptual del dominio de la aplicación. Modelo Vista Controlador

Un diagrama sencillo que muestra la relación entre el modelo, la vista y el controlador. Nota: las líneas sólidas indican una asociación directa, y las punteadas una indirecta. Modelo Vista Controlador (MVC) es un patrón de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos. El patrón de llamada y retorno MVC (según CMU), se ve frecuentemente en aplicaciones web, donde la vista es la página HTML y el código que provee de datos dinámicos a la página. El modelo es el Sistema de Gestión de Base de Datos y la Lógica de negocio, y el controlador es el responsable de recibir los eventos de entrada desde la vista. Historia El estilo fue descrito por primera vez en 1979 1 por Trygve Reenskaug, entonces trabajando en Smalltalk en laboratorios de investigación de Xerox. La implementación original está descrita en Programación de Aplicaciones en Smalltalk-80(TM): Como utilizar Modelo Vista Controlador.2 Descripción del patrón 

Modelo: Esta es la representación específica de la información con la cual el sistema opera. En resumen, el modelo se limita a lo relativo de la vista y su controlador facilitando las presentaciones visuales complejas. El sistema también puede operar con más datos no relativos a la presentación, haciendo uso integrado de otras lógicas de negocio y de datos afines con el sistema modelado.

Vista: Este presenta el modelo en un formato adecuado para interactuar, usualmente la interfaz de usuario.


Controlador: Este responde a eventos, usualmente acciones del usuario, e invoca peticiones al modelo y, probablemente, a la vista.

Muchos de los sistemas informáticos utilizan un Sistema de Gestión de Base de Datos para gestionar los datos: en líneas generales del MVC corresponde al modelo. La unión entre capa de presentación y capa de negocio conocido en el paradigma de la Programación por capas representaría la integración entre Vista y su correspondiente Controlador de eventos y acceso a datos, MVC no pretende discriminar entre capa de negocio y capa de presentación pero si pretende separar la capa visual gráfica de su correspondiente programación y acceso a datos, algo que mejora el desarrollo y mantenimiento de la Vista y el Controlador en paralelo, ya que ambos cumplen ciclos de vida muy distintos entre sí. Aunque se pueden encontrar diferentes implementaciones de MVC, el flujo que sigue el control generalmente es el siguiente: 1. El usuario interactúa con la interfaz de usuario de alguna forma (por ejemplo, el usuario pulsa un botón, enlace, etc.) 2. El controlador recibe (por parte de los objetos de la interfaz-vista) la notificación de la acción solicitada por el usuario. El controlador gestiona el evento que llega, frecuentemente a través de un gestor de eventos (handler) o callback. 3. El controlador accede al modelo, actualizándolo, posiblemente modificándolo de forma adecuada a la acción solicitada por el usuario (por ejemplo, el controlador actualiza el carro de la compra del usuario). Los controladores complejos están a menudo estructurados usando un patrón de comando que encapsula las acciones y simplifica su extensión. 4. El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de usuario. La vista obtiene sus datos del modelo para generar la interfaz apropiada para el usuario donde se reflejan los cambios en el modelo (por ejemplo, produce un listado del contenido del carro de la compra). El modelo no debe tener conocimiento directo sobre la vista. Sin embargo, se podría utilizar el patrón Observador para proveer cierta indirección entre el modelo y la vista, permitiendo al modelo notificar a los interesados de cualquier cambio. Un objeto vista puede registrarse con el modelo y esperar a los cambios, pero aun así el modelo en sí mismo sigue sin saber nada de la vista. El controlador no pasa objetos de dominio (el modelo) a la vista aunque puede dar la orden a la vista para que se actualice. Nota: En algunas implementaciones la vista no tiene acceso directo al modelo, dejando que el controlador envíe los datos del modelo a la vista. 5. La interfaz de usuario espera comenzando el ciclo nuevamente.

nuevas interacciones del usuario,


*ARQUITECTURA DE SISTEMA DE INFORMACIÓN DE COMUNICACIÓN))

SISTEMAS DE INFORMACION  

ARQUITECTURA DE LOS SISTEMAS DE INFORMACION