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.
|
