Checking Java Concurrency Design Patterns Using Bandera

Checking Java Concurrency Design Patterns Using Bandera Cleidson R. B. de Souza and Roberto S. Silva Filho Department of Information and Computer Science University of California, Irvine {cdesouza, rsilvafi}@ics.uci.edu Abstract It is also a common practice to present the informa- Software patterns express a generic solution for a spe- tion about the advantages of using a pattern. This helps cific design problem, conveying some knowledge and the designer in the process of choosing a design pattern, expertise from designers. Model checking is an automatic when there are more than one of them available to solve technique for verifying finite state systems that deter- the same problem. These advantages are usually written mines if a property holds of the given finite state machine. by the pattern developer and are based on his experience. The paper describes the experience of the authors in In some cases, before being published the patterns are modeling three concurrency design patterns using the discussed in conferences by experts who evaluate the Bandera toolset for model checking. The concurrency pattern, i.e., these experts try to validate them. However, properties of these patterns were specified using the this process is completely informal, it does not use any BASL language and submitted for checking after the re- kind of formal method or tool in order to validate those laxation of the code. Due to some problems related to the advantages. Of course, this process is error-prone and immaturity of the tool, only one model could be checked, suggests that some kind of formal approach must be used. in one special property. The main contribution of the pa- This paper addresses this issue. per is the formalization of the patterns and the sequence We present a formal specification of the properties of of steps followed in order to formalize and check these three concurrency design patterns implemented in Java. patterns. The analysis was performed using a Java source code model checker tool called Bandera [CDH+00]. Three different design patters were implemented and submitted Key Words: Pattern verification, Design Patterns, Model for checking by this tool. These implementations had to Checking, Software Specification. be modified due to problems in Bandera’s parser. We were not completely successful in checking all patterns because of bugs in the tool such as this parser problem. 1. Introduction We specified some properties using the specification language provided by the tool in order to validate the concurrency control features which the pattern claimed to Software patterns [Gamma94] facilitate reuse of address. In this case, we used an approach for checking well-established solutions to known problems. Although properties called model checking. Model checking is an there are several different ways of presenting a pattern, automatic technique for verifying finite state systems that there is an agreement in the community that a pattern determines if a property holds in a finite state machine description must include, at least its name, description, (Chapter 1) [CGP99]. This finite state machine is auto- problem and the solution proposed. Therefore, when a matically generated by Bandera, based on the source file designer identifies the same problem, he can apply the presented to this tool. During the checking, an exhaustive correspondent pattern to that problem and easily solve it. search is done in the states to check if the property holds There are several levels of abstraction for a software at every state. pattern [BMRSS96]: in an implementation level, they are called idioms; in a design level, design patterns; and fi- 1.1. Paper Description nally if a higher-level of abstraction is used, they are called architectural patterns. In our work, we are dealing The paper is organized as follows. Section 2 presents specifically with design patterns, therefore, in the rest of the motivation to our work. The next section, briefly dis- the paper patterns and design patterns will be assumed as cusses the concept of design patterns, as well as presents synonyms. the three design patterns that are checked. Section 4 pre- 1 sents the Bandera model checker toolset. Then, section 5 provides support for checking deadlock-freedom as presents the annotations that were inserted in each pattern well as other runtime properties of the system. with the tests that we developed to check the satisfaction 4. Now, a specific tool supporting the method should be of these conditions. Section 6 summarizes our results and selected. In our case, Bandera [CDH+00] was chosen our experience using Bandera. Finally, some conclusions because of it provides support for Java programs are presented. checking using annotations in Java code. 5. Usually, the tools used in model checking have some specific input language, such as SPIN’s Promela for- 2. Motivation mal language. Therefore, the patterns must be specified in this language. Since Bandera uses Java source code as its input, this step should not be necessary. Software patterns express a generic solution for a We discuss it in more details in section 4. specific design problem, conveying some of the knowl- 6. Finally, the properties to be checked are specified edge and expertise from designers. These patterns are according to the tool selected. Bandera has a lan- abstracted in a way that other designers can reuse. guage called BSL (Bandera Specification Language) Design patterns, such as that provided by which supports different constructs such as pre and [Gamma94] are typically presented and documented us- post conditions, invariant expression definition, ing textual descriptions and problem motivations. It also predicate evaluation and so on. These annotations are uses object-oriented diagrams (class and sequence), and provided in the Java code to be analyzed as JavaDoc an implementation in a specific programming language, notes. using a simple problem example. This approach has been successfully applied in other books and conferences. In Of course, this sequence of steps is not mandatory, fact, there are several conferences and workshops de- i.e., it is just a recommendation. It can be modified to voted to patterns. accommodate other objectives. For example, the selection The approach presented in this paper addresses this of Bandera influenced our decisions in the opposite way: issue. We argue that validating design patterns using we wanted to test the Bandera toolset, therefore we se- some kind of formal method could help the adoption of lected concurrency patterns previously implemented in patterns, providing a way to check their reliability and Java. correctness. By validating, we mean checking if the patterns provide the features that they claim. For example, does the Read/Write Lock [Grand98] pattern guarantee mutual exclusion? Since nowadays there are thousands of 3. Design Patterns: History, Definition and patterns, can one trust that a pattern provides all advan- Java concurrency Patterns tages described in their specification? These questions are addressed in this paper through the formalization of three Design Patterns are design solutions adapted in the concurrent design patterns. By formalizing, we mean the resolution of frequent problems in the software develop- process of mathematically verifying properties of these ment phase. In the following sections, we present a brief patterns. Using this approach, the knowledge that is ex- history of design patterns, the concepts that comprise pressed in a design pattern can be validated, i.e., we avoid their use and documentation, and we describe the patters the problem of someone defining a pattern that does not used in the project. provide the advantages claimed. In order to validate design patterns, we suggest the 3.1. Brief History of Design Patterns following approach: Software patterns have their origin in the ideas pub- 1. First, the patterns to be checked must be identified. lished in 1977 and 1979 by Christopher Alexander in the In our case, we selected a small (three) number of field of architecture patterns for urban planning [Alexan- concurrency patterns proposed by [Grand98] in his der79]. In his work, the design rationales of common book. design solutions were presented in a structured way. In 2. The properties to be checked are identified. Since we 1987, Ward Cunnigham and Kent Beck verified that the are interested in checking concurrency patterns, the approach of documentation and reuse of ideas, presented most important properties identified were deadlock in this work, could be applied in the Software Engineer- freedom and mutual exclusion. ing field. In 1987, Ward Cunnigham and Kent Beck de- 3. Then, according with these properties, the adequate scribed five patters for user interface design. Such ideas formal method is selected. We selected a model were based on the initial work of Christopher Alexander. checking approach to validate the patterns because it 2 (OOPSLA-87 – “Using Pattern Languages for Object- and its abstraction level. Their classification, according to Oriented Programs”). some criteria, makes it easy to understand, document and In 1994, the book Design Patterns by Reich Gamma, be identified. In this work, we used some of the Concur- Richard Helm, John Vlissides and Ralph Johnson rency Design patterns described in the Mark Grand's [Gamma94], also known as "Gang of Four", popularized book. the concept of software design pattern. In 1998 the book “Patterns in Java”, by Mark Grand 3.3. Concurrency Design Patterns [Grand98], was published. It releases as an evolution to the "Gang of Four" book. The book presents several pat- These patterns present generic solutions to frequent terns, many of them not present in the Gamma’s book. In concurrency problems found in concurrent and distrib- this book, the UML notation is used to describe the gen- uted systems. They focus on two kinds of problems, the eral solutions and the design patterns. The examples are sharing of resources, focusing on the deadlock manage- coded and described using the Java programming lan- ment, and the concurrent execution of operations.

Load more