TEST TBW TEMA 4

La Arquitectura del Software define la estructura de bajo nivel de un sistema software. V. F.

La Arquitectura del Software implica definir los componentes software y la relación entre ellos. V. F.

En Arquitectura del Software, un patrón es una solución reutilizable a un problema común. V. F.

El patrón Modelo-Vista-Controlador (MVC) engloba como conjunto la representación de la información de la interacción con la misma. V. F.

El patrón más extendido para el desarrollo de aplicaciones web es el Adapter. V. F.

La gran mayoría de frameworks implementan versiones modificadas del patrón MVC. Las diferencias principales radican en cómo las tareas del MVC se reparten entre cliente y servidor. V. F.

En toda aplicación web podemos distinguir dos componentes: 1.- Lógica de la aplicación 2.- Gestión de datos. V. F.

En el MVC el controlador gestiona toda la interacción con el usuario. Envía al modelo órdenes de actualización y modificación. V. F.

En el MVC el modelo gestiona toda la interacción con el usuario. Envía a la interfaz órdenes de actualización y modificación. V. F.

El controlador en MVC gestiona las peticiones del cliente (URLs, POST, GET...) en el lado servidor y orquesta las acciones sobre los modelos pero no invoca la generación de vistas ya que de eso se encargará el modelo. V. F.

En el MVC el modelo notifica únicamente alas vistas cuándo se producen cambios en su estado. V. F.

El modelo en MVC mantiene la gestión y estructura de los datos, permite operaciones CRUD y es generalmente realizado por un sistema de gestión de BBDD. V. F.

Un modelo en MVC es cualquier variable u objeto manejado por la aplicación, en general son datos. V. F.

Un modelo en MVC es exclusivamente persistente. V. F.

El modelo en MVC solo se encuentra en el servidor en forma de base de datos relacionales o no relacionales. V. F.

El modelo en el MVC en el servidor se encuentra de manera persistente o temporal y en el cliente de manera persistente. V. F.

El session storage los datos son eliminados cuando termina la sesión. V. F.

En el local storage, al igual que el session storage los datos son temporales. V. F.

La vista en MVC recibe del modelo o pide al mismo la información necesaria para generar la salida al usuario. V. F.

Como sabemos la Arquitectura indica que el Backend es el lado del servidor y el Frontend el lado del cliente. V. F.

El backend y el frontend deben ser definidos por el mismo patrón. V. F.

La arquitectura push-based es cuando el controlador envía los datos a la vista y la pull-based cuando la vista solicita los datos al controlador. V. F.

La arquitectura es pull-based cuando el controlador envía los datos a la vista y la push-based cuando la vista solicita los datos al controlador. V. F.

Solo existen la arquitectura MVC. V. F.

Entre las ventajas del MVC nos encontramos la facilidad de identificar que es un controlador y como separar los componentes para reusar el código. V. F.

MOVE: Modelo, Operaciones, Vistas, Enlazado. V. F.

En MOVE: Modelo: lo que sabe tu aplicación Operaciones: lo que hace tu aplicación Vistas: interfaz con el usuario. Eventos: “pegamento” para unir estos componentes. V. F.

Event-driven es una arquitectura dirigida por eventos. Es una arquitectura síncrona y distribuida pensada para crear aplicaciones altamente escalables. V. F.

La arquitectura Event-Driven se comunica de forma tradicional como MVC. V. F.

La arquitectura PAC es una arquitectura dirigida por eventos. V. F.

La arquitectura PAC es una arquitectura que se basa en una jerarquía de agentes cooperantes. V. F.

PAC Alineador: es el que recupera y procesa los datos y su funcionalidad, como en MVC. Presentación: presenta la información y/o la lógica de operaciones en un formato previamente asignado. Control: se encarga de asuntos como el flujo de control y de la comunicación entre los otros dos componentes. V. F.

HMVC es previo a MVC. V. F.

HMVC usa una jerarquía de capas MVC padre-hijo. V. F.

HMVC permite un desarrollo de aplicaciones más profundo y robusto donde cada tríada funciona en conjunto una de la otra. Una tríada puede solicitar acceso a otra tríada a través de sus controladores. V. F.

SPA son aplicaciones que se basan en una jerarquía de agentes cooperantes. V. F.

SPA tiene tiempo de respuestas mucho más lentos que una aplicación web tradicional. V. F.

Programación reactiva: Paradigma de programación cuya principal característica es el uso de llamadas asíncronas bloqueantes siempre que sea posible. V. F.

La programación reactiva es utilizada en la parte de back-end y se basa en la utilización de e un pool de hilos que realizarán todos los procesos. V. F.

En la programación reactiva se encolan las tareas y se van asignando a algún hilo libre del pool. V. F.

En la programación reactiva todo se basa en vistas. V. F.

Un sistema reactivo debe ser siempre adaptable, resilente y elástico. V. F.

Un sistema reactivo debe ser adaptable: aseguran la calidad del servicio cumpliendo unos tiempos de respuesta establecidos. V. F.

Un sistema reactivo debe ser resilente: se mantienen adaptables incluso ante aumentos en la carga de trabajo. V. F.

Un sistema reactivo debe ser elástico: se mantienen adaptables en cualquier situación, incluso cuando se enfrentan a situaciones de error. V. F.

Un sistema reactivo debe ser orientado a mensajes: minimizan el acoplamiento entre componentes al establecer interacciones basadas en el intercambio de mensajes de manera asíncrona. V. F.

Un sistema reactivo debe ser adaptable: minimizan el acoplamiento entre componentes al establecer interacciones basadas en el intercambio de mensajes de manera asíncrona. V. F.

Un sistema reactivo surge como motivación de la necesidad de responder a las limitaciones de escalado presentes en los modelos de desarrollo actuales. V. F.

Un Rx se compone de tres puntos claves, observable, observador, y schedulers. V. F.

En Rx un observable son las secuencias de datos. Empaqueta los datos que se pueden pasar de un hilo a otro. Emiten los datos periódicamente o solo una vez en su ciclo de vida en función de sus configuraciones. V. F.

En Rx los observadores: consumen la secuencia de datos emitida por el observable. Se suscriben al observable utilizando el método subscribeOn() para recibir los datos emitidos por el observable. V. F.

Rx se usa en programación asincrónica y, por tanto, necesitamos un administrador de subprocesos. Los schedulers son el componente que le indican a los observables y observadores, en qué hilo deben ejecutarse. V. F.

El método observeOn y scheduleOn son utilizados en Rx por los observadores. V. F.

El método suscribeOn es utilizado en Rx por los observables. V. F.

En Rx los observables: consumen la secuencia de datos emitida por el observable. Se suscriben al observable utilizando el método subscribeOn() para recibir los datos emitidos por el observable. V. F.

En Rx un observador son las secuencias de datos. Empaqueta los datos que se pueden pasar de un hilo a otro. Emiten los datos periódicamente o solo una vez en su ciclo de vida en función de sus configuraciones. V. F.