Formal Methods for Software Architectures

Developing a good software architecture for a complex system is a critically important step for insuring that the system will satisfy its principal objectives. Unfortunately, today descriptions of software architecture are largely based on informal “box-and-line” drawings that are often ambiguous, incomplete, inconsistent, and unanalyzable. This need not be the case. Over the past decade a number of researchers have developed formal languages and associated analysis tools for software architecture. In this paper I describe a number of the representative results from this body of work.

Requirements and architecture are two essential inter-related products in the software lifecycle. Software architecture has long been recognized to have a profound impact on non-functional requirements about security, fault tolerance, performance, evolvability, and so forth. In spite of this, very few techniques are available to date for systematically building software architectures from functional and non-functional requirements so that such requirements are guaranteed by construction. The paper addresses this challenge and proposes a goal-oriented approach to architectural design based on the KAOS framework for modeling, specifying and analyzing requirements. After reviewing some global architectural decisions that are already involved in the requirements engineering process, we discuss our architecture derivation process. Software specifications are first derived from requirements. An abstract architectural draft is then derived from functional specifications. This draft is refined to meet domain-specific architectural constraints. The resulting architecture is then recursively refined to meet the various non-functional goals modelled and analyzed during the requirements engineering process.

In this overview paper, we outline a tool supported approach to the design and analysis of complex systems at the architectural level. The foundations of this approach are the use of the architectural description language Darwin to capture structural information about components and their interconnection and the use of a process algebra FSP to describe the behaviour of individual components. These descriptions are combined to construct a system behavioural model that can be animated to validate requirements and model checked against properties specified in Linear Temporal Logic. Recently, this foundation has been extended with work on the synthesis of behavioural models from scenarios captured as message sequence charts (MSC). Models described in this way can be used as an initial basis for validating requirements and as a specification that must be satisfied by more detailed models. The approach we outline is supported by the Labelled Transition system Analyser (LTSA) tool, which has been extended to deal with MSCs.

As the focus of software design shifts increasingly toward the architectural level, so too are its analysis techniques. Dependence analysis is one such technique that shows promise at this level. In this paper we briefly describe and illustrate the application of dependence analysis to architectural descriptions of software systems.

Distributed systems are increasingly built using distributed object or component middleware. The dynamic behaviour of those distributed systems is influenced by the particular combination of middleware synchronisation and threading primitives used for communication amongst distributed objects. A designer may accidentally choose combinations that cause a distributed application to enter undesirable states or violate liveness properties. We exploit the fact that modern object and component middleware offer only a small number of underlying synchronisation primitives and threading policies. For each of these we define a UML stereotype and a formal process algebra specification of the stereotype semantics. We devise a means to specify safety and liveness properties in UML and again map those to process algebra safety and liveness properties. We can thus apply model checking techniques to verify that a given design does indeed meet the desired properties. We propose how to reduce the state space that needs to be model checked by exploiting middleware characteristics. We finally show how model checking results can be related back to the input UML models. In this way we can hide the formalism and the model checking process entirely from UML designers, which we regard as critical for the industrial exploitation of this research.

SAs provide a high-level model of large, complex systems using suitable abstractions of the system components and their interactions. SA dynamic descriptions can be usefully employed in testing and analysis. We describe here an approach for SA-based conformance testing: architectural tests are selected from a Labelled Transition System (LTS) representing the SA behavior and are then refined into concrete tests to be executed on the implemented system. To identify the test sequences, we derive abstract views of the LTS, called the ALTSs, to focus on relevant classes of architectural behaviors and hide away uninteresting interactions. The SA description of a Collaborative Writing system is used as an example of application. We also briefly discuss the relation of our approach with some recent research in exploiting the standard UML notation as an Architectural Description Language, and in conformance testing of reactive systems.

Although architectural concepts and techniques have been considered mainly as a means of controlling the complexity of developing software, we argue, and demonstrate, that they can play a vital role in supporting current needs for systems that can evolve and adapt, in run-time, to changes that occur in the application or business domain in which they operate.

When tackling the construction of a software system, at the software architecture design level there are two main issues related to the system performance. First, the designer may need to choose among several alternative software architectures for the system, with the choice being driven especially by performance considerations. Second, for a specific software architecture of the system, the designer may want to understand whether its performance can be improved and, if so, it would be desirable for the designer to have some diagnostic information that guide the modification of the software architecture itself. In this paper we show how these two issues can be addressed in practice by employing a methodology relying on the combined use of Æmilia — an architectural description language based on stochastic process algebra — and queueing networks — structured performance models equipped with fast solution algorithms — which allows for a quick prediction, improvement, and comparison of the performance of different software architectures for a given system. The methodology is illustrated through a case study in which a sequential architecture, a pipeline architecture, and a concurrent architecture for a compiler system are compared on the basis of typical average performance indices.

Nowadays, architects, designers and developers build systems based on an architecture-driven approach. They specify the system’s software architecture using Architecture Description Languages or other standard modeling notations like UML. Given the previous, we examine what we need to specify at the architectural level to enable the automated generation of models for dependability analysis. In this paper, we further present a prototype implementation of the proposed approach, which relies on UML specifications of dependable systems’ software architectures. Moreover, we exemplify our approach using a case study system.