1 Introduction
Software intensive systems are becoming increasingly big and complex, which makes their verification a challenge. To address this challenge, compositional verification techniques separate the verification of single components from the verification of their composition. In architecturebased verification (ABV) [30], for example, verification of such systems is split into two parts: First, suitable contracts are identified for the involved components and their implementation is verified against these contracts. Since a single component is usually of limited complexity, in ABV this step is fully automated using Model Checking [2]. In a second step, component contracts are combined to verify overall system properties. Reasoning about the composition of contracts, however, might be difficult and sometimes requires manual interaction [29]. Thus, in ABV, it is done using interactive theorem provers, such as Isabelle [33].
A fullfledged interactive theorem prover, however, can be quite complex and its usage usually requires expertise which is not always available in the architecture context [28]. Thus, in an effort to bridge the gap between interactive theorem proving and the architecture domain, we developed APML: a language to specify proofs for the composition of contracts using abstractions an architect is familiar with. APML comes with a graphical notation, similar to Message Sequence Charts [15], to sketch proofs at the architecture level and it is shown to be sound and complete regarding the verification of architecture contracts. It is implemented in Eclipse/EMF [40], where it can be used to model proofs for architecture contracts and synthesize corresponding proofs for Isabelle’s structured proof language Isar [42, 43].
The aim of this paper is to introduce APML. To this end, we provide the following contributions: (i) We provide a formal description of APML, including a formal semantics for architecture contracts. (ii) We show soundness and completeness of APML for the verification of architecture contracts. (iii) We present an algorithm to map an APML proof to a corresponding proof in Isabelle/Isar. (iv) We describe its implementation in terms of an Eclipse/EMF modeling application. (v) We demonstrate the approach by means of a running example and report on the outcome of a case study in which we applied APML for the verification of a railway control system. Thereby, to the best of our knowledge, this is the first attempt to synthesize proofs for an interactive theorem prover from an architecture description.
Our presentation is structured as follows: In section 2, we provide some background to clarify our understanding of architecture in general and specifically our notion of architecture contract. In section 3, we describe our running example, a reliable calculator. In section 4, we introduce APML, demonstrate it by verifying a property for our running example, and present our soundness and completeness results. In section 5, we present our algorithm to map an APML proof to a corresponding proof in Isabelle/Isar and demonstrate it by means of the running example. In section 6, we describe the implementation of APML in terms of an Eclipse/EMF modeling application and in section 7 we describe our effort to evaluate APML by means of a larger case study. In section 8, we discuss related work before we conclude the paper in section 9 with a brief summary and a discussion of future work.
2 Background
2.1 Basic Mathematical Notations
For a function , we shall use to denote the restriction of to domain . In addition, we shall use partial functions for which we denote with its domain and with its range.
We will also use finite as well as infinite sequences of elements. Thereby, we denote with the set of all finite sequences over elements of a given set , by the set of all infinite sequences over , and by the set of all finite and infinite sequences over . The th element of a sequence is denoted with and the first element is . Moreover, we shall use to denote the length of . For a sequence of functions we shall use to denote the sequence of all restrictions .
2.2 Architecture Model
In our model [27, 32], components communicate to each other by exchanging messages over ports. Thus, we assume the existence of set , containing all messages, and set , containing all ports, respectively. Moreover, we postulate the existence of a type function
(1) 
which assigns a set of messages to each port.
Ports are means to exchange messages between a component and its environment. This is achieved through the notion of port valuation. Roughly speaking, a valuation for a set of ports is an assignment of messages to each port.
Definition 1 (Port Valuation)
For a set of ports , we denote with the set of all possible, typecompatible port valuations, formally:
Components communicate through interfaces by receiving messages on its input ports and sending messages through its output ports.
Definition 2 (Interface)
An interface is a pair , consisting of disjoint sets of input ports and output ports . For an interface , we denote by the set of input ports, the set of output ports, and the set of all ports. A set of interfaces is called disjoint iff its interfaces do not share any ports. For such sets of interfaces, we shall use the same notation as introduced for single interfaces, to denote their input, output, and all ports.
In addition, a component has a behavior which is given in terms of a nonempty set of sequences of port valuations over its interface.
In our model, an architecture connects input and output ports of a set of interfaces. Thereby, the types of connected ports must be compatible.
Definition 3 (Architecture)
An architecture is a pair , consisting of a disjoint set of interfaces and a connection , such that
(2) 
Note that a connection is modeled as a partial
function from input to output ports, meaning that not every input port of an architecture is connected to a corresponding output port and vice versa. Thus, ports of an architecture can be classified as either
connected (given by ) or disconnected (given by ).2.3 Composition
The interface of an architecture with its environment is given by its disconnected ports.
Definition 4 (Architecture Interface)
For an architecture , its interface is defined as , consisting of input ports and output ports .
Note that, since is required to be disjoint, an architecture’s input and output ports are guaranteed to be disjoint, too. Thus, an architecture interface fulfills all the requirements of definition 2 and thus represents a valid interface. Hence, we can use the same notation as introduced for interfaces to access its ports.
We can now define a notion of composition to obtain the behavior of an architecture from the behavior of its components.
Definition 5 (Architecture Behavior)
Given an architecture and a nonempty behavior for all of its interfaces . The behavior of the composition is given by a set of traces , defined as follows:
(3)  
(4)  
(5) 
2.4 Contracts
In the following, we are considered with the specification of architectures (as they were described in the previous section). To this end, we assume the existence of a set of predicates to specify valuations for a set of ports .
Our notion of contract is inspired by Dwyer’s work on specification patterns [18] which is often found in practice [24]. Thereby, contracts have the form: “if is true then happens after time points”.
Definition 6 (Contracts)
A contract for an interface is a triple , consisting of a (possibly empty) trigger , a guarantee , and a duration . For every entry of a trigger, we denote by its predicate and with its time point. Moreover, we require the following conditions for a contract:

The time point of the first trigger is : (if ).

Triggers are ordered by their time points: .

The guarantee is after the last trigger: (or if ).
Moreover, since they are specified over interfaces, contracts can be specified for components as well as for architectures. They are best expressed graphically using a notation similar to Message Sequence Charts [15] (see fig. 4 or fig. 5 for an example).
In the following, we define what it means for a behavior of a component (or architecture) to satisfy a corresponding contract. Thereby, we denote with that a valuation satisfies a predicate .
Definition 7 (Satisfaction)
A behavior for an interface satisfies a contract for that interface, written , whenever for all , satisfaction of the triggers implies satisfaction of the guarantee:
Again, the same definition can be applied for component contracts as well as for architecture contracts.
2.5 Isabelle
Isabelle [33] is a generic proof assistant which allows mathematical formulæ to be expressed in a formal language and which provides tools for proving those formulas in a logical calculus. The version of Isabelle used for the work presented in this paper is Isabelle/HOL, which includes tools to support the specification of datatypes, inductive definitions, and recursive functions.
Specifications in Isabelle are grouped into socalled theories, which may import other theories. To modularize results, Isabelle supports the development of abstract specifications by means of locales [3]. Figure 1 shows how such a locale usually looks like: It consists of a name, a list of parameters, and a list of assumptions about these parameters. In previous work [29], we show how to map an architecture specification to a corresponding Isabelle locale. Thereby, ports are mapped to corresponding locale parameters and specifications to locale assumptions.
In Isabelle, proofs can be expressed in a natural way using Isabelle’s structured proof language Isar [43]. A typical Isar proof is depicted in fig. 2: It consists of a sequence of proof steps, which are discharged by some proof methods. For example, Isabelle’s classical reasoner blast can perform long chains of reasoning steps to prove formulas. Or the simplifier simp can reason with and about equations. Moreover, external, firstorder provers can be invoked through sledgehammer.
3 Running Example: A Reliable Adder
As a running example, let us consider a simple system which calculates the sum of two numbers in a redundant way. Its architecture is depicted in fig. 3: It consists of a dispatcher component which receives two numbers as input from its environment and forwards copies of these numbers to two different adder components. The adder components then calculate the sum of the two numbers and communicate their result to a merger component. The merger component compares the two results and forwards the final result to its environment.
The behavior of each component is specified in terms of contracts (as introduced by definition 6) by the sequence diagrams depicted in fig. 4: Figure 4 depicts contract dispatch for the dispatcher component. It requires a dispatcher to forward incoming messages received at ports and , on its output ports , within one time unit. The contracts for the two adder components, add1 and add2, are depicted in fig. 4 and fig. 4, respectively. They both require an adder to calculate the sum of the numbers obtained on its input ports and and output it on its output port . For our example, we assume that the two components use different algorithms to calculate the sum, which is why Adder1 requires four time units while Adder2 requires only three time units to output its result. Figure 4, fig. 4, and fig. 4, depict three different contracts for the merger component. Contract merge1 requires the merger component to compare the messages received on its input ports and , and for the case they coincide, to forward the message after two time units on its output port . Contracts merge2 and merge3 require the merger component to cope with a potential delay of one time unit for messages received on its input ports and , respectively.
Among other things, we expect the resulting system to output the sum of two numbers it receives on its input ports and after seven time units on its output port . This can be expressed in terms of a contract over its architecture as specified by the sequence diagram depicted in fig. 5.
Note that our running example is deliberately oversimplified, since its main purpose is to demonstrate our concepts and ideas rather than evaluating the approach in a real world scenario. For details about how the approach works on a real example, we refer to the description of the case study in section 7.
4 Modeling Architecture Proofs
An architecture contract can be verified from a set of contracts for its components through a sequence of proof steps.
Definition 8 (Proof Step)
A proof step for an architecture and corresponding contracts for its interfaces , is a tuple , consisting of

a time point denoted ,

an architecture state (for some ) denoted ,

a rationale (for some ) denoted ,

a (possibly empty) sequence of references denoted , such that and where is a nonempty set of elements .
Note that an element of is either a reference to an assumption of the architecture contract we want to prove, or a reference to another proof step and a set of connections . An architecture proof is given by a sequence of corresponding proof steps.
Definition 9 (Architecture Proof)
Given an architecture and corresponding contracts for its interfaces . An architecture proof for a contract over the architecture’s interface is a finite, nonempty sequence of proof steps, such that the state of the last entry implies the guarantee of the architecture contract:
(6) 
the time of the last entry corresponds to the duration of the architecture contract:
(7) 
and for all entries , such that :

refers only to triggers of the architecture contract or previous proof steps:
Note that this implies that contains only references to triggers of the architecture contract.

The time points of the referenced entries respect the time points of the triggers of the rationale. Thus, we first introduce a function (for ) to return the relative time point of a reference:
Now we can use this function to formalize the condition (note that by definition 8, ):
Note that this condition implies that for all , the referenced time points of all entries is the same.

The referenced entries imply the corresponding triggers of the rationale:

The time of the current entry respects the duration of the rationale (note that the time of corresponds to the time point of the first trigger of the rationale):

The guarantee of the rationale implies the current state:
Similar as for contracts, architecture proofs are best expressed graphically using a notation similar to Message Sequence Charts (see fig. 6 for an example).
4.1 Verifying Reliable Adder
Table 1 shows an architecture proof for the contract of our running example depicted in fig. 5. It consists of four steps: 0. First, we apply contract dispatch of the dispatcher component to trigger of the architecture contract, to obtain a valuation of the dispatcher’s output ports at time point with messages and , respectively. 1. Then, we use connections and to pass messages and to the corresponding input ports of Adder1 and apply contract add1 to obtain a new state for time point , in which the output port of Adder1 contains the sum of and . 2. Similarly, we can use connections and to apply contract add2 to the architecture state given by step , to obtain a new state for time point , in which the output port of Adder2 contains the sum of and . 3. Finally, we can use connections and to pass the calculated sums to the input of the merger component and apply contract merge3 to forward it on its output port.
dispatch  
add1  
add2  
merge3 
Note that the proof is only valid, since we chose contract merge3 for the merger component. If we had chosen merge1 or merge2, the proof would have violated condition 2 of definition 9.
4.2 Soundness and Completeness
In the following, we provide two theoretical results for APML. The first one ensures that if we can prove an architecture contract from the contracts of its components using APML, then, an architecture in which the components satisfy the corresponding contracts is indeed guaranteed to satisfy the architecture contract.
Theorem 4.1 (Soundness)
Given an architecture and corresponding contracts for each interface , such that . If there exists an architecture proof for an architecture contract , we have .
Proof (The full proof is provided in appendix 0.a)
According to definition 7 we have to show that for all and all , . Thus, we assume and we show by complete induction over the length of the proof sequence that . Thus, and, by eq. 6 and eq. 7, we can conclude .∎
The second result guarantees that, whenever the satisfaction of contracts for components of an architecture leads to the satisfaction of a corresponding contract for the architecture, then it is possible to find a corresponding APML proof.
Theorem 4.2 (Completeness)
Given an architecture and corresponding contracts for each interface . For each architecture contract , such that for all possible behaviors :
(8) 
there exists an architecture proof for .
Proof (The full proof is provided in appendix 0.b)
For the proof we construct a “maximal” architecture proof , according to definition 9, by repeatedly applying all feasible contracts. If we eventually reach an entry such that and then we are done. If not, then we build an architecture trace , such that and and and for all other , we choose , such that the projection to every interface does not satisfy the assumptions of any contract . Now, we can show that and thus, by eq. 8 we can conclude . Thus, since , we can conclude which is a contradiction to .∎
5 From APML to Isabelle
To verify soundness of an APML proof, algorithm 1 shows how an APML proof can be mapped to a corresponding Isar proof for the interactive theorem prover Isabelle.
Let us see how the algorithm can be applied to generate an Isar proof for the APML proof of our running example, described in section 4.1. First, we create an Isabelle locale for the architecture as described in fig. 3: locale rsum fixes Dispatcher: di1natnat and di2natnat and do1natnat and do2natnat and do3natnat and do4natnat Adder1: and a1i1natnat and a1i2natnat and a1onatnat Adder2: and a2i1natnat and a2i2natnat and a2onatnat Merger: and mi1natnat and mi2natnat and monatnat Contracts: assumes dispatch n x y di1 n x di2 n y do1 n1 x do2 n1 y do3 n1 x do4 n1 y and add1 n x y a1i1 n x a1i2 n y a1o n4 x y and add2 n x y a2i1 n x a2i2 n y a2o n3 x y and merge1 n x mi1 n x mi2 n x mo n2 x and merge2 n x mi1 n x mi2 n1 x mo n3 x and merge3 n x mi2 n x mi1 n1 x mo n3 x Connections and do1a1i1 n a1i1 n do1 n and a1i2do2 n a1i2 n do2 n and do3a2i1 n a2i1 n do3 n and a2i2do4 n a2i2 n do4 n and a1omi1 n mi1 n a1o n and mi2a2o n mi2 n a2o n Note that each contract, as presented in fig. 4, results in a corresponding locale assumption. Now, we can create a theorem for the architecture contract described by fig. 5: theorem sum fixes n x y assumes a0 di1 n x di2 n y shows mo n7 x y Finally, we can apply algorithm 1 to create an Isar proof for the theorem from the APML proof described in table 1: proof from a0 have di1 n x di2 n y by auto hence s1 do1 n1 x do2 n1 y do3 n1 x do4 n1 y using dispatch by blast from s1 have a1i1 n1 x a1i2 n1 y using do1a1i1 a1i2do2 by auto hence s2 a1o n5 x y using add1 by blast from s1 have a2i1 n1 x a2i2 n1 y using do3a2i1 a2i2do4 by auto hence s3 a2o n4 x y using add2 by blast from s2 have mi1 n5 x y using a1omi1 by auto moreover from s3 have mi2 n4 x y using mi2a2o by auto ultimately have mo n7 xy using merge3 by blast thus thesis by autoqed
6 Modeling Architecture Proofs in FACTum Studio
To support the development of APML proofs in practice, we implemented the language in FACTum Studio [31]: an architecture modeling application based on Eclipse/EMF [40]. FACTum Studio now supports the user in the development of “correct” APML proofs by means of three key features: (i) It analyses the structure of a given APML proof and checks it for syntactical errors. (ii) It uses socalled validators to check for violations of the conditions described in definition 8 and, to a limited extent, also the ones described in definition 9. (iii) The textual development of APML proofs in Xtext [5] is complemented by corresponding graphical notations using Sirius [34]. To support the verification of single proof steps, we implemented algorithm 1 in FACTum Studio. Thus, after specifying an APML proof, a user can automatically generate a corresponding Isar proof for Isabelle.
Figure 7 depicts the specification of our running example in FACTum Studio: First, the architecture is specified graphically in terms of interfaces (represented as gray rectangles) and connections between their input (empty circles) and output (filled circles) ports. Then, contracts can be added for each component using a textual notation.
Figure 8 shows how we can verify the adder system using FACTum Studio’s APML implementation: After specifying the contract, we can provide a corresponding proof in terms of a sequence of proof steps as described in definition 8.
As mentioned above, FACTum Studio performs several checks to ensure consistency of proofs: (i) For each step it checks whether enough rationales are provided (last condition of definition 8). (ii) It verifies that only existing connections are used in the “with” clause (last condition of definition 8). (iii) It ensures that each step only refers to triggers of the contract or previous proof steps (condition 1 of definition 9) (iv) It ensures consistency of the time points of contracts with those of rationales (conditions 2 and 4 of definition 9).
7 Case Study: Trainguard MT Control System
We evaluated our approach by applying it for the verification of a railwaycontrol system. To investigate whether the approach can indeed be used to apply interactive theorem proving by users not trained in using this technology, verification was performed by a subject with no prior experience with formal methods in general and specifically with the use of interactive theorem provers. The subject holds a Bachelor of Science degree in computer science and has four years of industrial experience as software developer in the domain of business information systems.
Study Context. Trainguard MT (TGMT) is an automatic train control system for metros, rapid transit, commuter, and light rail systems currently in development by one of our industrial partners.
For the purpose of this case study, we focused on the verification of one key feature of TGMT: controlling of the platform screen doors (PSDs). The situation is depicted by fig. 9: In an effort to make train stations safer for the passengers, modern stations protect their rail zone with a wall (represented by a black line) with several doors (represented by gray lines), the socalled PSDs. When a train arrives at the station, its onboard control unit communicates with the Wayside control unit to control opening/closing of the PSDs.
Study Setup. To model the PSD functionality, the company provided four documents as input, which were taken directly from the PSD development: a highlevel system requirements specification ( pages), a more detailed system architecture specification ( pages), a performance specification ( pages), and a glossary ( pages). Based on the documents, we specified a corresponding architecture for the PSD functionality, consisting of components with contracts in total.
Study Execution. The subject then verified five architecture contracts: (P1) If the train is moving, the PSDs are closed. (P2) If the train is at standstill and the position of the train doors match the position of the PSDs, the PSDs are opened. (P3) If the train doors open on the right hand side, the platform must be on the right hand side. (P4) If door release is permissive and the train is at standstill, its doors are open. (P5) When the train indicates that the doors are closed, the PSDs are closed.
Results. After a study of the architecture and a brief introduction into APML, the subject was able to verify versions of all the properties with no further guidance.
Figure 10 depicts the verification effort in terms of APML proof steps required for each property. In total, the subject required roughly working hours to develop the proofs. Sometimes, however, the original contracts needed to be adapted to fit the structure of a contract as defined by definition 6. This was mainly due to two reasons: (i) Some of the contracts required to express statements of the form “whenever x happens, after n time points y happens and in between z holds”. (ii) In addition, some components required contracts combined by disjunction rather than conjunction. Moreover, the proofs for properties P1 and P5 share a common proof sequence of proof steps, which is more than of the steps required to proof the properties. Finally, some of the proof steps could only be discharged by adapting the generated Isabelle script to tune the simplifier and the logical reasoner, respectively.
Conclusions. From our results, we derive the following conclusions:
 C1

The approach can be used to support users with no prior experience with formal methods in the development of proofs for interactive theorem provers.
 C2

Some of the properties sometimes required in a practical setting cannot yet be expressed by the notion of contract used in this paper.
 C3

The verification of properties can involve considerable, redundant proof sequences.
 C4

Some initial setup may be required to automatically discharge generated proof steps.
8 Related Work
Related work can be found in two different areas: verification of contractbased specifications and interactive verification of componentbased systems.
Verification of contractbased specifications. Verification of contractbased specifications is not a new topic, at all. First works in this area go back to Pnueli’s work about modular model checking [36] and Clarke’s work on compositional model checking [14], in which they investigated possibilities to leverage assumptions about a component’s environment for the verification of its implementation. Later on, attempts were made to automatically synthesize minimal assumptions from a component’s implementation [7, 19, 20, 35]. In all these studies, the focus is mainly on the verification of component implementations under the presence of assumptions about its environment. In contrary, the focus of the work presented in this paper, is on the verification of contractcomposition, without even considering component implementations.
Another line of research in this area is work which focuses on the analysis of contract compatibility. In parametric AG reasoning [38], there may even be many assumptions and guarantees for each component. An example of work in this area is Damm et al. [16], in which the authors describe an approach for virtual integration testing based on rich components. Another example is the work of Chilton et al. [11], which provides an approach to AG reasoning for safety properties. Later on, Kugele and Marmsoler [25] provide an approach to check compatibility of AG contracts using SMT solvers [17]. Finally, Broy [8] provides a detailed characterization about compatible assumptions and guarantees for Focus [9]. While the work in this line of research also focuses on the verification at the level of contracts, the focus is mainly on the verification of contract compatibility. With our work, however, we focus on a related, though different problem: verification of refinement of contracts.
Work in this area of research which is most closely related to our work is Cimatti’s work on OCRA [12, 13]. Here, the author proposes an approach based on bounded model checking [6] to verify refinement of LTLbased contracts. With our work, we follow a similar goal by applying an alternative approach based on interactive theorem proving, which is why we actually complement Cimatti’s work.
Interactive Verification Component based Systems. There exists some work which investigates the application of interactive theorem proving (ITP) for the verification of componentbased systems. Fensel and Schnogge [21], for example, apply the KIV interactive theorem prover [37] to verify architectures in the area of knowledgebased systems. More recently, some attempts were made to apply ITP for the verification of architectural connectors: Li and Sun [26], for example, apply the Coq proof assistant [4] to verify connectors specified in Reo [1]. Moreover, there exists work on the formalization of OCL [41] in Isabelle [10]. In addition, Spichkova [39] provides a framework for the verification of componentbased systems in Isabelle and Marmsoler [28] extends the work to deal with dynamic reconfiguration. Also the mechanization of UTP [23] in Isabelle, due by Foster et al. [22], belongs to this line of research. However, while most of these works focus on the interactive verification of component based systems, verification is usually done at the level of the prover. With the work presented in this paper, we aim to contribute to this line of research by exploring possibilities and limitations of synthesizing proofs for the provers from architectural descriptions.
Summary. Concluding, to the best of our knowledge, this is the first attempt to synthesize proof for an interactive theorem prover for the verification of contract composition from architectural descriptions.
9 Conclusion
With this paper, we introduced APML: an architecture proof modeling language. To this end, we first introduced a formal semantics for component contracts as well as architecture contracts. Then, we described APML and showed soundness and completeness of it for the verification of architecture contracts. Moreover, we presented an algorithm to map an APML proof to a corresponding proof in Isabelle/Isar and discussed its implementation in Eclipse/EMF. Finally, we demonstrated the approach by means of a running example and evaluated it by means of a larger case study from the railway domain.
Our theoretical results (Section 4.2) show that APML can indeed be used to specify abstract proofs for the composition of contracts using a notation similar to Message Sequence Charts. Moreover, as indicated by 7 of our case study, it supports users with no prior experience in interactive theorem proving in the development of proofs. Thus, APML indeed contributes to the overall goal of bridging the gap between software architecture and interactive theorem proving. Nevertheless, the case study also revealed some limitations of the approach, which should be addressed by future work: As indicated by 7, future work should investigate possibilities to enhance expressiveness of the contracts. Specifically, the support for untillike contracts and disjunction of contracts should be investigated. Moreover, as indicated by 7, future work should investigate possibilities to support reuse of proof sequences. To this end, a proof step should be allowed to reference to already verified contracts. Finally, as indicated by 7, future work should investigate possibilities to increase automation at the level of interactive theorem proving.
Acknowledgments. We would like to thank Simon Foster and Mario Gleirscher for inspiring discussions about APML. Parts of the work on which we report in this paper was funded by the German Federal Ministry of Education and Research (BMBF) under grant no. 01Is16043A.
References
 [1] Arbab, F.: Reo: a channelbased coordination model for component composition. Mathematical structures in computer science 14(03), 329–366 (2004)
 [2] Baier, C., Katoen, J., Larsen, K.: Principles of Model Checking. Mit Press, MIT Press (2008), https://books.google.de/books?id=nDQiAQAAIAAJ
 [3] Ballarin, C.: Locales and locale expressions in Isabelle/Isar. Lecture notes in computer science 3085, 34–50 (2004)
 [4] Barras, B., Boutin, S., Cornes, C., Courant, J., Filliatre, J.C., Gimenez, E., Herbelin, H., Huet, G., Munoz, C., Murthy, C., et al.: The Coq proof assistant reference manual: Version 6.1. Ph.D. thesis, Inria (1997)
 [5] Bettini, L.: Implementing domainspecific languages with Xtext and Xtend. Packt Publishing Ltd (2016)
 [6] Biere, A., Cimatti, A., Clarke, E., Zhu, Y.: Symbolic model checking without BDDs. In: International conference on tools and algorithms for the construction and analysis of systems. pp. 193–207. Springer (1999)
 [7] Bobaru, M.G., Păsăreanu, C.S., Giannakopoulou, D.: Automated assumeguarantee reasoning by abstraction refinement. In: International Conference on Computer Aided Verification. pp. 135–148. Springer (2008)
 [8] Broy, M.: Theory and methodology of assumption/commitment based system interface specification and architectural contracts. Formal Methods in System Design 52(1), 33–87 (2018), https://doi.org/10.1007/s1070301703049
 [9] Broy, M., Stølen, K.: Specification and development of interactive systems: Focus on streams, interfaces, and refinement. Springer Science & Business Media (2012)
 [10] Brucker, A.D., Wolff, B.: A proposal for a formal OCL semantics in Isabelle/HOL. In: Carreño, V.A., Muñoz, C.A., Tahar, S. (eds.) Theorem Proving in Higher Order Logics. pp. 99–114. Springer Berlin Heidelberg, Berlin, Heidelberg (2002)
 [11] Chilton, C., Jonsson, B., Kwiatkowska, M.: Assumeguarantee reasoning for safe component behaviours. In: International Workshop on Formal Aspects of Component Software. pp. 92–109. Springer (2012)
 [12] Cimatti, A., Dorigatti, M., Tonetta, S.: OCRA: A tool for checking the refinement of temporal contracts. In: 2013 28th IEEE/ACM International Conference on Automated Software Engineering (ASE). pp. 702–705 (Nov 2013)
 [13] Cimatti, A., Tonetta, S.: Contractsrefinement proof system for componentbased embedded systems. Sci. Comput. Program. 97(P3), 333–348 (Jan 2015), http://dx.doi.org/10.1016/j.scico.2014.06.011
 [14] Clarke, E.M., Long, D.E., McMillan, K.L.: Compositional model checking. In: [1989] Proceedings. Fourth Annual Symposium on Logic in Computer Science. pp. 353–362. IEEE (1989)
 [15] Damm, W., Harel, D.: LSCs: Breathing life into message sequence charts. Formal methods in system design 19(1), 45–80 (2001)
 [16] Damm, W., Hungar, H., Josko, B., Peikenkamp, T., Stierand, I.: Using contractbased component specifications for virtual integration testing and architecture design. In: 2011 Design, Automation & Test in Europe. pp. 1–6. IEEE (2011)
 [17] De Moura, L., Bjørner, N.: Satisfiability modulo theories: Introduction and applications. Commun. ACM 54(9), 69–77 (Sep 2011), http://doi.acm.org/10.1145/1995376.1995394
 [18] Dwyer, M.B., Avrunin, G.S., Corbett, J.C.: Patterns in property specifications for finitestate verification. In: Proceedings of the 1999 International Conference on Software Engineering (IEEE Cat. No. 99CB37002). pp. 411–420. IEEE (1999)
 [19] Elkader, K.A., Grumberg, O., Pasareanu, C.S., Shoham, S.: Automated circular assumeguarantee reasoning. In: Bjørner, N., de Boer, F.S. (eds.) FM 2015: Formal Methods  20th International Symposium, Oslo, Norway, June 2426, 2015, Proceedings. Lecture Notes in Computer Science, vol. 9109, pp. 23–39. Springer (2015), https://doi.org/10.1007/9783319192499_3
 [20] Emmi, M., Giannakopoulou, D., Pasareanu, C.S.: Assumeguarantee verification for interface automata. In: Cuéllar, J., Maibaum, T.S.E., Sere, K. (eds.) FM 2008: Formal Methods, 15th International Symposium on Formal Methods, Turku, Finland, May 2630, 2008, Proceedings. Lecture Notes in Computer Science, vol. 5014, pp. 116–131. Springer (2008), https://doi.org/10.1007/9783540682370_10
 [21] Fensel, D., Schnogge, A.: Using KIV to specify and verify architectures of knowledgebased systems. In: Automated Software Engineering. pp. 71–80 (Nov 1997)
 [22] Foster, S., Zeyda, F., Woodcock, J.: Isabelle/UTP: A mechanised theory engineering framework. In: Naumann, D. (ed.) Unifying Theories of Programming. pp. 21–41. Springer International Publishing, Cham (2015)
 [23] Hoare, C.A.R., Jifeng, H.: Unifying theories of programming, vol. 14. Prentice Hall Englewood Cliffs (1998)
 [24] Huber, F., Schätz, B., Schmidt, A., Spies, K.: Autofocus—a tool for distributed systems specification. In: International Symposium on Formal Techniques in RealTime and FaultTolerant Systems. pp. 467–470. Springer (1996)
 [25] Kugele, S., Marmsoler, D., Mata, N., Werther, K.: Verification of component architectures using modebased contracts. In: 2016 ACM/IEEE International Conference on Formal Methods and Models for System Design, MEMOCODE 2016, Kanpur, India, November 1820, 2016. pp. 133–142. IEEE (2016), https://doi.org/10.1109/MEMCOD.2016.7797758
 [26] Li, Y., Sun, M.: Modeling and analysis of component connectors in Coq. In: Fiadeiro, J.L., Liu, Z., Xue, J. (eds.) Formal Aspects of Component Software  10th International Symposium, FACS 2013, Nanchang, China, October 2729, 2013, Revised Selected Papers. Lecture Notes in Computer Science, vol. 8348, pp. 273–290. Springer (2013), https://doi.org/10.1007/9783319076027_17
 [27] Marmsoler, D., Gleirscher, M.: On activation, connection, and behavior in dynamic architectures. Scientific Annals of Computer Science 26(2), 187–248 (2016)
 [28] Marmsoler, D.: A framework for interactive verification of architectural design patterns in Isabelle/HOL. In: The 20th International Conference on Formal Engineering Methods, ICFEM 2018, Proceedings (2018)
 [29] Marmsoler, D.: Hierarchical specication and verication of architecture design patterns. In: Fundamental Approaches to Software Engineering  21th International Conference, FASE 2018, Held as Part of the European Joint Conferences on Theory and Practice of Software, ETAPS 2018, Thessaloniki, Greece, April 1420, 2018, Proceedings (2018)
 [30] Marmsoler, D.: Verifying dynamic architectures using model checking and interactive theorem proving. Software Engineering und Software Management 2019 (2019)
 [31] Marmsoler, D., Gidey, H.K.: FACTum Studio: A tool for the axiomatic specification and verification of architectural design patterns. In: International Conference on Formal Aspects of Component Software. pp. 279–287. Springer (2018)
 [32] Marmsoler, D., Gleirscher, M.: Specifying properties of dynamic architectures using configuration traces. In: International Colloquium on Theoretical Aspects of Computing, pp. 235–254. Springer (2016)
 [33] Nipkow, T., Paulson, L.C., Wenzel, M.: Isabelle/HOL: a proof assistant for higherorder logic, vol. 2283. Springer Science & Business Media (2002)
 [34] Obeo: Sirius. https://www.eclipse.org/sirius/
 [35] Pasareanu, C.S., Dwyer, M.B., Huth, M.: Assumeguarantee model checking of software: A comparative case study. In: Proceedings of the 5th and 6th International SPIN Workshops on Theoretical and Practical Aspects of SPIN Model Checking. pp. 168–183. SpringerVerlag, Berlin, Heidelberg (1999), http://dl.acm.org/citation.cfm?id=645879.672067
 [36] Pnueli, A.: In transition from global to modular temporal reasoning about programs. In: Logics and models of concurrent systems, pp. 123–144. Springer (1985)
 [37] Reif, W.: The KIVapproach to software verification. KORSO: Methods, Languages, and Tools for the Construction of Correct Software pp. 339–368 (1995)
 [38] Reussner, R.H., Becker, S., Firus, V.: Component composition with parametric contracts. Tagungsband der Net. ObjectDays 2004, 155–169 (2004)
 [39] Spichkova, M.: Focus on Isabelle: From specification to verification. In: 21 st International Conference on Theorem Proving in Higher Order Logics. p. 104. Citeseer (2008)
 [40] Steinberg, D., Budinsky, F., Merks, E., Paternostro, M.: EMF: Eclipse Modeling Framework. Pearson Education (2008)
 [41] Warmer, J.B., Kleppe, A.G.: The Object Constraint Language: Precise modeling with UML. AddisonWesley object technology series (1998)
 [42] Wenzel, M.: The Isabelle/Isar reference manual (2004)
 [43] Wenzel, M.: Isabelle/Isar – a generic framework for humanreadable proof documents. From Insight to Proof – Festschrift in Honour of Andrzej Trybulec 10(23), 277–298 (2007)
Appendix 0.A Proof for Thm. 4.1
The following diagram depicts an overview of the main concepts and its relationships and marks the proof obligation with a question mark:
Appendix 0.B Proof for Thm. 4.2
The proof proceeds in four steps: First, we construct a “maximal” architecture proof. If it is a valid proof for the architecture contract, we are done, otherwise, we derive a contradiction: To this end, we construct an architecture trace which satisfies all contracts but violates the guarantee of the architecture contract.
The following figure depicts the relationship of an architecture proof (consisting of a sequence of proof steps) and an architecture trace (consisting of a sequence of architecture states).
Constructing the Architecture Proof
For the proof we construct a “maximal” architecture proof , according to Def. 9, by repeatedly applying all feasible contracts:

closure: for all contracts we have:
(14) implies
(15) 
strongest: for all , such that
Comments
There are no comments yet.