Mert Ozkaya

Are We There Yet? Analyzing Architecture Description Languages for Formal Analysis, Usability, and Realizability

Research on Software Architectures has been active since the early nineties, leading to a number of different architecture description languages (ADL). Given their importance in facilitating the communication of crucial system properties to different stakeholders and their analysis early on in the development of a system this is understandable. After all these years one would have hoped that we could point to a handful of ADLs as the clear winners as the languages of choice of practitioners for specifying software system architectures. However it seems that ADLs have still not entered the mainstream. We believe this is so because practitioners find the current offering either too difficult to use or not supporting automated analysis commensurate to the level of effort they require for specifying a system, especially so for complex systems. In this paper we present a comparative analysis of a number of ADLs, both of first generation and more recent ones, against a small set of language properties that we believe are crucial for an ADL that would be easy for practitioners to adopt in their design and development practices. These properties are: formal semantics, usability, and realizability.

Design-by-contract for reusable components and realizable architectures

Architectural connectors can increase the modularity and reusability benefits of Component-based Software Engineering, as they allow one to specify the general case of an interaction pattern and reuse it from then on. At the same time they enable components to be protocol-independent - components do not need to know under which interaction patterns they will be used, as long as their minimal, local interaction constraints are satisfied. Without connectors one can specify only specific instances of such patterns and components need to specify themselves the interaction protocols that they will follow, thus reducing their reusability. Connector frameworks so far allow designers to specify systems that are unrealizable in a decentralized manner, as they allow designers to impose global interaction constraints. These frameworks either ignore the realizability problem altogether, ignore connector behaviour when generating code, or introduce a centralized controller that enforces these global constraints but does so at the price of invalidating any decentralized properties of the architecture. We show how the Xcd ADL extends Design-by-Contract (DbC) for specifying (i) protocol-independent components, and (ii) arbitrary connectors that are always realizable in a decentralized manner as specified by an architecture - Xcd connectors impose local constraints only. Use of DbC will hopefully make it easier for practitioners to use the language, compared to languages using process algebras. We show how Xcd specifications can be translated to ProMeLa so as to verify that (i) provided services local interaction constraints are satisfied, (ii) provided services functional pre-conditions are complete, (iii) there are no race-conditions, (iv) event buffer sizes suffice, and (v) there is no global deadlock. Without formally analyzable architectures errors can remain undiscovered for a long time and cost too much to repair.

Xcd – Modular, Realizable Software Architectures

Connector-Centric Design (Xcd) is centred around a new formal architectural description language, focusing mainly on complex connectors. Inspired by Wright and BIP, Xcd aims to cleanly separate in a modular manner the high-level functional, interaction, and control system behaviours. This can aid in both increasing the understandability of architectural specifications and the reusability of components and connectors themselves. Through the independent specification of control behaviours, Xcd allows designers to experiment more easily with different design decisions early on, without having to modify the functional behaviour specifications (components) or the interaction ones(connectors).

Towards Design-by-Contract based software architecture design

Design-by-Contract (DbC) gained wide familiarity among software developers for specifying software. It aids in documenting the behaviour of class methods as contracts between clients of the methods (pre-) and their suppliers (post-condition). This not only allows developers to document software behaviour precisely at such a high-level that can more easily be communicated, but also enables the formal verification of the behaviour. In this paper, we provide a comprehensive extension to DbC so that it can also be applied to the level of software architecture design. We illustrate this through our architecture description language XCD. Components in XCD have four different types of interfaces: provided and required interfaces of methods or emitter and consumer interfaces of events where methods/events are contractually specified. Contract specification is separated into functional and interaction contracts thus modularising the functional and interaction component behaviours. Furthermore, treating interaction protocols as connectors, XCD allows to specify connectors with interaction contracts that participating components adhere to. The formal semantics of XCD are defined using Finite State Process (FSP) thus enabling formal analysis of contractually specified software architectures for quality properties, e.g., deadlock.

Do the informal & formal software modeling notations satisfy practitioners for software architecture modeling?

Abstract Context Software architectures can be modeled using semantically informal (i.e., ambiguous) or formal (i.e., mathematically precise) software modeling notations. Objective In this paper, 115 different practitioners from 28 different countries who work in companies that perform software development have been surveyed. The goal is to understand practitioners’ knowledge and experience about informal and formal modeling notations in specifying software architectures. Method The survey consists of 35 different questions, divided into three parts, i.e., the participant profile, the informal modeling, and formal modeling. The results of the survey lead to many interesting findings: Results (1) Informal software modeling notations (especially UML) are practitioners’ top choice in specifying software architectures (94%). (2) Despite many informal languages, some practitioners (40%) insist using informal ad-hoc techniques (i.e., simple boxes/lines and natural languages) to specify complex design decisions (e.g., structure, behaviour, and interaction). (3) Practitioners using informal notations are impressed by their low learning-curve (79%), visuality (62%), and general-purpose scope (66%). (4) Practitioners still criticise informal notations too, essentially for the lack of support for complex design decisions and their exhaustive analysis. (5) While formal modeling notations bridge this gap mentioned in step-4, many practitioners (70%) rarely use formal notations due essentially to the high-learning curve, the lack of knowledge among stakeholders, and the lack of popularity in industry. (6) Among the considered formal notations (i.e., process algebras, high-level formal specification languages, and architecture description languages (ADLs)), process algebras are never used and ADLs are the least used formal languages are ADLs (i.e., 12% frequently use ADLs). (7) Practitioners complain about ADLs’ weak tool support (38%) and their lack of tutorials/guidance/etc (33%). Conclusion The survey results will let the community realise the advantages and disadvantages of informal and formal modeling notations for software architecture modeling from practitioners’ viewpoint.

Realizable, Connector-Driven Software Architectures for Practising Engineers

Despite being a widely-used language for specifying software systems, UML remains less than ideal for software architectures. Architecture description languages (ADLs) were developed to provide more comprehensive support. However, so far the application of ADLs in practice has been impeded by at least one of the following problems: (i) advanced formal notations requiring a steep learning curve, (ii) lack of support for user-defined, complex connectors, and (iii) potentially unrealizable architectural designs.

Highly Analysable, Reusable, and Realisable Architectural Designs with XCD

Connector-Centric Design (XcD) is a new approach to specifying software architectures. XcD views complex connectors as highly significant in architectural designs, as it is the complex connectors that non-functional quality properties in systems can emanate from. So, XcD promotes in designs a clean separation of connectors (interaction behaviours) from components (functional behaviours). Designers can then specify connectors in detail explicitly thus easing the analysis of system designs for quality properties. Furthermore, XcD separates control behaviour from connectors as control strategies. Architectural designs in XcD thus become highly modular with re-usable components, connectors, and control strategies (representing design solutions for quality properties). The end result is the eased architectural experimentation with different design solutions by re-using components/connectors and formal analysis of these solutions to find out the optimal ones.

Implementing Contract-based Software Architectures in Java: The Structural, Behavioural, and Interaction Design Decisions.

Architectural languages (ALs) have been so actively researched since the nineties and this leads to many ALs with different capabilities that have been proposed each day. However, most of the ALs ignore the specifications of the structural, behavioural, and interaction design decisions and do not support their analysis and development. The ALs that do support suffer from the process algebra based notation sets that practitioners do not prefer to work with. This issue is tackled in the paper by extending the Design-by-Contract based architectural language called XCD that supports the contractual specifications of the structural, behavioural, and interaction design decisions about software systems and their formal analysis. XCD is extended with a development support in Java so as to transform the contractual specifications in XCD into a complete Java program that considers all the structural, behavioural, and interaction decisions specified. So, practitioners will be able to specify non-algebraic, contractual specifications in XCD, formally analyse them, and produce the Java source-code that reflects the specified architecture completely and consistently. The produced Java code can also be tested for incompleteness and wrong use of component services automatically.

Architecture Descriptions of Software Systems: Complex Connectors vs Realisability.

With the advent of software architectures, architectural languages have become an active research area for the specification of software architectures in terms of components & connectors and for some extra capabilities such as formal analysis and code generation. In this paper, the existing architectural languages have been analysed for two important language features i.e., interaction protocols and realisability. The analysis results show that only a few languages support interaction protocols via their first-class connector elements (also referred to as complex connectors). However, complex connectors of those languages lead to unrealisable specifications due to enabling global constraints which may not be possible for distributed systems. Therefore, practitioners cannot implement the system in the way specified, and any analyses (e.g., performance) made on the unrealisable specifications will all be invalid.

Visual Specification and Analysis of Contract-Based Software Architectures

XCD is a design-by-contract based architecture description language that supports modular specifications in terms of components and connectors (i.e., interaction protocols). XCD is supported by a translator that produces formal models in SPIN’s ProMeLa formal verification language, which can then be formally analysed using SPIN’s model checker. XCD is extended with a visual notation set called VXCD. VXCD extends UML’s component diagram and adapts it to XCD’s structure, contractual behaviour, and interaction protocol specifications. Visual VXCD specifications can be translated into textual XCD specifications for formal analysis. To illustrate VXCD, the well-known gas station system is used. The gas system is specified contractually using VXCD’s visual notation set and then formally analysed using SPIN’s model checker for a number of properties including deadlock and race-condition.