Diseña una Arquitectura de Software

Descripción

En este ejercicio se necesita diseñar la arquitectura de un sistema en línea para venta de libros y gadgets. Se basará en servicios web y mensajería. En esta etapa sólo tienes que tomar y documentar las decisiones sobre la arquitectura Back-End del sistema, por ejemplo, ¿Qué tipo de servicios web se utilizarán?, ¿Cómo se realizará la gestión del ciclo de vida de los servicios?, ¿Qué interfaces externas se prestarán a otros sistemas?, etc. 

Para tomar estas decisiones arquitectónicas necesitas considerar arquitecturas de referencias y patrones de diseño.

Lee atentamente los siguientes requisitos y asegurate de entender la funcionalidad que será proporcionada en línea por el sistema antes de empezar a tomar y documentar tus decisiones arquitectónicas. ¡A continuación, se indican las instrucciones de cómo hacer esto!

Requisitos

Tomar pedidos	Los clientes pueden hacer pedidos a través de dos canales diferentes: sitio web y call center. Cada uno de estos sistemas se basa en una tecnología diferente y almacena pedidos entrantes en un formato de datos diferentes. El sistema call center es una aplicación empaquetada, mientras que el sitio web es una aplicación J2EE personalizada. Queremos tratar todos los pedidos, independientemente de su fuente. Por ejemplo, un cliente debe poder hacer un pedido a través del call center y comprobar el estado del pedido en el sitio web.
Procesar pedidos	El procesamiento de un pedido implica varios pasos, incluyendo la verificación del inventario, las mercancías de envío y facturación al cliente. Tanto los sistemas de facturación como de inventario, captan mensajes de órdenes nuevas y se reenvía el mensaje combinado (del procesamiento de ambos sistemas). Los mensajes de órdenes nuevas, contienen generalmente varios elementos (múltiples pedidos individuales) y los sistemas de inventario pueden procesar sólo pedidos individuales. No hay que olvidar que tenemos sistemas de dos inventarios, uno para libros y otro para gadgets, lo que significa que necesitamos enrutar los mensajes de órdenes nuevas para un sistema de inventario adecuado.
Registro	Todos los mensajes del call center son enviados a un sistema de registro donde se almacenan en una base de datos por 1 año. La pérdida de registro de mensajes es aceptable. Decide cómo el sistema de registro se comunicará con la base de datos.
Rastreo de órdenes	Los clientes y proveedores deben ser capaces de recuperar información acerca de sus pedidos. Por lo tanto, cada pedido debe tener un ID único. Los clientes y proveedores pueden enviar solicitudes al sistema de envío a través de una interfaz web y obtener información sobre el estado de su orden. Debido a que solamente el comerciante es capaz de comunicarse directamente con el envío (que no se basa en mensajes), el sistema Monsters en línea debe proporcionar la interfaz adecuada que será utilizada por el cliente web. Decide cómo realizar el seguimiento de pedidos así como el diseño de la interfaz apropiada para la comunicación entre el cliente web y el sistema de envío.
Anuncios	Cada cierto tiempo, el comerciante desea anunciar ofertas especiales a los clientes. Los clientes pueden suscribirse a anuncios seleccionados desde el sistema de venta en línea. El comerciante también desea anunciar ofertas especiales sólo para los clientes preferenciales. Decide cómo realizar anuncios a suscriptores y clientes preferenciales.
Inicio de sesión del cliente	Un cliente tiene que iniciar sesión para poder comprar libros y gadgets en línea y es responsable de guardar su sesión con el fin de mantener el estado de sus pedidos (objetos remotos con estado). Si la sesión está inactiva por un período de tiempo predefinido la sesión debería expirar y automáticamente el cliente se desconecta. Decide cómo implementar la creación y gestión del ciclo de vida de las sesiones.

Attribute-Driven Design (ADD) 2.0

El método ADD es un enfoque a la definición de una arquitectura de software en el que se basa el proceso de diseño de los requisitos del software de atributos de calidad. ADD es un proceso de diseño recursivo que descompone un sistema o elemento del sistema mediante la aplicación de tácticas arquitectónicas [Bass 03] y los patrones que satisfacen los drivers. ADD sigue esencialmente el ciclo “Plan, Do, and Check”:

• Plan: Los atributos de calidad y las restricciones de diseño son consideradas para seleccionar qué tipos de elementos se utilizan en la arquitectura.
• Do: Los elementos son instanciados para satisfacer los atributos de calidad, así como los requisitos funcionales.
• Check: El resultado es analizado para determinar si los requisitos son satisfechos.

Este proceso se repite hasta que todos los requisitos de gran importancia arquitectónica se cumplen.

-->

Paso 1: Confirmar que existe suficiente información sobre los requerimientos

¿Que se hace en el paso 1?

En el primer paso, usted confirma que hay suficiente información acerca de los requisitos para proceder con el paso 2. En esencia, se asegura que los stakeholders ​​han dado prioridad a los requisitos de acuerdo a los objetivos de negocio y a la misión. También debe confirmar que se dispone de información suficiente sobre los atributos de calidad para proceder.

Como arquitecto, se debe priorizar la lista de requerimientos para determinar en qué elementos del sistema se deben concentrarse durante el diseño. Se deben considerar los requisitos y su impacto potencial en la estructura de la arquitectura, en orden descendente de importancia para los stakeholders. Los requisitos que no han sido priorizadas deberán ser marcados y devueltos a para su clasificación.

Además, se debe determinar si existe suficiente información acerca de los atributos de calidad del sistema. Cada atributo de calidad debe ser expresado de la forma "estímulo-respuesta", de la misma manera como escenarios de atributos de calidad [Bass 03]. Each requirement should be described as the system’s measurable quality attribute response to a specific stimulus with the following made explicit:

• Estímulo fuente

• Estímulo

• Artefacto

• Entorno

• Respuesta

• Respuesta de medida

Conocer esta información para cada atributo de calidad ayuda al arquitecto para seleccionar varios patrones de diseño y tácticas para lograr esos requisitos. Si esta información no está disponible, usted debe crear requisitos derivados o trabajar con los interesados ​​para aclarar los requisitos. En cualquier caso, los escenarios de atributos de calidad se puede utilizar para documentar estos requisitos.

¿Que decisiones de diseño se toman durante el paso 1?: No se toman decisiones de diseño durante este paso.

-->

Paso 2: Seleccionar un elemento del sistema para descomponer

¿Que se hace en el paso 2?

En este segundo paso, se debe elegir qué elemento del sistema será el enfoque de diseño en los pasos subsiguientes (el elemento con el cual se va a trabajar). Se puede llegar a este paso en una de las siguientes dos maneras:

• Caso 1: Primera iteración. Si se accede por primera vez a la Etapa 2 como parte de una "nueva creación" de desarrollo. El único elemento que puede descomponerse es el propio sistema. Por defecto, todos los requisitos son asignados a ese sistema.
• Caso 2: Más de una iteración. Se están perfeccionando un sistema parcialmente diseñado y se ha visitado el paso 2 anteriormente. En este caso, el sistema se ha dividido en dos o más elementos, y los requisitos han sido asignados a estos elementos. Debe elegir uno de estos elementos como el elemento central de las etapas subsiguientes.

En el segundo caso, es posible elegir el elemento que se centran en base a una de las cuatro áreas de interés:

1. Conocimiento de la arquitectura actual
   1. Si es el único elemento que puede elegir (por ejemplo, todo el sistema o el último elemento de la izquierda)
   2. El número de dependencias que tiene con otros elementos del sistema (por ejemplo, mayor o menor dependencias)
2. Riesgo y dificultad
3. Criterio de negocio
4. Criterio de la organización

¿Que decisiones de diseño se toman durante el paso 1?: No se toman decisiones de diseño durante este paso.

-->

Paso 3: Identificar los drivers arquitecturales candidatos

¿Que se hace en el paso 3?

En este punto, usted ha elegido un elemento del sistema a descomponerse, y las partes interesadas han dado prioridad a los requisitos que afecten a ese elemento. Durante este paso, podrás clasificar estos mismos requisitos por segunda vez en función de su impacto relativo en la arquitectura. Esta segunda clasificación puede ser tan simple como la asignación de "alto impacto", "medio impacto" o "bajo impacto" para cada requisito.

Dado que las stakeholders clasificaron los requisitos inicialmente, la segunda clasificación basada en el impacto arquitectura tiene el efecto de ordenar parcialmente los requisitos en un grupos. Si utiliza simples rankings alta / media / baja, los grupos serían:

(H,H) (H,M) (H,L) (M,H) (M,M) (M,L) (L,H) (L,M) (L,L)

-->

Paso 4: Elige un concepto de diseño que satisfaga los drivers arquitecturales

¿Que se hace en el paso 4?

En el paso 4, debe elegir los tipos principales de elementos que aparecerán en la arquitectura y los tipos de relaciones entre ellos. Restricciones de diseño y los atributos de calidad (que son los aspirantes a drivers de arquitectura) se utilizan para determinar los tipos de elementos, relaciones y sus interacciones.

Como arquitecto, debe seguir estos seis sub-pasos:

1. Identificar los problemas de diseño que se asocian con los drivers arquitectónicos candidatos. Por ejemplo, para un requisito de atributo de calidad en cuanto a disponibilidad, las preocupaciones principales de diseño podría ser la prevención de fallo, detección de fallos, y la recuperación de fallos [Bass 03].
2. Para cada problema de diseño, crear una lista de patrones alternativos que responden a la preocupación. Los patrones en la lista se derivan de:
   1. Conocimientos, habilidades y experiencia con la que los patrones.
   2. Táctica de arquitectura conocida para lograr los atributos de calidad [Bass 03] Si un driver arquitectónico candidato se refiere a más de un atributo de calidad, se pueden aplicar múltiples tácticas.
   3. Otras fuentes, como libros, documentos, material para conferencias, motores de búsqueda, productos comerciales, etc.

Para cada patrón en su lista, usted debe

• Identificar los parámetros discriminantes de cada modelo para ayudar a elegir entre los patrones y tácticas en la lista. Por ejemplo, en cualquier patrón de reinicio (por ejemplo, warm restart, cold restart), la cantidad de tiempo que le toma a un reinicio es un parámetro discriminante. Para los patrones usados ​​para lograr la modificabilidad (por ejemplo, layers), un parámetro discriminante es el número de dependencias que existen entre los elementos en el patrón.
• Estimar los valores de los parámetros discriminantes

 Si te interesa conocer los pasos 4, 5, 6, 7, 8 de ADD consulta  ADDv2.0 o enviame un correo!

Bridge **

Cuando se especifica un diseño usando Layers o Domain Object...

… debemos tener en cuenta que la implementación de los objetos puede variar independientemente de sus interfaces.

✦✦✦

Un objeto puede tener una de varias implementaciones diferentes. La diferencia entre estas implementaciones podría ser específico de la plataforma, o una decisión de ejecución. La utilización de la herencia para separar el interfaz y la implementación, sin embargo, puede exponer el cliente del objeto a las decisiones sobre su implementación.

La herencia es un acercamiento típico a la separación del interfaz y la implementación: una interfaz declara la funcionalidad visible del objeto, e implementa los métodos declarados en la interfaz. De ser accesado vía la clase concreta, no obstante, existe un acoplamiento que se convierte en un pasivo en la lucha para un diseño estable: el código de cliente ahora depende del tipo de aplicación subyacente. Si se accede constantemente a través de la interfaz, los usuarios de objeto no se verán afectados por los cambios en la clase de implementación subyacente, pero no están libres de todas las dependencias de la implementación: en el momento de la creación, el cliente debe tomar una decisión sobre el tipo subyacente, que puede estorbar y complicar el código de cliente.

Por lo tanto:

Dividir el objeto en dos partes: una abstracción handle que ofrece una interfaz y una jerarquía de impulsor separada que proporciona las distintas implementaciones para el cuerpo. 

NOTA

Tipo: Estructura

Desacopla una clase abstracta de su implementación para que puedan variar independientemente.

Reflection *

Cuando DOMAIN MODEL se transforma en una arquitectura de software técnica...

.. . a veces debe proporcionar un diseño que se prepara para la evolución y la integración de los cambios imprevistos.

✦✦✦

Apoyar la variación es la clave para arquitecturas sostenibles de aplicaciones de larga vida: con el tiempo, deben responder a las nuevas y cambiantes tecnologías, requisitos y plataformas. Sin embargo, es difícil predecir lo que puede variar en una aplicación y cuando debe responder a una petición de variación específica.

Para complicar las cosas, la necesidad de variación puede ocurrir en cualquier momento, específicamente, mientras la aplicación está en uso productivo. Las variaciones también pueden ser de cualquier escala, desde ajustes locales de un algoritmo para modificaciones fundamentales de la infraestructura de distribución. Sin embargo, mientras que la variación de la aplicación debe ser posible en el momento apropiado, la complejidad asociada con las variaciones particulares deben ser ocultados de mantenedores, y debe haber un mecanismo uniforme para soportar diferentes tipos de variación.

Por lo tanto:

Objetivar la información acerca de las propiedades y aspectos variantes de la estructura de la aplicación, el comportamiento y estado en un conjunto de metaobjects.

NOTA

Tipo: Arquitectónico

Proporciona un medio para cambiar dinámicamente la estructura y el comportamiento de un software.

Microkernel **

Cuando se realiza una transformación de DOMAIN MODEL (182) en una arquitectura de software técnica....

…. Debemos diseñar para soportar la escalabilidad y adaptabilidad en diferentes escenarios de desarrollo...

✦✦✦

Algunas aplicaciones existen en múltiples versiones. Cada versión ofrece diferente conjunto diferente de funcionalidad a los usuarios, o se diferencia de otras versiones en aspectos específicos, tales como su interfaz de usuario. A pesar de sus diferencias, sin embargo, todas las versiones de la aplicación debe estar basado en una arquitectura común y el núcleo funcional.

El objetivo es evitar la deriva de la arquitectura entre las versiones de la aplicación y reducir al mínimo esfuerzo de desarrollo y mantenimiento de la funcionalidad compartida. Además, actualizar una versión de la aplicación a otra mediante la adición y eliminación de características, o mediante el cambio de su aplicación, no debería requerir más que modificaciones mínimas partes del sistema. De manera similar, debe ser fácil proporcionar una versión de la aplicación particular, con diferentes interfaces de usuario, y también para ejecutar la versión en distintas plataformas, permitiendo a los clientes la utilización más adecuadamente dentro de sus entornos específicos.

Componer diferentes versiones de un aplicación extendiendo un core común vía plug and play con un mínimo de cambio en la infraestructura.

Un microkernel implementa la funcionalidad compartida por todas las versiones de las aplicaciones y proporciona la infraestructura para la integración de la funcionalidad específica de la versión. Servidores internos autónomos implementan la versión de la funcionalidad específica, y los servidores externos de las interfaces específicas de la versión de usuario o APIs. Configurar una versión de la aplicación específica mediante la conexión de los servidores internos correspondientes con el microkernel, y la adecuada servidores externos para acceder a su funcionalidad. En consecuencia, todas las versiones de la aplicación comparten un núcleo común funcional y la infraestructura, pero proporcionar un conjunto de funciones look-and-feel.

✦✦✦

Una arquitectura MICROKERNEL asegura que cada versión de la aplicación, pueden adaptarse para su propósito. Los usuarios o sistemas cliente sólo obtiene la funcionalidad y el look-and-feel que requieren, pero no tienen que incurrir en el costo de todo lo que no necesita. En general, la evolución de una versión particular hacia las funciones nuevas o diferentes "sólo" requiere reconfigurarla con las correspondientes servidores internos y externos: el propio microkernel no se ve afectado por dichas actualizaciones.

Los servidores internos y externos y otras versiones de la aplicación son igualmente afectados. Además, una arquitectura micronúcleo minimiza los esfuerzos de desarrollo y el mantenimiento de todos los miembros de la familia de aplicación: cada servicio, la interfaz de usuario, o API se aplica sólo una vez.

La estructura interna de la microkernel se basa típicamente en capas (185). Los resúmenes capa inferior de la plataforma del sistema subyacente, apoyando así la portabilidad de todos los niveles superiores. La segunda capa implementa la funcionalidad de la infraestructura, tales como la gestión de los recursos, en la que el microkernel depende. La capa superior aloja la funcionalidad de dominio que es compartida por todas las versiones de la aplicación. La capa superior incluye los mecanismos para la configuración de servidores internos con el micronúcleo, así como para el encaminamiento de las peticiones de los servidores externos a su destinatario.

Cada función específica y autónoma y responsabilidad dentro de la microkernel puede ser realizado como un objeto de dominio (208), que apoya su implementación independiente y evolución. La funcionalidad de enrutamiento del microkernel se implementa a menudo como un mediador (410) que recibe las solicitudes a través de una interfaz uniforme y envía estas solicitudes a las funciones de dominio correspondientes en el microkernel o los servidores internos. Para reducir al mínimo el consumo de recursos, particularmente la memoria, la capa de enrutamiento puede utilizar un configurador de componentes (490) o un administrador de objetos (492) para cargar los servidores internos de la demanda, descargarlos después de su uso, y controlar su ciclo de vida. Este diseño también permite la actualización de una versión de la aplicación particular, con una funcionalidad nueva, distinta, o modificados de forma dinámica en tiempo de ejecución.

NOTA

Tipo: Arquitectónico

Dentro de un software, separa un núcleo funcional de la funcionalidad añadida.

Presentation-Abstraction-Control

Al transformar un modelo de dominio (182) en una arquitectura de software técnica. . .

. . . hay que considerar que en ocasiones diferentes responsabilidades funcionales de una aplicación puede requerir diferentes paradigmas de interfaz de usuario.

✦✦✦

Una interfaz hombre-máquina permite a los usuarios interactuar con una aplicación a través de un 'paradigma', como formularios o menús y cuadros de diálogo. Sin embargo, algunas aplicaciones están mejor operado a través de un paradigma de interfaz distinta para cada tipo de funcionalidad que se ofrecen.

Por ejemplo, en un sistema de control del robot, la funcionalidad para la definición de una misión requiere una interfaz de usuario diferente de la funcionalidad de control de un robot móvil durante una misión. Sin embargo, debemos asegurarnos de que todas las funciones y sus interfaces de usuario forman un sistema coherente. Además, los cambios en cualquier interfaz de usuario no afecta a la aplicación de su funcionalidad correspondiente, ni la de las demás funciones y sus interfaces de usuario asociados. Del mismo modo, los cambios en las implementaciones de una función distinta no debe afectar a las interfaces de usuario y las implementaciones de otras funciones.

Por lo tanto:

La estructura de la aplicación interactúa como una jerarquía de agentes desconectados: un agente de nivel superior, varios agentes de nivel intermedio, y muchos agentes de nivel inferior. Cada agente es responsable de una funcionalidad específica de la aplicación y proporciona una interfaz de usuario especial para ello.

Los agentes de nivel inferior implementan de forma autónoma la funcionalidad con la que los usuarios pueden interactuar, por ejemplo la administración, manejo de errores, y la manipulación de datos. En el nivel medio se localizan los coordinar que son múltiples agentes relacionados con los agentes de nivel inferior, por ejemplo, todos los puntos de vista que visualizan un determinado tipo de datos. El agente de alto nivel proporciona la funcionalidad básica que es compartido por todos los agentes, como el acceso a una base de datos.

Dividir cada agente en tres partes. Una parte de la presentación define el agente de la interfaz de usuario. Una parte de la abstracción proporciona un agente específico del dominio funcionalidad. Una parte de control conecta la presentación con la abstracción y permite al agente comunicarse con otro agentes. La conexión de los agentes en la jerarquía se realiza a través de sus controles.

Dividir cada agente en tres partes. A parte de la presentación se definen los usuarios interactúan con un agente a través de su presentación. Todas las peticiones de usuario a la funcionalidad respectiva en su abstracción están mediados por el control del agente. Si una acción del usuario requiere el acceso o la coordinación de otros agentes, mediar esta solicitud a los mandos de estos agentes, ya sea hacia arriba o hacia abajo en la jerarquía, y de allí a sus abstracciones.

Los usuarios interactúan con un agente a través de su presentación. Todas las peticiones de usuario a la funcionalidad respectiva en su abstracción se realizan mediante el agente del control. Si una acción del usuario requiere el acceso o la coordinación de otros agentes, mediar esta solicitud a los controles de estos agentes, ya sea hacia arriba o hacia abajo en la jerarquía, y de allí a sus abstracciones.

✦✦✦

Una arquitectura PRESENTATION-ABSTRACTION-CONTROL ayuda a conectar múltiples subsistemas autónomos o aplicaciones completas, incluso con modelos especializados de interacción hombre-máquina a un sistema coherente (distribuido). La desventaja es su complejidad: varias interfaces de usuario debe ser proporcionada, y las acciones promovidas por una interfaz de usuario específico debe ser coordinada cuidadosamente y de forma explícita si el flujo de control se extiende por varios subsistemas y las reacciones de las causas o ver los cambios en su interfaz de usuario asociados. En consecuencia, una arquitectura PRESENTATION-ABSTRACTION-CONTROL sólo es rentable si un sistema de software no puede ser aplicado por un paradigma de interfaz de usuario única.

Para especificar una PRESENTATION-ABSTRACTION-CONTROL (PAC), la arquitectura, identificar todas las responsabilidades independientes que la aplicación debe ofrecer a sus usuarios. Cada responsabilidad se encapsula dentro del nivel bajo del agente. Si varios agentes de la funcionalidad social o necesidad de coordinación, factor cabo esta funcionalidad (coordinación) en un agente de nivel intermedio. No puede haber múltiples niveles de agentes de nivel intermedio dentro de una arquitectura PAC. Funcionalidad compartida por todos los agentes es proporcionado por el agente de nivel superior. Tal disociación soporta la modificación independiente de los agentes sin afectar a otros agentes, y permite a cada agente proporcionar su propia interfaz de usuario. Proporcionar a todos los agentes una arquitectura modelo-vista-controlador (188): la abstracción correspondiente con el modelo y su división en objetos de dominio (208), y la presentación de las vistas y controladores. Cambios en la interfaz del agente por lo tanto afectará a su realización.

El desacoplar la abstracción de un agente de su presentación a través de un componente de control que es un MEDIATOR (410) con una doble responsabilidad. En primer lugar, debe encaminar todas las solicitudes de los usuarios de la presentación del agente para la funcionalidad adecuada en su abstracción. También debe encaminar todos notificaciones de propagación del cambio de la abstracción a las opiniones de la presentación. En segundo lugar, el control debe coordinar la cooperación entre los agentes. Si una solicitud de usuario recibida por un agente particular no puede ser manejado por el agente sólo, las rutas de control de la solicitud a los controles apropiados de agentes de alto o de nivel inferior, junto con sus datos de entrada asociados. Los resultados se devuelven en la misma forma, pero a la inversa. De manera similar, el control de un agente puede recibir solicitudes y datos de los controles de otros agentes. Las solicitudes para ser enrutados se pueden encapsular dentro de objetos COMMAND (412), y los datos que contiene DATA TRANSFER OBJECTS (418). Los controles son la clave para un acoplamiento débil entre los agentes: si cambia de un agente de extracción, los efectos sobre otros agentes se limitan a sus controles.

NOTA

Tipo: Arquitectónico

Descompone un software interactivo en una jerarquía de agentes que colaboran. Cada agente desempeña alguna función de presentación por pantalla, funcionalidad básica (abstracción) o comunicación entre agentes (control).

Model-View-Controller **

Al transformar un modelo de dominio (182) en una arquitectura de software técnica, o especificando un agente en una configuración PRESENTATION-ABSTRACTION- CONTROL (191). . .

. . . debemos tener en cuenta que la interfaz de usuario de una aplicación cambia con más frecuencia que su funcionalidad del dominio.

✦✦✦

Las interfaces de usuario son propensas a solicitudes de cambio: algunos deben soportar múltiples look-and-feel skins, otras deben abordar las preferencias específicas del cliente. Sin embargo, los cambios en una interfaz de usuario no debe afectar a la funcionalidad de una aplicación subyacente, que generalmente es independiente de su presentación, y también cambia con menos frecuencia.

Los cambios en una interfaz de usuario debe ser fácil y local a la parte de interfaz modificada. Una interfaz de usuario modificable sin embargo no debe degradar la calidad de la aplicación del servicio: en cualquier momento se debe mostrar el estado actual de la computación, y responder a los cambios de estado de inmediato. Para complicar aún más las cosas, en un sistema que admite múltiples skins look-and-feel, cada skin puede cambiar a un ritmo diferente, que requiere desacoplamiento adicional de diferentes partes de la interfaz de usuario.

Divide la aplicación interactiva en tres partes disociadas: procesamiento, entrada y salida. Garantiza la coherencia de las tres partes, con la ayuda de un mecanismo de propagación de cambios.

Encapsula el núcleo funcional de la aplicación dentro de un modelo cuya aplicación es independiente de la interfaz de usuario específica look-and-feel and mechanics. Para cada aspecto del modelo que se presentará en la interfaz de usuario de la aplicación, introduce uno o más vistas autónomas. Asociar cada vista con un conjunto de controladores independientes que reciben la entrada del usuario y traducir esta entrada en las solicitudes de ya sea el modelo o la vista asociada. Permite a los usuarios interactuar con la aplicación únicamente a través de los controladores.

NOTA:

Tipo: Arquitectonico

Descompone un software interactivo en tres componentes: el modelo que tiene la funcionalidad y los datos, la vista que presenta la información en la pantalla, y el controlador que trata las entradas de información.