arquitectura de software. tema 3
TRANSCRIPT
Sumario...
●TEMA 3. Perte 2. Estilos arquitectonicos○Estilos de Llamada y Retorno
■Arquitecturas en Capas■Model-View-Controller (MVC)■Arquitecturas Orientadas a Objetos■Arquitecturas Basadas en Componentes
Contexto problemico
●Necesito hacer un sistema cuyas partes sean reutilizable y sean tratadas como componentes virtuales independientes. Permitiendose una escala bilidad vertical y horizaontal. Se conoce que las bases de datos de los 3clientes de la empresa son diferentes. Y que dos de ellos no aceptan la migracion a la web, por tanto un ambiente, MS Dos y el otro un ambiente escritorio.
●Que solucion dar (...)
●El sistema se organiza en capas, cada una de las cuales proporciona un conjunto de servicios.
●Se utiliza para modelar la interfaz entre subsistemas.d
Capa y Niveles. Organizacion Estructural
Arquitectura en Capas
●Descripción■Organizado jerárquicamente en capas, donde
cada capa provee servicios a la capa superior y es servido por la capa inferior
■Los componentes son cada una de las capas. Los conectores son los protocolos de interacción entre las capas
●Restricciones○La interacción está limitada a las capas adyacentes
Capa y Niveles. Organizacion Estructural
Como organizar el sistema, una ves determinada la estructura de capas●Orientado a objetos
○El sistema se estructura en un conjunto de objetos débilmente acoplados con interfaces bien definidas
○Cuando se implementan, se utiliza algún modelo de control para coordinar las operaciones de los objetos. (MVC)
Estilos de llamada y Retorno. Capa y Niveles
Como organizar el sistema, una ves determinada la estructura●Orientado a flujos de datos
○Basado en transformaciones funcionales que procesan las entradas y producen salidas.
○ Las transformaciones pueden ejecutarse secuencialmente o en paralelo.
Estilos de llamada y Retorno. Capa y Niveles
●Ventajas○ Facilita la descomposición del problema en varios niveles de
abstracción.
○ Soporta fácilmente la evolución del sistema; los cambios sólo
afectan a las capas vecinas
○ Se pueden cambiar las implementaciones respetando las
interfaces con las capas adyacentes.
●Desventajas○ No todos los sistemas pueden estructurarse en capas.
○ A menudo es difícil encontrar la separación en capas adecuada
Aplicaciones
Capa y Niveles. Organizacion Estructural
Arquitectura en capas
●Desventajas○ Es difícil razonar a priori sobre la separación en capas requerida○ Capas disjuntas requieren drivers de otras capas○ Formatos, protocolos y transportes de la comunicación entre capas
suelen ser específicos y propietarios○ Algunos componentes pueden estar lógicamente vinculados con
más de una capa○ En ocasiones, hay que pasar por encima de capas intermedias○ Otras veces, razones de performance hace que se sitúen funciones
en las capas indebidas (lógica de negocios en procedimientos almacenados)
○ La multiplicación de capas genera procesos adicionales de comunicación y coordinación
Contexto problemico
●Necesito hacer un sistema cuyas partes de representacion, modelo y eventos asociados a el modelo sean extensible, reutilizable y adaptable. Me de la posibilidad de modelar dinamicamente la navegacion d elos escenarios de mi presentacion. NO SE DEBERIA REPROGRAMAR LA ATENCION A EVENTOS: AUMENTA LOS COSTOS DLE PROYECTO.
●Que solucion dar (...)
Modelo-Vista-Controlador● Cuándo se utiliza: Es necesario modularizar la interface de usuario,
las reglas de negocios y el control de eventos○ P. ej. Modelo de programación de Visual Basic, aplicación cliente con
interface gráfica, etc● Modelo.
○ Administra el comportamiento y los datos del dominio de aplicación, responde a requerimientos de información sobre su estado (usualmente formulados desde la vista) y responde a instrucciones de cambiar el estado (habitualmente desde el controlador). Mantiene el conocimiento del sistema. No depende de ninguna vista y de ningún controlador.
● Vista. ○ Maneja la visualización de la información.
● Controlador. ○ Interpreta las acciones del ratón y el teclado, informando al modelo y/o a
la vista para que cambien según resulte apropiado.
Modelo-Vista-Controlador
Framework desarrollado por Trygve Reenskaug en 1970s
Modelo-Vista-Controlador
● Variante pasiva○ Un controlador manipula el modelo exclusivamente. Luego informa
a la vista que el modelo ha cambiado y debe refrescar los cambios. No hay forma en que el modelo notifique sus cambios.
○ Ejemplo: HTTP. El browser responde al input del usuario, pero no se notifica de los cambios en el servidor. Sólo cuando se pide un refresco se pueden refrescar los cambios.
● Variante activa○ El modelo cambia sin intervención del controlador. Ejemplos:
Display de cotizaciones de bolsa. El modelo detecta los cambios en su estado y notifica a la vista para que refresque. Cambio de los menúes visibles de acuerdo con el estado del modelo.
● Variante Documento-Vista○ En aplicaciones gráficas, se relaja la distinción entre vista y
controlador. ● Hay documentación específica sobre implementación de MVC
en ASP.NET.
Modelo-Vista-Controlador● Ventajas
○ Se pueden mostrar distintas variantes de display simultáneamente, porque la vista no depende del modelo (ni el modelo de la vista)
○ La interface tiende a cambiar más rápido que las reglas de negocios. Agregar nuevos tipos de vista no afecta al modelo.
● Desventajas○ Puede aumentar un poco la complejidad de la solución. Como está
guiado por eventos, puede ser algo más difícil de depurar.○ Si hay demasiados cambios en el modelo, la vista puede caer bajo
un diluvio de refrescos, a menos que se prevea programáticamente (por ejemplo, actualizando varias modificaciones en lotes)
Modelo-Vista-Controlador● Evita poner código indebido en la capa impropia
○ P. ej. Instrucciones de base de datos (modelo) en interface usuario (vista)
● Facilita despliegue en caso de modificaciones en el modelo de datos
● Consideraciones no funcionales importantes:○ A veces se logra mejor performance violando las reglas, p. ej.
Incluyendo reglas de negocios en los procedimientos almacenados en la base de datos
Contexto problemico
●Se desea hacer un sistema de manera que se logre una simplificacion del problema en todo el momento de la construccion.
●Que exista un nivel minimo de reutilizacion de los procedimientos.
●Que se permita el enclapsulamiento de los conceptos, la colaboracion, un modelado colaborativo entre angentes pasivos.
Que solucion dar (...)
Estilos de Llamada/Retorno. Arquitectura OO
● Usualmente sincrónicos● Parámetros de llamado, argumentos de respuesta● Variantes:
○ Programa principal / subrutinas○ Arquitecturas RPC○ Arquitecturas basadas en objetos○ Arquitecturas basadas en mensajes/recursos○ Arquitecturas basadas en servicios
● Ventajas○ Refinamiento (descomposición funcional) es sencillo
● Desventajas (en Programa Principal / Subrutinas)○ La reutilización se limita a los procedimientos
Arquitectura basada en Objetos
● A.k.a. Abstracción de dato, tipo de datos abstractos● Deriva de Programa Principal & Subrutinas● Se ha discutido si es un estilo abstracto de arquitectura o más bien una
tecnología concreta de implementación.● Los componentes son objetos● Los conectores son procesos de invocación de procedimientos y funciones● La comunicación es implícitamente stateful (hablando a una instancia de
objeto creada previamente)● Usualmente involucra protocolos, formatos y transportes específicos de
tecnología (REST, CORBA, COM, DCOM)
Arquitectura basada en Objetos
●La relación de herencia no es un organizador arquitectónico importante
○ No puede considerarse un conector○ En una arquitectura podrían “heredarse” no sólo objetos,
sino conectores y estilos arquitectónicos enteros
● Restricciones:○ Los objetos son responsables de la integridad de sus
representaciones○ Dicha representación es ocultada al resto de los objetos
Arquitectura basada en Objetos (3/3)
●Ventajas○ Encapsulamiento, reutilización, fácil descomposición en una colección de
agentes interactivos ○ Gracias al invariante de ocultación es posible reemplazar la
implementación sin que afecte a los clientes (“clientes” del objeto)●Desventajas
○ Propagación de cambios (p. ej. nombres, data types de argumentos) ○ Dependencias en cascada
Si se cambia un objeto, se deben modificar todos los que lo invocan. Efectos colaterales
○ Granularidad muy fina para sistemas grandes ○ Tipos Abstractos de Datos y OO. No otras variantes○ Para invocar métodos de un objeto se debe conocer su identidad
