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
Arquitectura de Software
 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”.
 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 “.
 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.”
 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.
 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.
 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

 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”.
 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.
 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.
 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.
 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.
 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)
 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.
 Arquitectura en el proceso de
desarrollo
• Aclarar intenciones
Requerimientos • Hacer explicitas las decisiones
• Permitir análisis a nivel de sistemas
Arquitectura

Diseño detallado

Implementación

Pruebas

Mantenimiento
Reducir los costos de mantenimiento
directa e indirectamente
 Representación de AS - Garlan

Requerimientos

???
Arquitectura de Software

Código
 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.
 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.
 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.
 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.
 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.
 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.
 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.
 Arquitecturas de Software
• ¿De qué no se ocupa?
–Diseño detallado.
–Diseño de algoritmos.
–Diseño de estructuras de datos.
 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.
 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).
 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).
 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
 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.
 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)
 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, 2004

32