AS

JSP, SERVLET, APPLET

JSP, SERVLET, JSF

JSP, SERVLET, LDF

new Class.forName("nombre_clase");

Class.forName("nombre_clase").newInstance();

Class.forName("nombre_clase");

Verdadero

Falso

Facilita el cambio global de la interfaz de usuario

Permite crear interfaces de usuario enriquecidas

Permite generar interfaces de usuario no solo para entornos web, sino para otros
entornos y dispositivos, como por ejemplo para móviles

Es el patrón que más se suele utilizar en la capa de negocio. Esto se debe a que no presenta ninguna desventaja con respecto a los otros patrones de diseño

La interacción con bases de datos relacionales es más compleja que en otros patrones y suelen aparecer muchas clases, en algunos casos de gran tamaño

El mantenimiento de la aplicación suele ser complicado, ya que cualquier cambio en las reglas de negocio significa realizar muchos cambios en las clases existentes

Table Module y Row Data Gateway

Service Layer y Two Step View

Active Record y Data Mapper

Verdadero

Falso

Es una tabla hash que se utiliza para redireccionar las peticiones que llegan desde la capa de presentación a cada uno de los comandos de la capa de negocio

El patrón Table Data Gateway no se utiliza en la capa de datos sino en la de negocio

Es un objeto que sirve de interfaz con una tabla de la base de datos. Una instancia gestiona todas las filas de la tabla

Table Module

Domain Model

Data Mapper

Optimiza la gestión de los datos en la base de datos, sirve de filtro para asegurar que los usuarios no realicen ataques intencionados al sistema, aunque requiere una mayor carga de trabajo

Permite organizar eficientemente la lógica de negocio, evita la duplicidad de código y aprovecha al máximo los mecanismos de la programación orientada a objetos

Es un patrón sencillo de implementar, resulta fácil comprender el funcionamiento de la lógica de negocio y ofrece un buen rendimiento.

Al principio del ciclo, para dar soporte técnico durante el análisis de los requisitos, y en las primeras etapas del diseño del software, para definir la arquitectura del sistema

Durante el diseño, la construcción y pruebas del sistema, liderando el proceso de definición de la arquitectura, planificando las tareas que debe realizar el equipo de desarrollo y verificando que el sistema no presenta fallos de implementación

Al principio del ciclo, para definir el ámbito del sistema, validar los requisitos y liderar la definición de la arquitectura; y al final del ciclo, para resolver los posibles problemas que puedan aparecer durante la aceptación del producto

Row Data Gateway

Domain Model

Transaction Script

El patrón Domain Model mantiene una instancia para cada objeto almacenado en la base de datos, mientras que el Table Module mantiene una sola instancia para todos los objetos de un mismo tipo

El Table Module representa un procedimiento aislado y el Modelo del Dominio realiza todos los casos de uso de una aplicación

El Domain Model es un patrón de la capa de negocio y el Table Module de la capa de datos

Seguridad en la transacción de datos

Las dos anteriores son correctas

Permiten el desarrollo de aplicaciones escalables

LAZY o EAGER. La primera carga todo el contexto mientras que la segunda carga únicamente los datos

LAZY o EAGER. La primera solo carga los datos mientras que la segunda carga todo el contexto

No existe la carga de entidades

Una sesión Stateless no mantiene un estado conversacional con el cliente

Una sesión Stateful no mantiene un estado conversacional con el cliente

Una sesión Stateless puede implementarse como un servicio web, una sesión Stateful no

Las reglas de negocio se suelen incluir dentro de las entidades del Domain Model, en forma de estructuras condicionales (normalmente switch), de forma que, dependiendo de las condiciones de los datos de entrada, se ejecuta una regla u otra. Si se quieren añadir, modificar o eliminar algunas reglas, hay que modificar el código de las entidades afectadas

Las reglas de negocio se estructuran convenientemente en las interfaces de usuario, de forma que cuando se quiere ejecutar un proceso de negocio, son los propios usuarios los que especifican qué reglas se deben aplicar y qué información de la base de datos se debe utilizar en cada caso

Las reglas de negocio se representan en forma de objetos independientes y cada una de las entidades del Domain Model ejecuta las reglas que les afectan haciendo uso del patrón Strategy. Esto tiene la ventaja de que si se quieren añadir nuevas reglas, solo hay que crear nuevas clases, con lo que no hace falta modificar el código de las entidades definidas en el Domain Model

UrlCompose

RequestDispatcher

HttpServletResponse

Mantener en un registro toda la información de una tabla que se transmite entre la capa de presentación y la base de datos

Gestionar el acceso de cada uno de los usuarios a los recursos del sistema con el fin de optimizar el uso de los mismos e implementar los mecanismos de seguridad necesarios

Organizar la lógica de negocio en procedimientos donde cada procedimiento gestiona una petición desde la capa de presentación

Patrón Command

Patrón Template View

Patrón Observer

El conjunto de elementos que sirven para conformar los diagramas que documentan cada uno de los artefactos que definen la estructura básica de una arquitectura

Lo que necesita cada uno de los stakeholders para comprobar que sus necesidades están siendo consideradas durante el desarrollo del producto

La representación de uno o más aspectos estructurales de una arquitectura que ilustra cómo la arquitectura aborda uno o más intereses de uno o más stakeholders

Es la clase que se encarga de aplicar cada una de las reglas de negocio a las entidades del dominio, de manera que mantiene una correspondencia entre cada una de las entidades y las reglas que se les aplican

Es el mecanismo por el cual las aplicaciones web son capaces de guardar la información de los usuarios que están accediendo en un momento concreto, con el fin de garantizar la seguridad en las transacciones

Es una capa de mapeadores que mueve los datos entre los objetos y la base de datos mientras los mantiene independientes entre sí

Diseño

Seguridad

Rendimiento

... a los desarrolladores de software a crear páginas web de contenido únicamente estático

... a los desarrolladores de software a crear páginas web de contenido dinámico

... a los desarrolladores de software a crear páginas web que no utilicen ninguna arquitectura de desarrollo

Java EE

Ninguno de los otros

Microsoft .NET

Las reglas de negocio se estructuran convenientemente en las interfaces de usuario, de forma que cuando se quiere ejecutar un proceso de negocio, son los propios usuarios los que especifican qué reglas se deben aplicar y qué información de la base de datos se debe utilizar en cada caso

Las reglas de negocio se suelen incluir dentro del código de los Transaction Script, en forma de estructuras condicionales (normalmente switch), de forma que, dependiendo de las condiciones de los datos de entrada, se ejecuta una regla u otra. Si se quieren añadir, modificar o eliminar algunas reglas, hay que modificar el código de los Transaction Script afectados

Las reglas de negocio se representan en forma de objetos independientes y cada uno de los Transaction Script ejecutan las reglas que les afectan haciendo uso del patrón Strategy. Esto tiene la ventaja de que si se quieren añadir nuevas reglas, solo hay que crear nuevas clases, con lo que no hace falta modificar el código de los Transaction Script

Stateless Session y Stateful Session

Client Session State, Server Session State y Database Session State

Transaction Script y Application Controller

Capturar los requisitos de los usuarios durante el proceso de análisis

Identificar e involucrar a los stakeholders

Adoptar un rol de liderazgo en la realización de la arquitectura

Session Beans y JSP Beans

Stateless Beans y Stateful Beans

Session Beans y Message-driven Beans

JPA hace uso de objetos de tipo entidad

Un objeto JPA se crea desde la interfaz javax.persistence.EntityManager

Uno de los objetivos de JPA es poder ser independientes de la BBDD

Exchange Syndication Light Tuition

Extensible Stylesheet Language Transformations

Extended Support for Literate Translation

Aísla completamente la lógica de negocio del acceso a la base de datos, de tal forma que los dos pueden variar de forma independiente

Produce un acoplamiento elevado entre la capa de negocio y el diseño de la base de datos

Es muy útil en aplicaciones donde la lógica de negocio no es muy compleja, como por ejemplo en aplicaciones donde existen muchos procesos de tipo CRUD

Punto de Vista Operacional

Punto de Vista del Contexto

Punto de Vista de Despliegue

La arquitectura de un sistema comprende un número de elementos arquitectónicos y las relaciones entre éstos

La descripción de la arquitectura documenta una arquitectura para sus stakeholders y demuestra que cumple con sus necesidades

La arquitectura de un sistema se compone, exclusivamente, de las perspectivas y vistas que se necesitan para que los desarrolladores puedan implementar el sistema

Las otras dos son correctas

El patrón Transaction Script es muy útil cuando la aplicación que se desea desarrollar está centrada en los datos de la base de datos y solo necesita procesos sencillos orientados a visualizar o actualizar esos datos

El patrón Domain Model es muy útil cuando la lógica de negocio de una aplicación es bastante compleja

Permite diseñar la aplicación haciendo uso de todas las características de la orientación a objetos, ya que las clases que define representan entidades reales que interaccionan con otras entidades

La ventaja principal es que facilita el acceso a bases de datos relacionales, ya que se organiza de forma similar a una tabla de registros

El patrón Table Module no sirve para estructurar la capa de negocio

@EJB

@Remote

@Localhost

La forma de visualizar cada uno de los modelos de la arquitectura, centrándose en los elementos y relaciones que definen el comportamiento global de los sistemas, utilizando una serie de principios fundamentales

Conjunto de vistas que se utilizan para definir cada uno de los intereses de cada uno de los stakeholders

Colección de patrones, plantillas y convenciones para construir un tipo de vista. Define los stakeholders cuyos intereses están reflejados en el punto de vista y las directrices, principios y plantillas de modelos para construir sus vistas

Java Servlet

ASP

JSP

Es un componente del lado del servidor que encapsula la lógica de negocio de una aplicación

Es una interfaz del lado del servidor que encapsula la lógica de negocio de una aplicación

Es un contenedor del lado del servidor que encapsula la lógica de negocio de una aplicación

Application Controller

Front Controller

Separated Interface

Calidad, Tiempo y Recursos

Coste, Calidad y Tiempo

Recursos, Coste y Calidad