Diseño y Evaluación de Arquitecturas de Software Introducción Arquitectura de Software

Transcripción

1 Diseño y Evaluación de Arquitecturas de Software Introducción Arquitectura de Software César Julio Bustacara Medina Facultad de Ingeniería Pontificia Universidad Javeriana 14/08/2015 1

2 Arquitectura de Software

3 Antecedentes historicos 1968, Edsger Dijkstra, propuso que se establezca una estructuración correcta de los sistemas de software antes de lanzarse a programar, escribiendo código de cualquier manera.

4 Antecedentes historicos En la conferencia de la NATO de 1969, P. I. Sharp formuló :... La arquitectura es diferente de la ingeniería.... La razón de que OS sea un amontonamiento amorfo de programas es que no tuvo arquitecto. Su diseño fue delegado a series de grupos de ingenieros, cada uno de los cuales inventó su propia arquitectura. Y cuando esos pedazos se clavaron todos juntos no produjeron una tersa y bella pieza de software.

5 Antecedentes historicos P. I. Sharp... Lo que sucede es que las especificaciones de software se consideran especificaciones funcionales. Sólo hablamos sobre lo que queremos que haga el programa.

6 Antecedentes historicos En 1975, Brooks, identificaba y razonaba sobre las estructuras de alto nivel y reconocía la importancia de las decisiones tomadas a ese nivel de diseño. Deferencia entre arquitectura e implementación; Arquitectura -> se ocupa de Qué hacer Implementación -> se ocupa de Cómo hacer.

7 Antecedentes historicos 1972, David Parnas, Los criterios seleccionados en la descomposición de un sistema impactan en la estructura de los programas. Módulos con ocultamiento de información Estructuras de software Familias de programas Enfatizó siempre en la búsqueda de calidad del software, medible en términos de economías en los procesos Desarrollo Mantenimiento.

8 Antecedentes historicos Decía Parnas que las decisiones tempranas de desarrollo serían las que probablemente permanecerían invariantes en el desarrollo ulterior de una solución. Esas decisiones tempranas constituyen de hecho lo que hoy se llamarían decisiones arquitectónicas. Elección de la estructura correcta

9 Antecedentes historicos 1984, Mary Shaw, vuelve a reivindicar las abstracciones de alto nivel, reclamando un espacio para esa reflexión y augurando que el uso de esas abstracciones en el proceso de desarrollo pueden resultar en un nivel de arquitectura de software en el diseño.

10 Antecedentes historicos 1992, Perry y Wolf, El primer estudio en que aparece la expresión arquitectura de software en el sentido en que hoy lo conocemos.

11 Antecedentes historicos Perry y Wolf presentan un modelo para la arquitectura de software que consiste en tres componentes: elementos, forma y razón (rationale). Elementos: son elementos ya sea de procesamiento, datos o conexión. Forma: las propiedades de, y las relaciones entre, los elementos, es decir, restricciones operadas sobre ellos. Razón: proporciona una base subyacente para la arquitectura en términos de las restricciones del sistema, que lo más frecuente es que se deriven de los requerimientos del sistema.

12 Antecedentes historicos Beneficios (Perry y Wolf): marco de referencia para satisfacer requerimientos, una base esencial para estimación de costos administración del proceso análisis de las dependencias evaluar la consistencia del sistema.

13 Antecedentes historicos 1994, Surge también la programación basada en Componentes 1996, Paul Clements, la AS promovía un modelo que debía ser más de integración de componentes pre-programados que de programación. 1995, Surgimiento de los patrones, cristalizada en dos textos fundamentales, el de la Banda de los Cuatro (GoF) en 1995 y la serie POSA desde 1996.

14 Antecedentes historicos Finales de los 90 s: Homogenización de la terminología en AS, Tipificación de los estilos arquitectónicos Lenguajes de descripción de arquitectura (ADLs), Se consolidó la concepción de las vistas arquitectónicas, reconocidas en todos y cada uno de los frameworks generalizadores que se han propuesto (4+1, TOGAF, RM/ODP, IEEE)

15 Antecedentes historicos 2000, Roy Fielding, presentó el modelo REST, el cual establece definitivamente el tema de las tecnologías de Internet y los modelos orientados a servicios y recursos... Se publica la versión definitiva de la recomendación IEEE Std 1471, que : procura homogenizar y ordenar la nomenclatura de descripción arquitectónica homologa los estilos como un modelo fundamental de representación conceptual.

16 Arquitectura en el proceso de desarrollo Requerimientos Aclarar intenciones Hacer explicitas las decisiones Permitir análisis a nivel de sistemas Arquitectura Diseño detallado Implementación Pruebas Reducir los costos de mantenimiento directa e indirectamente Mantenimiento

17 Representación de AS - Garlan Requerimientos Arquitectura de Software??? Código

18 Arquitecturas de Software Atacan: Complejidad creciente de aplicaciones. Sistemas distribuidos (segunda coordenada de complejidad). Sistemas abiertos y basados en componentes (tercera coordenada de complejidad). Idea principal: Estructura de alto nivel de un sistema de software y sus propiedades globales.

19 Arquitecturas de Software Características: Parte del diseño de software. Nivel del diseño de software donde se definen la estructura y propiedades globales del sistema. Incluye sus componentes, las propiedades observables de dichos componentes y las relaciones que se establecen entre ellos.

20 Arquitecturas de Software Características: Representación de alto nivel de la estructura del sistema describiendo las partes que lo integran. Puede incluir los patrones que supervisan la composición de sus componentes y las restricciones al aplicar los patrones. Trata aspectos del diseño y desarrollo que no pueden tratarse adecuadamente dentro de los módulos que forman el sistema.

21 Arquitecturas de Software Nueva disciplina: Toda aplicación tiene una arquitectura, aunque no sea explícita. Tradicionalmente ha habido un repertorio de técnicas, patrones y expresiones para estructurar sistemas de software complejos. Arquitectura de Software: Hace explícito con rigor lo anterior. Incluye modelos, lenguajes y herramientas para la descripción y desarrollo práctico de arquitecturas de software.

22 Arquitecturas de Software Objetivos: Comprender (abstracción) y mejorar la estructura de las aplicaciones complejas. Reutilizar dicha estructura (o partes de ella) para resolver problemas similares. Analizar la corrección de la aplicación y su grado de cumplimiento respecto a los requisitos iniciales. Permitir el estudio de algunas propiedades específicas del dominio.

23 Arquitecturas de Software Objetivos: Planificar la evolución de la aplicación, identificando las partes mutables e inmutables de la misma, así como los costos de los posibles cambios. adaptación al cambio: composición, reconfiguración, reutilización, escalabilidad, mantenibilidad, etc.

24 Arquitecturas de Software Objetivos Organización a alto nivel del sistema, incluyendo aspectos como: la descripción análisis de propiedades relativas a su estructura y control global los protocolos de comunicación Protocolos de sincronización utilizados la distribución física del sistema y sus componentes, etc.

25 Arquitecturas de Software De qué no se ocupa? Diseño detallado. Diseño de algoritmos. Diseño de estructuras de datos.

26 Arquitecturas de Software Definiciones La arquitectura de un programa o sistema computacional es la estructura o estructuras de ese sistema, y comprende los componentes del software, sus propiedades externamente visibles, y las relaciones entre las mismas.

27 Arquitecturas de Software Definiciones Una estructura compuesta por componentes de software y reglas que caracterizan la interacción entre estos componentes (Jones, 1993). Un conjunto de elementos arquitecturales que tienen una forma particular. Estos elementos se dividen en tres clases: elementos de procesamiento, elementos de datos y elemento de conexión. (Perry y Wolf, 1992).

28 Arquitecturas de Software Definiciones Una colección de componentes computacionales - o, simplemente, componentes - en conjunto con una descripción de las interacciones entre estos componentes, es decir, de los conectores.(garlan y Shaw, 1993). Una estructura organizacional de un sistema de software que incluye componentes, conexiones, restricciones y una exposición razonada (rationale) de los requerimientos que ella satisface o de algunos otros aspectos de la arquitectura (Kogut y Clement, 1994).

29 Elementos de las Arquitecturas SW La arquitectura de software define: Componentes: lugar de almacenamiento o computo: Filtros, bases de datos, objetos, TADs Conectores: Mediadores entre componentes Llamadas a procedimientos Pipes Broadcast Propiedades: Información para construcción y análisis Pre/Post condiciones, invariantes Un estilo o patrón de arquitecturas define una familia: Componentes y conectores Configuraciones Semántica de las restricciones

30 Arquitecturas Software Cómo interviene en la consecución de una solución? Métodos arquitectónicos. Espacio de los diseños arquitectónicos: propiedades de los diferentes diseños arquitectónicos y su capacidad para resolver diferentes problemas. Cómo no interviene? Métodos de desarrollo de software: Proporcionan un camino entre el espacio del problema y la solución.

31 Arquitecturas Software Puntos en común: Los métodos de desarrollo suelen basarse en un estilo arquitectónico preferido. Nuevos estilos arquitectónicos proponen nuevos métodos de desarrollo. Un mismo diseño arquitectónico puede servir para dos aplicaciones distintas (ej. los patrones de diseño)

32 Bibliografía David Garlan and Mary Shaw, An Introduction to Software Architecture, 1994 D.L. Parnas, On the Criteria To Be Used in Decomposing Systems into Modules, 1972 D. L. Parnas, The Modular Structure of Complex Systems, 1985 Dewayne E. Perry and Alexander L. Wolf, Foundations for the Study of Software Architecture, 1992 Dewayne E. Perry, An Overview of the State of the Art in Software Architecture, 1997 Carlos Billy Reynoso, Introducción a la Arquitectura de Software,