A documentation framework for architecture decisions

A major cause of many complications in the field of software architectures is the lack of appropriate abstractions for separating, combining and encapsulating concerns of various kinds in architectural descriptions. Architectures of most complex software-intensive systems involve concerns that inherently crosscut the natural boundaries of the elements composing the architecture descriptions. Crosscutting concerns intersect the common modularity of systems as prescribed by their architecture descriptions, by traversing both the components and connectors, i.e., the relationships among the components. Crosscutting concerns are critical aspects of many architectural problems. However, architectural descriptions written in special-purpose languages (ADLs) like Wright, Darwin, Rapide and Acme should support descriptions of multiple structures, which include diagrams, models and views, that intentionally address different kinds of concerns. ADLs should show how various concerns affect each other in architectural designs; they should also allow one to identify, analyze and elaborate architectural concerns that cut across several software components, such as transactions, security, load balancing, synchronization, reuse, customization, scalability, etc.; they should, but they do not. This dissertation presents a new approach to software architecture that is suitable for supporting concern-oriented development and documentation of architectures for software-intensive systems. This approach allows for creating and documenting a multidimensional software structure that is referred to as concern-oriented software architecture; it provides new mechanisms for encapsulating individual concerns into independent architectural constructs. The ultimate goal of this new approach is to provide support for achieving design by concerns all through the development and description of software architectures. Moving towards this goal, we present a particular concern-oriented architectural framework called Perspectival Concern-Spaces (PCS). The PCS Framework offers a flexible and extensible means a) for supporting advanced separation of concerns in architectural design, and in the construction and evolution of software-intensive systems; and b) for filling the gap between architectural descriptions and modern software development artifacts. To show the feasibility of the proposed approach, we provide new modeling techniques that are used to describe and apply an aspect-oriented architectural pattern, called the On-demand Remodularization pattern. We give several examples of how the PCS Framework can be used to integrate concern-oriented architectural documentations with mainstream software development artifacts.

Software architecture lies at the backbone of any software system and its choice directly influences important non-functional characteristics such as maintainability, extensibility, etc. Up-to-date software architecture descriptions should be at any time available to support the analysis and evaluation of the current state of the architecture. However the current state of the art lacks both methodologies and tools for ensuring availability of architecture descriptions and fails to offer objective means for evaluating software architectures. Currently, no generally accepted method for comparing software from an architecture point of view exists. In this paper, we present our current results towards creating a so-called architecture quality index that includes a bidirectional architecture quality model as well as a quality benchmark created for the context of the ARAMIS research project. The proposed architecture quality index aims to support the architects to evaluate and compare the architecture of software systems based on information extracted during the considered systems' run-time.

Software architecture analysis plays an important role in software development lifecycle. However, from the view of separation of concerns, there is an absence of both structural description and behavioural analysis of software architecture. This paper proposes an aspect-oriented software architecture (AOSA) to reduce the complexity of software model and improve the reliability of software system. Aspect-oriented architecture description language based on XML is defined for structural description of software architecture, while aspect-oriented statechart and temporal logic are used for its behavioural analysis. A carousel case illustrates that the formal method is effective.

Architecture description languages (ADLs) play an important role in specifying the software architectures. While most of these ADLs are unable to deal with the change directly, especially for dynamic evolution of software systems. This paper proposes an XML-based ADL, named Breeze/ADL, which is supported by Breeze Graph Grammar (BGG) - a graph grammar we defined, to describe software architecture and capture the change in the architecture definition. Our approach is explained in two directions. First, we give the basic definitions of Breeze/ADL, and then show how to map the BGG to Breeze/ADL to specify the structural model, style constraints and dynamic evolution. The other direction is that we use a Client/Server application as a running example to demonstrate our approach throughout this paper. In this approach, the software architecture description has both a textual and a graph representations, and the unplanned change can be captured and defined.

Software architectures, chemical abstract machine, specification, refinement. In this paper we propose an approach to compare descriptions of software architectures based on the CHAM formalism. The need to compare descriptions of the same system at different level of abstraction often arises typically when the software practice uses a stepwise refinement approach. Differently from other approaches presented in the literature our framework allows for expressing correct refinement both of the static structure and of the dynamic behaviour of an architecture. Statically we rely on a suitable definition of partial morphism between the signatures of the two architectures. Dynamically we propose a notion of structure preserving simulation which allows the behaviors of the two CHAM descriptions to be (preorderly) related. In both definitions an important role is played by the membrane construct which allows for expressing non-functional constraints on the architecture to be refined. The main idea is to use the membranes to denote basic software components of the architecture that can be further decomposed during a refinement process but that cannot be destroyed even if the behaviour of the overall system is preserved. One point in favour of our approach is that we do not constrain too much the further development since we only require the membrane structure to be preserved.

Architecture description languages are a sound and convenient approach to software architecture representation. The majority of well-known ADLs provide separation of computation and communication in components and connectors, respectively. However, computation and communication are not the only crosscutting concerns that may appear in a software architecture description. Traditional ADLs do not normally provide appropriate support to separate any kind of crosscutting concerns, which frequently result in poor architectures descriptions with highly coupled components. In this paper we present the AO-ADL language, based on a symmetric decomposition model that considers components and connectors as the basic structural elements (similar to traditional ADLs). We will show how aspects are treated as specific types of components that are composed by means of connectors. In order to cope with the separation of concerns we enrich the semantic and expressivity of traditional connectors to support either aspectual and nonaspectual component interactions.

Making architectural decisions is a crucial task but also very difficult, considering the scope of the decisions and their impact on quality attributes. To make matters worse, architectural decisions need to combine both technical and business factors, which are very dissimilar by nature. We provide a cost-benefit approach and supporting tooling that treats architectural decisions as financial investments by: (a) combining both technical and business factors; and (b) transforming the involved factors into currency, allowing their uniform aggregation. Apart from illustrating the method, we validate both the proposed approach and the tool, in terms of fitness for purpose, usability, and potential limitations. To validate the approach, we have performed a case study in a software development company, in the domain of low-energy embedded systems. We employed triangulation in the data collection phase of the case study, by performing interviews, focus groups, an observational session, and questionnaires. The results of the study suggested that the proposed approach: (a) provides a structured process for systematizing decision-making; (b) enables the involvement of multiple stakeholders, distributing the decision-making responsibility to more knowledgeable people; (c) uses monetized representations that are important for assessing decisions in a unified manner; and (d) enables decision reuse and documentation. The results of the study suggest that architectural decision-making can benefit from treating this activity as a financial investment. The various benefits that have been identified from mixing financial and technological aspects are well-accepted from industrial stakeholders.

The focus of this paper is the design and implementation of dependable quality requirements, and their incorporation in the description of software architecture in an explicit and structured manner. More specifically, we propose three architectural styles for developing dependable collaboration-based software designs based on three notions: (i) the idealized fault-tolerant component model, (ii) the collaboration/role interaction model, and (iii) computational reflection together with a set of design patterns that focus on providing design solutions for implementing fault tolerance techniques, namely, error handling, coordinated recovery and software redundancy. Computational reflection defines a meta-level architecture that is composed of a base level where the application’s logic is implemented and a meta level where meta components are responsible for implementing the application’s quality requirements in a way that it is transparent to application designers. Application designers can apply the notion of separation of concerns and concentrate their attention on the functional requirements, abstracting from the quality requirements.

With the growing use of UML diagrams for software architecture description and the importance of non-functional requirements evaluation at software architecture level, filling the scientific gap between architect and requirement analyst is considered to be significant. Software architects are not usually familiar with non-functional requirement analysis and are not able to analyze such requirements easily. On the other hand, non-functional requirements cannot be evaluated directly by UML diagrams. Therefore, the architect should annotate additional information of the nonfunctional requirements to software architecture description and then an executable model can be produced. These executable models can be petri nets, queuing networks, stochastic process algebra and etc. One kind of the UML diagrams that can be used to describe software architecture is component diagram. In this paper, we propose a new algorithm that enables an architect to transform a component diagram into an executable model based on different extensions of petri nets. Moreover, we show how to use this petri net model for performance evaluation and simulation and the implications of this transformation are described completely. Finally, to represent the usage of our proposed algorithm, we consider a case study as an example.

To keep our software products and cross-product software components maintainable, an approach to software architecture management with a long-term perspective is required. One-time modeling of the intended software architecture is not sufficient. Instead, it must be maintained throughout the whole life-cycle of the software system. Tool support is required to monitor the actual physical software architecture. Deviations must be resolved by modifying the software system or the software architecture description. All software architectures are required to follow a consistent architectural style, which is defined in a technology-neutral way and mapped to all technologies we use in development. In order to support this multi-technology landscape, the architectural style, and our use cases, we developed a tool suite, the BTC RevEngTools.

Interest in software architecture as an area of research, education, and practice within software engineering has been growing steadily over the past decade. Software architecture is concerned with the principled study of large-grained software components, including their properties, relationships, and patterns of combination. It is becoming clear that one key to the effective development, operation, and evolution of software systems is the design and evaluation of appropriate architectures.As a complement to the Fourth Symposium on the Foundations of Software Engineering (FSE-4), whose theme was software architecture, the Second International Software Architecture Workshop (ISAW-2) brought together practitioners and researchers for two intense days of discussion and work. The ISAW-2 proceedings [6] were published in the Joint Proceedings of the SIGSOFT '96 Workshops, ACM Press, ISBN 0-89791-867-3.The participants were organized into three parallel working groups each focused on a different topic within software architecture.• Styles and Patterns ---Techniques and models for centering software architecture activities on generally useful design methods, components, and assemblages of components.• Architecture Description ---Languages and methods for the capture of architectural designs.• Tools and Methods ---Automated aids for designing, evaluating, validating, implementing, and evolving software architectures.Tying these work groups together was the use of a common case study derived from a real-world architecture found in industry. Each working group studied this architecture from its particular perspective and, to a greater or lesser extent, used the case study to organize their discussions. It is interesting to note, for example, that the three groups created specialized depictions of the architecture for their discussion (see figures 6, 8, and 10).The case study was the architecture of the Call Center Customer Care (C4) System, which was developed by Andersen Consulting. A description of the architecture and some of its more interesting challenges appears in Section 2. It is reproduced here in the hopes that it might be prove of continued use to the community.Also appearing here are reports from each working group. The Styles and Patterns Working Group was led by Frances Paulisch, of Siemens, and Mary Shaw, of CMU. The group tried to uncover the styles and patterns that underlay various components of the C4 architecture. In the process, they defined a new kind of architectural style that they named the Data Ooze. The Architectural Description Working Group was led by Paul Clements, of the SEI, and Jeff Magee, of Imperial College. The group concentrated on identifying critical aspects of architectures that require description and on identifying important areas where further work in architectural description is needed. The Tools and Methods Working group was led by William Griswold, of UCSD, and Philippe Kruchten, of Rational. The group pretended to go through a development cycle for the C4 system in order to uncover various architectural tool and method needs.At the conclusion of the workshop, the working group chairs held a panel session in which each group asked a "challenge" question of the other two groups. The questions and responses appear in Section 5.2.We hope that these succeedings capture at least some essence of the very fruitful discussion that occurred at the workshop. Of course, this report cannot replace the benefits of actual attendance. The workshop will indeed continue, and we hope that the reader will be interested in attending a future ISAW.

There is a plethora of models, techniques and tools that support model-and component-based software development of vehicular distributed embedded systems. However, a large majority of them have a limited or no support to model and specify end-to-end resource reservations on the software architectures of these systems. Resource reservations allow flexibility during the development and execution of such complex systems without jeopardizing their predictable behavior. As a result, several applications in the system that share the same hardware platform can be developed independently. In this paper we identify several requirements that any existing component model should fulfill in order to support the modeling of end-to-end resource reservations on the software architectures of such systems. As a proof of concept, we extend the Rubus Component Model (RCM) by fulfilling these requirements. RCM is used for the development of control functionality in vehicular embedded systems by several international companies. We also provide a technique to extract execution models from the software architectures of these systems with resource reservations. In order to show the usability of our technique, we model a vehicular distributed embedded system with the extended component model and extract the execution model from the software architecture augmented with end-to-end resource reservations.

This article describes a software methodology for built-in-test (BIT) for processor based modules. Firstly, an example of the hardware comprising a common processor module is given. This is followed by a description of the BIT software architecture and details of the component elements: the test executive, which integrates all the components and provides the interface to external applications and boot programs; the BIT reconfiguration table, for test control flexibility; test result handling; and the individual test functions, written in both assembly language and C. This BIT product is extremely flexible, portable, and very thorough are high fault detection, high isolation coverage, and support for unique test requirements.

Software architecture is being widely used today to describe a very high-level design methodology of large software systems. Software architecture represents the overall structure of a system in an abstract, structured manner. A good architectural representation scheme holds the key to the effectiveness of a software architecture description and usage. In this work we look at architectural styles and architectural representation schemes. We propound the idea that the layered architectural model is a suitable candidate for a generalized architectural style and that it can cater to many different problem domains, other than the message-passing systems it has traditionally been used to model. We propose some rules by which the layered architectural style can be improved and modified in order to be able to model a wider problem domain. Then we evaluate different methods of architectural representations that have been used to model software architecture and analyze their strengths and shortcomings. We propose the use of a modified data flow diagram architecture representation scheme. This scheme is called AND-OR DFD method and is introduced and developed in this thesis. The main concept introduced here is a combination of components to form action groups to support multiple workflows and the relationships among them, without significant increase in the architectural complexity. Finally, we look at UML as a prospect for a generalized architecture description language and discuss its merits and demerits with examples.

This article explores the world of dependable systems, specifically focusing on system design, software solutions, and architectural decisions that facilitate collaborative work on shared text documents across multiple users in near real time. It aims to dive into the intricacies of designing robust and effective document collaboration software focusing on understanding the requirements of such a system, the working principle of collaborative text editing, software architecture, technology stack selection, and tooling that can sustain such a system. To examine the pros and cons of the proposed system, the paper will detail how collaborative text editing software can benefit from such an architecture regarding availability, elasticity, and scaling. The intricate nature of this system renders this paper a valuable resource for prospective investigations within the domain of dependable systems and distributed systems. This research first examines the requirements of a real-time collaboration system and the necessary core features. Then, it analyzes the design, the application structure, and the system organization while also considering key architectural requirements as the necessity of scaling, the usage of microservices, cross-service communications, and client–server communication. For the technology stack of the implementation, this research considers the alternatives at each layer, from client to server. Once these decisions are made, it follows system development while examining possible improvements for the issues previously encountered. To validate the architecture, a testing strategy is developed, to examine the key capabilities of the system, such as resource consumption and throughput. The conclusions review the combination of modern and conventional application development principles needed to address the challenges of conflict-free document replication, decoupled and stateless event-driven architecture, idempotency, and data consistency. This paper not only showcases the design and implementation process but also sets a foundation for future research and innovation in dependable systems, collaborative technologies, sustainable solutions, and distributed system architecture.