CHARMY: A Framework for Designing and Verifying Architectural Specifications

Introduced in the early stages of software development, the Charmy framework assists the software architect in making and evaluating architectural choices. Rarely, the software architecture of a system can be established once and forever. Most likely poorly defined and understood architectural constraints and requirements force the software architect to accept ambiguities and move forward to the construction of a suboptimal software architecture. Charmy aims to provide an easy and practical tool for supporting the iterative modeling and evaluation of software architectures. From an UML-based architectural design, an executable prototype is automatically created. Charmy simulation and model checking features help in understanding the functioning of the system and discovering potential inconsistencies of the design. When a satisfactory and stable software architecture is reached, Java code conforming to structural software architecture constraints is automatically generated through suitable transformations. The overall approach is tool supported.     

The Accidental Architecture

Every interesting software-intensive system has an architecture. While some of these architectures are intentional, most appear to be accidental. Philippe Kruchten has observed that "the life of a software architect is a long and rapid succession of suboptimal design decisions taken partly in the dark." The journey between vision and ultimate executable system is complex, and for every interesting software-intensive system that path is marked by myriad decisions, some large and some small, some of which advance progress while others represent vestigial dead ends or trigger points for scrap and rework. As Philippe also observes, the architecture of classical systems comes primarily from theft, whereas the architecture of unprecedented systems comes largely from intuition carried out in the context of a controlled exploratory process. The fact that this is so for software-intensive systems shouldn't come as a surprise, for as Henry Petroski explains in his book To Engineer Is Human (Vintage, 1992), all sound engineering disciplines advance by building on past successes while simultaneously mitigating causes of observable failure.Thus, having an accidental architecture is not necessarily a bad thing, as long as the decisions that make up that architecture are made manifest and the essential ones are made visible as soon as they are instituted and then allowed to remain visible throughout the meaningful life of that system. Insofar as we can then name these architectures after they're formed, we can use these names and their associated semantics to communicate decisions using a common language, just as we can do now with design patterns, and perhaps even reuse these architectural patterns in future systems. In other words, by naming these accidental architectures, we again raise the level of abstraction by which we can describe and reason about a system.     

Bridging the gap between software architecture rationale formalisms and actual architecture documents: An ontology-driven approach

Documenting software architecture rationale is essential to reuse and evaluate architectures, and several modeling and documentation guidelines have been proposed in the literature. However, in practice creating and updating these documents rarely is a primary activity in most software projects, and rationale remains hidden in casual and semi-structured records, such as e-mails, meeting notes, wikis, and specialized documents. This paper describes the TREx (Toeska Rationale Extraction) approach to recover, represent and explore rationale information from text documents, combining: (1) pattern-based information extraction to recover rationale; (2) ontology-based representation of rationale and architectural concepts; and (3) facet-based interactive exploration of rationale. Initial results from TREx’s application suggest that some kinds of architecture rationale can be semi-automatically extracted from a project’s unstructured text documents, namely decisions, alternatives and requirements. The approach and some tools are illustrated with a case study of rationale recovery for a financial securities settlement system.     

架构设计决策管理工具的研究与设计

目前的架构设计决策隐含于最终架构制品中,导致了涉众交流困难、演化代价高、难以复用等问题。针对上述问题,通过分析架构设计决策的属性及决策制定过程,提出一种描述设计决策与其他外部元素之间关系的元模型,在此基础上设计一个结合编码化和人际化的管理策略的架构设计决策管理工具,实现对设计决策的显式编档、管理和复用。     

Two controlled experiments on model-based architectural decision making

ContextIn recent years, architectural design decisions are becoming more and more common for documenting software architectures. Rather than describing the structure of software systems, architectural decisions capture the design rationale and – often reusable – architectural knowledge. Many approaches and tools have been proposed in the literature to support architectural decision making and documentation (for instance, based on models, ontologies, or templates). In this context, the capturing, organization, and effective reuse of architectural knowledge has gained a lot of attention.ObjectiveHowever, there is little empirical evidence about the supportive effect of reusable architectural knowledge on the effectiveness and efficiency of architectural decision making.MethodTo investigate these aspects, we conducted two separate controlled experiments with software architecture students in which we tested the supportive effect of reusable decision models in decision making and documentation.ResultsOur results show that the use of reusable decision models can significantly increase both the efficiency and the effectiveness of novice architects.ConclusionWe can report, that our findings are in line with similar studies and support the claims regarding reusable architectural design decisions in principle.     

Semi-automated architectural abstraction specifications for supporting software evolution

In this paper we present an approach for supporting the semi-automated architectural abstraction of architectural models throughout the software life-cycle. It addresses the problem that the design and implementation of a software system often drift apart as software systems evolve, leading to architectural knowledge evaporation. Our approach provides concepts and tool support for the semi-automatic abstraction of architecture component and connector views from implemented systems and keeping the abstracted architecture models up-to-date during software evolution. In particular, we propose architecture abstraction concepts that are supported through a domain-specific language (DSL). Our main focus is on providing architectural abstraction specifications in the DSL that only need to be changed, if the architecture changes, but can tolerate non-architectural changes in the underlying source code. Once the software architect has defined an architectural abstraction in the DSL, we can automatically generate architectural component views from the source code using model-driven development (MDD) techniques and check whether architectural design constraints are fulfilled by these models. Our approach supports the automatic generation of traceability links between source code elements and architectural abstractions using MDD techniques to enable software architects to easily link between components and the source code elements that realize them. It enables software architects to compare different versions of the generated architectural component view with each other. We evaluate our research results by studying the evolution of architectural abstractions in different consecutive versions of five open source systems and by analyzing the performance of our approach in these cases.     

A classification and comparison of model checking software architecture techniques

Software architecture specifications are used for many different purposes, such as documenting architectural decisions, predicting architectural qualities before the system is implemented, and guiding the design and coding process. In these contexts, assessing the architectural model as early as possible becomes a relevant challenge. Various analysis techniques have been proposed for testing, model checking, and evaluating performance based on architectural models. Among them, model checking is an exhaustive and automatic verification technique, used to verify whether an architectural specification conforms to expected properties. While model checking is being extensively applied to software architectures, little work has been done to comprehensively enumerate and classify these different techniques.The goal of this paper is to investigate the state-of-the-art in model checking software architectures. For this purpose, we first define the main activities in a model checking software architecture process. Then, we define a classification and comparison framework and compare model checking software architecture techniques according to it.     

基于时序逻辑的面向方面体系结构描述语言

运用传统体系结构描述语言描述的软件体系结构(SA)方案始终存在着一些横切行为和特征,它们混杂和散列在不同的SA设计单元中,使得SA难以理解、难以演化和难以重用。针对这一问题,基于时序逻辑语言XYZ/E,在统一的时序逻辑框架下设计出一种面向方面体系结构描述语言AC2-ADL。系统地阐述了AC2-ADL的概念框架并用XYZ/E进行语义解释,最后结合案例介绍了如何用AC2-ADL对SA进行描述。     

The Decision View's Role in Software Architecture Practice

A decision view provides a useful complement to the traditional sets of architectural views and viewpoints. It gives an explanatory perspective that illuminates the reasoning process itself and not solely its results. The decision view documents aspects of the architecture that are hard to reverse-engineer from the software itself and that are often left tacit. The decision view and the decisions that it captures embody high-level architectural knowledge that can be transferred to other practitioners and merged when systems are merged, and they offer useful support for maintaining large, long-lived software-intensive systems. This article leads readers through a succession of epiphanies: from design to architecture, then architecture representation to architecture design methods, and finally to architectural design decisions.     

A review and future directions of SOA-based software architecture modeling approaches for System of Systems

Software architecture is a software system’s earliest set of design decisions that are critical for the quality of the system desired by the stakeholders. The architecture makes it easier to reason about and manage change during different phases of complex software life cycle. The modeling of software architecture for System of Systems (SoS) is a challenging task because of a system’s complexity arising from an integration of heterogeneous, distributed, managerially and operationally independent systems collaborating to achieve global missions. SoS is essentially dynamic and evolutionary by design requiring suitable architectural patterns to deal with runtime volatility. Service-oriented architecture offers several architectural features to these complex systems; these include, interoperability, loose coupling, abstraction and the provision of dynamic services based on standard interfaces and protocols. There is some research work available that provides critical analysis of current software architecture modeling approaches for SoS. However, none of them outlines the important characteristics of SoS or provides detailed analysis of current service-oriented architecture modeling approaches to model those characteristics. This article addresses this research gap and provides a taxonomy of software architecture modeling approaches, comparing and contrasting them using criteria critical for realization of SoS. Additionally, research gaps are identified, and future directions are outlined for building software architecture for SoS to model and reason about architecture quality in a more efficient way in service-oriented paradigm.     

How do architecture patterns and tactics interact? A model and annotation

Software architecture designers inevitably work with both architecture patterns and tactics. Architecture patterns describe the high-level structure and behavior of software systems as the solution to multiple system requirements, whereas tactics are design decisions that improve individual quality attribute concerns. Tactics that are implemented in existing architectures can have significant impact on the architecture patterns in the system. Similarly, tactics that are selected during initial architecture design significantly impact the architecture of the system to be designed: which patterns to use, and how they must be changed to accommodate the tactics. However, little is understood about how patterns and tactics interact. In this paper, we develop a model for the interaction of patterns and tactics that enables software architects to annotate architecture diagrams with information about the tactics used and their impact on the overall structure. This model is based on our in-depth analysis of the types of interactions involved, and we show several examples of how the model can be used to annotate different kinds of architecture diagrams. We illustrate the model and annotation by showing examples taken from real systems, and describe how the annotation was used in architecture reviews. Tactics and patterns are known architectural concepts; this work provides more specific and in-depth understanding of how they interact. Its other key contribution is that it explores the larger problem of understanding the relation between strategic decisions and how they need to be tailored in light of more tactical decisions.     

以决策为中心的软件体系结构设计方法

提出针对体系结构层次设计的决策抽象和问题分解原则,以及基于该原则的一种以决策为中心的体系结构设计方法.该方法从决策的视角对体系结构进行建模,并通过一个从导出体系结构关键问题到对体系结构方案决策的过程完成设计,还在其中实现了候选体系结构方案的自动合成以及设计决策与理由的捕捉.这种以决策为中心的方法切合体系结构层次的特点,降低了体系结构设计的复杂性和设计决策与理由捕捉的代价.     

Knowledge representation of the software architecture design process based on situation calculus

Software architecture design is an interactive, complex, decision‐making process. Such a design process involves the exploration, evaluation, and composition of design alternatives. Increasingly, new computer‐aided tools are available to help designers in these complex activities. However, these tools do not know how design is actually done, in other words, by means of which design activities the final artefact was obtained. In fact, the architectural design knowledge exclusively rests in the mind of designers, and there is an urgent need to move it, as much as possible, to a computer‐supported environment that enables the capture of this type of knowledge. This contribution addresses this need by introducing a model for capturing how products under development are generated and transformed along the software architecture design process. The proposed model follows an operational perspective, where architectural design decisions are modelled by means of sequences of operations that are applied on the design products. Situation calculus is used to formally express the existence of an object in a given state of a design process. In addition, this formalism allows us expressing without ambiguities when an operation can be performed in a specific state of the design process.     

Evolution Through Architectural Reconciliation

One of the possible scenarios in a system evolution cycle, is to translate an emergent set of new requirements into software architecture design and subsequently to update the system implementation. In this paper, we argue that this form of forward engineering, even though addresses the new system requirements, tends to overlook the implementation constraints. An architect must also reverse-engineer the system, in order to make these constraints explicit. Thus, we propose an approach where we reconcile two architectural models, one that is forward-engineered from the requirements and another that is reverse-engineered from the implementation. The final reconciled model is optimally adapted to the emergent set of requirements and to the actual system implementation. The contribution of this paper is twofold: the application of architectural reconciliation in the context of software evolution and an approach to formalize both the specification and transformation of the architectural models. The architectural modeling is based upon the UML 2.0 standard, while the formalization approach is based on set theory and first-order logic.