Arquitecturas de Desarrollo de Software

Presentación del tema: "Arquitecturas de Desarrollo de Software"— Transcripción de la presentación:

1 Arquitecturas de Desarrollo de Software
Capitulo 2 Arquitecturas de Desarrollo de Software Miguel Ángel Niño Zambrano

2 Motivación Discurso Académico vs. Discurso de la industria.
Calidad del Software. Diseño de software y desarrollo basado en la arquitectura. ¿Cómo diseñar: Orientado a Objetos, componentes, servicios, Patrones de software?

3 Agenda Historia del la Arquitectura de Desarrollo de Software.
Introducción a la Arquitectura de Software Tipos de Arquitecturas. Paradigmas de Desarrollo de software. Aplicación de Arquitectura en el Desarrollo de Software Web.

4 Historia del la Arquitectura de Desarrollo de Software.

5 Historia de la Arquitectura de DS
Estructura antes de programar. Niveles de Abstracción. Diseño Conceptual – Niklaus Wirth 1968: Edsger Dijkstra Arquitectura del Software. Especificaciones: Funcionales + Diseño + Forma. 1969: P.I. Sharp formula 1970: Diseño Estructurado Modelos de desarrollo de software. Salen de cascada a modelos Orgánicos, Evolutivos y Cíclicos. : David Parnas Cada vez que se narra la historia de la arquitectura de software (o de la ingeniería de software, según el caso), se reconoce que en un principio, hacia 1968, Edsger Dijkstra, de la Universidad Tecnológica de Eindhoven en Holanda y Premio Turing 1972, propuso que se establezca una estructuración correcta de los sistemas de software antes de lanzarse a programar, escribiendo código de cualquier manera [Dij68a] . Módulos y Ocultamiento de Información. Estructuras de software y Familias de Programas. Búsqueda de Calidad del Software. Decisiones de Diseño Tempranas. 1975: Brooks Arquitectura como la especificación completa de la IU. Arquitectura (¿Qué?) vs. Implementación (¿Cómo?)

6 Historia de la Arquitectura de DS
1960 (Simula) TADs y Clases, Smalltalk Teoría: Modelar el Dominio del problema e implementarlo en un lenguaje POO. 1980s: POO Arquitectura del Software análogo a la construcción de edificios. Bases de la AS (Elementos, Forma, Razón). Herramientas CASE. 1992: Perry & Wolf 1990s: Apogeo de la AS Paul Clements: Componentes. 1995 – Patrones de Diseño. B4. Estilos arquitectónicos (ADLs) Vistas Arquitectónicas. Modelo propuestos: 4+1. TOGAF. RM/ODP. IEEE. 2000: Roy Fielding Modelo REST: Tecnologías Web y Modelo Orientado a Servicios. IEEE Std 1471. 2000s: Líneas de Productos y Metodologías de DS basada en La Arquitectura.

7 Introducción a la Arquitectura de Software

8 Introducción a la AS Definición: (Clements 1996): La AS es, a grandes rasgos, una vista del sistema que incluye los componentes principales del mismo, la conducta de esos componentes según se la percibe desde el resto del sistema y las formas en que los componentes interactúan y se coordinan para alcanzar la misión del sistema. La vista arquitectónica es una vista abstracta, aportando el más alto nivel de comprensión y la supresión o diferimiento del detalle inherente a la mayor parte de las abstracciones. Definición: (IEEE Std 1471): La Arquitectura de Software es la organización fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y el ambiente y los principios que orientan su diseño y evolución Aunque las literaturas de ambos campos rara vez convergen, entendemos que es productivo contrastar esa definición con la de ingeniería de software, conforme al estándar IEEE : "La aplicación de una estrategia sistemática, disciplinada y cuantificable al desarrollo, aplicación y mantenimiento del software; esto es, la aplicación de la ingeniería al software."

9 Puntos de vista de la AS Modelos estructurales: componentes, conexiones entre ellos , la configuración, estilo, restricciones, semántica, análisis, propiedades, racionalizaciones, requerimientos, necesidades de los participantes, (ADLs). Modelos de framework: refieren a dominios o clases de problemas específicos. Modelos dinámicos: Enfatizan la cualidad conductual de los sistemas. Modelos de proceso: programación de procesos para derivar arquitecturas. Modelos funcionales: conjunto de componentes funcionales, organizados en capas que proporcionan servicios hacia arriba Según: Shaw y David Garlan [SG95]

10 Conceptos de AS Estilos: Concepto descriptivo, define una forma de organización. Ej. flujo de datos, las peer-to-peer, las de invocación implícita, las jerárquicas, las centradas en datos o las de intérprete-máquina virtual. Lenguajes de Descripción Arquitectónica – ADLs. Frameworks y Vistas: Es una estructura de soporte definida en la cual otro proyecto de software puede ser organizado y desarrollado. Un framework representa una arquitectura de software que modela las relaciones generales de las entidades del dominio. Provee una estructura y una metodología de trabajo la cual extiende o utiliza las aplicaciones del dominio. Los Frameworks son diseñados con el intento de facilitar el desarrollo de software, permitiendo a los diseñadores y programadores pasar más tiempo identificando requerimientos de software que tratando con los tediosos detalles de bajo nivel de proveer un sistema funcional. Por ejemplo, un equipo que usa Apache Struts para desarrollar un sitio web de un banco puede enfocarse en cómo los retiros de ahorros van a funcionar en lugar de preocuparse de cómo se controla la navegación entre las páginas en una forma libre de errores. Sin embargo, hay quejas comunes acerca de que el uso de frameworks añade código innecesario y que la preponderancia de frameworks competitivos y complementarios significa que el tiempo que se pasaba programando y diseñando ahora se gasta en aprender a usar frameworks. Fuera de las aplicaciones en la informática, un framework puede ser considerado como el conjunto de procesos y tecnologías usados para resolver un problema complejo. Es el esqueleto sobre el cual varios objetos son integrados para una solución dada. (Wikipedia)

11 Conceptos de AS Principales Frameworks y Vistas Zachman (Niveles)
TOGAF (Arquitecturas) 4+1 (Vistas) [BRJ99] (Vistas) POSA (Vistas) Microsoft (Vistas) Scope Negocios [Text] Lógica Diseño Empresa Datos Proceso Conceptual Sistema lógico Aplicación Física Implementación Tecnología Desarrollo Despliegue . Representación Casos de uso Funcionamiento Concepto de Vista Una vista es, para definirla sucintamente, un subconjunto resultante de practicar una selección o abstracción sobre una realidad, desde un punto de vista determinado [Hil99]. Las vistas se introdujeron como una herramienta conceptual para poder manejar la complejidad (artefactos), tales como especificaciones de requerimientos o modelos de diseño. Principales Arquitecturas de Vistas El marco de referencia para la arquitectura empresarial de John Zachman [Zac87] identifica 36 vistas en la arquitectura (“celdas”) basadas en seis niveles (scope, empresa, sistema lógico, tecnología, representación detallada y funcionamiento empresarial) y seis aspectos (datos, función, red, gente, tiempo, motivación). El marco de referencia arquitectónico de The Open Group (TOGAF) reconoce cuatro componentes principales, uno de los cuales es un framework de alto nivel que a su vez define cuatro vistas: Arquitectura de Negocios, Arquitectura de Datos/Información, Arquitectura de Aplicación y Arquitectura Tecnológica. The Open Group propone un modelo de descripción arquitectónica, Architecture Description Method (ADM) que se supone independiente de las técnicas de modelado, aunque en la versión 7 se propone Metis como herramienta. En 1995 Philippe Kruchten propuso su célebre modelo “4+1”, vinculado al Rational Unified Process (RUP), que define cuatro vistas diferentes de la arquitectura de software: (1) La vista lógica, que comprende las abstracciones fundamentales del sistema a partir del dominio de problemas. (2) La vista de proceso: el conjunto de procesos de ejecución independiente a partir de las abstracciones anteriores. (3) La vista física: un mapeado del software sobre el hardware. (4) La vista de desarrollo: la organización estática de módulos en el entorno de desarrollo. El quinto elemento considera todos los anteriores en el contexto de casos de uso [Kru95]. En su introducción a UML (1.3), Grady Booch, James Rumbaugh e Ivar Jacobson han formulado un esquema de cinco vistas interrelacionadas que conforman la arquitectura de software, caracterizada en términos parecidos a los que uno esperaría encontrar en el discurso de la vertiente estructuralista. En los albores de la moderna práctica de los patrones, Buschmann y otros presentan listas discrepantes de vistas en su texto popularmente conocido como POSA [BMR+96]. La estrategia de arquitectura de Microsoft define, en consonancia con las conceptualizaciones más generalizadas, cuatro vistas, ocasionalmente llamadas también arquitecturas: Negocios, Aplicación, Información y Tecnología [Platt02]. La vista que aquí interesa es la de la aplicación, que incluye, entre otras cosas: (1) Descripciones de servicios automatizados que dan soporte a los procesos de negocios; (2) descripciones de las interacciones e interdependencias (interfaces) de los sistemas aplicativos de la organización, y (3) planes para el desarrollo de nuevas aplicaciones y la revisión de las antiguas, basados en los objetivos de la empresa y la evolución de las plataformas tecnológicas. Cada arquitectura, a su vez, se articula en vistas también familiares desde los días de OMT que son (1) la Vista Conceptual, cercana a la semántica de negocios y a la percepción de los usuarios no técnicos; (2) la Vista Lógica, que define los componentes funcionales y su relación en el interior de un sistema, en base a la cual los arquitectos construyen modelos de aplicación que representan la perspectiva lógica de la arquitectura de una aplicación; (3) la Vista Física, que es la menos abstracta y que ilustra los componentes específicos de una implementación y sus relaciones.

12 Conceptos de AS – Clasificación de Vistas según Jamers Rumbaugh, Ivar Jacobson, Grady Booch
Área Vista Diagramas Conceptos principales Estructural Vista estática Vista de casos de uso Vista de implementación Vista de despliegue Diagrama de clases Diagramas de casos de uso Diagrama de componentes Diagrama de despliegue Clase, asociación, generalización, dependencia, realización, interfaz Caso de uso, actor, asociación, extensión, inclusión, generalización de casos de uso Componente, interfaz, dependencia, realización Nodo, componente, dependencia, localización Dinámica Vista de máquinas de estados Vista de actividad Vista de interacción Diagrama de estados Diagrama de actividad Diagrama de secuencia Diagrama de colaboración Estado, evento, transición, acción Estado, actividad, transición de terminación, división, unión Interacción, objeto, mensaje, activación Colaboración, interacción, rol de colaboración, mensaje Gestión del modelo Vista de gestión del modelo Paquete, subsistema, modelo

13 Conceptos de AS Procesos y Metodologías: Relacionadas a las vistas dinámicas. Métodos Pesados (CMM) vs. Métodos Ágiles (XP,FDD,etc.). Abstracción: consiste en extraer las propiedades esenciales, o identificar los aspectos importantes, o examinar selectivamente ciertos aspectos de un problema, posponiendo o ignorando los detalles menos sustanciales, distractivos o irrelevantes. Escenarios (Guión o Libreto): casos de uso (secuencias de responsabilidades) y casos de cambio (modificaciones propuestas al sistema).. Escenarios Según algunas definiciones, como la de Clements y Northrop [CN96], los escenarios son algo así como libretos (en el sentido teatral o cinematográfico del término) correspondientes a las distintas piezas de funcionalidad de un sistema. Se los considera útiles para analizar una vista determinada [Cle95a] o para mostrar la forma en que los elementos de múltiples vistas se relacionan entre sí [Kru95]. Pueden concebirse también como una abstracción de los requerimientos más importantes de un sistema. Los escenarios se describen mediante texto común en prosa utilizando lo que se llama un script y a veces se describen mediante dibujos, como por ejemplo diagramas de interacción de objeto.

14 Investigación y Evolución en AS
David Garlan y Dewayne Perry : en su introducción al volumen de abril de 1995 de IEEE Transactions on Software Engineering dedicado a la AS Lenguajes de descripción de arquitecturas. Fundamentos formales de la AS (bases matemáticas, caracterizaciones formales de propiedades extra-funcionales tales como mantenibilidad, teorías de la interconexión, etcétera). Técnicas de análisis arquitectónicas. Métodos de desarrollo basados en arquitectura. Recuperación y reutilización de arquitectura. Codificación y guía arquitectónica. Herramientas y ambientes de diseño arquitectónico. Estudios de casos Introducción A medida que pasa el tiempo, la AS tiende a redefinir todos y cada uno de los aspectos de la disciplina madre, la ingeniería de software, sólo que a un mayor nivel de abstracción y agregando una nueva dimensión reflexiva en lo que concierne a la fundamentación formal del proceso.

15 Investigación y Evolución en AS
Paul Clements [Cle96b] (Reusabilidad): define cinco temas fundamentales en torno de los cuales se agrupa la disciplina. Diseño o selección de la arquitectura: Cómo crear o seleccionar una arquitectura en base de requerimientos funcionales, de rendimiento o de calidad. Representación de la arquitectura: Cómo comunicar una arquitectura. Este problema se ha manifestado como el problema de la representación de arquitecturas utilizando recursos lingüísticos, pero el problema también incluye la selección del conjunto de información a ser comunicada. Evaluación y análisis de la arquitectura: Cómo analizar una arquitectura para predecir cualidades del sistema en que se manifiesta. Un problema semejante es cómo comparar y escoger entre diversas arquitecturas en competencia. Desarrollo y evolución basados en arquitectura: Cómo construir y mantener un sistema dada una representación de la cual se cree que es la arquitectura que resolverá el problema correspondiente. Recuperación de la arquitectura: Cómo hacer que un sistema legacy evolucione cuando los cambios afectan su estructura; para los sistemas de los que se carezca de documentación confiable, esto involucra primero una “arqueología arquitectónica” que extraiga su arquitectura. Introducción A medida que pasa el tiempo, la AS tiende a redefinir todos y cada uno de los aspectos de la disciplina madre, la ingeniería de software, sólo que a un mayor nivel de abstracción y agregando una nueva dimensión reflexiva en lo que concierne a la fundamentación formal del proceso.

16 Arquitectura vs. Diseño
Taylor y Medvidovic [TM00]: señalan que la literatura actual mantiene en un estado ambiguo la relación entre ambos campos, albergando diferentes interpretaciones y posturas: Una postura afirma que arquitectura y diseño son lo mismo. Otra, en cambio, alega que la arquitectura se encuentra en un nivel de abstracción por encima del diseño, o es simplemente otro paso (un artefacto) en el proceso de desarrollo de software. Una tercera establece que la arquitectura es algo nuevo y en alguna medida diferente del diseño (pero de qué manera y en qué medida se dejan sin especificar). La arquitectura y el diseño sirven al mismo propósito. Sin embargo, el foco de la AS en la estructura del sistema y en las interconexiones la distingue del diseño de software tradicional En su reciente libro sobre el arte de la AS, Stephen Albin [Alb03] se pregunta en qué difiere ella de las metodologías de diseño bien conocidas como la orientación a objetos. La AS, se contesta, es una metáfora relativamente nueva en materia de diseño de software y en realidad abarca también las metodologías de diseño, así como metodologías de análisis. El arquitecto de software contemporáneo, escribe Albin, ejecuta una combinación de roles como los de analista de sistemas, diseñador de sistemas e ingeniero de software. Pero la arquitectura es más que una recolocación de funciones. Esas funciones pueden seguir siendo ejecutadas por otros, pero ahora caen comúnmente bajo la orquestación del chief architect. En una presentación de 1997, Dewayne Perry, uno de los fundadores de la disciplina, bosquejó la diferencia entre arquitectura y diseño. La arquitectura, una vez más (todo el mundo insiste en ello) concierne a un nivel de abstracción más elevado; se ocupa de componentes y no de procedimientos; de las interacciones entre esos componentes y no de las interfaces; de las restricciones a ejercer sobre los componentes y las interacciones y no de los algoritmos, los procedimientos y los tipos. En cuanto a la composición, la de la arquitectura es de grano grueso, la del diseño es de fina composición procedural; las interacciones entre componentes en arquitectura tienen que ver con un protocolo de alto nivel (en el sentido no técnico de la palabra), mientras que las del diseño conciernen a interacciones de tipo procedural (rpc, mensajes, llamadas a rutinas) [Per97].

17 Tipos de Arquitecturas
Estilos más relevantes de desarrollo de software

18 Estilos de Flujo de datos (EFD)
Esta familia de estilos enfatiza la reutilización y la modificabilidad. Es apropiada para sistemas que implementan transformaciones de datos en pasos sucesivos. Ejemplares de la misma serían las arquitecturas de tubería-filtros y las de proceso secuencial en lote. Ernst-Erich Doberkat define este estilo así: Una tubería (pipeline) es una popular arquitectura que conecta componentes computacionales (filtros) a través de conectores (pipes), de modo que las computaciones se ejecutan a la manera de un flujo. Los datos se transportan a través de las tuberías entre los filtros, transformando gradualmente las entradas en salidas. Ej. Unix, Compiladores, XML Ráfaga SAX, SGBD, Workflow.

19 Características del Estilo EFD
El estilo se debe usar cuando: Se puede especificar la secuencia de un número conocido de pasos. No se requiere esperar la respuesta asincrónica de cada paso. Se busca que todos los componentes situados corriente abajo sean capaces de inspeccionar y actuar sobre los datos que vienen de corriente arriba (pero no viceversa). Ventajas: Es simple de entender e implementar. Es posible implementar procesos complejos con editores gráficos de líneas de tuberías o con comandos de línea. Fuerza un procesamiento secuencial. Es fácil de envolver (wrap) en una transacción atómica. Los filtros se pueden empaquetar, y hacer paralelos o distribuidos.

20 Características del Estilo EFD
Desventajas: El patrón puede resultar demasiado simplista, especialmente para orquestación de servicios que podrían ramificar la ejecución de la lógica de negocios de formas complicadas. No maneja con demasiada eficiencia construcciones condicionales, bucles y otras lógicas de control de flujo. Agregar un paso suplementario afecta la performance de cada ejecución de la tubería. Una desventaja adicional referida en la literatura sobre estilos concierne a que eventualmente pueden llegar a requerirse buffers de tamaño indefinido, por ejemplo en las tuberías de clasificación de datos. El estilo no es apto para manejar situaciones interactivas, sobre todo cuando se requieren actualizaciones incrementales de la representación en pantalla. La independencia de los filtros implica que es muy posible la duplicación de funciones de preparación que son efectuadas por otros filtros (por ejemplo, el control de corrección de un objeto de fecha).

21 Ejemplo del Estilo Tubería- Filtro en una Aplicación Web
La aplicación típica del estilo es un procesamiento clásico de datos: el cliente hace un requerimiento; el requerimiento se valida; un Web Service toma el objeto de la base de datos; se lo convierte a HTML; se efectúa la representación en pantalla. Order Processing Pipeline proporciona la secuencia de pasos necesaria para procesar las compras en un sitio de Web. En la primera etapa, se obtiene la información del producto de la base de datos de catálogo; en la siguiente, se procesa la dirección del comprador; otra etapa resuelve la modalidad de pago; una etapa ulterior confecciona la factura y otra más realiza el envío del pedido. Cada etapa de la tarea representa una categoría de trabajo.

22 Estilos Centrados en Datos (ECD)
Esta familia de estilos enfatiza la integrabilidad de los datos. Se estima apropiada para sistemas que se fundan en acceso y actualización de datos en estructuras de almacenamiento. Sub-estilos característicos de la familia serían los repositorios, las bases de datos, las arquitecturas basadas en hipertextos y las arquitecturas de pizarra.

23 ECD – Pizarra o Repositorio
En esta arquitectura hay dos componentes principales: una estructura de datos que representa el estado actual y una colección de componentes independientes que operan sobre él [SG96]. En base a esta distinción se han definidos dos subcategorías principales del estilo: Si los tipos de transacciones en el flujo de entrada definen los procesos a ejecutar, el repositorio puede ser una base de datos tradicional (implícitamente no cliente-servidor). Si el estado actual de la estructura de datos dispara los procesos a ejecutar, el repositorio es lo que se llama una pizarra pura o un tablero de control. Ej. reconocimiento de patrones, reconocimiento de habla, Algunos Compiladores que usan TS, AST . Programación genética, evolutiva.

24 Uso del ECD en aplicaciones Web
No existe literatura profusa al respecto. Se espera que con los Agentes Inteligentes se obtengan resultados al respecto. Ej. STI Se puede entender hacia una aplicación que necesite hacer los siguiente: Fuentes de conocimiento, necesarias para resolver el problema. Una pizarra que representa el estado actual de la resolución del problema. Una estrategia, que regula el orden en que operan las fuentes.

25 Estilos de Llamada y Retorno ELR
Esta familia de estilos enfatiza la modificabilidad y la escalabilidad. Son los estilos más generalizados en sistemas en gran escala. Miembros de la familia son las arquitecturas de programa principal y subrutina, los sistemas basados en llamadas a procedimientos remotos, los sistemas orientados a objeto y los sistemas jerárquicos en capas.

26 ELR- Modelo Vista – Controlador MVC
Paradigma Interfaz – Base de Datos. Problemas: La interfaz suele cambiar, o acostumbra depender de distintas clases de dispositivos (clientes ricos, browsers, PDAs); La programación de interfaces de HTML, además, requiere habilidades muy distintas de la programación de lógica de negocios. Otro problema es que las aplicaciones tienden a incorporar lógica de negocios que van más allá de la transmisión de datos. El patrón conocido como Modelo-Vista-Controlador (MVC) separa el modelado del: - Dominio, - La presentación y - Las acciones basadas en datos ingresados por el usuario en tres clases diferentes

27 Características del MVC
Modelo. El 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). 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.

28 Ventajas y desventajas del MVC
Soporte de vistas múltiples. Dado que la vista se halla separada del modelo y no hay dependencia directa del modelo con respecto a la vista. Adaptación al cambio. Los requerimientos de interfaz de usuario tienden a cambiar con mayor rapidez que las reglas de negocios. Desventajas: Complejidad. El patrón introduce nuevos niveles de indirección y por lo tanto aumenta ligeramente la complejidad de la solución. También se profundiza la orientación a eventos del código de la interfaz de usuario, que puede llegar a ser difícil de depurar. Costo de actualizaciones frecuentes. Desacoplar el modelo de la vista no significa que los desarrolladores del modelo puedan ignorar la naturaleza de las vistas.

29 Uso del MVC en una Aplicación Web
En aplicaciones de Web, por otra parte, la separación entre la vista (el browser) y el controlador (los componentes del lado del servidor que manejan los requerimientos de HTTP) está mucho más taxativamente definida. Ejemplo Carrito de Compras.

30 Estilos de Orientación a Objetos
Los componentes de este estilo arquitectónico son los objetos – también considerados originalmente como instancias de tipos abstractos de datos, aunque ahora diríamos clases. Los objetos son ejemplos de un tipo de componentes que algunos llaman gestor porque es responsable de preservar la integridad de un recurso, es decir la representación. Los objetos interactúan a través de invocaciones de funciones y procedimientos.

31 ECR – Arquitectura Orientadas a Objetos
Hay dos aspectos importantes en relación con este estilo: un objeto es responsable de preservar la integridad de su representación (normalmente, manteniendo algún invariante de la misma) y la representación permanece oculta respecto de los demás objetos

32 Características de la Arquitectura OO
Los componentes del estilo se basan en principios OO: encapsulamiento, herencia y polimorfismo. Son asimismo las unidades de modelado, diseño e implementación, y los objetos y sus interacciones son el centro de las incumbencias en el diseño de la arquitectura y en la estructura de la aplicación. Las interfaces están separadas de las implementaciones. En general la distribución de objetos es transparente, y en el estado de arte de la tecnología apenas importa si los objetos son locales o remotos. El mejor ejemplo de OO para sistemas distribuidos es Common Object Request Broker Architecture (CORBA), en la cual las interfaces se definen mediante Interface Description Language (IDL); un Object Request Broker media las interacciones entre objetos clientes y objetos servidores en ambientes distribuidos. En cuanto a las restricciones, puede admitirse o no que una interfaz pueda ser implementada por múltiples clases. En tanto componentes, los objetos interactúan a través de invocaciones de funciones y procedimientos. Hay muchas variantes del estilo; algunos sistemas, por ejemplo, admiten que los objetos sean tareas concurrentes; otros permiten que los objetos posean múltiples interfaces.

33 Ventajas y Desventajas de A00
Sólo se señalan las más obvias. Entre las cualidades: Se puede modificar la implementación de un objeto sin afectar a sus clientes. Es posible descomponer problemas en colecciones de agentes en interacción. Un objeto es ante todo una entidad reutilizable en el entorno de desarrollo. Entre las limitaciones, el principal problema del estilo Para poder interactuar con otro objeto a través de una invocación de procedimiento, se debe conocer su identidad.. La consecuencia inmediata de esta característica es que cuando se modifica un objeto (por ejemplo, se cambia el nombre de un método, o el tipo de dato de algún argumento de invocación) se deben modificar también todos los objetos que lo invocan. También se presentan problemas de efectos colaterales en cascada: si A usa B y C también lo usa, el efecto de C sobre B puede afectar a A.

34 Uso de AOO en una aplicación Web
Ejemplo de Creación de Clases y Objetos en la aplicación de ejemplo del curso.

35 Estilos en Capas EC Los sistemas o arquitecturas en capas constituyen uno de los estilos que aparecen con mayor frecuencia mencionados como categorías mayores del catálogo, o, por el contrario, como una de las posibles encarnaciones de algún estilo más envolvente. En [GS94] Garlan y Shaw definen el estilo en capas como una organización jerárquica tal que cada capa proporciona servicios a la capa inmediatamente superior y se sirve de las prestaciones que le brinda la inmediatamente inferior. (más de 100 patrones o variantes de este estilo).

36 EC – Arquitectura Cliente / Servidor
Un componente servidor, que ofrece ciertos servicios, escucha que algún otro componente requiera uno; un componente cliente solicita ese servicio al servidor a través de un conector. El servidor ejecuta el requerimiento (o lo rechaza) y devuelve una respuesta. Modelo de Tres capas Microsoft DNA

37 Ventajas de los Modelos en Capas
El estilo soporta un diseño basado en niveles de abstracción crecientes, lo cual a su vez permite a los implementadores la partición de un problema complejo en una secuencia de pasos incrementales. El estilo admite muy naturalmente optimizaciones y refinamientos. Proporciona amplia reutilización. Al igual que los tipos de datos abstractos, se pueden utilizar diferentes implementaciones o versiones de una misma capa en la medida que soporten las mismas interfaces de cara a las capas adyacentes. Esto conduce a la posibilidad de definir interfaces de capa estándar, a partir de las cuales se pueden construir extensiones o prestaciones específicas.

38 Desventajas de los Modelos en Capas
Muchos problemas no admiten un buen mapeo en una estructura jerárquica. Incluso cuando un sistema se puede establecer lógicamente en capas, consideraciones de performance pueden requerir acoplamientos específicos entre capas de alto y bajo nivel. A veces es también extremadamente difícil encontrar el nivel de abstracción correcto; por ejemplo, la comunidad de comunicación ha encontrado complejo mapear los protocolos existentes en el framework ISO. Los cambios en las capas de bajo nivel tienden a filtrarse hacia las de alto nivel, en especial si se utiliza una modalidad relajada; también se admite que la arquitectura en capas ayuda a controlar y encapsular aplicaciones complejas, pero complica no siempre razonablemente las aplicaciones simples

39 Uso Arquitectura en Capas en una Aplicación Web.
Ejemplo de tres capas (Ej. e-Commerce): Interfaz: Corresponde a las páginas Web que presentan la información a los usuarios. Envía los requerimientos a la lógica para obtener una respuesta. Lógica: Representa los componentes del negocio (clases y objetos) que resuelven el tratamiento de la información. Física: Acceden a las diferentes fuentes de datos consultando y modificando, dependiendo de los requerimientos de la lógica.

40 Estilo CBSE (Ingeniería del Software Basado en Componentes)
Arquitecturas Basadas en Componentes: un componente de software, es una unidad de composición con interfaces especificadas contractualmente y dependencias del contexto explícitas. Que sea una unidad de composición y no de construcción quiere decir que no es preciso confeccionarla: se puede comprar hecha, o se puede producir en casa para que otras aplicaciones de la empresa la utilicen en sus propias composiciones. Ejemplos: CORBA Component Model (CCM), JavaBeans y Enterprise JavaBeans en J2EE y lo que alternativamente se llamó OLE, COM, ActiveX y COM+, y luego .NET.

41 Uso de AOC en una aplicación Web
El framework de .NET permite construir componentes avanzados e interoperar componentes y servicios a nivel de la tecnología COM+ 1.5, no como prestación legacy, sino en el contexto mayor (estilísticamente mixto) de servicios de componentes. Ejemplo: Controles de Usuario. Componentes del S.O.

42 Estilo de Código Móvil ECM
Esta familia de estilos enfatiza la portabilidad. Ejemplos de la misma son los intérpretes, los sistemas basados en reglas y los procesadores de lenguaje de comando. Fuera de las máquinas virtuales y los intérpretes, los otros miembros del conjunto han sido rara vez estudiados desde el punto de vista estilístico

43 ECM – Arquitectura de Máquina Virtual
La arquitectura de máquinas virtuales se ha llamado también intérpretes basados en tablas. De hecho, todo intérprete involucra una máquina virtual implementada en software. Se puede decir que un intérprete incluye un seudo-programa a interpretar y una máquina de interpretación. El seudo-programa a su vez incluye el programa mismo y el análogo que hace el intérprete de su estado de ejecución (o registro de activación). La máquina de interpretación incluye tanto la definición del intérprete como el estado actual de su ejecución. De este modo, un intérprete posee por lo general cuatro componentes: Una máquina de interpretación que lleva a cabo la tarea, Una memoria que contiene el seudo-código a interpretar, Una representación del estado de control de la máquina de interpretación, y Una representación del estado actual del programa que se simula. Ejemplos: Lenguajes de Alto Nivel.

44 Ejemplos de Implementaciones de Máquinas Virtuales
Numerosos lenguajes y ambientes de scripting utilizan máquinas virtuales: Perl, Javascript, Windows Script Host (WSH), Python, PHP, Pascal. WSH, por ejemplo, tolera programación en casi cualquier lenguaje de scripting que se atenga a ciertas especificaciones simples. En la nueva estrategia arquitectónica de Microsoft la máquina virtual por excelencia guarda relación con el Common Language Runtime, acaso unas de las dos piezas esenciales del framework .NET (la otra es la biblioteca de clases). El CLR admite, en efecto, diversos paradigmas puros y templados: programación funcional (Lisp, Scheme, F#, Haskell), programación imperativa orientada a objetos (C#, J#, C++, Python) y estructurada en bloques (Oberon), ambientes de objetos puros (Smallscript / Smalltalk), programación lógica declarativa (Prolog, P#), diseño basado en contratos (Eiffel), modelado matemático (Fortran), scripting interpretado (Perl), meta-programación (SML, Mondrian), programación cercana a la semántica de negocios (Cobol), programación centrada en reportes (Visual ASNA RPG), además de todos los matices y composiciones heterogéneas a que haya lugar

45 Estilos Heterogéneos - EH
Se incluye en este grupo formas compuestas o indóciles a la clasificación en las categorías habituales. Tipos: Sistemas de Control de Procesos: . El objetivo de un sistema de esta clase es mantener ciertos valores dentro de ciertos rangos especificados, llamados puntos fijos o valores de calibración. Arquitecturas Basadas en Atributos: Los estilos basados en atributos incluyen atributos de calidad específicos que declaran el comportamiento de los componentes en interacción. Estilos Peer to Peer: Consiste por lo general en procesos independientes o entidades que se comunican a través de mensajes. Arquitecturas Basadas en Recursos: Representational State Transfer o REST.

46 EH – Arquitecturas Basadas en Eventos
Las arquitecturas basadas en eventos se han llamado también de invocación implícita. Otros nombres propuestos para el mismo estilo han sido integración reactiva o difusión (broadcast) selectiva. Por supuesto que existen estrategias de programación basadas en eventos, sobre todo referidas a interfaces de usuario, y hay además eventos en los modelos de objetos y componentes, pero no es a eso a lo que se refiere primariamente el estilo, aunque esa variedad no está del todo excluida. Es implementado con el patrón Observer, un término que se hizo popular en Smalltalk a principios de los ochenta; en el mundo de Java se le conoce como modelo de delegación de eventos.

47 EH – Arquitectura Orientadas a Servicios
Sólo recientemente estas arquitecturas que los conocedores llaman SOA han recibido tratamiento intensivo en el campo de exploración de los estilos. Al mismo tiempo se percibe una tendencia a promoverlas de un sub-estilo propio de las configuraciones distribuidas que antes eran a un estilo en plenitud. Este predominio no se funda en la idea de servicios en general, comunicados de cualquier manera, sino que más específicamente va de la mano de la expansión de los Web services basados en XML, en los cuales los formatos de intercambio se basan en XML 1.0 Namespaces y el protocolo de elección es SOAP. SOAP significa un formato de mensajes que es XML, comunicado sobre un transporte que por defecto es HTTP, pero que puede ser también HTTPs, SMTP, FTP, IIOP, MQ o casi cualquier otro, o puede incluir prestaciones sofisticadas de última generación como WS-Routing, WS-Attachment, WS-Referral, etcétera.

48 Web Services como tendencia de programación Web
Un Web service es un sistema de software diseñado para soportar interacción máquina-a-máquina sobre una red. Posee una interfaz descripta en un formato procesable por máquina (específicamente WSDL). Otros sistemas interactúan con el Web service de una manera prescripta por su descripción utilizando mensajes SOAP, típicamente transportados usando HTTP con una serialización en XML en conjunción con otros estándares relacionados a la Web. (Parte del Modelo C/S)

49 Características de las arquitecturas orientadas a servicios
Un servicio es una entidad de software que encapsula funcionalidad de negocios y proporciona dicha funcionalidad a otras entidades a través de interfaces públicas bien definidas. Los componentes del estilo (o sea los servicios) están débilmente acoplados. El servicio puede recibir requerimientos de cualquier origen. La funcionalidad del servicio se puede ampliar o modificar sin rendir cuentas a quienes lo requieran. Los servicios son las unidades de implementación, diseño e implementación. Los componentes que requieran un servicio pueden descubrirlo y utilizarlo dinámicamente mediante UDDI y sus estándares sucesores. En general (aunque hay alternativas) no se mantiene persistencia de estado y tampoco se pretende que un servicio recuerde nada entre un requerimiento y el siguiente.

50 Bibliografía Introducción a la Arquitectura de Software. Carlos Billy Reynoso. Universidad de Buenos aires. Estilos y Patrones en la Estrategia de Arquitectura de Microsoft. Versión 1.0 – Marzo de Carlos Reynoso – Nicolás Kicillof. Universidad de Buenos aires. Blog de Arquitecturas, Consultado 12 Sept 2008. Video MVC VsNET.