Evaluating Software Architectures: Development Stability and Evolution

We survey seminal work on software architecture evaluationmethods. We then look at an emerging class of methodsthat explicates evaluating software architectures forstability and evolution. We define architectural stabilityand formulate the problem of evaluating software architecturesfor stability and evolution. We draw the attention onthe use of Architectures Description Languages (ADLs) forsupporting the evaluation of software architectures in generaland for architectural stability in specific

ArchOptions: A Real Options-Based Model for Predicting the Stability of Software Architectures

Architectural stability refers to the extent an architecture is flexible to endure evolutionary changes in stakeholders\' requirements and the environment. We assume that the primary goal of software architecture is to guide the system\'s evolution. We contribute to a novel model that exploits options theory to predict architectural stability. The model is predictive: it provides \"insights\" on the evolution of the software system based on valuing the extent an architecture can endure a set of likely evolutionary changes. The model builds on Black and Scholes financial options theory (Noble Prize wining) to value such extent. We show how we have derived the model: the analogy and assumptions made to reach the model, its formulation, and possible interpretations. We refer to this model as ArchOptions

Using real options to select stable Middleware-induced software architectures

The requirements that force decisions towards building distributed system architectures are usually of a non-functional nature. Scalability, openness, heterogeneity, and fault-tolerance are examples of such non-functional requirements. The current trend is to build distributed systems with middleware, which provide the application developer with primitives for managing the complexity of distribution, system resources, and for realising many of the non-functional requirements. As non-functional requirements evolve, the `coupling' between the middleware and architecture becomes the focal point for understanding the stability of the distributed software system architecture in the face of change. It is hypothesised that the choice of a stable distributed software architecture depends on the choice of the underlying middleware and its flexibility in responding to future changes in non-functional requirements. Drawing on a case study that adequately represents a medium-size component-based distributed architecture, it is reported how a likely future change in scalability could impact the architectural structure of two versions, each induced with a distinct middleware: one with CORBA and the other with J2EE. An option-based model is derived to value the flexibility of the induced-architectures and to guide the selection. The hypothesis is verified to be true for the given change. The paper concludes with some observations that could stimulate future research in the area of relating requirements to software architectures

Assessing architectural evolution: A case study

This is the post-print version of the Article. The official published can be accessed from the link below - Copyright @ 2011 SpringerThis paper proposes to use a historical perspective on generic laws, principles, and guidelines, like Lehman’s software evolution laws and Martin’s design principles, in order to achieve a multi-faceted process and structural assessment of a system’s architectural evolution. We present a simple structural model with associated historical metrics and visualizations that could form part of an architect’s dashboard. We perform such an assessment for the Eclipse SDK, as a case study of a large, complex, and long-lived system for which sustained effective architectural evolution is paramount. The twofold aim of checking generic principles on a well-know system is, on the one hand, to see whether there are certain lessons that could be learned for best practice of architectural evolution, and on the other hand to get more insights about the applicability of such principles. We find that while the Eclipse SDK does follow several of the laws and principles, there are some deviations, and we discuss areas of architectural improvement and limitations of the assessment approach

Topological Theory in Bioconstructivism

In the essay “Landscapes of Change: Boccioni’s Stati d’animo as a General Theory of Models,” in Assemblage 19, 1992, Sanford Kwinter proposed a number of theoretical models which could be applied to computer-generated forms in Bioconstructivism. These included topological theory, epigenesis, the epigenetic landscape, morphogenesis, catastrophe and catastrophe theory. Topological theory entails transformational events or deformations in nature which introduce discontinuities into the evolution of a system. Epigenesis entails the generation of smooth landscapes, in waves or the surface of the earth, for example, formed by complex underlying topological interactions. The epigenetic landscape is the smooth forms of relief which are the products of the underlying complex networks of interactions. Morphogenesis describes the structural changes occurring during the development of an organism, wherein forms are seen as discontinuities in a system, as moments of structural instability rather than stability. A catastrophe is a morphogenesis, a jump in a system resulting in a discontinuity. Catastrophe theory is a topological theory describing the discontinuities in the evolution of a system in nature. A project which applies these models, and which helps to establish a theoretical basis for Bioconstructivism by applying topological models, is a design for a theater by Amy Lewis in a Graduate Architecture Design Studio directed by Associate Professor Andrew Thurlow at Roger Williams University, in Spring 2011. In the project, moments of structural stability are juxtaposed with moments of structural instability, to represent the contradiction inherent in self-generation or immanence. The singularity of the surfaces of the forms in the epigenetic landscape contradicts the complex network of interactions of topological forces from which they result. Actions in the environment on unstable, unstructured forms, and undifferentiated structures, result in stable, structured forms, and differentiated structures

Implementation issues in product line scoping

Often product line engineering is treated similar to the waterfall model in traditional software engineering, i.e., the different phases (scoping, analysis, architecting, implementation) are treated as if they could be clearly separated and would follow each other in an ordered fashion. However, in practice strong interactions between the individual phases become apparent. In particular, how implementation is done has a strong impact on economic aspects of the project and thus how to adequately plan it. Hence, assessing these relationships adequately in the beginning has a strong impact on performing a product line project right. In this paper we present a framework that helps in exactly this task. It captures on an abstract level the relationships between scoping information and implementation aspects and thus allows to provide rough guidance on implementation aspects of the project. We will also discuss the application of our framework to a specific industrial project