JOHANNES KEPLER UNIVERSITÄT LINZ

INSTITUT FÜR WIRTSCHAFTSINFORMATIK

CD-LABOR FÜR SOFTWARE ENGINEERING

O. UNIV .-PROF. DR. G. POMBERGER

Software Engineering

R. Plösch

Tool Support for Design by Contract

CopyrightCopyright 1998 IEEE. Published in the Proceedings of the TOOLS-26 Conference, August1998, Santa Barbara, U.S.A, IEEE Computer Society Press, pp 282-294. Personal use of thismaterial is permitted. However, permission to reprint/republish this material for advertising orpromotional purposes or for creating new collective works for resale or redistribution to serversor lists, or to reuse any copyrighted component of this work in other works, must be obtainedfrom the IEEE. Contact: Manager, Copyrights and Permissions/IEEE Service Center/445 HoesLane/P.O. Box 1331/Piscataway, NJ08855- 1331, USA. Telephone: + Intl. 908-562-3966.

TR-SE-98.09

Tool Support for Design by Contract

Reinhold PlöschC. Doppler Laboratory for Software Engineering

Johannes Kepler University of LinzAltenbergerstr. 69, A-4040 Linz, Austria

ploesch@swe.uni-linz.ac.at

Abstract

Numerous experience reports indicate that prototyping is a serious and successfuldevelopment strategy. We believe that it is not sufficient to provide graphical notations forobject-oriented analysis, but that the notation of contracts in conjunction with prototyping,i.e., building executable models, is the proper technique for mastering complexity and gaininginsights into a problem domain.

We therefore developed a set of tools that is especially suitable for functional prototypingand for architectural prototyping. The underlying prototyping model is based on object-orientation and assertions. The infrastructure tools are implemented with the object-orientedprogramming language Python, while the high-level tools (assertion browser and graphicallyoriented debugger for assertions) are implemented in C++. The two parts of the system aretightly connected by means of the API provided by Python.

Although the tool support provided covers the core tasks for functional prototyping and forarchitecture prototyping, additional support for evolutionary software development and forhigher level techniques for requirements elicitation, e.g., for scenario oriented (use caseoriented) analysis is desired.

1: Motivation

Prototyping is a development approach to overcome the shortcomings of traditional softwarelife cycle approaches by developing executable prototypes for experimental purposes (seeFigure 1).

The emphasis of this prototyping-oriented life cycle is on the two planned iterations in theanalysis and design phase (user interface prototyping, architecture and componentprototyping).

A number of available experience reports ([12], [11], [7], [30]), illustrate the impact ofprototyping on software construction and on the overall development process. Bäumer et al.[2] summarize the experience gained in the application of prototyping in industrial projects.Although they draw very positive conclusions, the emphasis of their analysis and experiencereports is on user interface prototyping.

Currently established object-oriented development approaches consider prototyping to bean important methodology, but deal with it superficially. Booch [5], Rumbaugh [28] andJacobson [17] mention prototyping but fail to provide precise advice on how to use it in thecontext of object-oriented development.

Requirementsanalysis

Requirementsdefinition

User-interfaceprototyping

Design

Architecture andcomponentprototyping

Implementation

System test

Operation andmaintenance

Requirements analysis, projectcontract, coarse schedule

Requirements definition, projectschedule, system prototype

System architecture,architecture prototype

Systemimplementation

Product

Figure 1: Prototyping-oriented software life cycle [4]

We do not discuss different definitions of the terms prototype and prototyping in much detailas this is beyond the scope of this paper. For details see, e.g., Bischofberger and Pomberger[4] or Pomberger and Blaschek [25].

It is widely accepted in the research community, that a prototype is a working model of asystem. The essential difference between a prototype and a model produced with object-oriented methods like OMT is expressed by the word “working”. A prototype is thereforealways a usable model implemented on a computer. It is also commonly accepted that the laterusers have to be involved in the validation of the prototype; i.e., user participation is of vitalimportance.

Furthermore we believe that introducing formalisms is essential to ensure the quality ofrequirements specifications. This is also explicitly addressed by Bowen and Hinchey [6]. Oneessential problem with formal methods is the fact that they contradict the idea of quicklybuilding prototypes with user participation, as formal methods tend to be rigid and need asound understanding of the underlying mathematical concepts.

We therefore implemented Design by Contract (DBC) for the programming languagePython [20], a dynamically typed, object-oriented, interpreted programming language (seePloesch [24] for more details). The emphasis of this work was to provide reasonable supportthroughout prototyping-oriented software development.

We see the main benefits of a DBC solution with Python within the two proposed iterationsas depicted in Figure 1. We believe that the proposed combination of an object-oriented,dynamically typed, interpreted programming language (which facilitates the construction ofprototypes) with a more formal approach like DBC is a perfect fusion of informality andformalism in the first phases of the software life cycle. This is especially due to the fact thatthe concepts of DBC are easily and quickly understood.

Second, in prototyping-oriented development, an interpretable and lean language faroutperforms a statically typed programming language like Eiffel during analysis and earlydesign. This makes our DBC-Python approach especially valuable for prototyping-orienteddevelopment, no matter whether the DBC technique is used during requirements elicitationand specification or in the design phase, where the emphasis is on evaluating different designapproaches.

Nevertheless, support only on the level of the programming language is not sufficient,especially in the first phases of software development. We therefore developed a set of tools tofacilitate the construction and understanding of assertions.

Section 2 briefly describes our DBC model for Python to explain the need for tool support.Section 3 describes the provided tool support in depth. The final section draws someconclusions on the benefits of the provided tools as related to the prototyping-orientedsoftware life cycle described in this section.

2: DBC for Python

We describe our DBC model for Python only as far as it is relevant for understanding our needfor appropriate tool support. DBC was introduced in the programming language Eiffel [23],based on ideas by Dijkstra [9], Hoare [15] and some others. The original literature (see Meyer[23], [22]) and our previously published work on this subject [24] serve as basis for clarifyingcertain aspects of the theory. At the end of this section we will briefly discuss related andenhanced concepts

2.1: DBC elements

Preconditions/postconditions: In our Python model every method has its associateddocumentation. The basic idea of our Python DBC model is to specify preconditions andpostconditions in the documentation section of a method. Preconditions and postconditions arechecked according to the theory of DBC. Figure 2a shows a method SetProperties of classPerson.

def SetProperties(self, age, ssn):”””

param: IntType, IntType;old.age: self.age;req: age > 0;req: self.age > 0 and self.age < 100;ensure: self.old.age == self.age - 1;ensure: if age > 65: self.pensioner == 1;

”””self.age= ageself.ssn= ssn

class Person(LivingThing):”””

inv: self.age >= 0;inv: self.age < 100;inv: len(self.name) > 0;inv: self.socialSecurityNumber > 1000;

”””def __init__(self, a, n, ssn):

”””type: age: IntType,

name: StringType,socialSecurityNumber: IntType;

”””self.age= aself.name= nself.socialSecurityNumber= ssn

Figure 2a: Preconditions, postconditions Figure 2b: Invariants

There may be an arbitrary number of req: and ensure: clauses but only one param: clause permethod. The param: assertion is a feature beyond standard DBC concepts. The param: clausedescribes the type of parameters (not including the first parameter self) in the order of theiroccurrence. The param: clause leads to a run-time type check of the parameters. Typechecking is possible not only for Python built-in types but for arbitrary class types. Thisaddition and its methodical use leads to more comprehensible Python code and is a mechanismfor improving correctness of the developed software.

No special keywords (like require else and ensure else in Eiffel) are necessary foroverridden methods. The preconditions of the overridden method are automatically or-ed withthe original preconditions, and the postconditions of the overridden method are automatically

and-ed with the original postconditions. This rule is valid not only for direct ancestors of aclass but for the entire inheritance path.

Although Python supports multiple inheritance, inheritance of preconditions andpostconditions is restricted to single inheritance. We impose this limitation for the followingreasons:

• We do not want to encourage the use of multiple inheritance, as Python supportsimplementation inheritance only, which is often difficult to understand [29], especiallyin the analysis and early design stage. In addition, multiple inheritance can bereproduced by means of single inheritance and by use of the Adapter-Pattern [10].

• The model for solving name conflicts is poorly developed in Python. If an attribute isdefined in more than one place in the hierarchy, Python takes the closest and leftmostversion from the perspective of the object qualified [20]), which makes understandingmultiple inheritance architectures even harder.

As shown in Figure 2a, the specification of old expressions is possible. The right side of theold expression (self.age in our case) may consist not only of elementary data types but ofarbitrary class types. In the latter case, a deep copy of the object is created at method entry.

Boolean implications can be simulated by writing if statements in req: or ensure: clauses(see ensure: if age>100: self.pensioner == 1 in Figure 2a).

Class invariants: In Python every class has its associated documentation, as does everymethod. The basic idea is to specify class invariants in the documentation section of a class.Class invariants are checked according to the theory. Figure 2b shows class Person, a subclassof LivingThing.

Figure 2b shows the invariants of a class Person, defining a number of consistencyconditions on every object of class Person.

Method __init__, which semantically is comparable to C++ constructor operations, showsan example of a type: clause. The type: clause provides a mechanism for describing the typesof instance variables of a class. What we already stated for the param: clause is also valid forthe type: clause. The only difference is that the type: clause is treated like a class invariant;i.e., the types of instance variables are always checked before and after invocation of amethod.

Check instructions: Check instructions can be placed anywhere in method implementations.A check instruction may contain one boolean expression. Figure 3 shows an example ofmethod SetAge in class Person, which is a subclass of class LivingThing.

This particular check instruction in the example could be replaced by a precondition, whichwould have slightly different semantics, as the preconditions of the base class LivingThingwould have to be checked on program execution, too.

class Person(LivingThing):…def SetAge(self, age):

self.Check(“age > 10 and age < 100”)

Figure 3: Python check instructions

Loop invariants: Loop invariants are currently not considered in our DBC model for Python,as they are a lower level kind of specification compared to invariants, preconditions and

postconditions and check instructions. In this context we point out again that our emphasis isnot on correct software but on providing mechanisms to combine formal approaches withobject-oriented technology in the first phases of the software life cycle. For this purpose we donot consider loop invariants to be essential.

2.2: Related and enhanced concepts

Eiffel: The programming language Eiffel and the implementation by ISE is the onlycommercial object-oriented language with full support for invariants, preconditions andpostconditions.

Although the syntax of Python DBC differs from the Eiffel syntax, the semantics is close tothe Eiffel semantics. As already mentioned, we currently do not support loop invariants.Furthermore, Python DBC allows specification of type attributes for parameters and forinstance variables. This feature complements Python, as Python supports dynamic typechecking only. Naturally, this support is not necessary in a statically typed programminglanguage like Eiffel. The emphasis here is not to introduce some kind of static typing but toenhance understandability and readability by using type information.

Contracts: As defined by Helm [14], contracts are a technique for specifying the obligationsof participating objects. Essentially, a contract is intended to formalize the collaboration andbehavioral relationships between objects. A contract therefore defines communicatingparticipants and their contractual obligations. The contractual obligations not only comprisetraditional type signatures but also capture behavioral dependencies. An additional feature isto specify a sequence of messages that have to be sent (in the exact order of theirspecification) in the body of a method (Helm and Holland [14], [16] describe this aspect). Wecould easily provide syntax and run-time support for such a feature, but we are currently notconvinced that this is an appropriate mechanism during analysis and early design stages.

Larch/C++: This behavioral specification language [19] allows the specification of thebehavior of a C++ program. The underlying mathematical model is closely related to conceptsof Z [31]. Due to the underlying programming language and due to the underlying formalsemantics, this approach is interesting for ensuring correctness of C++ implementations, but itis not suitable for a prototyping-oriented approach.

Temporal system properties: Temporal perspectives as described by Arapis [1] and Mannaand Pnueli [21] allow the specification of the temporal ordering of state transitions in generaland thus also the temporal ordering of sequences of messages; this clarifies of course theexecution semantics, i.e., the behavior of objects. In principal such support could be integratedwith our approach, but we are currently not convinced that this is an appropriate approachduring analysis and early design.

3: Tool support

In this section we describe the tool support currently available. The main emphasis of ourDBC support for Python is not related to building bug-free software but on capturing parts ofrequirements in the form of assertions. Especially with the emphasis on using this techniquefor requirements elicitation and documentation as well as in the design phase (architectureprototyping), there is a need for interactive tools that allow easy inspection and editing ofassertions and inherited assertions.

In general, we differentiate between tools necessary for providing the infrastructure andtools for performing analysis and prototyping tasks. Figure 4 gives an overview of the toolscurrently available.

Browser

Debugger

DBCChecker

JITParser Parser

Python Programming Language and Runtime System

DBC Runtime Extension

Figure 4: Currently available tools

The parser, JIT parser, DBC checker and the DBC run-time extension form the infrastructuretools necessary for parsing the assertion statements from the documentation sections of thePython source code and for checking them properly at run-time. The tiling structure of Figure4 indicates, that, e.g., the DBC checker is based both on the parser and on the DBC run-timeextension. The browser and the debugger, suitable during requirements specifications or in thedesign phase (for architectural prototyping), form the analysis tools and also provide agraphical user interface to ease the use of the tools. Whereas the browser relies on theinformation provided by the parser only, the debugger additionally needs the DBC checker forchecking the assertions at run-time. In the following sections we describe the infrastructuretools and in more detail the analysis tools.

3.1: Infrastructure tools

Parser: We provide support for traditional parsing and for just-in-time (JIT) parsing. Bothparsing techniques heavily rely on the reflective capabilities of Python. This means that notthe source code of files is parsed, but the meta-information provided by the run-time system.This approach is applicable, as the necessary meta-information (e.g., class/base classrelationships, methods of a class, documentation of a class or method) is available at run time.This availability reduces the parsing effort substantially, as parsing is based on prestructuredsymbol information.

In case of the JIT parser, a class is always parsed in case of an import. This allows changingthe assertions of a class and applying these changes to a running system. To implement thisapproach elegantly, interception of the class loading mechanism is necessary to be able toparse the meta-information without having to change the code to be parsed. Whether a classhas already been parsed and whether DBC support should be provided by a class is checked atloading time. A configuration file controls the parsing activities, i.e., whether a class has to beparsed. If a class has to be parsed (according to the configuration file), all its base classes areparsed, too.

The traditional parser takes a configuration file (describing the classes to parse) as inputand generates persistent symbol information. Naturally the persistent symbol informationcomprises not only names of classes, base classes, methods, etc., but also the assertions relatedto a symbol. The analysis tools described in section 3.2 build upon this information.

DBC checker: The basic idea of our execution model is to extend the debugger frameworkprovided by Python. The DBC run-time extension (see Figure 4) is therefore a special

debugger for DBC that intercepts any method call and thus allows the DBC checker toperform the run-time checks according to the theory on the basis of the symbol informationprovided by the parser.

The process of DBC checking is controlled by an environment variable (to switch checkingon and off) and by a configuration file. The configuration file consists of a list of module/classpairs that have to be checked. Thus by altering the configuration file, DBC checking can beenabled and disabled selectively for certain classes.

3.2: Analysis tools

In this section we describe the analysis tools in more detail. The emphasis of the section is toshow that the tools provided are suitable for the intended purpose, i.e., for prototypingactivities during requirements elicitation and specification and for architectural prototyping.The analysis tools were implemented on Sun Solaris 2.x and Windows NT using theprogramming language C++ and the application framework ET++ [33]. The integration of theanalysis tools (implemented in C++) with the infrastructure tools (implemented in Python) aswell as the integration with other tools is described in more detail in the next subsection.

Architecture: Figure 5 gives an architectural overview of the analysis tools currentlyprovided. Figure 4 shows the basic relations between infrastructure tools and analysis tools;Figure 5 shows how the tools involved are interconnected and the main kinds of data andcontrol flow.

Analysis Tools

é DBC Browseré DBC Debugger

Infrastructure

é DBC Symbol Informationé Run-time Environment

SNiFF developmentenvironmentParser

Symbol Files Python Files

Figure 5: Architectural overview

The rounded boxes denote operating system processes. As we can see from the figure, DBCdebugger and DBC browser reside in the same address space. The debugger is just a tinyextension to the browser but principally uses the same graphical user interface as the browser.

The infrastructure, i.e., symbol information from the parser as well as the run-timeenvironment for assertion checking is embedded in the browser/debugger application.Nevertheless, the distinction between infrastructure tools and analysis tools is crucial, as theanalysis tools are implemented in C++ using the application framework ET++, whereas theinfrastructure tools are entirely written in Python. Python provides good APIs for embeddingitself in a C++ environment. The bi-directional solid arrow between infrastructure and coreanalysis tools indicates control and data exchange, in this case based on the API provided andby means of parameter passing. The API eases passing of datastructures beyond elementarydata types. It is therefore relatively simple to pass Python vectors or arbitrary Python objectsto the C++ part of the application and vice versa.

The main disadvantage of this embedded single-threaded architecture for the analysis toolsis, that, in a case when the control flow is passed to the infrastructure (e.g., in order to executesome Python code) the graphical user interface of the analysis tools is blocked. We do notconsider that to be a major drawback, as in most cases not very much (time consuming) codewill have to be executed. In this context we must recall, that the intended purpose of thetoolset is to provide some support for prototyping activities and not to debug full-fledgedapplications implemented in Python.

Currently the SNiFF development environment can be used to define new Python classes, toview the entire class hierarchy, to edit code, to directly edit assertions, etc. The analysis toolsand the SNiFF development environment are only loosely coupled, as there is no direct datatransfer (denoted by the doted line) but only exchange of control information. The analysistools typically request the SNiFF development environment to display a certain class ormethod whereas the SNiFF development environment informs the analysis tool that, e.g., aclass has been deleted.

The parser is controlled by the analysis tools and by the SNiFF development environment.The parser is responsible for reading Python source files and providing persistent symbolinformation that is needed by the analysis tools to properly display assertions. The informationprovided by the analysis tools is based solely on the symbol file; i.e., in principal no Pythonsource code is necessary to view the assertions.

As we have already seen in the above sections, the browser tool also allows editingoperations like adding new assertions, deleting assertions and changing assertions. Thebrowser applies these changes to the Python source code files on demand, i.e., when acorresponding menu entry is selected by the user. These changes are, of course, also reflectedin the SNiFF development environment.

Browser: The browser window depicted in Figure 6a is divided into three main parts. Theupper part (marked with � in Figure 6a) shows all classes and methods contained in theproject to analyze.

1

2

3

3

3

1

Figure 6a: DBC Browser Figure 6b: Editing type expressions

The gray icon in front of the class name or the method name gives some basic information onthe applicable assertions. The icons in front of the class names show whether there exist anyclass invariants, whereas the icons in front of the method names indicate whetherpreconditions, postconditions, old expressions or type expressions for parameters arespecified.

• A hollow box indicates that no assertion is specified for the respective symbol, neitherin the class itself nor in a subclass or superclass. This information is only related toassertions, not to any inheritance hierarchy in the sense of object-oriented programming.

• A box with a middle bar indicates that assertions are specified for the respectivesymbol, but that there are no assertions specified for any subclasses or superclass

• A box with a middle bar and gray corners indicates that assertions are specified for therespective symbol and for subclasses and/or the superclass. The filled upper cornerindicates that assertions apply for superclasses, whereas a filled lower corner indicatesthat assertions apply for subclasses (both corner may be filled, too).

We consider this information to be very valuable as it gives a rough overview about thecomplexity of classes with respect to assertions. Classes with inherited assertions, especiallyin cases where many methods of a class inherit assertions, have to be understood and reviewedthoroughly as they are obviously core components and sources of misunderstandings betweenthe developer and customers. On the other hand, classes with few assertions or few inheritancerelationships (in the context of assertions) indicate either minor importance or white spots,i.e., not yet well understood parts of an application domain.

The middle part of the browser (marked with ó in Figure 6a) displays the assertions of theselected symbol. The icons in front of the assertion expression indicate the type of assertion.Although this is redundant information (the type of an assertion can always be deduced fromthe assertion text), we consider this to be important information for the analyst, as the iconsallow quick and easy recognition what kind of assertions are most important.

By default all types of assertions are displayed for a class and all its superclasses. Tofacilitate understanding, i.e., to reduce the amount of assertions displayed simultaneously,filters may be applied. Three different filters (marked with ì in Figure 6a) apply to theassertions. First, the analyst may decide whether to include the assertions of base classes ornot. This hierarchy filter always shows the inheritance path of the currently selected class. Theanalyst may selectively include or exclude the assertions of arbitrary base classes along theinheritance path. Second, the analyst may filter the display of assertions related to classes, i.e.,class invariants and type expression for instance variables. Third, the analyst may filter thedisplay of assertions related to methods, i.e., preconditions, postconditions, olds expressionsand type expressions for method parameters. All three groups of filtering conditions aresimultaneously applied to the currently displayed assertions. The filter mechanism is usefulfor selectively browsing the assertions of a class or a family of classes and thus facilitatesunderstanding of specified assertions.

Besides merely viewing assertions, the tool allows browsing the code of arbitrary classeswith the SNiFF programming environment. The SNiFF application is controlled by ourbrowser by means of the protocol provided by the programming environment SNiFF.

Besides merely browsing assertions, the tools allows directly changing existing assertionsand adding or deleting assertions. It is not possible to alter the signatures of classes or to addnew classes. This task should be accomplished by using the programming environment SNiFF.We believe, that the syntax of Python is simple enough for easily specifying classes and

methods and is thus suitable for prototyping activities; nevertheless, classes and methodscould also be specified by using a graphic notation like UML [32].

The user interface for altering assertions is particularly designed for ease of use. Figure 6bgives an example for a window that allows editing the type expression of a class.

The currently specified instance variables and their associated type are depicted in the leftpart of Figure 6b.

The type of an instance variable is easily changed by dragging one of the types shown in theright part of the window to the respective instance variable in the left part of the window. Thetypes available for dragging are constructed dynamically, as, besides the built-in types, anyclass type currently available in the project may be used.

The analyst may export the changes made on demand directly to the Python source code.Besides the special-purpose editor depicted in Figure 6b, other special-purpose editors areavailable for other types of assertions.

Debugger: The DBC debugger is a separate tool but tightly integrated with the DBC browser.On selecting the debug mode in the Debug menu of the browser, the browser mutates to theDBC debugger as depicted in Figure 7a.

The debugger does not at all restrict the browsing and filtering mechanisms of the DBCbrowser but extends them for debugging purposes. Specifically, the debugger allows settingbreakpoints arbitrarily; i.e., a breakpoint may be set for a class, a method or an arbitraryassertion.

A breakpoint for a class instructs the run-time system to stop whenever a class invariant ischecked, i.e., before executing any method of this class. A breakpoint for a method indicatesthat the runtime system stops before checking the assertions of the particular method. Abreakpoint for an assertion indicates the run-time system to stop before checking the markedassertion.

Figure 7a: DBC Debugger Figure 7b: Inspecting objects

An arrow (see Figure 7a) indicates that a breakpoint has been reached. At this point thedebugger allows inspection of the object in question. For this purpose we integrated PTUI [27]into our debugger. The PTUI component is part of the DBC checker depicted in Figure 5. Anexample snapshot is given in Figure 7b. The PTUI object browser allows visualizing datamembers of objects including inherited members, as well as inspecting class members. AsPTUI is completely written in Python, the integration into our DBC checker was painless.

Violations of assertions detected by the DBC checker are displayed in a window. Webelieve that the debugging support provided, in combination with the analysis support of thebrowser, contributes to facilitating the understanding of complex contractual relations.

3.3: Related tools

The programming language Eiffel and the implementation by ISE is the only commercialobject-oriented language with full support for invariants, preconditions and postconditions. AsDesign by Contract is built-in in the Eiffel programming language and run-time system, nospecial discussion is necessary.

iContract: iContract [18] is a tool that provides support for Design by Contract for theprogramming language Java. iContract is a source-code preprocessor that instruments the codewith checks for assertions. Special comment tags are interpreted by iContract and convertedinto assertion check code that is inserted into the source code. The instrumentation level (e.g.,only postcondition checks) can be chosen on a file level, enabling fine-grained performancecontrol.

The basic idea, i.e., using special comment tags for marking assertion statements, is similarto our approach. The implementation differs substantially, as our implementation reliesheavily on reflective capabilities of Python, whereas iContract is a source-code preprocessor.We do not believe that iContract would be suitable for prototyping activities, as the underlyingprogramming language is too complex for prototyping issues and no distinctive tool supportfor prototyping is available.

Design by Contract for Smalltalk: The work by Carillo-Castellon et al. [8] implementsportions of Design by Contract for the programming language Smalltalk. The emphasis here isto support correctness. Due to a lack of static typing and dynamic type assertions (as providedby Python DBC) it is difficult to fully support correctness. No special tools are available foranalyzing assertions. The implementation is straightforward; i.e., it is necessary to invoke theappropriate methods for checking assertions in the Smalltalk code manually. The assertionexpressions are passed as Smalltalk blocks.

4: Conclusion and further work

We believe that the DBC approach, together with the tool support provided (i.e., Python as akind of model description language together with the high-level analysis and debugging tools)is a well-suited technique for prototyping of functional requirements and for architecturalprototyping.

Furthermore, we believe that there is a need for evolutionary development. In this context,migration techniques have to be developed to transform the prototypes (implemented bymeans of Python and our DBC extensions) to a target environment, i.e., C++ or Java. We arecurrently implementing such transformational tools.

The technique presented in this paper together with the tool support provided has to becombined with other widely used techniques especially in the analysis phase of the softwarelife cycle. Therefore we are currently investigating the integration of our approach with userinterface prototyping and with use-case-centered requirements elicitation techniques [3], [13],[26].

Bibliography

[1] Arapis C.: “A Temporal Perspective of Composite Objects”, in: Nierstrasz O., Tsichritzis D.: “Object-Oriented Software Composition”, Prentice Hall, The Object-Oriented Series, 1995, pp 123-152

[2] Bäumer D., Bischofberger W. R., Lichter H., Züllighoven H.: “ User Interface Prototyping - Concepts, Tools,and Experience”, Proceedings of the 18th International Conference on Software Engineering (ICSE), Berlin,Germany, March 1996, pp 532-541

[3] Behringer D.: “Modelling Global Behaviour with Scenarios in Object-Oriented Analysis”, Theses No. 1655(1997), Ecole Polythechnique Federale de Lausanne (EPFL), 1997

[4] Bischofberger W. R., Pomberger G: “Prototyping-Oriented Software Development – Concepts and Tools”,Springer-Verlag, 1992

[5] Booch G.: “Object-oriented Analysis and Design with Applications”, The Benjamin Cummings PublishingCompany, 1994

[6] Bowen J. P., Hinchey M. G.: “Ten Commandments of Formal Methods”, IEEE Computer, IEEE ComputerSociety, April 1995, pp 56-63

[7] Carey J. M., Currey J. D.: “The Prototyping Conundrum”, Datamation, June 1, 1989, pp 29-33

[8] Carillo-Castellon M., Garcia-Molina J., Pimentel E., Repiso I.: “Design by Contract in Smalltalk”, Journal ofObject Oriented Programming, November-December 1996, pp 23-28

[9] Dijkstra E.W.: “A Discipline of Programming”, Prentice Hall, Englewood Cliffs, 1976

[10] Gamma E., Helm R., Johnson R., Vlissides J.: “Design Patterns - Elements of Reusable Object-OrientedSoftware”, Addison-Wesley, Professional Computing Series, Reading, Massachusetts, 1994

[11] Goma H.: “Prototypes – Keep Them or Throw Them Away”, in: Lipp M. E. (ed.): “Prototyping – State of theArt Report”, Pergamon Infotech Ltd, Maidenhead, 1986, pp 41-54

[12] Gordon S., Bieman J.: “Rapid Prototyping and Software Quality: Lessons from Industry”, Technical ReportCS-91-113, Department of Computer Science, Colorado State University, 1991

[13] Graham I.: “Task Scripts, Use Cases and Scenarios in Object Oriented Analysis”, Object Oriented Systems 3,1996, pp 123-142

[14] Helm R., Holland I.M., Gangopadhyay D.: “Contracts: Specifying Behavioral Compositions in Object-Oriented Systems”, Proceedings of ECOOP/OOPSLA'90 conference, 1990, pp 169-180

[15] Hoare C.A.R.: “Proof of Correctness of Data Representations”, Acta Informatica, Vol. 1, 1972, pp 271-281

[16] Holland I.M.: “Specifying Reusable Components Using Contracts”, Proceedings of ECOOP 92 conference,Lecture Notes in Comuter Science 615, Springer Verlag, 1992, pp 287-308

[17] Jacobson I.: “Object-Oriented Software Engineering – A Use Case Driven Approach”, Addison-Wesley, 1993

[18] Kramer R. “iContract-The Java Design by Contract Tool”, to be published in Proceedings of TOOLS USA’98 conference, 1998

[19] Leavans G. T.: “An Overview of Larch/C++: Behavioral Specifications for C++ Modules”, TR 96-01d,February 1996, revised March, April 1996, January, July 1997, Department of Computer Science, Iowa StateUniversity, 1997

[20] Lutz M.: “Programming Python”, O'Reilly & Associates, Sebastopol, 1996

[21] Manna Z., Pnueli A.: “The Temporal Logic of Reactive and Concurrent Systems – Specification”, Springer-Verlag, 1991

[22] Meyer B.: “Building Bug-Free O-O Software: An Introduction to Design by Contract”, Object Currents, SIGSPublication, Vol. 1, No. 3, March 1996

[23] Meyer B.: “Eiffel - The Language”, Prentice Hall, Object-Oriented Series, Hemel Hempstead, 1992

[24] Ploesch R.: “Design by Contract for Python”, Proceedings of the Asia Pacific Software EngineeringConference, 1997

[25] Pomberger G., Blaschek G.: “Object-Orientation and Prototyping in Software Engineering”, Prentice Hall,The object-oriented series, Hemel Hempstead, 1996

[26] Ralyté J., Ben Achour C.: “Scenario Integration into Requirements Engineering Methods”, Proceedings of theWorkshop on the Many Facets of Process Engineering (MFPE'97), Gammarth, Tunis, September 22-23, 1997

[27] Roadhouse Z.: see http://starship.skyport.net/crew/zack/ptui for more details

[28] Rumbaugh J.: “Object-Oriented Modeling and Design”, Prentice Hall, 1991

[29] Shang D. L.: “Multiple Inheritance - A Critical Comparison on Transframe, Java & C++”, Object Currents,SIGS Publication, Vol. 1, No. 11, November 1996

[30] Sobol M. G., Kagan A.: “Which Systems Analysts are more Likely to Prototype?”, Journal of InformationSystem Management, Summer 1989, pp 36-43

[31] Spivey J. M.: “The Z Notation: A Reference Manual”, International Series in Computer Science, Prentice-Hall, New York, 1992

[32] UML: “Unified Method for Object-Oriented Development”, Rational Software Corporation, Version 0.91,1996

[33] Weinand A., Gamma E., Marty R.: “Design and Implementation of ET++, a Seamless Object-OrientedApplication Framework”, Structured Programming, Vol. 10, No. 2, Springer International, 1989, pp 63-87