ESTILO DE LLAMADA Y RETORNO

En este estilo se hace especial énfasis a la modificabilidad y escalabilidad. siendo los más generalizados en sistemas a gran escala, en este grupo se encuentran las arquitecturas de programa principal y subrutina, los sistemas basados en llamadas a procedimientos remotos, así como también los sistemas

orientados a objetos y los jerárquicos en capas (sobre esta arquitectura se hace referencia, en el apartado de los tipos de arquitectura).

10.3.1 Model-View-Controller (MVC)

Son Taylor y Medvidovic, quienes hacen referencia y reconocen este estilo arquitectónico, sin embargo Robert Allen y David Garlan, se refieren a esta, como una microarquitectura, el Model-View-Controller ha sido propio de las aplicaciones Smalltalk, desde 1992 aproximadamente, muchas veces ha sido definido como un patrón de diseño o como práctica recurrente.

Gráfico 8. Arquitectura Model-view-controller

Este modelo realiza una separación entre el modelado y lo que se considera el dominio, asi como la presentación y las diferentes acciones que se basan en los datos ingresados por el usuario en tres clases distintas, esto quiere decir lo siguiente:

 _{El modelo: Administra la actuación y los datos del dominio de} aplicación, respondiendo a los requerimientos de información sobre su estado y respondiendo a las instrucciones de cambio de estado cuando así corresponda.

 _{Controlador: Es el encargado de interpretar las acciones tanto del} ratón, asi como tambien del teclado, asi como de informar al modelo y/o a la vista para que realicen el cambio de acuerdo al requerimiento. Existen una dependencia hacia el modelo por parte de la vista, como del controlador, sin embargo el no depende de otras clases.

• _Ventajas

 Puede soportar vistas múltiples, esto debido a que hay una separación entre el modelo y la vista, esto quiere decir, que la interfaz del usuario permite visualizar múltiples vistas de los datos iguales en forma secundaria.

 Se adapta a los cambios con facilidad, esto debido a que los requerimientos de interfaz suelen ser cambiantes de manera constante, puede ocurrir que los usuarios prefieran nuevas opciones de representación entre otras y como no existe una dependencia entre la vista y el modelo, realizan estos cambios, se decir, agregar una nueva opción de presentación no afecta el modelo.

• _Desventajas

 La complejidad, se profundiza la orientación a eventos relacionados en el código de la interfaz de usuario, llegando a ser difícil de depurar en ocasiones.

 Generación de costo de actualizaciones frecuentes, esto debido que si el modelo experimenta cambios frecuentes, se podría desbordar las vistas con diversos requerimientos de actualización.

10.3.2 Arquitecturas Orientadas a Objetos

Los elementos de este tipo de estilo esta representado por los objetos, considerados también instancias de los tipos de datos denominados abstractos. Para David Garlan y Mary Shaw, los objetos son una representación de un tipo de componentes que ellos denomina managers, los cuales son los responsables de salvaguardar la integridad de su representación. Un aspecto importante es que la representación

de forma interna de un objeto en particular no es alcanzable desde otros objetos.

Se basan en los principios de encapsulamiento, herencia y polimorfismo, también se consideran que las unidades de modelado, asi como el diseño, la implementación, los objetos y las interacciones de estos, son el centro de las atribuciones en el diseño de una arquitectura y de igual manera en la estructura de la aplicación. Las interfaces se hallan separadas de las implementaciones.

Por otro lado, se puede decir que el mejor ejemplo de OO para sistemas distribuidos es Common Object Request Broker Architecture (CORBA), en la cual las interfaces son definidas a través de la Interface Description Language (IDL); un Object Request Broker interviene en las interacciones entre objetos que se consideran clientes y objetos que son los servidores, esto en ambientes conocidos como distribuidos.

Existe una restricción en cuanto a que una interfaz logre ser efectuada por variadas clases. Este estilo puede considerarse a una familia arquitectónica más amplia como la Arquitecturas de Llamada-y-Retorno (Call-and-Return).

• _Ventajas

 Se puede cambiar la ejecución de determinado objeto sin causar una afectación a sus clientes.

 Transformar determinados problemas en una recopilación de agentes que interactuan..

 Se considera un objeto como una entidad que puede ser reutilizable en el ambiente de desarrollo.

• Desventajas

Se debe conocer la identidad del objeto para poder interactuar con otro utilizando para ello una petición de procedimiento, entre otras limitaciones que posee esta arquitectura.

10.3.3 Arquitecturas Basadas en Componentes

Esta arquitectura se fundamenta en los principios que fueron definidos por la ingeniería de software, por otro lado, mucho se ha discutido sobre el significado de componentes, en este sentido Clemens Alden Szyperski han ofrecido una definición que es bastante operativa, y es la siguiente: para ellos un componente de software, es una unidad de composición que contiene interfaces detalladas.

Que sea una unidad de composición y no de construcción quiere decir que no es necesario crear, es decir, se puede obtener hecha, o se puede realizar desde casa con el fin de que otras aplicaciones de la empresa la utilicen en sus propias composiciones.

De igual manera se puede definir un componente de forma pragmática como un artefacto diseñado y desarrollado de acuerdo ya sea con CORBA Component Model (CCM), JavaBeans y Enterprise JavaBeans en J2EE y lo que alternativamente se llamó OLE, COM, ActiveX y COM+, y luego .NET.

• _Ventajas

 Las interfaces se encuentran separadas de las implementaciones, siendo estas junto a sus interacciones el centro de incumbencias en el diseño arquitectónico.

 Los componentes pueden soportan algún régimen de introspección, de modo que su funcionalidad y propiedades puedan ser descubiertas y utilizadas en tiempo de ejecución.

• _Desventajas

 Una interfaz sea implementada por múltiples componentes.

 Los estados de un componente no son accesibles desde el exterior Es importante hacer mención, que el marco arquitectónico estándar para la tecnología de componentes está constituido por los cinco puntos de vista de RM-ODP (Empresa, Información, Computación, Ingeniería y Tecnología).