PAT approach to Architecture Behavioural Verification Nacha Chondamrongkul ∗ , Jing Sun † , Ian Warren ‡ Department of Computer Science The University of Auckland Auckland, New Zealand ∗ ncho604@aucklanduni.ac.nz † jing.sun@auckland.ac.nz ‡ i.warren@auckland.ac.nz Abstract—Software architecture design plays a vital role in software development, as it gives an overview of how the software system should be constructed and executed at runtime. The verification of software architecture design is hence important but it is an error-prone task that heavily relies on knowledge and experience of the software architect, especially for a large software system that its behaviour is complex. Automated verifi- cation can be a solution to this problem, however, the specification language must be expressive enough to describe the behaviour of different design entities. This paper presents an enhancement of an architecture description language supported by PAT. The enhancement aims to improve the expressiveness of the language, in order to support the automated behaviour verification of software architecture design. With this enhancement, different behaviour of specific component and connector can be thoroughly checked and traced. The implementation of this enhancement is presented to demonstrate how the standard model checking engine such as PAT can be extended to support an architecture description language. We evaluated our approach with a case study and the result is presented. Index Terms—Software Architecture, Architecture Description Language, Model Checking, Linear Temporal Logic I. I NTRODUCTION Software architecture design gives an overview of how the software system is implemented and works. If the software architecture design is made incorrectly, it can cause the project to fail or delay due to design re-correction, therefore the verifi- cation is a significant task. However, the software architecture designs are usually represented by informal notations, such as graphical diagram and text. The design interpretation can hence be inconsistent and the verification process is an error- prone and time consuming task, even to those with extensive experience and knowledge. If the software architecture design can be formally defined, the verification task can be automated. Therefore, applying the formal methods to the software archi- tecture design would be a useful approach to this problem. Many architecture description languages (ADL) have been proposed to formally define the software architecture design model such as [1], [2], [3], and [4]. With the formal model in ADL, different properties can be defined and automatically DOI reference number:10.18293/SEKE2019-041 verified with the model checker. Allen and Garlan [1] proposed Wright, an ADL that allows connections in software architec- ture design to be formally defined in communicating sequential process (CSP). The formal format of design model allows to check the architectural compatibility among connections. However, the behavioural property definition and verification had not been completely addressed so there are number of works that aim to fulfil this. Darwin [5] was proposed to allow behavioural properties to be defined in the linear temporal logic (LTL) and use LTSA [2] as a model checker to verify them. Defining and verifying behaviours in the evolving soft- ware system is a challenge. Oquendo [3] presented π-Method with an ADL based on π-calculus. The ADL for π-Method helps to formally define evolvable software system in both structural and behavioural view. In addition, the refinement model can be defined to check and preserve the behavioural properties. Some works have applied process algebra to formalize specific behaviour in the software system because of its expressiveness in describing system behaviour. Aldini et al. [6] presented a guideline that includes a principle of formalizing system behaviour into process algebra. The manual formal- ization from the design model to ADL has been an obstacle to making it widely used by the software engineers, due to the fact that the majority of them do not have background knowledge in the formal methods and the verification output from model checker can be difficult to understand. Therefore, the degree of formality needs to be balanced with the practi- cality. Some approaches, such as Bose et al. [7], Baresi et al. [8] and CHARMY [4], hence provide a feature that translates the input model in graphical notation into formal language that can be automatically checked. While, some approaches, such as Arcade [9], aim to make the verification output from the model checker more readable. The graphical abstraction may promote the practicality and understandability of using formal ADL, but the ambiguity might occur from the lack of complete semantic mapping between the graphical input and the model checking input. In addition, most of the existing approaches use standard model checking engines that is not designed with the architecture design concept. For example, Wright uses FDR as a model checker, while Darwin and