Design by Contract in Java a roadmap to excellence in trusted components

Transcription

1 Design by Contract in Java a roadmap to excellence in trusted components Abstract Reuse is one of the main targets in future software engineering. This article outlines a new concept in software development, that could enforce reuse with trusted components. The central idea is the involvement of the well known concept of design by contract into the Java programming language with recent approaches. In addition, processes and tools that support design by contract throughout the whole software engineering have to be set up. Authors Markus Wiedmann studies business engineering at the University Karlsruhe (TH) and writes presently his diploma thesis on quality management processes on the basis of design by contract and works as external collaborator for nova data AG on a project about software quality management. address: Im Wörth 7a, D Baden-Baden, Germany markus.wiedmann@novadata.de Hagen Buchwald studied business engineering at the University Karlsruhe (TH). In 1994 he wrote his diploma thesis on a genetic algorithm programming environment based on Eiffel. He works as IT consultant for nova data AG in the Innovation & Competence Center which is focused on e-business. address: Becker Göring Str. 26, D Karlsbad, Germany hagen.buchwald@novadata.de web: Detlef Seese leads as university professor the group complexity management of the Institut AIFB and is responsible in teaching and research for programming in Java, complexity and quality management, electronic commerce, intelligent software agents and the application of intelligent methods in the area of computational finance address: Institute AIFB, Universty Karslruhe (TH), D Karlsruhe, Germany seese@aifb.uni-karlsruhe.de web: 1

2 1 - Introduction Time is one of the key success factors in the IT market. Quality is taken for granted by customers and the price for software is related to customer benefits. Preferred IT partners are IT companies which excel in time. In order to increase your excellence in time, you have to make reuse of components to an integral part of your software development process. However, no reuse without excellence in trusted components. Trust in components means, that we can believe that a piece of software is correct. But what is correctness about and how to create trust in the correctness of software components? Formally, correctness could be defined as the ability of software products to fulfil their exact tasks as defined by their specification. The verification of correctness of any software application could be achieved by a mathematical correctness proof for instance or you could work the other way around and reveal bugs by dynamic testing. A different approach to demonstrate that a certain software meets its specification was introduced by Bertrand Meyer and first implemented in his Eiffel programming language more than one decade ago: the method of design by contract. This article will first describe the basics of design by contract and state some examples to explain its usage and benefits to our readers. In the second paragraph current tools for the application of this technique to the Java language are discussed. In the third section we describe an approach to implement design by contract in a modern software development process that supports this concept throughout the software lifecycle with specific tools in order to create trust in developed components. Finally, we describe the first experiment to introduce our approach in a development team of a software company. 2 - Basics of design by contract The basic ingredients of design by contract is the representation of an application s specification within the code by contracts between the routines of communicating objects. Contracts are defined by pre- and postconditions and class invariants. These constraints can be observed during runtime for their fulfilment if checks are enabled. Defining those constraints for a routine is a way to determine a contract that binds the routine and its callers (see [7], cf. table 1): Like a legal contract, they produce a mixture of benefits and obligations for both, the supplier and the client of a method. The client has to fulfil the requirements stated in preconditions in order to make the supplier execute its public methods. Has the client obeyed these obligations, the supplier guarantees, that the result of the called method will satisfy the postcondition. Communication among objects will be checked during runtime for their compliance with these constraints. obligation benefit for supplier Fulfil postcondition Client calls obey precondition for client Fulfil precondition Supplier guarantees a result that meets postcondition Table 1: Obligations and benefits of a contract Syntactically, these constraints are Boolean expressions with a few extensions, that involve software elements like attributes and methods. Within recent realisations of design by contract for Java (cf. next paragraph) the quantifiers for all and exists extend the syntax to predicate calculus. Pre- and postconditions might be added to every method in the scope of a class. Class invariants express general consistency constraints that apply to every instance as a whole. However, they only apply for stable states before and after the execution of an operation, that are observable from an external point of view. Stable states are those in which a client can apply a feature to an instance. At any other time, there is no need for the class invariant to hold. Invariants reduce redundancy by stating once what could be expressed by adding these constraints to every pre- and postcondition throughout the class. Technically, constraints of class invariants are simply conjuncted with pre- and postconditions of non-private methods during runtime. 2

3 Let us describe as an example the type Person: An object of this type contains the private property personsage that could be manipulated with the method setage(int). Typical constraints for this method could be 1 : public class Person { //invariant: personsage > 0 private int personsage; } //precondition: age > 0 //postcondition: personsage == age@pre public void setage (int age) { personsage = age; } The resulting benefits and obligations for method setage ( ) are shown in table 2 2 : Supplier Client Obligation original value of formal parameter is transferred to class variable personsage call setage( ) with positive int value as formal parameter Benefit setage ( ) is called with a positive int value value of formal parameter is transferred to personsage Table 2: Obligations and benefits for method setage ( ) If any constraint evaluates to false during runtime, it is obviously because of a discrepancy between the specification and the implementation of the software. If such a contract violation occurs, an exception will be thrown in order to reveal the bug that caused it. Meyer and Mandrioli (see [8]) formulated guidelines for the interpretation of an exception: A precondition violation shows a bug in the client: the calling routine did not obey its part of the deal. A postcondition violation shows a bug in the supplier: the called routine did not perform its task. If the class invariant is violated this indicates also a bug on the supplier side. A routine should either fulfil its contract, or it fails to fulfil it and an exception will be thrown. There should not be exception handling for those exceptions originated by contract violations, since causing bugs must be revealed. Critics might say, the constraints of the previous example could have been implemented directly in the software code. But Meyer s intention is to reduce software complexity by taking out the constraint checking of the method bodies. In addition design by contract leads to better documentation and readability of the code since the specification of each method is attached compactly to it. Those who are familiar with the C/C++ programming language might say design by contract would be similar to the assert ( ) function. This is enforced by Meyer s misleading introduction of the notion assertion that describes the constraints used in pre-/postconditions and class invariants. But unlike the assert( ) function, assertions address also the inheritance concept of the object-oriented paradigm. The associated type substitution principle demands free assignment of subtype objects to their supertypes. Design by contract offers principles that support correct inheritance of constraints between super- and subtypes according to this rule (see [7]): As benefit for developers, you must not repeat constraints of parent classes in your subclasses. 1 Note: variable@pre symbolises the value of a formal parameter before method execution. 2 Besides the listed benefits and obligations, the satisfaction of the class invariant will be checked. 3

4 To add another example we describe the classes Father, Mother and Child, which are extensions of Person. Both of them inherit methods and constraints of the class Person. Additional constraints are given by the rules that a child has unique biological parents, but parents can have more than one child. Picture 1 describes this bilateral relationship with several objects of these types. Object of type Father: Peter Object of type Mother: Mary has a... has a... Object of type Child: Luke Picture 1: Objects of type Father, Mother and Child and their associations A violation of this rule is expressed in Picture 2: Object of type Father: has a... Peter Object of type Child: Objects of type Mother: Mary Martha has a... has a... Luke Picture 2: Objects that violate the stated constraints In order to implement this system with its constraints we could use class invariants that prevent situations like the case of picture 2 by throwing exceptions. The class diagram in picture 3 sketches a possible implementation. Be aware of the constraint inheritance: The invariant of the class Person is conjuncted with subclass invariants, although it is not repeated. 4

5 Class Person inv.: personsage > 0 Class Father invariant: children!= null implies forall Child c in children.elements( ) c.getfather( ) = = this public Children children; Class Child invariant: getfather( )!= null implies exists Child c in getfather( ).children.elements( ) c = = this and getmother( )!= null implies exists Child c in getmother( ).children.elements( ) c = = this 1 Class Mother invariant: children!= null implies forall Child c in children.elements( ) c.getmother( ) = = this public Children children; 1 private Mother mother; private Father father; public Mother getmother ( ) { return mother; } public Father getfather ( ) { return father;} * 1 1 Class Children (extends Vector) public void addchild(child c) { addelement(c); } 2 Picture 3: Implementation of Father, Mother and Child So we have seen, that design by contract supports software development within three areas: With the formal representation of a system s specification as assertions in the code, the design and the documentation of any piece of software are improved. Through runtime monitoring of assertion violations the correctness of the implementation is observed and the source code can be improved in case bugs are revealed. Runtime monitoring after product release creates customer trust in supplied components since constraint violations are revealed immediately and can be located exactly. 3 - Applying design by contract to Java Recently a number of concepts were introduced to extend the Java language with features of design by contract beyond the original Java syntax: jcontractor (see [5]) and Handshake (described in [4]) were developed at the Department of Computer Science at the University of California, Santa Barbara. Jass (from [1]) is an approach made by the University of Oldenburg, Germany. icontract (cf. [6]) was constructed as semi-commercial tool from the Reliable Systems company. jcontractor is a library-based approach. Assertions are attached to the code by implementing specific methods for pre-/postconditions and invariants. They are checked during runtime either by using the jcontractor class loader, which instruments classes on the fly during loading, or by instantiating new objects with the New method of the jcontractor library. The Handshake system allows developers to set up external contract specification files for classes. It is designed as dynamically linked library that intercepts the JVM s file accesses and instruments the Java bytecodes on the fly. Jass and icontract are both design by contract pre-processors for Java. Assertions are attached to classes and methods within tagged Javadoc comment lines. Both pre-processors generate modified 5

6 source codes where assertion checking routines are attached to the original methods in additional private ones. An overview of the performance of all four approaches is shown in table 3. Realisation Assertion implementation Instrumentation for assertion checks Switch runtime checks on/off Object Constraint Language (OCL) Instrumented Classes run with JVM without extensions Support for Javadoc jcontractor Handshake Jass icontract Dynamically linked Pre-processor; Pre-processor; library; must be ported pure Java pure Java to other platforms Java library / class loader approach; pure Java Specific methods for constraint-checking are added in original Java code; with library approach: New( )- method instrumentation on the fly For all constraint checks together (disable jcontractor class loader) Constraints are added in external files; source code remains unchanged instrumentation on the fly For all constraint checks together Constraints are added within Javadoc comments (e.g.: /** require <expr>**/) During compilation comments are transformed into private routines Pre-processor enables free combination of constraint checks for every class not supported not supported quantifiers and implies can be used in assertions No: jcontractor class loader / library necessary assertion methods are listed No: dynamically linked library necessary for constraint checks No Table 3: Overview of current approaches to apply design by contract for Java For the project we present in the next paragraph we preferred the last two approaches. Yes Yes Constraints are added within Javadoc comments (e.g.: <expr> **/) During compilation comments are transformed into private routines Pre-processor enables free combination of constraint checks for every class quantifiers and implies can be used in assertions Yes No Tags are not accepted 4 - Adapting software engineering for design by contract with Java Now that necessary tools to support design by contract in the Java language are available, how could the software engineering be adapted to this concept? The central idea is the implementation of a software process for the development with Java that supports design by contract throughout the whole lifecycle and realises benefits from this concept concerning the three areas design, implementation and documentation. Adapting design phase: Analysing and designing a new system is connected to huge efforts in documentation and communication for the designing team. Therefore, we need an appropriate standard communication means that provides flexibility and extendibility to involve design by contract already in the communication of the design phase. The Unified Modelling Language (UML) predefines <<invariant>>, <<precondition>> and <<postcondition>> as three standard stereotypes of constraints for class diagrams. As soon as we have broken down the overall system specification to the class level, we express it as part of our class design. In addition, with the OCL as part of the UML we have a powerful means for expressing constraints. But in current development activities, there often follows a gap between designing and coding of a system: on one side diagrams are produced and on the other side the real system is coded in a development environment. The link is missing. Even with the usage of code producing front-end CASE-Tools, constraints and specifications kept in diagrams (and therefore design by contract) are normally lost when class files are generated. 6

7 At first, we filled this gap between the diagramming and the coding task: we manipulated a specific UML to Java code generator the way, that textual constraints attached to classes and methods in the diagrams were directly embedded as Javadoc comments into the empty code body with the requested tags for the pre-processor in use. Adaptation of the implementation phase: Sometimes, an implementation does not meet exactly the intention that was written down in its specification. Testing against stated constraints could reveal those discrepancies. But traditional tests are based on input/output comparison. We need a test strategy for the implementation phase that is focused on testing software to software communication and on revealing contract violations. Therefore, we lent the special habit of testing from the Extreme Programming (XP) method (see [2]). On the one hand, test writing prior to implementing the code into method bodies enforces thoughts about the detailed design of a system. Specification (i.e. assertions) and design of a system are reviewed again, when functional tests are written. Writing a test when a method interface is unclear or the implementation seems to be a bit complicated could help to find a proper solution. An additional link between design and implementation is created. On the other hand testing during coding, as suggested by XP, demonstrates that features work together, follow their specification and are finished. Testing with fully enabled constraints during the coding phase creates trust and confidence in a system or reveals bugs in implementation or specification. This strategy leads to continuous improvement of the business logic of a system since failures are revealed early in the implementation phase. In addition, design by contract achieves a reduction of complexity in the source code: constraints must not be checked within the method body and potential sources for new defects in the code are diminished. For the testing activity, we designed an interface ITestable which has to be implemented by every class. Having a unified test interface allows fully automated test runs. With every new version of the implementation, the embedded test method is then checked in into the version control system. So, a suitable test method is always attached to every version of a class. This supports consistency throughout the whole activity of implementing and testing. The ITestable interface implements two static method bodies that give a Vector object back to its caller: class ITestable { public static Vector BBTest( ) { } public static Vector WBTest( ) { } } The methods BBTest and WBTest suggest to implement separate black and white box tests since a good test strategy should be a mixture of both kinds of tests. The target for development is to implement tests that call every public method of a class and collect all upcoming exceptions in a vector to pass them back to the calling test software. After introducing this development concept, there was a need for an automated rebuild and class test application, that runs daily during night-time, when all systems are executable again after a working day. Running those public tests motivates the team and supports confidence in a system. This is realised by our automated Rebuild and Black/White Box Test Application (RebBoT). It is automatically started (e.g.) during night-time and searches for new or updated classes, which are then send to a design by contract pre-processor. The resulting files are instrumented with design by contract and have the ability for assertion checking during runtime. Correctly instrumented classes become instantiated. Their test routines are called and collected contract violations are fed into a product management server (PMS) database. The database stores error messages against the name of the owner or author of a class. This happens in order to assign responsibility and to gain commitment of all team members in the sense of total quality management. The next working day, every developer finds his contract violations listed in the PMS database. Development now has the possibility to evaluate priority, severity and the actual state of rework for each problem. So, a consistent view that describes the current state of quality is created. 7

8 For quality and product management this database view is to detailed. Therefore we set up a second application that generates reports of the stored data. Three tables are offered in the intranet of the company: One table shows the quantity of problems for every product aggregated by their state of rework and severity. A second one displays the quantity of announced problems for each component sorted by their state (See screenshot 1). And a last table gives detailed information about every single problem. Screenshot 1: this table gives an overview of failure quantities vertically sorted by component and horizontally sorted by current state from open to release 5 - Experiences with our model During the experiment with a development team of the nova data AG, we first tried to implement design by contract in classes of an existing system. A two days task force of three developers should manage to instrument 150 classes by applying our concept. At first, we took the class model of an existing system and added textual assertions to every property in order to generate new code with embedded assertions. The main weakness was the userunfriendliness of our CASE tool since the constraints were hidden in tiny text fields that did not appear in the actual diagram. As result of this phase, we discovered some badly designed classes that had to be redesigned because of assertions that were much to complex. Our development team started to be a bit more self-critical for the future. Since we added constraints to an existing system, we assumed that we could almost skip the implementation phase. But we had a lot of adjustments to maintain: the exception handling was so strict, that even contract violations would not have come through. Some correct Java constructions 8

9 (e.g. embedded classes) were not accepted by our pre-processor and we had to create workarounds. For future works we set up new programming guidelines which address all these problems. Our automated rebuild concept was criticised by the team, since they expected failures in the assertion syntax to be displayed as soon as possible. Waiting till the next working day was not acceptable for them. So, we had to construct an additional system that could be used directly during coding on a developer s workstation in order to verify the syntax of constraints. The documentation aspect of design by contract was not supported the way we assumed: tags for the used icontract pre-processor were refused by Javadoc. Despite all problems the basic idea of design by contract was accepted early by our development team. With this technique, origins of defects in the system were exactly located. Only the way to get design by contract into the source code must be improved. 6 - Conclusion and Perspective We described a new software development process for Java that is focused on the creation of correct software components. Therefore we combined the technique of design by contract with some testing aspects of Extreme Programming and implemented them in an existing process model including appropriate tool support. There is still a need to adjust the code generating CASE-Tool, since we have no way to read the generated assertions back into the model once we have changed them in the code. This produced a lack of acceptance in our development team. The pre-processors should be improved as well: interfaces to the environment on side of the preprocessor applications are not satisfactory. Providing detailed error codes which are passed back to RebBoT would lead to a clearer automated error classification on our side. Present pre-processors are still far away from the current OCL standard, so a powerful assertion syntax is not yet available. In addition, the used icontract pre-processor, did not accept all constructions that are allowed in Java syntax. The improvement of software documentation was not as good as expected, since assertions for the icontract pre-processor could not be displayed with Javadoc. For further works we suggest to take the tracked quantity of contract violations as a basis for new software quality metrics. The number of occurring errors per class should be set into relation to existing complexity metrics for object-oriented design like suggested by Chidamber and Kemerer [3] for instance. Without any relation to complexity, error quantities are meaningless for management, since they have a lack of insight into software codes. In another step should be explored whether a global minimum quantity of errors exists for every development team that is dependent on the complexity. Interpreting the relationship of occurring errors in inter-software communication to metrics that describe depth of inheritance, etc. could then serve as an individual team guideline for development. Using design by contract the way we suggested could help to manage the software process through all development steps. This will decrease costs and increase quality. As result trusted components for an acceptable price can be produced. Such trusted components are a basis for reuse: No reuse without trust and no excellence in development time without reuse. 7 - References [1] Bartetzko, Detlef; Fischer, Clemens: The Jass page ; Oldenburg.de/~jass [2] Beck, Kent: Extreme programming explained ; Addison Wesley Longman, Reading Massachusetts 1999 [3] Chidamber, Shyam; Kemerer, Chris: A Metrics Suite for Object Oriented Design ; IEEE Transaction on Software Engineering, Edition 20, No. 6; June 1994 [4] Duncan, Anrew, Hölzle, Urs: Adding Contracats to Java with Handshake ; Technical Report TRCS98-32, Departement of Computer Science University of California, Santa Barbara, TRs/TRCS98-32.html [5] Karaorman, Murat; Hölzle, Urs; Bruno, John: jcontractor: A Reflective Java Library to Support Design by Contract ; Technical Report TRCS98-31, Departement of Computer Science University of California, Santa Barbara, TRs/TRCS98-31.html 9

10 [6] Kramer, Reto: icontract The Java Design by Contract Tool, Proceedings 26 th TOOLS 1998, S , Santa Barbara California [7] Meyer, Bertrand: Object-Oriented Software Construction, 2 nd edition, Prentice Hall PTR, New Jersey, 1997 [8] Meyer, Bertrand; Mandrioli, Dino: Advances in object-oriented Software Engineering, Prentice Hall, New York,