INSTITUTO UNIVERSITARIO DE TECNOLOGIA                      DE ADMINISTRACION INDUSTRIAL                        ESPECIALIDA...
INTRODUCCIÓNDesde los años 90 del siglo XX, la Arquitectura de Información ha tenido,             unacreciente popularidad...
Definición de arquitecturaToda arquitectura es diseño, pero no todo el diseño es arquitectura. Laarquitectura es aquella q...
 Portátil: Cambio de plataforma hardware, sistemas operativos,        lenguajes.     Mantenible: Detención y reparación ...
independencia del ordenador principal, llamado ahora servidor, que se      especializa    en      ciertas   funciones   es...
proceso, velocidad de proceso, disponibilidad de ancho de banda       conexión de red, capacidad de almacenamiento,…), en ...
Al hablar de redes y de comunicaciones entre ordenadores resultan fundamentales 2conceptos: Protocolos y Arquitectura de c...
•   La capa de la presentación: Esta capa reúne todos los aspectos del       software que tiene que ver con las interfaces...
Este enfoque de RPM termina por sesgar la metodología hacia el desarrollo de la capadel Dominio de la Aplicación, y en la ...
elemento de la capa i puede notificar a cualquier elemento de cualquier       capa superior a la capa i.   3. Arquitectura...
Esto no siempre es posible (piense por ejemplo en una solicitud de servicio a       una base de datos que no logra complet...
Existen tres propuestas de arquitecturas de capas para Sistemas deInformación, donde las capas a veces reciben el nombre d...
La mayoría de estos sistemas buscan conservar la tecnología de BD relacionalpara la capa del repositorio e introducir la t...
dos vistas de un modelo de documento. Una vista podría mostrar un bosquejodel documento y el otro podría mostrar el docume...
CONCLUSIÓNUn proyecto de desarrollo de un Sistema de Información comprende varioscomponentes o pasos llevados a cabo duran...
ReferenciasE. Teniente López - A Olive Ramón. E. Mayol Sarroca – Gómez Seoane.Diseño de Sistema del software en UMLhttp://...
Upcoming SlideShare
Loading in...5
×

diseño de arquitectura de un sistema de informacion

1,339

Published on

Published in: Education, News & Politics
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,339
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
33
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

diseño de arquitectura de un sistema de informacion

  1. 1. INSTITUTO UNIVERSITARIO DE TECNOLOGIA DE ADMINISTRACION INDUSTRIAL ESPECIALIDAD: INFORMATICA SECCION: 204-A-3 UNIDAD CURRICULAR: DISEÑO DE SISTEMA DISEÑO DE LA ARQUITECTURA DE UN SISTEMA DE INFORMACION Profesora: Autores:Naydrubys Trejo Perez Elaynne CI: 20.209.733 Rojas Zulay CI: 18.556.085 Guarenas, Julio del 2011
  2. 2. INTRODUCCIÓNDesde los años 90 del siglo XX, la Arquitectura de Información ha tenido, unacreciente popularidad. Popularidad que decreció con la caída de las "punto com" en el2001, pero que volvió a tomar auge en posteriores años.En la presente información se dan a conocer breves conceptos como:Una arquitectura es un diseño estructural integrado de un sistema, sus elementos ydefiniciones dependen de los requerimientos proporcionados. El concepto de“arquitectura” es ampliamente usado en el contexto de la construcción decomputadoras. Cuando se aplica a los sistemas de información asumimos que unaarquitectura es un plano abstracto que incluye los diseños de procesos de un sistema,basado en principios de diseño y dentro de un marco metodológico.La Arquitectura de Software, consiste en un conjunto de patrones yabstracciones coherentes que proporcionan el marco de referencia necesariopara guiar la construcción del software para un sistema de información.La Arquitectura de Software establece los fundamentos para que analistas,diseñadores, programadores, etc. trabajen en una línea común que permitaalcanzar los objetivos del sistema de información, cubriendo todas lasnecesidades.Y los diferentes estilos de arquitectura de un sistema de información:El modelo cliente/servidor: Es una arquitectura de procesamientos cooperativodonde uno de los componentes pide servicios a otro. Este términooriginalmente es aplicado a la arquitectura de software; describe elprocesamiento entre dos o más programas; una aplicación yun servicio soportante.De comunicación, de capas, entre otros.
  3. 3. Definición de arquitecturaToda arquitectura es diseño, pero no todo el diseño es arquitectura. Laarquitectura es aquella que representa las decisiones de diseño significativasque le dan forma a un sistema, donde lo significativo puede ser medido por elcosto del cambio. Definición de arquitectura de softwareLa arquitectura del software es una descripción de los subsistemas ycomponentes (computacionales) de un sistema software y las relaciones entreellos.La determinación de la arquitectura del software consiste en la toma dedecisiones respecto a: • La organización del sistema software. • La selección de los elementos estructurales y sus interfaces. • comportamiento de estos elementos estructurales. • La posible composición de los elementos estructurales en subsistemas más grandes. • El estilo que guía esta organización.Teniendo en cuenta las propiedades (requisitos no funcionales) del sistema delsoftware que se quiere lograr: • eficiencia, cambiabilidad, usabilidad, fiabilidad…La arquitectura del software es el resultado de la actividad de diseñoarquitectónico del software.Propiedades: • Cambiable:  Extensible: Nuevas funcionalidades o mejora de los componentes.
  4. 4.  Portátil: Cambio de plataforma hardware, sistemas operativos, lenguajes.  Mantenible: Detención y reparación de errores.  Reestructurable: Reorganización de componentes.• Interoperable: Capacidad de dos o más entidades software de intercambiar funcionalidad y datos.• Eficiente:Tiempo de respuesta, rendimiento, uso de recursos.• Fiable:  Tolerancia a fallos: Pérdida de conexión y recuperación posterior.  Robustez: Protección contra el uso incorrecto y el tratamiento de errores inesperados.• Probable: Facilitar las pruebas del sistema.• Reusable:  Reusar software ya existente.  Hacer software para ser reusado.• Integridad conceptual: Harmonía, simetría y predictibilidad. Estilos de arquitectura Cliente/Servidor: Representa un modelo de organización de la relación entre los distintos y numerosos ordenadores que existen en una empresa. Es la conexión en la que el “terminal” es llamado ahora cliente el cual tiene una capacidad propia de ejecución muy alta, con
  5. 5. independencia del ordenador principal, llamado ahora servidor, que se especializa en ciertas funciones especificas. La arquitectura cliente/servidor es una distribución lógica de funciones donde la capacidad de proceso de los ordenadores personales se emplea extensamente.Esta arquitectura consiste básicamente en que un programa cliente realizapeticiones a otro programa, servidor, que le da respuesta. Por lo tanto, en estaarquitectura se divide la capacidad de proceso de información entreordenadores cliente y servidor. En realidad la separación entre cliente yservidor es una separación de tipo lógico, donde el servidor no esnecesariamente una sola maquina, ni posee necesariamente un solo programa.En general, este modelo utiliza el procesamiento distribuido entre clientes yservidores conectados todos ellos por una red de comunicación.Características significativas: o Las funciones del cliente y del servidor pueden estar en plataformas separadas, o en la misma plataforma. o Un servidor puede dar servicios a múltiples clientes de forma concurrente. o Cada plataforma puede ser escalable de manera independiente. o El esquema cliente/servidor construye además, a proporcionar, a los diferentes departamentos de una organización, soluciones locales, pero permitiendo la integración de la información relevante a nivel global.  Peer to peer: Esta arquitectura convierte a los usuarios en servidores de contenido, de forma transparente, proporcionándoles un papel que va mas allá del que hasta este momento habían tenido, como simples consumidores de datos. En termino de funcionalidad, esta arquitectura consiste en que los nodos de una red pueden adoptar tanto el rol del cliente, como el del servidor con los demás nodos de la red. Basa su funcionamiento, dirigido a optimizar los recursos de la red (capacidad de
  6. 6. proceso, velocidad de proceso, disponibilidad de ancho de banda conexión de red, capacidad de almacenamiento,…), en que todos los usuarios pueden compartir. Existen variantes de esta arquitectura, ya que la red puede llamarse P2P, aunque utilice una filosofía C/S para ciertas tareas:Redes P2P centralizadas: En esta modalidad todas las transacciones sehacen a través de un único servidor que sirve de punto de enlace entre todoslos nodos, y como servidor de acceso al contenido. Esta arquitectura tieneproblemas de escalabilidad del servidor, de tolerancia a fallos, etc.Redes P2P “puras” o totalmente descentralizada: No requieren de un nodocentral. Son más comunes, y las más versátiles.Redes P2P hibridas: En esta topología, se puede observar la interacciónentre un nodo o más nodos que actúan de servidores centrales paraadministrar los recursos de ancho de banda de conexión de la red, y gestionarlos enrutamientos y comunicaciones entre nodos; aunque lo hacen de maneratransparente, es decir, sin conocer la identidad de cada nodo, y sin almacenarcontenidos, o proporcionar otros recursos que pueden ser alcanzados por otrosnodos.Las redes P2P se usan muy a menudo para compartir toda clase de archivosque contienen: audio, video, texto, software y datos, en cualquier formatodigital. Esta arquitectura se liga a menudo a distribución de contenidos, sinembargo, su aplicación en la empresa a puesto de manifiesto su potencialidadpara otro tipo de soluciones, tales como, el soporte a servicios de comunicacióny colaboración, la implantación de sistemas descentralizados de computaciónmasiva, el desarrollo de plataformas C2C (client to client) de soporte acomplejas relaciones comerciales, etc.  De comunicación: Es una estructura organizada jerárquicamente con el fin de permitir el intercambio de datos entre niveles lógicos semejantes en distintas máquinas o terminales de la misma o distinta red.
  7. 7. Al hablar de redes y de comunicaciones entre ordenadores resultan fundamentales 2conceptos: Protocolos y Arquitectura de comunicación.Los protocolos se utilizan para la comunicación entre entidades de diferentessistemas. Ejemplos de entidades son programas de aplicación de usuario, paquetesde transferencia de ficheros, sistemas de manejo de BD y terminales. Ejemplo desistemas son ordenadores, terminales y sensores remotos. Podemos decir, que unaentidad es algo capaz de enviar o de recibir información y un sistema es un objeto quecontiene una o más entidades. Para que 2 entidades puedan comunicarse han dehablar el mismo idioma, mediante una serie de convenciones entre estas, a esteconjunto de convenciones se le denomina protocolo, que puede definirse como elconjunto de reglas que gobiernan el intercambio de datos entre 2 entidades.Debido a la complejidad que requiere la comunicación entre 2 entidades de diferentessistemas, encontramos implementadas las funciones de comunicación mediante unconjunto de protocolos estructurados. Esta organización de los protocolos se realizamediante capas o niveles con objeto de simplificar su diseño. El propósito de cadacapa es ofrecer ciertos servicios a las capas superiores.La capa n en una máquina conversa con la capa n de la otra máquina. Las reglas yconvecciones utilizadas en la conversación se conocen como protocolo de la capa n.A las entidades de una misma capa correspondiente a máquinas diferentes se ledenomina procesos pares.En la realidad, la transferencia de datos desde una capa n de una máquina a la capa nde otra máquina no se realiza directamente, sino que los datos son pasados a la capainmediatamente inferior de la máquina y así sucesivamente hasta llegar a la capa 1,donde nos encontramos el medio físico, por donde se realiza la comunicación con laotra máquina.Entre cada par de capas adyacentes hay una interfaz, la cual define losservicios y operaciones primitivas que la capa inferior ofrece a la superior. Alconjunto de capas con las interfaces y protocolos recibe el nombre dearquitectura de la red.  De capas: 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:
  8. 8. • 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. • 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 unacapa de Presentación. Menciona que es conveniente usar un enfoque deprototipaje y que pueden ser útiles los casos reales de uso; sin embargo noproporciona métodos, principios o lineamientos metodológicos que apoyen eldesarrollo de una metáfora de diseño para la interfaz, el diseño lógico de lapresentación o su diseño físico.RPM tampoco proporciona muchas luces sobre el desarrollo de la capa del Repositorioy tiende a subestimar su complejidad.Una vez elaborado el Modelo de Uso, RPM recomiendo seguir con actividades deanálisis de requerimientos. Para ello se elabora un Modelo Conceptual, en el cual sebusca identificar los conceptos importantes del dominio de la aplicación, abstrayendotodo lo que puedan ser mecanismos o conceptos propios de un diseño o de unaimplementación. Así, en el ejemplo de un Sistema de Punto de Venta, nos interesanlos conceptos como Venta, Recibo, Efectivo, Cheque, Impuesto que tienen que ver conlos procesos de negocio que se están apoyando y no nos interesan conceptos comoMenú, Ventana, Tabla relacional, Consulta a Base de Datos que tienen que ver concómo mejor implementar los conceptos del negocio. La mayoría de estos elementosde un Modelo Conceptual terminan agrupándose naturalmente en la capa del Dominiode La Aplicación.
  9. 9. Este enfoque de RPM termina por sesgar la metodología hacia el desarrollo de la capadel Dominio de la Aplicación, y en la práctica, tiende a hacer presuponer que eldesarrollo de las otras capas se puede ajustar al diseño de la capa del Dominio deAplicación, lo cual no es siempre el caso, incluso dentro del ámbito de los Sistemas deInformación.Antes de estudiar el Modelo Conceptual, nos conviene aclarar qué es una arquitecturade capas, su importancia e implicaciones, para tener mayor claridad en los riesgos quecorremos 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
  10. 10. 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 sí. El ejemplo más conocido es el de los protocolos en Redes de Computadores.Al implementar una arquitectura top-down de capas, se deben tomar en cuenta lossiguientes factores: 1. ¿Cuál es el criterio de abstracción para agrupar servicios/clases en una capa? Mencionar el criterio Presentación-Dominio de Aplicación-Repositorio de Sistemas de Información. 2. Determinar el número de capas En términos simplistas, a más capas más flexibilidad pero menor desempeño. 3. Típicamente las capas más internas ofrecen menos servicios. Esto ayuda la reutilización de capas ("pirámide invertida de reuso"). 4. El grado de encapsulamiento de las capas. A mayor encapsulamiento, menor dependencia externa sobre la estructura de una capa. 5. Estructura interna de cada capa. 6. ¿Cuánta información pasar de una capa a otra? Tomemos el caso de la arquitectura top-down. Es muy posible que, de acuerdo con el tipo de servicio solicitado, la capa inferior requiera una cantidad de información variable. En un modelo puro "empujado" (push), la capa superior está obligada a enviarle toda la información que pueda llegar a hacerle falta a la capa inferior en la solicitud.
  11. 11. Esto no siempre es posible (piense por ejemplo en una solicitud de servicio a una base de datos que no logra completarse por estar fuera de línea. ¿Qué se hace: reintentar, abandonar, usar una fuente alterna?). En el modelo contrario, "halado" (pull o por demanda), la capa inferior solicita mayor información sólo si le hace falta --¿pero de quién la pida? El modelo de solicitudes top-down presupone un invocador anónimo y un invocado conocido. La solución la proporciona el patrón Editorial-Suscriptor (Publish-Subscribe) que encapsula la idea del callback. Este patrón de diseño lo estudiaremos más adelante. 7. Diseñe la estrategia de manejo de errores. Este es un aspecto que es frecuentemente obviado, aunque tiene impacto fuerte tanto en el tiempo de procesamiento como en el esfuerzo de programación. Típicamente se recomienda manejar el error en el nivel que lo descubrió, si esto no es posible, dejar que lo resuelva la capa más arriba, pero generalmente abstrayendo el tipo de error para que sea comprensible en término de los servicios de la capa superior.Todo patrón tiene ventajas y desventajas: en el caso de la arquitectura decapas ya las hemos mencionado [dejar que los estudiantes las resuman]: • 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.
  12. 12. Existen tres propuestas de arquitecturas de capas para Sistemas deInformación, donde las capas a veces reciben el nombre de niveles (en Ingléstiers): • Arquitectura de dos capas; • Arquitectura de tres capas; • Arquitectura de cuatro capas.Dos capasEn la actualidad muchos sistemas de información están basados enarquitecturas 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 enaprovecharse de la estructura cliente-servidor (aplicación en los clientes, basede 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 capasPor estas razones, existe una fuerte y bien avanzada tendencia a adoptar unaarquitectura de tres capas: • Aplicación • Dominio de la aplicación; • Repositorio.
  13. 13. La mayoría de estos sistemas buscan conservar la tecnología de BD relacionalpara la capa del repositorio e introducir la tecnología OO para el dominio de laaplicación. Para la capa de presentación existe una pelea entre tecnologíaHTML (Java-enabled) vs. Generadores GUI.¿Qué contiene el dominio de la aplicación? En terminología más clásica de BD los tresniveles 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 enrelación a la semántica de la aplicación, sin tener que preocuparse sobre cómoestá implementado ese dominio (ubicación y estructura física de la data).Cuatro capasLos 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; • RepositorioLa idea básica es separar todo lo que es programación GUI de la aplicación perse (y por ende tiende a usar frameworks para GUI como MFC). El nivel de lapresentación no hace cálculos, consultas o actualizaciones sobre el dominio--de hecho nisiquiera tiene visibilidad sobre la capa del dominio. La capa de laaplicación es la encargada de accesar la capa del dominio, simplificar lainformación del dominio convirtiéndolo a los tipos de datos que entiende lainterfaz: enteros, reales, cadenas de caracteres, fecha y clases contenedoras(container, collection).  Modelo vista controlador (MVC): Separa los datos de aplicación (contenidos en el modelo) de los componentes de presentación grafica (la vista) y lógica de procesamiento de la entrada (el controlador).El MVC no restringe una aplicación a una sola vista o un solo controlador. Enun programa más sofisticado (como un procesador de palabras), podría haber
  14. 14. dos vistas de un modelo de documento. Una vista podría mostrar un bosquejodel documento y el otro podría mostrar el documento completo. El procesadorde palabras podría también implementar varios controladores: uno paramanejar la entrada del teclado y otro para manejar las selecciones del ratón. Sicualquiera de los dos controladores realiza un cambio en el modelo, tanto lavista del bosquejo como la ventana de vista previa de impresión mostrarán elcambio inmediatamente, cuando el modelo notifique los cambios a todas lasvistas.Otro beneficio clave para el patrón de arquitectura MVC es que losdesarrolladores pueden modificar cada componente de manera individual, sintener que modificar los demás componentes. Por ejemplo, los desarrolladorespodrían modificar la vista que muestra el documento en línea, y no tendrían quemodificar ni el modelo ni las demás vistas o controladores.
  15. 15. CONCLUSIÓNUn proyecto de desarrollo de un Sistema de Información comprende varioscomponentes o pasos llevados a cabo durante la etapa del análisis, el cual ayuda atraducir las necesidades del cliente en un modelo de Sistema que utiliza uno más delos componentes: Software, hardware, personas, base de datos, documentación yprocedimientos.En una organización o Empresa, el análisis y Diseño de Sistemas, es el proceso deestudiar su Situación con la finalidad de observar cómo trabaja y decidir si esnecesario realizar una mejora; el encargado de llevar a cabo estas tareas es elanalista de sistemas.Lo más importante de los estilos de arquitectura de un sistema de información:Cliente/Servidor puede incluir múltiples plataformas, bases de datos, redes ysistemas operativos. Estos pueden ser de distintos proveedores, enarquitecturas propietarias y no propietarias y funcionando todos al mismotiempo. Por lo tanto, su implantación involucra diferentes tipos de estándares:APPC, TCP/IP, OSI, NFS, DRDA corriendo sobre DOS, OS/2, Windows oPC UNIX, en Token Ring, Ethernet, FDDI o medio coaxial, sólo por mencionaralgunas de las posibilidades.
  16. 16. ReferenciasE. Teniente López - A Olive Ramón. E. Mayol Sarroca – Gómez Seoane.Diseño de Sistema del software en UMLhttp://books.google.co.ve/books?id=p7nD8_g77_MC&printsec=frontcover&dq=dise%C3%B1o+de+sistemas&hl=es&ei=eTAiTsXRBsrs0gGR-dSsAw&sa=X&oi=book_result&ct=result&resnum=2&ved=0CC8Q6AEwAQ#v=onepage&q&f=falseJuan José Goñi Zabala. El cambio son personas: la dirección de los procesosde cambiohttp://books.google.co.ve/books?id=E-PgDbPnSKsC&pg=PA85&dq=definicion+arquitectura+cliente/servidor+del+sistema+de+informacion&hl=es&ei=8FIiTuzuIYj40gGrusnZAw&sa=X&oi=book_result&ct=result&resnum=1&ved=0CCgQ6AEwAA#v=onepage&q&f=falseHarvey M. Deitel,Paul J. Deitel. Cómo programar en Javahttp://books.google.co.ve/books?id=is2J44U4DpsC&pg=PA910&dq=arquitectura+modelo+vista+controlador+del+sistema+de+informacion&hl=es&ei=ckYkTuriNM6ftgev0Z23Aw&sa=X&oi=book_result&ct=result&resnum=2&ved=0CDUQ6AEwAQ#v=onepage&q&f=false

×