Instituto Universitario De Tecnologa De Administracin Industrial Especialidad: Informtica Seccin: 204A3 Unidad Curricular: Diseo de Sistemas Prof.

Naydrubis Trejo

DISEO DE LA ARQUITECTURA DE UN SISTEMA

Autores: Centeno Deidys C.I. 15.557.149 Centeno Edgar C.I. 19.532.989 Barrios Josu C.I. 18.529.905

Guarenas, Julio 2.011

NDICE

Pg.

Introduccin Arquitectura en Sistemas de Informacin Origen del trmino Arquitectura Arquitectura del software Estilos de arquitectura Cliente / servidor Caractersticas Funcionamiento Ventajas del esquema Cliente/Servidor Desventajas del esquema Cliente/Servidor De Comunicaciones De capas 3 Capas Capa de presentacin Capa de lgica de negocio Capa de acceso a datos 4 Capas Modelo Vista controlador Finalidad del Modelo Vista Controlador Ventajas del Modelo Vista controlador Desventajas del Modelo Vista controlador Conclusiones Referencias Bibliogrficas

03

04 - 06 07 07 - 08

08 09 - 10 10 - 11 11 - 12 13 14 - 15 16 16 16 16 - 17 17 18 18 -19 19 - 20 20 - 21 21 22 23

INTRODUCCION

La programacin se considera un arte y se desarrolla como tal, debido a la dificultad que entraa para la mayora de las personas, pero se han ido descubriendo y desarrollando formas y guas 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 construccin, estas indican la estructura, funcionamiento e interaccin 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 diseo que hace foco en aspectos "ms all de los algoritmos y estructuras de datos de la computacin; el diseo y especificacin de la estructura global del sistema es un nuevo tipo de problema".

En el presente trabajo se estar describiendo como objetivo principal los aspectos relevantes que estn involucrados al tema Arquitectura en Sistemas de Informacin, estudiando los estilos de arquitectura, segn su clasificacin Cliente/servidor, de comunicacin, de capas y el modelo vista controlador desarrollaremos las caractersticas de cada uno de ellos.

Para lograr el objetivo planteado se ha estructurado el trabajo de la siguiente manera: Introduccin se especifica el prembulo del tema, el objetivo del trabajo y el contenido del mismo. Contenido se describen los aspectos involucrados al tema Arquitectura en Sistemas de Informacin Referencias se especifican las fuentes que fueron consultadas para el presente desarrollo.

Arquitectura en Sistemas de Informacin

Origen del trmino

El trmino arquitectura se comienza a usar en el contexto computacional por la empresa IBM alrededor del ao 1959, un hecho que puede ser rastreado en el trabajo de Lyle R. Jonson y Frederick P. Brook, miembros en 1959 del departamento de Organizacin de Mquinas en el centro principal de investigacin de la IBM Computer architecture. Ms adelante uno de estos autores, Frederick P. Brook, en el libro Planning a Computer System: Project Stretch, editado por W. Buchholz en 1962, escribi en el captulo 2: "La arquitectura de computadora, como la otra arquitectura, es el arte de determinar las necesidades de los usuarios de una organizacin y luego disear para satisfacer esas necesidades tan eficientemente como sea posible dentro de condiciones econmicas y tecnolgicas.

Por otra parte, en la literatura tcnica de la IBM podemos encontrar una conceptualizacin del trmino "arquitectura" como: "la estructura conceptual y el comportamiento funcional, distinguindose de la organizacin de los flujos de datos y los controles, el diseo lgico, y la implementacin fsica" (Amdahl, Blaauw, Brooks; 1964).

Aunque el uso del trmino en estos casos se asocia al de Arquitectura de Computadora (Computer Architecture) es obvio que su conceptualizacin marca una pauta importante en la posterior extensin de su uso en otras esferas de la computacin.

En 1967 Nicolas Negroponte fund el Grupo de Arquitectura de Mquinas del MIT (Instituto Tecnolgico de Massachusetts) que fue una combinacin de laboratorio y "think tank" dentro del estudio de los nuevos acercamientos a la Interaccin Persona-Ordenador (Nicholas Negroponte. Wikipedia; 2008). Este laboratorio se transform posteriormente en el famoso MediaLab del MIT.

En julio de 1970 surge la empresa Xerox Palo Alto Research Center (PARC). En sus inicios Xerox Corporation reuni a un grupo de cientficos de clase mundial, especializados en Ciencias de la Informacin y Ciencias Naturales, y les dio la misin de crear una "arquitectura de la informacin" (the architecture of information) (Pake; 1985). Muchas han sido las aportaciones de esta empresa a la tecnologa: la primera computadora personal con una interfaz amigable, el primer editor de texto WYSIWYG, impresora lser, las redes Ethernet, etc. Muchas de las tcnicas investigativas de la empresa estuvieron enfatizadas en la Interaccin Persona-Ordenador (HCI: Human-Computer Interaction) y los aspectos sociales de la computacin (Hearst; 1996).

Es notorio que la primera evidencia documental del uso del trmino compuesto de "Arquitectura de la Informacin" tiene dos elementos interesantes: especialistas en Ciencias de la Informacin y desarrollo enfocado a los usuarios. Este enfoque al usuario se evidencia tambin desde los primeros usos del trmino "arquitectura". Este proyecto de la Xerox fue el que dio vida a la primera computadora personal con interfaz grfica de usuario.

La segunda evidencia histrica del uso del trmino se encuentra en los trabajos de Richard Saul Wurman, entre los que se encuentra un artculo escrito junto con Joel Katz titulado "Beyond Graphics: The Architecture of Information" escrito en octubre del 1975 y publicado por AIA Journal; y una conferencia, ofrecida en el ao 1976, durante una reunin de la AIA (American Institute of Architecture) con el ttulo La Arquitectura de la Informacin (The Architecture of Information). Esta afirmacin fue reconocida en un libro publicado por el propio autor (Wurman; 1996). Wurman es arquitecto de profesin y est considerado como uno de los pioneros del Diseo de Informacin (Jacobson; 1999). Segn su propio sitio web (www.wurman.com) l ha tenido una pasin toda su vida: "hacer la informacin comprensible" ("making information understandable"). Wurman se ha enfocado, desde sus orgenes como profesional, en el diseo de informacin en los entornos urbanos, haciendo hincapi en los procesos de organizacin de la informacin, como pasos previos para hacer la informacin visiblemente comprensible para los usuarios.

Es necesario destacar que la forma en que se ha visto el trmino "arquitectura de informacin" en ingls se muestran de dos formas: "Architecture of information" e "Information architecture". Ambas formas significan lo mismo, solo que la primera est usada en un registro ms formal que la segunda, que es ms coloquial.

La tercera evidencia del uso del trmino "arquitectura de informacin" en la estructura terminolgica "information architecture" la encontramos en una serie de artculos publicados en la dcada de los 80. Los autores de estos artculos se refieren a la Arquitectura de Informacin como una herramienta para el diseo y creacin se sistemas de informacin (information system design). La mayora de estos artculos tienen enfoques prcticos de la aplicacin de la misma.

Arquitectura

Una arquitectura es un entramado de componentes funcionales que aprovechando diferentes estndares, convenciones, reglas y procesos, permite integrar una amplia gama de productos y servicios informticos, de manera que pueden ser utilizados eficazmente dentro de la organizacin.

Debemos sealar que para seleccionar el modelo de una arquitectura, hay que partir del contexto tecnolgico y organizativo del momento y, que la arquitectura Cliente/Servidor requiere una determinada especializacin de cada uno de los diferentes componentes que la integran.

Arquitectura del software

La Arquitectura de Software es la organizacin fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y el ambiente y los principios que orientan su diseo y evolucin.

Paul Clements, 1996: La AS es, a grandes rasgos, una vista del sistema que incluye los componentes principales del mismo, la conducta de esos componentes segn se la percibe desde el resto del sistema y las formas en que los componentes interactan y se coordinan para alcanzar la misin del sistema. La vista arquitectnica es una vista abstracta, aportando el ms alto nivel de comprensin y la supresin o diferimiento del detalle inherente a la mayor parte de las abstracciones.

La arquitectura de software es el conjunto de estructuras que conforman el sistema, lo que comprende los elementos de software, las propiedades externamente visibles de esos elementos (la funcionalidad), y las relaciones existentes entre esos elementos.

Estilos de arquitectura

Cliente / servidor

Diversas aplicaciones se ejecutan en un entorno cliente/servidor. Esto significa que los equipos clientes (equipos que forman parte de una red) contactan a un servidor, un equipo generalmente muy potente en materia de capacidad de entrada/salida, que proporciona servicios a los equipos clientes. Estos servicios son programas que proporcionan datos como la hora, archivos, una conexin, entre otros.

Los servicios son utilizados por programas denominados programas clientes que se ejecutan en equipos clientes. Por eso se utiliza el trmino "cliente" (cliente FTP, cliente de correo electrnico, etc.) cuando un programa que se ha diseado para ejecutarse en un equipo cliente, capaz de procesar los datos recibidos de un servidor (en el caso del cliente FTP se trata de archivos, mientras que para el cliente de correo electrnico se trata de correo electrnico).

Caractersticas Combinacin de un cliente que interacta con el usuario, y un servidor que interacta con los recursos compartidos. El proceso del cliente proporciona la interfaz entre el usuario y el resto del sistema. El proceso del servidor acta como un motor de software que maneja recursos compartidos tales como bases de datos, impresoras, mdems, etc. Las tareas del cliente y del servidor tienen diferentes requerimientos en cuanto a recursos de cmputo como velocidad del procesador, memoria, velocidad y capacidades del disco input-output devices. Se establece una relacin entre procesos distintos, los cuales pueden ser ejecutados en la misma mquina o en mquinas diferentes distribuidas a lo largo de la red. Existe una clara distincin de funciones basada en el concepto de "servicio", que se establece entre clientes y servidores. La relacin establecida puede ser de muchos a uno, en la que un servidor puede dar servicio a muchos clientes, regulando su acceso a recursos compartidos. Los clientes corresponden a procesos activos en cuanto a que son stos los que hacen peticiones de servicios a los servidores. Estos ltimos tienen un carcter pasivo ya que esperan las peticiones de los clientes.

 No existe otra relacin entre clientes y servidores que no sea la que se establece a travs del intercambio de mensajes entre ambos. El mensaje es el mecanismo para la peticin y entrega de solicitudes de servicio. El ambiente es heterogneo. La plataforma de hardware y el sistema operativo del cliente y del servidor no son siempre la misma. Precisamente una de las principales ventajas de esta arquitectura es la posibilidad de conectar clientes y servidores independientemente de sus plataformas. El concepto de escalabilidad tanto horizontal como vertical es aplicable a cualquier sistema Cliente/Servidor. La escalabilidad horizontal permite agregar ms estaciones de trabajo activas sin afectar significativamente el rendimiento. La escalabilidad vertical permite mejorar las caractersticas del servidor o agregar mltiples servidores.

Funcionamiento

En el modelo cliente servidor, el cliente enva un mensaje solicitando un determinado servicio a un servidor (hace una peticin), y este enva uno o varios mensajes con la respuesta (provee el servicio). En un sistema distribuido cada mquina puede cumplir el rol de servidor para algunas tareas y el rol de cliente para otras.

La idea es tratar a una computadora como un instrumento, que por s sola pueda realizar muchas tareas, pero con la consideracin de que realice aquellas que son ms adecuadas a sus caractersticas. Si esto se aplica tanto a clientes como servidores se entiende que la forma ms estndar de aplicacin y uso de sistemas Cliente/Servidor es mediante la explotacin de las PCs a travs de interfaces grficas de usuario; mientras que la administracin de datos y su seguridad e integridad se deja a cargo de computadoras centrales tipo mainframe. Usualmente la mayora del trabajo pesado se hace en el proceso llamado servidor y el o los procesos cliente slo se ocupan de la interaccin con el usuario (aunque esto puede variar). En otras palabras la arquitectura Cliente/Servidor es una extensin de programacin modular en la que la base fundamental es separar una gran pieza de software en mdulos con el fin de hacer ms fcil el desarrollo y mejorar su mantenimiento.

Ventajas del esquema Cliente/Servidor

Uno de los aspectos que ms ha promovido el uso de sistemas Cliente/Servidor, es la existencia de plataformas de hardware cada vez ms baratas. Esta constituye a su vez una de las ms palpables ventajas de este esquema, la posibilidad de utilizar mquinas considerablemente ms baratas que las requeridas por una solucin centralizada, basada en sistemas grandes. Adems, se pueden utilizar componentes, tanto de hardware como de software, de varios fabricantes, lo cual contribuye considerablemente a la reduccin de costos y favorece la flexibilidad en la implantacin y actualizacin de soluciones.

 El esquema Cliente/Servidor facilita la integracin entre sistemas diferentes y comparte informacin permitiendo, por ejemplo que las mquinas ya existentes puedan ser utilizadas pero utilizando interfaces ms amigables al usuario. De esta manera, podemos integrar PCs con sistemas medianos y grandes, sin necesidad de que todos tengan que utilizar el mismo sistema operacional. Al favorecer el uso de interfaces grficas interactivas, los sistemas construidos bajo este esquema tienen mayor interaccin y ms intuitiva con el usuario. En el uso de interfaces grficas para el usuario, el esquema Cliente/Servidor presenta la ventaja, con respecto a uno centralizado, de que no es siempre necesario transmitir informacin grfica por la red pues esta puede residir en el cliente, lo cual permite aprovechar mejor el ancho de banda de la red. Una ventaja adicional del uso del esquema Cliente/Servidor es que es ms rpido el mantenimiento y el desarrollo de aplicaciones, pues se pueden emplear las 7 herramientas existentes (por ejemplo los servidores de SQL o las herramientas de ms bajo nivel como los sockets o el RPC). La estructura inherentemente modular facilita adems la integracin de nuevas tecnologas y el crecimiento de la infraestructura computacional, favoreciendo as la escalabilidad de las soluciones. El esquema Cliente/Servidor contribuye adems, a proporcionar, a los diferentes departamentos de una organizacin, soluciones locales, pero permitiendo la integracin de la informacin relevante a nivel global.

Desventajas del esquema Cliente/Servidor El mantenimiento de los sistemas es ms difcil pues implica la interaccin de diferentes partes de hardware y de software, distribuidas por distintos proveedores, lo cual dificulta el diagnstico de fallas. Se cuenta con muy escasas herramientas para la administracin y ajuste del desempeo de los sistemas. Es importante que los clientes y los servidores utilicen el mismo mecanismo (por ejemplo sockets o RPC), lo cual implica que se deben tener mecanismos generales que existan en diferentes plataformas. Adems, hay que tener estrategias para el manejo de errores y para mantener la consistencia de los datos. La seguridad de un esquema Cliente/Servidor es otra preocupacin importante. Por ejemplo, se deben hacer verificaciones en el cliente y en el servidor. El desempeo es otro de los aspectos que se deben tener en cuenta en el esquema Cliente/Servidor. Problemas de este estilo pueden presentarse por congestin en la red, dificultad de trfico de datos, entre otros.

De Comunicaciones

El sistema de comunicaciones tiene diversos mdulos. Todos ellos son propios de cualquier sistema de comunicaciones. Sin embargo la caracterstica subyacente de dos de ellos (Bsqueda y Comunicacin) es el ambiente mvil, que determina su implementacin adecuada. La

caracterstica ms importante es el hecho de estar o no en lnea con la red, cuya topologa es variable. La segunda caracterstica ms importante es considerar las acciones que son propias del dispositivo local junto con las del dispositivo remoto, ya que es la misma arquitectura la que debe administrar los procesos tanto de inicio de una accin o evento, como el de ser receptor de una accin o un evento.
Comunicacin Involucra todo lo que signifique intercambio de

informacin entre usuarios: correo, chat, voz, avisos de incorporacin de un miembro de la comunidad a la red inalmbrica. Se puede presentar dos tipos de comunicacin: sncrona (chat / voz) cada vez que dos dispositivos pertenecientes a la red (y por tanto dos miembros de la comunidad) se encuentran en el mismo instante comunicndose; asncrona (correo) cada vez que el dispositivo se encuentra incomunicado del resto de la red, pudiendo funcionar en forma independiente. En el caso de la comunicacin sncrona existe previamente un proceso de negociacin en la solicitud a iniciar una sesin en lnea, donde son consultados los perfiles de usuario y los permisos de acceso, con el fin de evitar contactar personas que por alguna razn se ha informado al sistema que son no aptas de contactar. De esta forma, slo se informa de una solicitud de conexin cuando tanto el agente local como el remoto hayan determinado que los participantes no tienen restriccin de contactarse mutuamente.

Bsqueda involucra los recursos que se desea buscar, y los perfiles que se desea compatibilizar. Se cuenta con dos tipos de bsqueda: estructurada y no estructurada. La Bsqueda Estructurada enva una bsqueda de un recurso en forma de texto, y posteriormente el agente de bsqueda se encargar de su transformacin (asociacin) a un Grupo de intereses y posterior transmisin de dicho Grupo. El texto a solicitar se encuentra dentro de un contexto de categoras que selecciona el usuario, lo que internamente corresponde a una Preferencia especfica, a travs de la cual se gua la bsqueda. Por ejemplo, Categora: Cultural, Preferencia: Asistir a Obras de Teatro, el texto a ingresar puede ser: Tengo 2 entradas para ver Hamlet. Esto provoca una bsqueda a travs de la red por la Preferencia indicada, a partir del nodo solicitante. Al final del proceso de bsqueda, que sigue un algoritmo que se explica ms adelante, se obtiene una lista de nodos que pueden responder al requerimiento solicitado. Todos los nodos respuesta tienen perfiles que se asemejan al nodo solicitante, de modo que si se efecta un contacto posterior, existe mayor probabilidad de una relacin exitosa en su inicio, y/o duradera en el tiempo. La Bsqueda No Estructurada, llamada Panel, funciona como un panel dinmico pblico de Ofertas y Necesidades, que vara dependiendo de los miembros visibles en el momento de la consulta. Esta bsqueda no cuenta con el filtro o seleccin por perfil, debido a que la bsqueda de recurso, al no poder clasificarse como estructurada, es tan especfica que no permite restringir los resultados.

Agenda involucra dar a las comunicaciones sentido (semntica), de manera de integrar los medios de comunicacin disponibles con los contactos (miembros de la comunidad). Cuenta con los servicios de recordatorio de tareas, concertacin de reuniones con otros miembros de la red, directorio de miembros, solicitud de avisos de llegada de un miembro al entorno, configurar accesos a cada miembro, formacin de grupos personalizados para envo de correo.

De capas

3 Capas

La arquitectura se basa entonces en 3 capas principales: Capa de presentacin

Esta capa resuelve la presentacin de datos al usuario. Esta capa se encarga entonces de "dibujar" las pantallas de la aplicacin al usuario, y tomar los eventos que el cliente genere (por ejemplo, el hacer click en un botn).

Existen numerosas tecnologas para esta capa (JSP, Struts, JSF, Flex, Velocity, Wicket, GWT), cada una con sus ventajas y desventajas.

Capa de lgica de negocio

Esta capa resuelve la lgica de la aplicacin. Contiene los algoritmos, validaciones y coordinacin necesaria para resolver la problemtica.

Los elementos fundamentales de esta capa son los objetos de dominio. Estos objetos representan los objetos principales del negocio. Son simples objetos que slo contienen los datos que representan (por ejemplo, un Cliente, una Factura, una Direccin, un Producto).

La lgica para manipularlos se encuentra en los llamados objetos de negocio (Business Object, o BO). Estos objetos contienen la lgica del negocio, y manipulan a los objetos de dominio. A su vez, estos son los objetos que exponen mtodos que se transforman en el contrato de la capa de lgica de negocio.

Los BO constan de una interfaz (dnde se expone la lgica del negocio) y una clase que la implementa.

Capa de acceso a datos

Esta capa resuelve el acceso a datos, abstrayendo a su capa superior de la complejidad del acceso e interaccin con los diferentes orgenes de datos.

Esta capa se encarga de proveer un API simple de usar, orientado al negocio, sin exponer complejidades propias de un repositorio de datos.

En esta capa se resuelven:

Cualquier acceso a la base de datos, cualquier acceso a filesystem, cualquier acceso a otros sistemas, cualquier acceso a un repositorio de datos en cualquier forma.

Estos objetos se construyen a partir del patrn Data Access Object (DAO). Los DAO constan de una interfaz (dnde se expone la lgica de acceso a datos) y una clase que la implementa.

4 Capas

Se emplea el aadido de una nueva capa al modelo de 3 capas que se vena manejando con anterioridad y es la capa de Aplicacin La idea bsica es separar todo lo que es programacin GUI de la aplicacin per se (y por ende tiende a usar frameworks para GUI como MFC). El nivel de la presentacin no

hace clculos,

consultas o

actualizaciones sobre el dominio --de hecho ni siquiera tiene visibilidad sobre la capa del dominio. La capa de la aplicacin es la encargada de accesar la capa del dominio, simplificar la informacin del dominio convirtindolo 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 aplicacin es considerarla una fachada al dominio. Cada aplicacin presenta una fachada diferente (y simple) del dominio a la interfaz, el patrn Proxy puede aplicarse a la capa de la aplicacin, de forma de tener una parte de la capa en el cliente y otra en el servidor.

Modelo Vista controlador

Modelo Vista Controlador (MVC) es un patrn de arquitectura de software que separa los datos de una aplicacin, la interfaz de usuario, y la lgica de control en tres componentes distintos. El patrn MVC se ve frecuentemente en aplicaciones web, donde la vista es la pgina HTML y el cdigo que provee de datos dinmicos a la pgina, el modelo es el Sistema de Gestin de Base de Datos y la Lgica de negocio y el controlador es el responsable de recibir los eventos de entrada desde la vista

Finalidad del Modelo Vista Controlador

La finalidad del modelo es mejorar la reusabilidad por medio del desacople entre la vista y el modelo. Los elementos del patrn son los siguientes:

El modelo es el responsable de Acceder a la capa de almacenamiento de datos. Lo ideal es que el modelo sea independiente del sistema de almacenamiento. Define las reglas de negocio (la funcionalidad del sistema). Un ejemplo de regla puede ser: Si la mercanca pedida no est en el almacn, consultar el tiempo de entrega estndar del proveedor. Lleva un registro de las vistas y controladores del sistema.

 Si estamos ante un modelo activo, notificar a las vistas los cambios que en los datos pueda producir un agente externo (por ejemplo, un fichero bath que actualiza los datos, un temporizador que

desencadena una insercin, etc).

El controlador es el responsable de Recibe los eventos de entrada (un clic, un cambio en un campo de texto, etc.). Contiene reglas de gestin de eventos, del tipo SI Evento Z, entonces Accin W. Estas acciones pueden suponer peticiones al modelo o a las vistas. Una de estas peticiones a las vistas puede ser una llamada al mtodo Actualizar (). Una peticin al modelo puede ser Obtener tiempo de entrega (nueva orden de venta).

Las vistas son responsables de Recibir datos del modelo y los muestra al usuario. Tienen un registro de su controlador asociado (normalmente porque adems lo instancia). Pueden dar el servicio de Actualizacin (), para que sea invocado por el controlador o por el modelo (cuando es un modelo activo que informa de los cambios en los datos producidos por otros agentes).

Ventajas del Modelo Vista controlador Es posible tener diferentes vistas para un mismo modelo (ej.. representacin de un conjunto de datos como una tabla o como un diagrama de barras). Es posible construir nuevas vistas sin necesidad de modificar el modelo subyacente. Proporciona

un

mecanismo

de

configuracin

componentes

complejos muchos ms tratable que el puramente basado en eventos (el modelo puede verse como una representacin estructurada del estado de la interaccin).

Desventajas del Modelo Vista controlador Tener que ceirse a una estructura predefinida, lo que a veces puede incrementar la complejidad del sistema. Hay problemas que son ms difciles de resolver respetando el patrn MVC. La curva de aprendizaje para los nuevos desarrolladores se estima mayor que la de modelos ms simples como Webforms. La distribucin de componentes obliga a crear y mantener un mayor nmero de ficheros.

CONCLUSIN

Al finalizar la investigacin queda evidenciado que la arquitectura de los sistemas de informacin tiene sus orgenes en las dcadas sucesivas al nacimiento de las computadoras, aunque no se desarroll a profundidad ya para entonces se tomaba en cuenta como un aspecto clave en la interaccin que habra de tener el usuario final con los sistemas.

Aunque no fue sino hasta la dcada del 70 con la conformacin de la empresa Xerox que la arquitectura de la informacin comienza a desarrollarse ms ampliamente ya que fue uno de los retos impuesto a los cientficos de Xerox. En los aos venideros otros profesionales del campo publicaron diferentes trabajos entre ellos destaco uno que hoy se le considera como un pionero en la materia, Wurman aporto muchas de las bases usadas en la actualidad lo que dio pie al desarrollo de los modelos conocidos hoy en da entre los cuales uno de los ms usados es el Cliente/Servidor el cual tienen dos fases en su funcionamiento, una es la Cliente, la cual de manera principal solicita un servicio o requerimiento y el Servidor, el cual responde al requerimiento hecho por el Cliente.

Al final se puede destacar que en los ltimos aos la arquitectura se ha desarrollado ms ampliamente para cubrir con las crecientes expectativas de los avances en materia de software y computacin esto con el fin de ofrecer a los usuario herramientas ms verstiles que hacen ms fcil el da a da de ellos.

REFERENCIAS BIBLIOGRAFICAS

http://www.nosolousabilidad.com/articulos/historia_arquitectura_informacion.h tm

http://es.kioskea.net/contents/cs/csintro.php3

http://www.dosideas.com/cursos/mod/resource/view.php?id=10

http://neo.lcc.uma.es/evirtual/cdd/tutorial/modelos/Arqcom.html

http://www.dcc.uchile.cl/~mmarin/revista-sccc/sccc-web/Vol5/ecc2.pdf