An extension of a tool for the formal support for component-based development

Texto

(1)Universidade Federal do Rio Grande do Norte Centro de Ciências Exatas e da Terra Departamento de Informática e Matemática Aplicada. Programa de Pós-graduação em Sistemas e Computação. An Extension of a Tool for the Formal Support for Component-based Development Dalay Israel de Almeida Pereira Dissertação de Mestrado. Natal Agosto de 2017.

(2) Universidade Federal do Rio Grande do Norte Centro de Ciências Exatas e da Terra Departamento de Informática e Matemática Aplicada. Dalay Israel de Almeida Pereira. An Extension of a Tool for the Formal Support for Component-based Development. Trabalho apresentado ao Programa de Programa de Pósgraduação em Sistemas e Computação do Departamento de Informática e Matemática Aplicada da Universidade Federal do Rio Grande do Norte como requisito parcial para obtenção do grau de Mestre em Sistemas e Computação.. Orientador: Marcel Vinícius Medeiros Oliveira. Natal Agosto de 2017.

(3) iii. Catalogação da Publicação na Fonte. UFRN / SISBI / Biblioteca Setorial Especializada do Centro de Ciências Exatas e da Terra – CCET. Almeida, Dalay Israel de. An extension of a tool for the formal support for component-based development / Dalay Israel de Almeida. – Natal, RN, 2017. x, 73f. : il. Orientador: Marcel Vinícius Medeiros Oliveira. Dissertação (Mestrado) – Universidade Federal do Rio Grande do Norte. Centro de Ciências Exatas e da Terra. Departamento de Informática e Matemática Aplicada. Programa de Pós-Graduação em Sistemas e Computação. 1. Engenharia de software – Dissertação. 2. Sistemas baseados em componentes – Dissertação. 3. CSP – Dissertação. 4. Automação – Dissertação. 5. SMT – Dissertação. 6. Deadlock – Dissertação. 7. Extensão – Dissertação. I. Oliveira, Marcel Vinícius Medeiros. II. Título. RN/UF/BSE-CCET. CDU 004.41.

(4) Resumo. Utilizando a abordagem de desenvolvimento baseado em componentes, a complexidade dos sistemas é reduzida e a sua manutenção é facilitada, trazendo mais segurança e reuso dos componentes. Porém, a composição dos componentes (e suas interações) ainda é uma grande fonte de problemas e requer uma análise mais detalhada. Esse problema é ainda mais relevante quando lidamos com aplicações críticas. Uma abordagem para especificar esse tipo de aplicação é o uso de Métodos Formais, uma metodologia precisa para a especificação de sistemas, que possui uma base matemática forte e que traz, entre outros benefícios, mais segurança. Como exemplo, o método formal CSP permite a especificação de sistemas concorrentes e a verificação de propriedades inerentes a esses sistemas. CSP dispõe de um conjunto de ferramentas para a sua verificação, como, por exemplo, FDR. Usando CSP é possível indentificar e resolver problemas como deadlock e livelock em um sistema, muito embora isso possa ser custoso em termos de tempo gasto em verificações. Nesse contexto, BRIC surge como uma abordagem baseada em CSP para o desenvolvimento de sistemas baseados em componentes, garantindo a ausência de deadlock e livelock por construção. Essa abordagem usa CSP para especificar restrições e interações entre componentes de maneira a permitir uma verificação formal do sistema. Uma extensão de BRIC , BRICK , propõe adicionar metadados aos componentes a fim de diminuir a complexidade e a quantidade das verificações feitas quando componentes são compostos. Porém, a aplicação prática dessa abordagem pode se tornar muito complexa e cansativa se feita manualmente. Com o objetivo de automatizar o uso da abordagem BRICK , foi desenvolvida anteriormente uma ferramenta (BTS - BRICK Tool Support) que automatiza as verificações das composições dos componentes gerando e verificando automaticamente as condições impostas pela abordagem utilizando FDR. Porém, devido ao número e à complexidade das verificações feitas em FDR, a ferramenta pode levar ainda muito tempo nesse processo. Esta dissertação apresenta uma extensão à BTS que melhora o modo como são feitas as verificações, substituindo o FDR utilizado na ferramenta pela sua mais recente versão e adicionando um provador SMT que, concorrentemente, verifica algumas das propriedades da aplicação. Nós também adaptamos a ferramenta para ser usada na especificação de um maior número de sistemas e avaliamos a ferramenta estendida com dois estudos de caso, comparando as verificações feitas na versão anterior da ferramenta com a nossa nova abordagem de verificação. Palavras-chave: Sistemas baseados em componentes, CSP, Automação, SMT, Deadlock, Ferramenta, Extensão. iv.

(5) Abstract. Using the component-based development approach, the system complexity is reduced and its maintenance is facilitated, bringing more reliability and reuse of components. However, the composition of components (and their interactions) is still a significant source of problems and requires a more detailed analysis. This problem is even more relevant when dealing with safety-critical applications. An approach for specifying this kind of applications is using Formal Methods, which are a precise methodology for system specification that has strong mathematical background which brings, among other benefits, more safety. As an example, the formal method CSP allows the specification of concurrent systems and the verification of properties inherent to such systems. CSP has a set of tools for verification, like, for instance, FDR. Using CSP, one can detect and solve problems like deadlock and livelock in a system, although it can be costly in terms of the time spent in verifications. In this context, BRICK has emerged as a CSP based approach for developing componentbased systems, which guarantees deadlock and livelock freedom by construction. This approach uses CSP to specify the constraints and interactions between the components to allow a formal verification of the system. An extension to BRIC , BRICK , makes use of metadata as part of the components in order to decrease the complexity and the quantity of verifications made when composing components. However, the practical use of this approach can be too complex and cumbersome. In order to automate the use of the BRICK approach a tool has been previously developed (BTS - BRICK Tool Support), which automates the verifications of component compositions by automatically generating and checking the side conditions imposed by the approach using FDR. Nevertheless, due to the number and complexity of the verifications made in FDR, the tool can still take too much time in this process. In this dissertation, we present an extension to BTS that improves the way how it make verifications by replacing the FDR used inside the tool by its most recent version and adding a SMT-solver, that, concurrently, checks some properties of the specification. We also adapted the tool in order to be used for the specification of a greater number of systems and we evaluated the extended tool with two case studies, comparing the verifications made in the older version of the tool with this new approach of verification. Keywords: Component-Based Systems, CSP, Automation, SMT, Deadlock, Tool, Extension.. v.

(6) Declaration. I hereby declare that the contents of this dissertation are the result of my own original contribution with the guidance of my advisor, except where otherwise stated. I have acknowledged other sources of joint work through explicit referencing. The following material has been previously published: 1. Pereira, D. I. A., Oliveira, M. V. M., & Silva, S. R. R. (2016, November). Tool Support for Formal Component-based Development. In I Escola de Informática Teórica e Métodos Formais (ETMF2016) (p. 51-60). SBC. 2. Pereira, D. I. A., Oliveira, M. V. M., Conserva Filho, M. S., & Silva, S. R. R. (2017, September). BTS: A Tool for Formal Component-based Development. In 13th International Conference on integrated Formal Methods (IFM2017) (p. 211-226). Springer.. vi.

(7) Contents. List of Figures. ix. List of Tables. x. List of Definitions. xi. 1. Introduction 1.1 Objectives and Contributions 1.2 Dissertation Outline. 1 3 4. 2. Component-Based Development. 5. 3. Communicating Sequential Processes 3.1 Syntax 3.2 Semantics 3.2.1 Traces Model 3.2.2 Stable Failures Model 3.2.3 Failures/Divergences Model 3.3 Tools 3.3.1 FDR. 7 7 9 10 11 11 13 13. 4. Systematic Development of Trustworthy Component-based Systems 4.1 Component Contract 4.2 Compositions 4.3 BRICK 4.4 Final Considerations. 15 15 17 24 28. 5. An Extension to BTS 5.1 BTS 5.2 Upgrading to FDR4 5.3 Verification with a SMT-solver 5.3.1 Language and Tools 5.3.2 Translation 5.4 Structural Changes 5.5 Implementing the use of Context Processes 5.6 A new generalised buffer for FDR4 5.7 Creation of parametrised behaviours. 29 29 32 34 35 35 41 43 44 46. vii.

(8) CONTENTS. 5.8. Final Considerations. viii 48. 6. Case Study 6.1 Dining Philosophers 6.2 Ring Buffer 6.3 Results 6.3.1 Comparison Between the Verification Tools 6.3.2 The use of Context Processes. 51 51 51 55 55 58. 7. Conclusion 7.1 Related Work 7.2 Future Work. 60 60 63. Bibliography. 64. A Verification using context processes. 71.

(9) List of Figures. 2.1. Diagram representing the five stages of building a component-based system [BW96].. 6. 4.1 4.2 4.3 4.4 4.5. Representation of a bi-directional buffer Interleave composition between the forks and between the philosophers. Communication composition between the forks the philosophers. Feedback composition between the forks the philosophers. Diagram of the final structure of the Philosophers Dining Table example. 18 19 21 22 23. 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12. The home screen of BTS Interface for type and channel creation, respectively Contract definition screen of BTS Behaviour and decoupled channels definition screens of BTS, respectively Composition and result screens of BTS, respectively Diagram representing the structure of the previous version of BTS. Diagram representing the structure of the extended version of BTS. The new behaviour definition interface The new instantiation interface Verification process in the earlier version of BTS Verification process in the new version of BTS Interface for choosing the approach of verification. 29 30 31 31 32 41 42 47 47 48 49 49. 6.1 6.2 6.3. Representation of a Ring Buffer with 3 cells [OSA+ 13] Representation of the Ring Buffer example with two cells. Time spent in Interleave verifications in the Ring Buffer and the Dining Philosophers case studies, respectively (in ms) Curve representing the time spent in verifications in the Dining Philosophers case study (in ms). Curve representing the time spent in verifications in the Ring Buffer case study (in ms).. 52 55. 6.4 6.5. ix. 56 57 58.

(10) List of Tables. 1.1. Relation between the objectives and the contributions. 4. 3.1. Operators in CSP syntax in Unicode and ASCII (used inside the tools). 9. 5.1. Assertions that can be solved by a SAT solver. 6.1. Time spent in the Dining Philosophers compositions verifications by each of the available tools (in ms) Time spent in the Ring Buffer compositions verifications by each of the available tools (in ms) Comparison between the time spent in compositions verifications of the Dining Philosophers case study with 3 philosophers by the way BTS generates the SMT script (in ms) Time spent in the verification of the compatibility between two protocols (in ms).. 6.2 6.3. 6.4. A.1 Time spent in verifications with and without using Context Processes (in ms). x. 36 56 57. 58 59 71.

(11) List of Definitions. 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15 4.16 4.17 4.18 4.19 4.20 4.21 4.22 4.23 4.24 4.25 4.26. Definition (I/O channel) Definition (Input determinism) Definition (Strong output decisiveness) Definition (I/O Process) Definition (Component contract) Definition (Component contract instantiation) Definition (Asynchronous Binary Composition) Definition (Interleave composition) Definition (Projection) Definition (Communication protocol) Definition (Protocol implementation) Definition (Strong protocol compatibility) Definition (Communication composition) Definition (Asynchronous unary composition) Definition (Decoupled channels) Definition (Feedback composition) Definition (Buffering self-injection compatibility) Definition (Reflexive composition) Definition (Communication context process) Definition (Dual protocol) Definition (Enriched component contract) Definition (Enrich Component Contract) Definition (Enriched Interleaving composition) Definition (Enriched Communication composition) Definition (Enriched Feedback composition) Definition (Enriched Reflexive composition). xi. 15 15 15 16 16 17 18 19 19 20 20 20 21 21 22 22 23 23 24 24 25 25 26 26 27 27.

(12) C HAPTER 1. Introduction. The development of increasingly more complex applications is demanding a greater investment of resources in software development processes. To reach reliability in such systems is not an easy or simple task, demanding a hard work on specifying these systems in order to guarantee their correctness. Therefore, many approaches, languages and tools have been created with the aim of helping to improve the quality of software products. Component-based System Development (CBSD) [McI68] has emerged as a promising approach for mastering the complexity of building large systems. In this paradigm, the system is divided into independent pieces of software (components) that can interact and communicate with each other, yielding a more complex system. A component is a composition unit with contractually specified interfaces and with explicit context dependencies. Although CBSD has improved the quality of final products and the organisation of the development processes, it do not present ways to formally specify the systems, which is still a big source of problems specially for critical systems. In order to improve reliability, Formal Methods arise in the development cycle, solving some of the problems and proving to be an interesting development approach for critical systems. There are many languages and formalisms used to specify systems, each one with a different system view and describing different properties. Some examples of these languages are: B [Sch01], Z [Dil90], CSP [Hoa78, Ros10], Circus [WC02]. In order to describe concurrent systems, one can use one of the various existing formalisms (CSP [Hoa78, Ros10, RHB98], CCS [Mil86], Pi-calculus [Mil99], ACP [BK84], Circus [WC01], for instance). Our work focuses on CSP (Communicating Sequential Processes). CSP is a formal notation used to model concurrent and reactive applications where processes interact with each other by exchanging messages. The existence of CSP semantic models allows us to formally verify and compare processes. There are many available tools that facilitate the use of CSP like, for instance, the model-checker FDR, which had a major upgrade from FDR2 [For11] to FDR4 [RGRAB14] three years ago. The use of CSP allows us to identify problems inherent to concurrent systems, such as deadlock and livelock. A deadlock occurs when two or more processes are blocked because they are waiting the end of the execution of each other or the release of resources held by each other, and a livelock happens when the system reaches a state from which the system may compute through an infinite sequence of internal actions. To ensure the absence of these problems is one of the benefits of using CSP. However, verifying these kinds of problems in the whole system can be too much costly in terms of memory and time, even using FDR. In [RSM09a, Ram11], Ramos presented an approach, called BRIC , for the trustful and systematic development of component-based systems for CSP models, considering a grey-box 1.

(13) CHAPTER 1 INTRODUCTION. 2. style of composition [Bru00]. In BRIC , component composition is achieved using four predefined rules which imposes restrictions on the basic components. Once satisfied the restrictions, deadlock-freedom is ensured by construction. A further advantage of this approach is the use of verification strategies based on local analysis of each component avoiding the global analysis, which is always more costly. Besides the BRIC strategy, Ramos developed an extension, BRICK , that inserts metadata (K ) inside the components as a way to decrease the amount and the complexity of the verifications when composing components [Ram11]. An example of metadata is the Context Process: a CSP processes that represents all the possible communications of a component via a specific port, which allows us to restrict proofs concerning this communication. BRIC has proved to be efficient in the verification of deadlock-freedom [OAR+ 16]. The absence of livelock, however, is trivially ensured, since the basic components are, by definition, livelock-free, and no operator that may introduce such a behaviour can be used. The work presented in [CF16, CFOSC16] considered black-box compositions in BRIC , a component notion that seems to be better aligned to CBSD, where the internal services of components are hidden from its environment. [CF16, CFOSC16] also presented a technique for constructing livelock free BRIC systems using local analysis. The use of BRICK , however, demands considerable effort in specifying components and their compositions. This can make its practical application too complex and cumbersome. Trying to solve this problem, a tool, BTS (BRIC Tool Support) [Sil13], has been previously created to provide a simpler way to define and compose BRIC components using the predefined rules. It provides an automatic analysis of the components and their compositions, making the development process safer and more efficient. The tool also considers the extension of BRIC , BRICK , allowing the user to include metadata to the components and decreasing even more the verification costs [Per15]. BTS also contains a module that provides efficient livelock verification using the local livelock analysis described in [CF16, CFOSC16]. Even representing a step forward from pre-existent systems, BTS makes a large number of verifications and still uses FDR2 in order to check them, which can be not so efficient in terms of time. There are some solutions to this problem that can be applied to this tool. A more recent version of this model checker has been developed and released, FDR4 [RGRAB14], which can be much more efficient when compared with its previous version. Furthermore, the work described in [OSA+ 13] presents the possibility of using other tools (SAT-Solvers, for instance) to make part of the verifications needed in components and compositions. Besides, although BTS accepts the insertion of all the metadata information inside the components, the use of context processes, one of these metadata information, has never been suitably implemented inside the tool and its use has also never been evaluated. In this work we extend BTS in order to improve the way how the verifications are handled by upgrading FDR to its latest stable version and creating a module responsible for making some verifications using a SMT-Solver with the aim of decreasing the time BTS spent in system validation. Besides, we analysed the use of context processes as a way to alleviate verifications, as it was described in [Ram11]. In order to do that, we extended the information presented in [OSA+ 13] by specifying how the verifications using context processes can be automated, and then, we implemented it in our tool..

(14) 1.1 OBJECTIVES AND CONTRIBUTIONS. 3. In order to evaluate our new version of BTS, we used two case studies: the Dining Philosophers, as presented in [Ram11, OSA+ 14], and the Ring Buffer, as presented in [OSA+ 13]. The previous version of the tool (before our extension), had been evaluated only by the Ring Buffer case study. So, in order to use BTS to specify other examples (like the Dining Philosophers), it was necessary to adapt some structures of the tool. In our evaluation, we compared the time spent by both versions of BTS on the verification of compositions. Besides, we also use these case studies to analyse the possible gains a user may have by using context processes as a component metadata inside the tool. Furthermore, we adapted the tool to allow the use of parametrised behaviours, in order to prepare BTS to be used in other case studies (like [AOS+ 14], for instance).. 1.1. Objectives and Contributions. This work presents an extension of BTS, a tool that automates the use of the BRICK approach by generating specifications and verifying them automatically. The aim of our work is to fulfill two main general objectives: 1. decrease the time BTS spends in verifications; 2. update the tool in order to allow its use in a larger range of case studies. We extended BTS in order to fulfill these objectives. In this dissertation, it is possible to identify six main contributions: 1. the upgrade of the tool used to make verifications: from FDR2 to FDR4, which contains new features, like full use of multiple cores and an integrated type-checker; 2. implementation of a module that allows the use of a SMT-solver, CVC4 [BCD+ 11], to carry out verifications concurrently with FDR by translating some of the FDR assertions to SMT [RT06b] in order to be verified by this solver, which reduces the time spent in verifications (as presented in Section 6.3); 3. implementation of support to use Context Processes as a way of alleviating the verifications made when composing components (the possible gains of using this metadata information are also discussed in Section 6.3); 4. a unification of the different buffer specifications presented in the literature ([Ram11] and [OSA+ 13]) in order to allow the use of the tool with a larger class of case studies; 5. modification of the component creation interface in order to allow the creation of behaviours with parameters, which allows the use of BTS with a larger subset of CSP; 6. modification of the structure of the tool in order to allow our extension and improve the extensibility and maintainability of the tool. The relation between the contributions and our goals are presented in Table 1.1, which relates the contributions that help to fulfill each objective (marked with an “X”). The sixth contribution does not help to fulfill any objective directly, however, it was an essential task which had a major impact on the beginning of our extension. Besides, this is considered a contribution because it modified the structure of the tool in order to facilitate our extension and new future extensions..

(15) 1.2 DISSERTATION OUTLINE. 4. Table 1.1 Relation between the objectives and the contributions. Contributions/objectives Objective 1 Objective 2 Contribution 1 X Contribution 2 X Contribution 3 X Contribution 4 X Contribution 5 X. 1.2. Dissertation Outline. The presentation of this dissertation is organised in the following structure. The Chapters 2 and 3 focus on the background required to understand the BRICK approach. The former gives an overview of Component-Based Development, an approach for the development of systems where BRICK is based on. The latter introduces CSP, its syntax, semantic models and tools. The formalism given by CSP is used as a basis to specify and verify systems in the BRICK approach. In Chapter 4 we introduce the BRIC approach. This chapter focuses on the creation and composition of components and the rules in order to guarantee deadlock freedom by construction. Besides, we also introduce the BRICK approach: an extension of BRIC that inserts metadata inside the components. In Chapter 5 we present our work: an extension to BTS. In this chapter we present, foremost, an overview of the tool before the extension and then we explain all changes we have worked on. The case studies used to evaluate our tool and the result of this evaluation are presented in Chapter 6. Finally, Chapter 7 presents our final considerations, and the related and future work..

(16) C HAPTER 2. Component-Based Development. In its most simple definition, “components are for composition” [Szy02]. The notion of components is integrated to most production processes and it lays on the concept of divide and conquer: divide the product in smaller pieces that can be produced separately and, when combined, they comprise the final product. In software production, the concept of component was born together with the software crisis [McI68], as a way to solve it. The first definitions of both terms were presented in the NATO conference [NR69] in 1969, where it was discussed, among other subjects, the problem of achieving reliability in large systems and still meet deadlines and specifications. The notion of omponents are well established in all other engineering disciplines, but, until the 1990s, they were unsuccessful in the world of software [Szy02]. When building a house, an engineer must plan each of its aspects, including components (walls, windows, doors, wires, lamps, pipes, sinks and much more) and how they interact with each other. It can be very frustrating for an end-user to have an electrical wire passing through the center of a room. This analogy shows how important it is to design the structure of a system (their components and interactions) in order to avoid errors in the final product. All other engineering disciplines introduced components as they became mature and, in Software Engineering, the construction of a large system from small pieces can reduce the development time and improve the final product quality. By using this approach, a developer can create components and reuse them many times in a system or even reuse them in other systems. In its firsts ideas, software components were planned to be seen as pieces of a product, which can be stored, catalogued and even sold, as occurs in the production of other kind of products [NR69]. According to [CCL06], “Components are built to be used and reused in many applications, some possibly not yet existing, in some possibly unforeseen way”. There are many definitions for software components according to many authors [BDH+ 98]. These definitions agree in some aspects but they completely disagree in others. In our work, a component is a unit of composition with a given behavior, contractually specified interfaces and explicit context dependencies only. A component can be deployed independently and is subject to composition by third parties [Szy02]. After creating the components, it is necessary to compose them in order to create the system. [BW96] presents a reference model for describing the engineering practices of assembling component-based systems. This model is comprised of five stages, each one describing the status of the components in their life cycle. In the first stage the components are in their normal form (the way they were created) and that is the moment when the developer selects and evaluates the components, leading the developing process to the next stage, where the work 5.

(17) CHAPTER 2 COMPONENT-BASED DEVELOPMENT. 6. concentrates only on the qualified components. Before composing components, it is necessary to solve problems about mismatches of components, that is, conflicts between components that difficult their composition. The third stage occurs after the adaptation of the components according to their intended composition. In order to assemble components, one must define the infrastructure that binds the components, allowing them to interact with each other. Being the assembled components the fourth stage, the fifth one exists as long as the system exists. The fifth stage comprises error fixing and functionality addition. Figure 2.1 presents a diagram describing the five stages of building a component-based system.. Figure 2.1 Diagram representing the five stages of building a component-based system [BW96].. [Ram11] defines component contracts containing a behaviour, a set of channels and a set of interfaces. The behaviour defines the function of the component (what it does). The interface defines what kind of information a component can communicate and the set of channels represents the interaction ports between the components. The composition of two components results in a new component containing both behaviours, an union between both interface sets and an union between the sets of channels. After some compositions, the final component may be considered the complete aimed system. Although all the benefits of the component-based development, this approach does not present ways to formally specify the systems, which is still a big source of problems, specially for critical systems (where failure or malfunction will lead to significant negative consequences, demanding strict requirements for security and safety in order to protect the user [HC10]). Problems may arise when composing two or more components because of the lack of interoperability standards to facilitate the integration of components [KR01]. Solutions for integrating components are often created in an ad hoc manner, in which hidden incompatibilities are not discovered until their side effects emerge during implementation [HGK+ 06]. In order to specify systems formally and construct reliable systems, there are formal methods of specification. This approach has a mathematical background, ensuring the correctness of some properties of the systems before their implementation. The Chapter 3 focuses in CSP, a formalism for specifying reactive and concurrent systems..

(18) C HAPTER 3. Communicating Sequential Processes. Concurrent systems have a complicated nature by themselves. They consist of many components which may execute in parallel, and the complexity arises from the combinations of ways in which their parts can interact [Sch99]. There are some inherent problems in such systems that can be introduced, like deadlock and livelock. Formal languages like CSP, provide a level of abstraction that allows us to better understand and avoid these problems. Using CSP, one can describe systems at different stages of the system development (specification, design, implementation). In this chapter we discuss about the features of CSP. The first section presents the syntax and how we can specify a system in CSP. Later we discuss about some of its semantic models. The last section introduces some of the tools that support the CSP specification and analysis.. 3.1. Syntax. The CSP language has a rich syntax that allows us to build a well detailed specification. The most basic constructors are channels and processes. Some basic processes are STOP and SKIP. The former represents a system break, a deadlock or just an inability to continue. The SKIP process also terminates the execution, but differently from STOP, it indicates that the execution was successfully completed. Channels can have specific types, like integer, interval of numbers, boolean, or even a specific set of atomic constants, called datatype. Different processes can communicate through channels and this communication may have a value. Processes are defined using the events that constitute them. An event is an atomic single action that a process engages in. An event is comprised by a communication channel and the information this channel can carry. In CSP, the declaration of a channel a is made by: channel a : T1 ...Tn , where a indicates the name of the channel and T1 ...Tn are the types of the channel. Being c a channel, the notation {|c|} (given by FDR), denotes the set of events consistent with the declaration the channel c. As an example, if the type of c is the set {1, 2}, then {|c|} = {c.1, c.2}. Given an event a in the interface of a process P, the prefixing a → P is initially able to perform a, after which it will behave like P. Strictly speaking, the semantics of CSP does not differentiate inputs from outputs. However, the prefixing operator can also be used to denote directional communication. The process c!v → P sends the value v via channel c and behaves as P afterwards. On the other hand, the process c?x → P receives a value on channel c and then. 7.

(19) 3.1 SYNTAX. 8. assigns it to the implicitly declared variable x, which can be used in the subsequent behaviour P. CSP also provides notations to describe different paths of behaviour. The external choice P 2 Q initially offers the initial events of both processes, P and Q. The environment makes the choice of synchronisation. It can be thought as buttons being offered to a client (a user) that will decide which one to press. The other CSP choice operator is the internal choice: the process P u Q is completely out of the environment’s control. This choice is also called nondeterministic, since the system will internally decide what to do and it will initially be ready to perform the initial events from just one of the processes. Furthermore, given a set S = {a, b, ..., q} that indexes any finite collection of channels, the expression 2x∈S P(x) represents all the external choices of the processes P(x) for each x in the collection S (similar to P(a) 2 P(b) 2 ... 2 P(q)). Similarly ux∈S P(x) represents all the internal choices of the processes P(x) for each x in the collection S (similar to P(a) u P(b) u ... u P(q)). The process RUNA represents a process which, for a set of events A ⊆ Σ, it can always communicate any event of A desired by the environment (RUNA =2x∈A x → RUNA ). Two processes can be composed sequentially. The process P; Q behaves as P and, if P terminates successfully (ends with a SKIP), it behaves as Q afterwards. Processes can be also composed in interleaving. In P ||| Q, the processes P and Q execute concurrently, but they do not synchronise on any event. It is also possible to compose two processes in parallel synchronising in a specific set of events cs. In P k Q, the processes P and Q are executed cs. concurrently and synchronise on the events in cs; any other events are executed independently. It is also possible to make an indexed interleaving (similar to the indexed choice): |||x∈S P(x) represents an interleaving between all processes P(x), for each channel x inside the set of channels S. As an example, we use a classical concurrent system, the Dining Philosophers [RHB98], which will be used throughout this work. In this example, a group of philosophers is seated at a round table to eat. Each pair of philosophers has a fork between them. Each philosopher must pick up two forks (the right one and the left one) before eating and put them down afterwards. In this example, a deadlock occur when each philosopher picks up the fork on their right side at the same time and then they wait indefinitely for the another fork to be released. There are many approaches to avoid this deadlocked state. In our work we consider that one of the philosophers is left-handed, picking up the fork in the left before the fork in the right side. This approach guarantees that at least one of the philosophers will have access to the resources he needs, being able to eat and then releasing more resources. datatype EV = up | down datatype LF = thinks | eats channel fk1, fk2, pfk1, pfk2 : EV channel life : LF Fork = (fk1.up → fk1.down → Fork) 2 (fk2.up → fk2.down → Fork) Phil = life.thinks → pfk1.up → pfk2.up → life.eats → pfk1.down → pfk2.down → Phil The channels fk1, fk2, pfk1 and pfk2 can only communicate up or down, information from.

(20) 9. 3.2 SEMANTICS. the type EV (a datatype). The channel life can communicate thinks or eats. The process Fork offers an external choice between the events fk1.up and fk2.up. This process ensures that two philosophers cannot hold the same fork simultaneously. The process Phil represents the life cycle of a philosopher: before eating, the philosopher thinks and then he picks up the forks. After eating he puts the forks back down. Finally, the CSP notation offers operators for hiding and renaming events. The hiding operator provides means to hide events from the environment. The process P \ cs behaves as P but hides the set of events cs from the environment. The renaming P[[b ← a]] behaves as P, but the occurrences of the event a are replaced by occurrences of the event b. These notations so far were presented in its Unicode [AAB+ 12] form. However, in order to be used inside the tools, there is another form of CSP: CSPM , which “is one result of a research effort with the primary aim of encouraging the creation of tools for CSP” [SA11]. CSPM is an ASCII [GBG63] syntax of CSP that combines the CSP process algebra with a functional programming language, which has the purpose of supporting the description of parallel systems in a form that it can be automatically manipulated. The Table 3.1 presents the notations introduced so far in Unicode and in ASCII (CSPM ). Table 3.1 Operators in CSP syntax in Unicode and ASCII (used inside the tools). Operator Deadlock process Terminating Process Prefix External choice Internal choice Indexed external choice Indexed internal choice RUN Process parallelism. Unicode STOP SKIP a→P P2Q PuQ 2x∈S P(x) ux∈S P(x) RUNA PkQ. ASCII STOP SKIP a -> P P [] Q P |~| Q [] x:S @ P(x) |~| x:S @ P(x) RUN(A) P [| cs |] Q. cs. interleaving indexed interleaving Hiding Renaming. 3.2. P ||| Q P ||| Q |||x∈S P(x) ||| x:S @ P(x) P \ cs P \ cs P[[b ← a]] P[[b <- a]]. Semantics. CSP has a number of semantic models for understanding the language, as it is presented in [Ros10]. The operational semantics transforms the processes into labelled transition systems (LTS), a directed graph with a label on each edge representing what happens when taking an action: each transition represents a possible execution. The algebraic semantics uses algebraic laws to syntactically transform a process in such a manner that the process properties can be deduced. The denotational semantics treats each process as a set of values in one of the.

(21) 3.2 SEMANTICS. 10. mathematical models. Some of these models are: Traces, Stable Failures, Failures/Divergences. These models are key points to understand part of our work. 3.2.1. Traces Model. In the Traces model, each process is defined by a set of traces: the sequences of communications between the environment and the process. The notation traces(P) defines the set of all finite sequences of events a process P can perform. For example: • traces(STOP) = {hi} – the STOP process performs nothing, hence, the only sequence of events it can engage is the empty sequence, • traces(SKIP) = {hi, hXi} – the SKIP process only performs the internal special event X, • traces(a → b → STOP) = {hi, hai, ha, bi}, • traces((a → STOP) 2 (b → STOP)) = {hi, hai, hbi}, • traces((a → STOP) u (b → STOP)) = {hi, hai, hbi}. In CSP, the symbol Σ represents the set of all the possible events for processes in the universe under consideration. It is important to mention that the event X (tick) is not a member of Σ in this presentation of CSP. The tick is a special event that indicates successful termination and it cannot be used explicitly in any other process. The only way of using this event is implicitly, inside the SKIP process. In order to present the traces of SKIP we extend the alphabet of possible events in the Traces model to be all the non-empty, prefix-closed subsets of ΣX (Σ ∪ {X}), represented by Σ∗X . The result of traces(P) for any process P will always be a non-empty set, since it always contains the empty trace. This result has also the prefix-closed property: if ha, bi is a trace, at some earlier point in the process the trace was hai. The Traces model cannot differentiate determinism from non-determinism. The processes (a → STOP) 2 (b → STOP) and (a → STOP) u (b → STOP) have the same mean in the Traces model, since these processes have the same set of traces. Since a trace is a sequence of events, it is possible to use sequence notations to express some information about these traces. For instance, considering a sequence s, the notation #s represents the length of this trance, that is, the number of events inside this sequence. In the Traces model, a process P is a refinement of a process Q (written as Q vT P) if, and only if, every trace of P is a trace of Q. These processes are trace equivalent (written as P ≡T Q) if P vT Q and Q vT P. The Traces model can be used to express safety conditions, guaranteeing that a refinement will perform only what was specified in the original process. That is, if Q vT P, then traces(P) ⊆ traces(Q). However, this model cannot assure liveness, since the process STOP is a refinement of any other process (it does not perform any event different from other processes). In order to assure liveness, one can use the Stable Failures model, which is presented in the next section..

(22) 3.2 SEMANTICS. 3.2.2. 11. Stable Failures Model. In the Traces model, the processes (a → STOP) 2 (b → STOP) and (a → ST OP) u (b → ST OP) have the same traces. The Traces model cannot distinguish these processes. In order to overcome this limitation, the Stable Failures model defines a process as its set of traces and a set of refusals. In this model, a refusal is a pair (s, X), where s is a trace of the process and X is the refusals after the trace s. The notation failures(P) represents the set of all failures of P. For example: • failures(STOP) = {({hi}, X) | X ⊆ Σ∗X } – the STOP process only performs the empty trace and refuses everything from the extended alphabet ΣX , • failures(SKIP) = {({hi}, X) | X ⊆ Σ∗ } ∪ {(hXi, X) | X ⊆ Σ∗X } – the SKIP process initially refuses everything, except the X event. After performing X it behaves like the STOP process and refuses everything, • failures((a → STOP) 2 (b → STOP)) = {(hi {X}), (hai, X), (hbi, X) | X ⊆ {a, b, X}} – initially it cannot refuse anything. After performing a it refuses {a, b, X}, or in any subset of {a, b, X}, and after performing b it refuses {a, b, X}, or any subset of {a, b, X}, • failures((a → ST OP) u (b → ST OP)) = {(hi, Y), (hi, Z), (hai, X), (hbi, X) | X ⊆ {a, b, X}, Y ⊆ {a, X}, Z ⊆ {b, X}} – initially it can refuse the events of the sets {a, X} or {b, X}. After performing a it refuses {a, b, X}, or in any subset of {a, b, X}, and after performing b it refuses {a, b, X}, or in any subset of {a, b, X}. As presented in the example above, the Stable Failures model can successfully differentiate non-determinism. In the process (a → STOP) 2 (b → STOP), the process initially cannot refuse either a or b, which is different from the process (a → ST OP) u (b → ST OP) containing a nondeterministic choice, where the process will initially refuse a or b. The “stable” means that the sequences represented by s are those reaching a stable state (no transition is chosen non-deterministically), that is, stable states are those in which there are no choices between external and internal actions. An internal action, in this context, is represented by an invisible (or silent) state, described by the special symbol τ (tau). In this model, a process P is a refinement of a process Q (denoted as Q vF P) if, and only if, all traces of P are also traces of Q and all failures of P are failures of Q. That is: (Q vF P) ⇔ (traces(P) ⊆ traces(Q) ∧ failures(P) ⊆ failures(Q)). These processes will be stable failures equivalent (P ≡F Q) if P vF Q and Q vF P. 3.2.3. Failures/Divergences Model. The Stable Failures model has some efficiency by assuring the liveness property in a refinement by guaranteeing that the refinement will not refuse any event after a determined trace.

(23) 3.2 SEMANTICS. 12. if the original process does not refuse it. But there is another issue regarding the liveness property: divergences. A divergence (or livelock) occurs when a process can perform only internal events indefinitely. This problem may invalidate certain analysis methodologies and it is known to be even worst than deadlock since, as an endless loop, it “may consume unbounded computing resources without achieving anything” [Hoa85]. An example of divergence is: P = (a → P) \ a. In this example, the event a is converted to the internal action τ, which will be performed indefinitely. A divergent process is represented by div in the CSP notation. The processes a → STOP and (a → STOP) u div have the same failures and traces and, in order to differentiate them, it is necessary a new model: Failures/Divergences. The Failures/Divergences model is considered the most satisfactory model for analysing liveness and safety properties since it is able to detect the presence of deadlock and livelock in a process. In this model a process is represented by a pair of sets (failures⊥ (P), divergences(P)), where: • divergences(P) is the set of traces after which P can diverge, • failures⊥ (P) represents all the stable failures of P extended by all the pairs (s, X) for s ∈ divergences(P) and X ⊆ Σ, allowing the process to refuse anything after diverging: failures⊥ (P) = failures(P) ∪ {(s, X) | s ∈ divergences(P) ∧ X ⊆ Σ} A process P is divergence-free if, and only if, divergences(P) = {}. For example, some divergent and not divergent processes are: • divergences(STOP) = {} – the STOP process only performs the empty trace, so it cannot lead to a divergent state, • divergences(SKIP) = {} – the SKIP process only performs X and, similar to STOP, it cannot lead to a divergent state, • divergences(div) = Σ∗X – the div process immediately can refuse any event and it diverges after any trace, • divergences(a → STOP) = {} – there is no path in this process that leads to a divergent state, • divergences((a → STOP) u div) = Σ∗X – this process may enter in a divergent state before executing any event, which means that it have the same set of divergences as divergences(div). Similar to the previous models, a process P is a refinement of a process Q (Q vFD P) if, and only if: failures⊥ (P) ⊆ failures⊥ (Q) and divergences(P) ⊆ divergences(Q). These processes are Failures/Divergences equivalent (P ≡FD Q) if, and only if, Q vFD P and P vFD Q..

(24) 3.3 TOOLS. 3.3. 13. Tools. CSP disposes of many tools that facilitates the definition, analisys and verification of CSP processes: ProBE [Exp03], CSP Type Checker [Sys], FDR4[RGRAB14] are some examples of them. An important fact about these applications is that they use a different version of CSP, named CSPM , that uniforms the syntax in order to be used in many tools and, besides, it includes a functional programming language to CSP. ProBE [Exp03] allows us to animate CSP processes by expanding them and following events that lead from one state to another. Its interface presents the processes as hierarchical lists to display the possible actions and states of a process. The CSP Type Checker tool [Sys], as its name express, is a simple CSPM type checker that can be accessed by command line. Using this tool, one can analyse a CSPM file in order to discover syntax and type errors. 3.3.1. FDR. The model checker FDR (Failures-Divergence Refinement) [For11] is a tool that allows users to verify properties of the processes written in CSPM related to the semantic models (traces, stable failures, Failures/Divergences). The main ideas behind FDR are presented in [Ros10]. FDR is indeed the most important tool for CSP and it is known to be responsible for the success of CSP in specification, analysis and verification of concurrent systems. In order to make verifications in FDR, one must write assertions about the processes and their properties inside the specification of the system using the command “assert”. The tool analyses the specification based on the assertions that the user created, exploring every possible behaviour of the processes in order to check if the assertions are true. If the tool finds that an assertion is false, it provides counter-examples. Some of the verifications allowed by the tool are: deadlock-freedom, livelock-freedom, process determinism and refinement (based on the semantic models). Some simple examples of assertions are presented below: • assert P : [deadlock free], – which verifies if there is a possibility of the occurrence of a deadlock in the execution of a process P; • assert P : [livelock free], – which verifies if there is a possibility of the occurrence of a livelock in the execution of a process P; • assert P : [deterministic], – which verifies if the process P is deterministic; • assert P vT Q, – which verifies if the process Q is a refinement of the process P in the Traces model; • assert P vF Q, – which verifies if the process Q is a refinement of the process P in the Stable Failures model;.

(25) 3.3 TOOLS. 14. • assert P vFD Q, – which verifies if the process Q is a refinement of the process P in the Failures/Divergence model. It is also possible to make set-logic verifications (like disjunction or equality of sets, for instance) using CSP assertions. In order to create these assertions it is necessary to use two auxiliary processes: ERROR = error → SKIP, and Test(c) = not c & ERROR, where error is a channel and c represents a statement. Some of these logic verification assertions are: • assert STOP vT RUN(inter(A, B)) – The intersection (inter) between the sets of events A and B are disjoint if the offering of all events (RUN) of this intersection is a refinement of STOP; • assert (not (Test(A == B) vT ERROR)) – If the sets of events A and B are equal, the process ERROR is not a refinement of the process Test and the assertion is true; • assert not P \ {| c |} vT Q – The channel c belongs to the alphabet of the process P (c ⊆ ΣP ) if P is not a refinement of P with all the events from c hided; • assert not Test(subseteq(A, B)) vT ERROR – The set of events A is a subset (subseteq) of B when ERROR is not a refinement of Test; FDR4 [RGRAB14] is the most recent version of FDR and an evolution of FDR2 [For11] that brings more efficiency, more features and a fully redesigned interface [oO16]. It analyses programs written in an enhanced version CSPM and it also has support for analysing timed systems via tockCSP [ALOR14]. The tool also includes a fully integrated version of ProBE and a type checker. By the use of multiple cores, FDR4 can make refinement verifications concurrently, which brings more efficiency to the verification of assertions. The time spent on verifications decreases as the number of cores increases. Besides, the verification by itself has been optimised, which means that the performance of FDR4 is better even in a single core computer. FDR4 runs on Windows, Mac OS X and linux-based systems (differently of FDR2 that runs only on linux), which allows users of different types of operating systems to verify their specifications without the obligation to use a linux-based system. Furthermore, differently from FDR2, which makes syntax verification at the run-time (when verifying the assertions), in FDR4, with the inclusion of a type checker, the tool is able to make early type verifications, showing errors (encountered in the script) to the user before any other verification. This last improvement guarantees the type correctness in the whole specification, instead of verifying only the processes pointed by the assertions..

(26) C HAPTER 4. Systematic Development of Trustworthy Component-based Systems. This chapter presents an approach for creating and composing components: BRIC [Ram11]. This approach is based on a set of rules that guarantees the absence of deadlock and livelock by construction. A Dining Philosophers example (briefly presented on Chapter 3) with two philosophers is used throughout this chapter which may contribute with a better understanding of the approach.. 4.1. Component Contract. This section presents some basic structures and definitions for the construction of trustworthy component-based systems using the BRIC approach. In order to define a component contract it is necessary to understand some basic definitions first. In the BRIC approach, a channel must be defined as an input or output channel [Ram11]. The definition of an I/O channel is presented below. Definition 4.1 (I/O channel). We can say that a channel c is an I/O channel if there exists two functions, inputs(c, P) and outputs(c, P) for every process P, such that: inputs(c, P) ∪ outputs(c, P) ⊆ {| c |} ∧ inputs(c, P) ∩ outputs(c, P) = {}. In this definition, the events of a channel c are partitioned into outputs and inputs. There are also some properties about inputs and outputs inside a process that must be respected in a component contract: input determinism and strong output decisiveness. Definition 4.2 (Input determinism). We say a process P is input deterministic if: ∀ s : seqΣ; c.a : Σ | s a hc.ai ∈ traces(P) ∧ c.a ∈ inputs(c, P) • (s, {c.a}) ∈ / failures(P) For any trace that the process P may perform, if the last event is an input, this input event cannot be refused. Besides, if a set of input events are offered to the environment, none of them are refused. Definition 4.3 (Strong output decisiveness). We say a process P is strong output decisive if: ∀ s : seqΣ; c.b : Σ | s a hc.bi ∈ traces(P) ∧ c.b ∈ outputs(c, P) • (s, outputs(c, P)) ∈ / failures(P) ∧ (s, outputs(c, P) \ {c.b}) ∈ failures(P) 15.

(27) 4.1 COMPONENT CONTRACT. 16. This means that the process does not provide any choice among output events to the environment, hence, all choices among output events are internal. The next definition describes some required properties of a component in the BRIC approach. Definition 4.4 (I/O Process). We say a CSP process P is an I/O process if: • whenever an event c.x is in the alphabet of P (αP ), c is either an input or an output channel of P; • P has infinite traces; • P is divergence free; • P is input deterministic; • P is strong output decisive. In an I/O process, all events are either inputs or outputs (the channels are I/O channels), the process is divergent-free and has infinite traces (but the state-spaces are finite). Besides, P must be input deterministic and strong output decisive (definitions 4.2 and 4.3). Based on all these definitions, it is possible to define a component contract, the building block of the BRIC approach. Definition 4.5 (Component contract). A component contract Ctr comprises an observational behaviour BCtr and a total function RCtr : CCtr → ICtr between the set of communication channels CCtr and the set of interfaces ICtr , which are also part of the definition of a contract: Ctr : hBCtr , RCtr , ICtr , CCtr i such that: • BCtr is an I/O process; • dom RCtr = CCtr ∧ ran RCtr = ICtr ; • Let c ∈ CCtr , and considering that every event beginning with c.out or c.in represents an output or an input event, respectively, then: – outputs(c, BCtr ) = {out.x : RCtr (c) • c.out.x}, – inputs(c, BCtr ) = {in.x : RCtr (c) • c.in.x}. In the philosophers example we define two contracts to represent forks and philosophers: CtrFork = hFork, {fk1 → EV, fk2 → EV}, {EV}, {fk1, fk2}i CtrPhil = hPhil, {lf → LF, pfk1 → EV, pfk2 → EV}, {LF, EV}, {lf , pfk1, pfk2}i Besides the component contract, there is one more important definition to present: component contract instantiation. Usually, in the component-based development approach, a component is defined once and reused multiple times in different contexts. In the BRIC strategy, these contexts are represented as a set of channels, since channels represent interaction points of the component, and each channel is used to communicate with a single component in the environment. So, replacing the channels of a component contract makes it interact with another environment. In this approach, this replacement is represented by a bijection of the set of channels of the component contract into a set of new channels..

(28) 4.2 COMPOSITIONS. 17. Definition 4.6 (Component contract instantiation). Given a component contract Ctr : hBCtr , RCtr , ICtr , CCtr i and a bijection F between event prefixes, such that dom F = CCtr , the component contract instantiation is defined as: CompInst (Ctr, F) = hBCtr [[F]], F ∼ ; RCtr , ICtr , ran Fi where the new contract is formed of BCtr [[F]], which stands for the behaviour BCtr with its channels renamed according to the bijection F, the same interface ICtr , the set of channels from the range of F and the relation from the new channels with the interface, which is defined as the composition of the inverse of F, F ∼ , with the relation RCtr . In the philosophers example, the contract of each philosopher and each fork is defined as a component contract instantiation CtrPhili or CtrForki (i ∈ {1, 2}). The channels used by these components are fk, pfk, and life. In order to distinguish actions from each philosopher on each fork, there are two integers on the type of channels fk and pfk standing for the fork and for the philosopher. The type of channel life is the philosopher’s identifier. CtrFork1 = CompInst (CtrFork , {fk1 7→ fk.1.1, fk2 7→ fk.1.2}) CtrFork2 = CompInst (CtrFork , {fk1 7→ fk.2.2, fk2 7→ fk.2.1}) CtrPhil1 = CompInst (CtrPhil , {life 7→ lf .1, pfk1 7→ pfk.1.1, pfk2 7→ pfk.1.2}) CtrPhil2 = CompInst (CtrPhil , {life 7→ lf .2, pfk1 7→ pfk.2.2, pfk2 7→ pfk.2.1}) Expanding the contracts CtrFork1 and CtrPhil1 we obtain: Fork[[fk1 ← fk.1.1, fk2 ← fk.1.2]], CtrFork1 = {fk.1.1 → EV, fk.1.2 → EV}, {EV}, {fk.1.1, fk.1.2} * Phil [[life ← lf .1, pfk1 ← pfk.1.1, pfk2 ← pfk.1.2}]], + 1. CtrPhil1 =. {lf .1 → LF, pfk.1.1 → EV, pfk.1.2 → EV}, {LF, EV}, {lf .1, pfk.1.1, pfk.1.2}i. 4.2. Compositions. In [Ram11], composition rules are proposed in order to ensure, by construction, deadlock-free compositions in BRIC . There are two types of composition in this approach: binary compositions and unary compositions. The asynchronous communications are achieved by the use of infinite buffers as intermediate elements of the composition. A buffer is a process with one input channel and one output channel, both having the same type. The buffer copies information from its input channel to its output channel, without losing information and preserving the order. It never refuses inputs, besides it also never refuses outputs when it is non-empty. It is presented below the definition of the component BUFFIO , a bidirectional buffer, which includes two internal buffers that only communicates with the environment (they do not interact with each other), using the channels in and out. BUFFIO = BF1 ||| BF2.

(29) 4.2 COMPOSITIONS. 18. BF1 = let B(hi) = in?x → B(hxi) B(s) = (out!head(s) → B(tail(s))) 2 (in?x → B(s a hxi)) within B(hi). BF2 = let B(hi) = out?x → B(hxi) B(s) = (in!head(s) → B(tail(s))) 2 (out?x → B(s a hxi)) within B(hi). In order to perform asynchronous bidirectional communication we use this buffer (a bidirectional buffer), which transmits information in both directions. Figure 4.1 presents a graphical representation of this bidirectional buffer.. Figure 4.1 Representation of a bi-directional buffer. The asynchronous binary communication is defined below. It provides an asynchronous interaction on channels ic and oc between two contracts Ctr1 and Ctr2 mediated by a (possibly infinite) bi-directional buffer (BUFFIO ). Definition 4.7 (Asynchronous Binary Composition). Let Ctr1 and Ctr2 be two distinct component contracts with disjoint sets of channels (CCtr1 ∩ CCtr2 = {}), and ic and oc be channels within CCtr1 and CCtr2 , respectively. The asynchronous binary composition of Ctr1 and Ctr2 is given by: Ctr3 = Ctr1 hici . hoci Ctr2. = h((BCtr1 ||| BCtr2 ) k{|ic,oc|} BUFFIO ), RCtr3 , ICtr3 , CCtr3 i. where CCtr3 = (CCtr1 ∪ CCtr2 ) \ {ic, oc}, RCtr3 = CCtr3 C (RCtr1 ∪ RCtr2 ), and ICtr3 = ran(RCtr3 ). In the asynchronous binary composition, the resulting component Ctr3 is composed by: a behaviour BCtr3 represented by the composing components behaviours interleaved, which is in parallel with the buffer, synchronizing on the chosen channels; a set of channels CCtr3 resulted from the union of the composing components channels, excluding the channels attached in.

(30) 4.2 COMPOSITIONS. 19. the communication; a relation RCtr3 resulted from the union between the relations within the composing components, restricting the domains to CCtr3 ; and an interface ICtr3 , which is the range of the relation RCtr3 . The first binary composition is Interleave, which aggregates two independent entities such that, after composition, these components do not communicate with each other. Definition 4.8 (Interleave composition). Let Ctr1 and Ctr2 be two component contracts, such that CCtr1 ∩ CCtr2 = {}. Then, the Interleave composition of Ctr1 and Ctr2 , namely Ctr1 [|||] Ctr2 , is given by: Ctr1 [|||] Ctr2 = Ctr1 hi hi Ctr2 In this rule, components do not share any channel, so no synchronisation is performed. It is a particular kind of composition that involves no communication. In order to build our asymmetric model, philosophers and forks can be interleaved separately as presented below. Forks = CtrFork1 [|||] CtrFork2. Phils = CtrPhil1 [|||] CtrPhil2. These compositions are valid since the contracts have disjoint channels. A representation of the composition of these components is presented in Figure 4.2.. Figure 4.2 Interleave composition between the forks and between the philosophers.. The second rule is based on the traditional way to compose two components, attaching two components connecting two channels, one from each component. Before presenting this composition rule, we must present some definitions. Definition 4.9 (Projection). Let P be a process, and C a set of communication channels. The projection of P over C (denoted by P |` C) is defined as: P |` C = P \ (Σ \ {| C |}) The definition above restricts the behaviour of P to a set of events X by hiding all events but those in X. This notation can also be applied to a trace. Let t be a trace and S a set of events,.

(31) 4.2 COMPOSITIONS. 20. the notation t |` S yields a new sequence formed of all the occurrences of the events of S in the sequence t. It is also possible to describe the number of occurrences of these events inside a sequence by using the length operator: #(t |` S), which has the same meaning of the notation t ↓ S. In order to attach two channels in the Communication composition, protocols must have been defined. In the BRIC approach, protocols are regular I/O processes that input solely by a unique channel and output solely by another unique channel and they are the point of interaction of the protocol. The verification using protocols tends to be more efficient then using the whole behaviour. Definition 4.10 (Communication protocol). We say a CSP process P is a communication protocol if: ∃ c1 , c2 •inputs(P) ⊆ {| c1 |} ∧ outputs(P) ⊆ {| c2 |} The implementation of a protocol is defined below. Definition 4.11 (Protocol implementation). Let P be an I/O process, and ch a communication channel. The protocol implementation, namely ProtIMP (P, ch), implemented by P over ch is a protocol that satisfies the following property: ProtIMP (P, ch) ≡F P |` ch The protocol implemented by a component is given by the abstraction of its behaviour projection over a specific channel. The protocol has the same traces and failures as the projection, but it is divergence-free. In the Dining Philosophers example, we can define two processes, PROT PH(ch) and PROT FK(ch), representing the protocols related to each channel ch from the components Phils and Forks, respectively. These processes are represented by: PROT PH(ch) = ch.picksup → ch.picksack → ch.putsdown → ch.putsack → PROT PH(ch) PROT FK(ch) = ch.picksup → ch.picksack → ch.putsdown → ch.putsack → PROT FK(ch) When composing components attaching two channels, their protocols must be strong compatible. Definition 4.12 (Strong protocol compatibility). Let P and Q be two deadlock-free communication protocols, such that outputs(P) ⊆ inputs(Q) ∧ outputs(Q) ⊆ inputs(P) ∧ outputs(P) ∩ outputs(Q) = {} ∧ inputs(P) ∩ inputs(Q) = {}, The protocols P and Q are strong compatible ˜ ) if, and only if: (denoted P ≈Q ∀ s : traces(P) ∩ traces(Q) • ( OsP 6= {} ∨ OsQ 6= {}) ∧ OsP ⊆ IQs ∧ OsQ ⊆ IPs where IPs and OsP stand for the inputs and outputs performed by a process P after a trace s, respectively..

(32) 21. 4.2 COMPOSITIONS. The definition above ensures that the outputs of each process is always accepted by the other process. Hence, no information generated (an output) by a process is leaked; all of them are accepted by its peer in the communication. Based on these definitions, it is possible to define the Communication composition. Definition 4.13 (Communication composition). Let Ctr1 and Ctr2 be two component contracts, and ic and oc two channels, such that: ic ∈ CCtr1 ∧ oc ∈ CCtr2 , CCtr1 ∩ CCtr2 = {}, and BCtr1 {ic} and BCtr2 {oc} are strong compatible. Then, the Communication composition of P and Q, namely Ctr1 [ic ↔ oc]Ctr2 , via ic and oc is defined as follows: Ctr1 [ic ↔ oc]Ctr2 = Ctr1 hici . hoci Ctr2 .. In our example, we are able to compose the contracts Forks and Phils using the Communication composition rule: PComm = Forks[fk.1.1 ↔ pfk.1.1]Phils. This composition is graphically represented in Figure 4.3.. Figure 4.3 Communication composition between the forks the philosophers.. Besides binary compositions, it is also possible to make unary compositions in the BRIC approach by attaching channels from one single component. Definition 4.14 (Asynchronous unary composition). Let Ctr1 be a component contract and ic and oc two distinct channels within CCtr1 , the asynchronous unary composition of Ctr1 (namely (ic) Ctr1 |(oc) ) is given by: (ic). Ctr2 = Ctr1 |(oc) = h(BCtr1 k{|ic,oc|} BUFFIO ), RCtr2 , ICtr2 , CCtr2 i where CCtr2 = CCtr1 \ {ic, oc}, RCtr2 = CCtr2 C RCtr1 , and ICtr2 = ran RCtr2 . This definition is similar to the asynchronous binary composition, however, only one component is used in this composition. The first unary composition is Feedback. In order to attach two channels in the Feedback composition, they must be decoupled..

(33) 4.2 COMPOSITIONS. 22. Definition 4.15 (Decoupled channels). Let P be an I/O process and Ch a set of channels. Then, the channels within Ch are decoupled in P if, and only, if: P |` Ch ≡F |||z∈Ch ProtIMP (P, z) A channel ch1 is independent of (or decoupled from) a channel ch2 in a process when any communication of ch2 does not interfere with the order of events communicated by ch1 , and vice-versa. It means that they are offered to the environment independently. So, a communication between two channels of a same process behaves as communications between channels of distinct processes. Definition 4.16 (Feedback composition). Let Ctr be a component contract, and ic and oc two communication channels, such that {ic, oc} ⊆ CCtr are independent in Ctr, and BCtr ic and BCtr oc are strong compatible. Then, the Feedback composition of Ctr, namely Ctr[oc ,→ ic], hooking oc to ic, is defined as follows:

(34) hici Ctr[oc ,→ ic] = Ctr

(35) hoci The Feedback composition represents the simpler unary composition case, where two channels of the same component are assembled, but do not introduce a new cycle [RSM09b]. The contract PComm contains all forks and philosophers. The channels fk.2.1 and pfk.1.2, however, are independent in PComm because they occur in the interleaved sub-components Forks and Phils, respectively. We may, therefore, connect these channels using Feedback: PFeed1 = PComm[pfk.1.2 ,→ fk.2.1]. In our Dining Philosophers case study, in order to avoid the occurrence of a deadlocked state, we consider that one philosopher is left-handed. So, instead of connecting the independent channels fk.2.2 and pfk.2.2 from the sub-components FK2 and PH2, respectively, we may connect the channels fk.2.2 and pfk.2.1. As a consequence of it, the second philosopher is left-handed, picking up the fork in the left before the fork in the right side. So: PFeed2 = PFeed1 [pfk.2.1 ,→ fk.2.2]. These Feedback compositions are represented in Figure 4.4.. Figure 4.4 Feedback composition between the forks the philosophers..

(36) 4.2 COMPOSITIONS. 23. The Reflexive composition rule deals with more complex systems that indeed present cycles of dependencies in the topology of the system structure. This rule connects dependent channels, which may introduce undesirable cycles of dependencies among the communication of events in the system. In order to make a composition using the Reflexive rule, the buffering selfinjection property must be established. Definition 4.17 (Buffering self-injection compatibility). Let P be a deadlock-free I/O process, and c and z channels. Then Pj = P |` {| c, z |} is buffering self-injection compatible if, and only if: 1. ∀(s, X) : failures(Pj) | (s ↓ Oc = s ↓ Iz ) ∧ (s ↓ Oz = s ↓ Ic ) • X ∩ (Oc ∪ Oz ) = {} 2. ∀(s, X) : failures(Pj) | s ↓ Oc > s ↓ Iz • (s |` z, X ∪ {| c |}) ∈ failures(Pj |` z) 3. ∀(s, X) : failures(Pj) | s ↓ Oz > s ↓ Ic • (s |` c, X ∪ {| z |}) ∈ failures(Pj |` c) where Oc = outputs(P, c), Oz = outputs(P, z), Ic = inputs(P, c) and Iz = inputs(P, z) Buffering self-injection compatibility is very similar to the notion of strong compatibility, except for the fact that we do not compare the communication between two simple processes (protocols) but between events of the same process (The behaviour of the contract). All the outputs produced in s or z are consumed by the inputs of the process in a way that none of the outputs can be refused. The last composition rule, Reflexive, is presented below. Definition 4.18 (Reflexive composition). Let Ctr be a component contract, and ic and oc two channels, such that: {ic, oc} ⊆ CCtr , and BCtr {ic, oc} is buffering self-injection compatible,

(37) hici ¯ oc] = Ctr

(38) hoci . then, the Reflexive composition is defined as Ctr[ic ,→. Figure 4.5 Diagram of the final structure of the Philosophers Dining Table example. In our example, we conclude the design of our system using the Reflexive composition to connect channels fk.1.2 and pfk.2.2. ¯ pfk.2.2] PSystem = PFeed2 [fk.1.2 ,→.

(39) 4.3 BRICK. 24. This connection could not be achieved using Feedback because the two channels are not independent in PFeed2 . Intuitively, their connection introduces a cycle that causes the dependence between these channels. The final structure of the philosophers table is presented in Figure 4.5.. 4.3. BRICK. BRICK enriches components with metadata in a way to decrease the number of verifications made when composing them, since some properties of the new components can be predicted (using their parents) and maintained on the metadata. Context Processes and Dual-protocols are examples of metadata. Definition 4.19 (Communication context process). Let P be a deadlock-free communication protocol. The communication context process of P (denoted by CTXP ) is defined as a deadlockfree deterministic process, such that: traces(CTXP ) = traces(P) The communication context process represents all the possible communications between a protocol P and another process compatible with it, which allows us to restrict proofs concerning communication via a specific protocol. In the Dining Philosophers example, the Context processes CTX Phils(ch) and CTX Forks(ch) related to each channel ch from the components Phils and Forks, respectively, can be defined as: CTX Phils(ch) = ch.picksup → ch.picksack → ch.putsdown → ch.putsack → CTX Phils(ch) CTX Forks(ch) = ch.picksup → ch.picksack → ch.putsdown → ch.putsack → CTX Forks(ch). Definition 4.20 (Dual protocol). Let P be a deadlock-free communication protocol. The dual protocol of P is defined as a deadlock-free communication protocol DP, such that: inputs(P) = outputs(DP) ∧ outputs(P) = inputs(DP) ∧ traces(DP) = traces(P) Based on the definitions above, a dual protocol DP is always strong compatible with the protocol P. A systematic way of obtaining the dual protocol DP of a protocol P is by replacing internal choices by external choices and vice-versa within P. Similar to the Protocol definition, DUAL PROT PH(ch) and DUAL PROT FK(ch) are the processes representing the dual protocols related to each channel from the components Phils and Forks, respectivelly, in the Dining Philosophers example: DUAL PROT PH(ch) = ch.picksup → ch.picksack → ch.putsdown → ch.putsack → DUAL PROT PH(ch) DUAL PROT FK(ch) = ch.picksup → ch.picksack → ch.putsdown → ch.putsack → DUAL PROT FK(ch).

(40) 4.3 BRICK. 25. As described in [Ram11], by the use of this information, it is possible to verify the compatibility of two protocols P and Q by assuring that the dual protocol of P is refined by the protocol of Q in parallel with the context process of P, for instance: ProtDual (P) vF Q || CTX(P) The enriched component contract is defined below. Definition 4.21 (Enriched component contract). Let Ctr be a component contract, and K a metadata derived from its elements. An enriched component contract that includes Ctr is represented by: Ctr : hBCtr , RCtr , ICtr , CCtr , K i where K comprises: K : hProtK , CTX K , DProtK , DecK i such that: • • • •. ProtK is a relation from channels to protocols, CTX K is a relation from channels to context processes, DProtK is a relation from channels to dual protocols, DecK is a relation between channels.. The use of metadata decreases the number and the complexity of verifications, since the user is giving more information about the components. Instead of having to check compatibility among protocols in a process P, we check this on port-protocols within the metadata. Instead of verifying that two channels are decoupled in the same process, we verify it directly on relations between channels within the metadata. In this way, we perform lightweight verifications, as demonstrated in [OAR+ 16]. In order to make enriched component contracts from the regular components, there is the function Enrich as follows. Definition 4.22 (Enrich Component Contract). Let Ctr be a protocol oriented component contract, and K a metadata derived from its elements. Then: Enrich(Ctr, K ) = hBCtr , RCtr , ICtr , CCtr , K i This function denotes the construction of enriched component contracts from regular component contracts and already known metadata of these component contracts. The metadata is recalculated in every composition from the components parents in a way the user will never have to describe them again. However, this recalculation may not be complete, which means that some scenarios cannot be predicted. In such cases, BRIC verifications must be performed instead of using metadata. The composition rules for enriched component contracts are presented below..