Studiengang

:

Softwaretechnik

Prufer: ¨ Betreuer:

Prof. J. Ludewig Dipl. Inf. S. Opferkuch

begonnen am: beendet am:

1. September 2003 9. M¨ arz 2004

CR-Klassifikation:

D.2.1, D.2.4, D.2.5, D.2.9, D.2.11, K.6.3, K.6.4

Diplomarbeit Nr. 2139

Document-Driven Black-Box-Testing
M. Wetzel

¨ Softwaretechnologie Institut fur Abteilung Software Engineering Universit¨ at Stuttgart Universit¨ atsstr. 38 D–70569 Stuttgart

DOCUMENT-DRIVEN BLACK-BOX-TESTING
By MATTHIAS WETZEL
¨ Softwaretechnologie Institut fur Abteilung Software Engineering Universit¨ at Stuttgart Universit¨ atsstr. 38 D–70569 Stuttgart wetzel@informatik.uni-stuttgart.de

Abstract
Software running on embedded systems is playing an increasingly important role in safetycritical and mission-critical applications. Formal documentation methods, like the Tabular Expressions invented by Parnas et al., avoid the ambiguities inherent in natural language by using mathematical notation. This allows the intended behavior of software to be precisely defined, reducing the number of errors that are caused by misleading documentation. Despite its shortcomings, software testing is considered an important part of software quality assurance. A fundamental assumption of software testing is the existence of some mechanism, which is called an oracle, that is able to determine whether the results of a test execution are correct. The oracle is often implemented by manually deriving the expected output from informal—and possibly inconsistent—documentation and then comparing it to the actual test results. This procedure is both time-consuming and error-prone. However, if a formal specification exists, it can be used to automatically evaluate the test results and determine the success or failure of a test execution. This thesis describes the design and implementation of a working prototype, which combines the use of Tabular Expressions and embedded-systems products developed by Ashling Microsystems Ltd. in a tool that is able to automatically execute function tests on a target embedded system, and evaluate their results using an existing formal specification of the tested function. In addition to testresult-evaluation, the tool is able to determine the specification-coverage of a given set of testcases on the basis of a formal specification, without depending on knowledge—or even existence—of program code. This allows measuring and improving test quality at any phase of a software project, even prior to implementation. A small trial application demonstrates the usefulness of the methods described in this work. Possible applications in projects and expected benefits are discussed. It is shown that using tests based on formal documentation enforces consistency between documentation and implementation, which greatly increases the value of such a documentation, especially to maintenance programmers. It is further argued that tools performing such tests help to reduce costs for software testing while improving test quality, and by doing so more than compensate the additional costs of creating formal specifications. i

ii .

I would also like to thank Dr. Robert L. Martin von Mohrenschildt and Dr. Jochen Ludewig and Prof.Acknowledgements I would like to express my sincere thanks to Prof. I would like to express my gratitude to Ashling Microsystems Ltd. The supervision of Stefan Opferkuch is also greatly appreciated. iii . Baber. who both have provided helpful comments on this thesis. and all its employees. for providing me with the tools and knowledge needed to complete this work. David L. Parnas for their continuing support throughout the preparation and the execution of this thesis.

iv .

. . . . . . . . . . . . . . 2. . . . .5.3 Raw Table Skeleton . 1. . . . . . . . . . . . . .3 Dimensions . . .8 Interpretation of Tabular Expressions . . . . . . . . . . . . . . . 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 Tabular Expression background . . . . . . . . . . . . . . . . . . . .4 Applications of Tabular Expressions in projects 2. . . . . .7 Distinct types of table cells . . . . . . . . . . . . 2. . . . . . . . . . . . . . . . . 2. . . . . . . . . . . . . . . . .2. . . . . . .5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Tabular Expressions 2. . . . . . . . . . . . . . . . . . . . . 2. . . . . . . . 2. . . . . 2. . .4 Types of Tabular Expressions . . . . . . . . . . . .1 Relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 Scope . .2. . . . . . . . . . . . . .5. . . . . . 2. . . . . . . . . . . . . . . . . 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i iii v ix xi 1 1 2 3 4 5 6 6 6 7 7 7 8 8 10 10 10 11 12 12 13 15 15 16 v . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. . . . . . . . . .1 Background . . . . . .2. . . . 2. . . . . . . . . . .5 Tabular Expressions in this work . . . . 2. . .6 Forbidden characters . . . . . . . . . . .5. . . .2. . . . . . . . . . . 1. . . . . . . . . . . . . . . . 1. . . . . . . . . . . . . . .4 Semantics of Tabular Expressions . . . . . . . 2. . . . . . . . . . . . 2. . . . . . . . . . . . . .2 Purpose . . . . . . . . . . .2 Basic definitions of Tabular Expressions . . . . . . .2 Initial and final states . . . . . . . .2 Definition of Tabular Expressions . . .Contents Abstract Acknowledgements Table of contents List of figures List of tables 1 Introduction 1. . . . . . . . . . . . .5.5 Table-cell-expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5. . . . . . .3 Example of a Tabular Expression . . . . . . . . . . .1 Use of Tabular Expressions . . . .5. . 2. . . . . . . . .5. . .5 Outline . . . . . . . . . . . . . . . . . . . . . .4 Related Work 1. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . .2 AsIDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3. .4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5. . . . . . . . . . . . . . . . . . . . Implementation 4. . . . .3. 4. . . . . . . . . . . . . . . . . . . . . . . . . . . .4 Package common . . . . .6 Report generation . . . . . . . . .3 Conceptual Design 3. .6 ExecutedTestcasesFile . . . . . . . vi . . . . . .2 Software . . . 4. . . . . . . . . . 4. . . . . . . . . . . . . . 3. . . . .1. . . . . . .4 Exception handling . . . . . . . .5 Groupfile . . . . . . . . . . . . 22 22 25 25 26 27 29 30 31 32 32 32 35 35 36 36 38 39 39 39 40 42 43 44 45 46 47 51 52 52 53 54 54 56 60 61 61 61 61 62 62 62 62 64 65 4 . . . . . . . . . . . . .10 ConfigFile . . . . . . . . 4. . . . . . . . . .1 Computer specification . . . . . . . . . . . . . . . . . . .2. . . . . . . . 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 RawTestcasesFile . . . . . . . . . . . . . .3 Embedded System . . . . . . . . . .3 Conceptual design solution . . . .2 Test data . . . . .3. . . . . . . . . . . .3. . . . . .2. . . .3 C-function . . . . .1 Storing variable values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. . . . . . . . . . . . . .8 GeneratedReportFile .1 FormalSpecificationFile . . . . . . 3.4. . . . . . . . . . . . 4. . . . . . . . . . . . . . . 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 Classes for imported and generated files 4. . . . . . . . . . . . .3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5. . .1 Problem description . . . . . . . . . . . . . . . . . . 3. . . . . . . . . . . . . . . . . .2 Structure of formal specifications 3. . .1 Parsing table-cell-expressions . . . . .3 PathFinder . . . . .4. . . . . . . 4. . . . . . . .1 Overview .3 Package exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2. . . . . . . . . . . . . . . . . .2 CFile . . . . . . . . . . . . . . . . . . . . .2 Detailed description . . . . . .3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 Display of Tabular Expressions . . . .3. . . . . . . . . . . .3. . . . . . . . . 3. . . 5. . . . . . . . . . . . . . . . . . . 3. . . . 4. .3. . . 4. . .3.4 CTestHarnessFile . . . . . . . . . .9 ImportedReportFile . . . . . . .4. .4 Testcases . 5. . . . . . . . . . . . . . . . . . . . . . . . . . . .2. . .3. . . . . . . . . . . . . . . . . . . . 4. . . . . .2 Package dataStructures . . . 4. 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. . . . . . . . . . . . . . . . . . . .1. . . . . . . . 4. . . . . . . . . . . .2. . 4. 5.4 Further implementation features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2. . . . . . .2. . . . 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 First part of the tool: TestPreparation 5. . . . . . . . . . . . . . . . . . . . . . . . . 4. . . . . . . . . . . . 4. . 3. . . . . . . . . . 5. . . .2 Conceptual design decisions . . . . . . . . 3. . . .3 Test execution . . . . . . . . . . . . . . . . . . . . . .1 Test machine configuration . . . . . . . . .3. . . . .3. . . . . . . . . . . . . . . . . . . . . . . . 4. . . . . . . . . . . . . . . . . . . . . . . . .2. . . . . . . . . . 4. . . . . .2. . . . . . .1. . . . . . . . . . . . . . .2 GUI . .1 Package files . . . .2 Tool Design . . . . . . . . . . . . . . . . . . . . .1 Prerequisites . . . . . . . 5 Trial application 5. .7 YacasFile . . . . . . . . . . . . . . . . . . . 4. . . . .3. . . . . . . . . . .3. . . . .2. . . . . . . . .5 Tool parts . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . .2 C-file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F. . .1 Application of Results . . . . . . . . . 66 68 69 70 70 71 72 74 I III VI VIII Conclusion 6. . . . . G Trial application data XXXVII G. . . . . . . . . . . . . . XV XVII XXIII XXIV XXVI XXVII XXXI XXXII XXXIV XXXIV XXXV . . . . . . . . . . . . . . . . . . . . X E. . . . . . . . . .7 Yacas-input-file . . . . .5. .2 Second part of the tool . . . . . . A Term definitions B Constants C LOC D Uses Relation E GUI X E. . . . . . . . . . . . . . . . . . . . . . . . . . . . F. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F. . . . .1 Formal specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 Yacas-output-file . . . . . . . . . . . . . . . . . . . . . . . . . . . XIII F File formats F. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 First part of the tool . . . . . . . . . . . . . . . F. . . . . . . . . .2 Critical Reflexion . . . . . . . . . . . . . . . . . . . .3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6. . .4 Imported raw testcases F.4 Conclusion . . . . . . . . . . . . . . . . . . . . .9 Report . . . F. . . . . . . . . . . . . . . . . . . . . . . . .3 C-Test-Harness . . . . . . . . . . . . . . . . . . .1 Formal specification . . . F. . . . . . . . .6 Executed testcases . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 6 5. . . . . . . . . . .2 C-File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Performance metrics . . .5 PathFinder-Groupfile F.3 Limitations and Future Work 6. . . . . .4 5. . . . . . . . . Results . . . . 6. . . F. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXXVII G. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 Second part of the tool: ReportGeneration . . . . . . . . . . . . . . . . . . . .10 Config-file . . . . . . . . . . . . . . XXXVIII Bibliography XLI vii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

viii .

2 4. . . . . . . . . . . . . . . . . . ix . . . . . . Screenshot Tool part 2: ReportGeneration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specification-coverage-report Testresult-evaluation-report . . . . Screenshot AsIDE . . . . . . . . . . . . Formal specification of function Float2 . . .1 Uses Relation . . . . . . . . . . . . . . . . . . 33 40 55 56 58 64 65 67 67 IX D. .3 4. . . . . . . . . . . . . . . . . . . . . . . . Screenshot PathFinder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 5. . . . . . . .List of Figures 3. .1 5. . . . . . . . . . . . . . . . . . . . . . . . . . . .4 Conceptual design diagram . . . . .1 4. . . . . . . . . . . . . .1 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Association between Files and Java-Classes Screenshot Tool part 1: TestPreparation . . . . . . . . . . . . . .3 5. . . . . . . . . . . . .2 5. . . . . . . . . .

x .

. . . . . .List of Tables 2. . .4 2. . . . . . . . . . . . . InvertedIntegerTable1 InvertedIntegerTable2 VectorFloatTable1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NormalIntegerTable1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9 18 19 21 VII C. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 GUI-elements of Tool part 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIV xi . . .3 2. .1 GUI-elements of Tool part 1 . . . .2 2. . . . . . . . . . . .1 2. . . XII E. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 Raw Table Skeleton . . . . .1 LOC . . . . . . . . . . . . . . . . . . . . . E. . .

xii .

an increasing amount of software is being developed for embedded systems and now plays an important role in a growing number of safety-critical and mission-critical applications. and the domain and range of such a function often contain elements of different types. because they consider it unreadable. Regardless of the precision of documentation that uses these methods. At the end of the chapter. precise and unambiguous. complex expressions when applied to real software products. but also by ’domain experts’ familiar with the application area of the embedded system. The documentation should be complete. Documentation of this software should be readable not only by its designers and programmers. Tabular Expressions developed by Parnas et al. This approach is particularly well suited to embedded-systems-software.1 Background Since the recent breakthrough of mobile devices. 1. some related work is shown and the contents of this thesis are outlined. and many programs are characterized by lists of condition-action pairs. computers can implement functions that have many irregular discontinuities. which 1 . Since documents containing only natural language rarely have these characteristics. the Software Quality Research Lab (SRQL) at the University of Limerick is developing and improving documentation methods which utilize mathematical functions and relations to describe the intended behaviour of a computing system [Par03]. the documentation will rarely be used by maintainence programmers. its purpose and its scope. The functions that are used for describing digital computer systems often have different properties than those prevalent in analog systems.Chapter 1 Introduction This chapter provides a brief introduction to the background of the thesis. and are particularly well-suited to software documentation. Traditional specification methods using mathematical notations often result in large. and should help to ensure the trustworthiness of the software [Abr97]. [Par92] have been found to be useful for improving the readability of complex mathematical functions. correct. Designing software usually requires numerous cases— including erroneous input cases—to be identified. which can be easily translated into Tabular Expressions [Abr97].

Often a previously determined ’expected output’ is manually compared with the test output. without having to manually determine expected results and compare them with actual test results. this specification can be used as an oracle by comparing the expected results defined by the specification with the actual test results. the expected output can not be determined because only the properties and not the value of a desired result are known. Wetzel March 9. Formal specifications can be used by tools to automatically evaluate test results. Furthermore. This is called specification-coverage in this thesis. it is checked whether the test results match the specification of the function for this combination of input values. e. to automatically test a function on a target embedded system.g. for numerical calculations [Pet95]. Combined with the in-circuit-emulators and software tools provided by Ashling Microsystems Ltd. and it has been observed that as much as 50% of the development costs for a software project are spent for testing [Pre92]. In some cases. can be used to determine whether the output of a tested program is correct [Wey82]. the structure provided by Tabular Expressions makes it easier to consider every case separately while writing or reading a design document. in Limerick. It is a fact that testing is costly and error-prone. Tools that help to increase the quality of testing while reducing its cost are therefore an important part of any research intent on improving the software development process. the use of Tabular Expressions for the specification of embedded-systems-software facilitates both automatic test execution and automatic evaluation of test results of software that is being developed for embedded systems. and the tools provided by Ashling Microsystems Ltd.Chapter 1: Introduction Diploma thesis M. 1. The described method can also be used to determine which of the distinct behaviors (cases) defined for different combinations of input-values in the specification of a function have been tested by a set of testcases how often. This is of great importance for the design and development of complex software for safety-critical or mission-critical applications. This thesis describes a method of combining the Tabular Expressions invented by Parnas et al. which is a tedious task that is both time-consuming and error-prone. However. A fundamental assumption of software testing is that some mechanism. 2004 rarely includes complex graphical interfaces that would be more difficult to describe using Tabular Expressions. After the function has been tested. 2 . This check is called testresult-evaluation in this thesis. but is hopelessly inadequate for showing their absence [Dij72]. if a formal specification of a program exists. which is called an oracle. there is consensus that testing is an important step in the software development process. Testresult-evaluation guides programmers efficiently to functions and parts of functions that still contain errors by highlighting which combinations of input-values failed to yield the specified results during test execution. Ireland [Mic03].2 Purpose Although it is well known that program testing can be a very effective way to show the presence of bugs (faults).

only the exercising of terminating functions is considered. The test quality that can be achieved by using this method is comparable to the quality of White-Box-Tests. making this method perfectly suited for Black-Box-Testing. testcases for White-Box-Tests can only be created after the implementation is complete. e. 90% or 100%. 1. It is also applicable for random and interactive testing. They do not depend on knowledge. instrumentation or even the existence of code. the tool must be able to determine the specification-coverage of the set of testcases in regard to the function specification. While the tool is planned to be a standalone-system. In addition. In addition. when time is short in most software projects. The goal of this thesis is to show yet another useful application of Tabular Expressions in the rapidly growing market of software for embedded systems by improving the quality of testing.3 Scope Testing is defined by the IEEE as: The process of exercising or evaluating a system or system component by manual or automated means to verify that it satisfies specified requirements or to identify differences between expected and actual results. 3 . The application of this method is not limited to measuring the quality of a set of testcases created and executed by one and the same person. [ANS83] In this thesis. thus allowing the addition of a minimal number of new testcases to fill those gaps and achieve the desired degree of specification-coverage. and evaluating the results of this test execution by comparing them with the specification of the function. It can be used to measure the quality of a set of testcases executed by another team member.Chapter 1: Introduction Diploma thesis M. The tool is intended as a working prototype demonstrating these capabilities and showing their usefulness for embedded software development. at SQRL. 2004 Determining the specification-coverage of a set of testcases allows measuring its quality by calculating the percentage of specified cases it covers. If ressources for testing are limited. The scope of this thesis is to implement a tool that is capable of automatically executing a given function with a given set of testcases on an embedded system. while reducing its costs. Wetzel March 9. However. another team or another company hired for testing. redundant testcases that cover the same case may be eliminated. later versions are likely to be integrated into the new Table-Tool-System-Framework (TTS) developed by Parnas et al. this method has the additional benefit of being able to start creating testcases directly after the completion of the specification. It also allows improving this quality by showing which cases have not been tested by any testcase. All of this can be done prior to test execution and even before implementation. In addition to having to instrument the code.g. it must be possible to determine the success or failure of a function execution from its initial and final states. since the quality measurement and -improvement are purely based on documentation.

Generating an oracle from the specification by using this method allows to ensure that documentation and code are consistent [Pet95]. Floating-Point. Inverted and Vector Tabular Expressions [Par92].4 Related Work The Test Oracle Generator (TOG) implemented by Peters [Pet95] is able to evaluate test results by generating an oracle from the formal specification of a function. this relation is implemented according to its specification as far as it is tested by this testcase. Arrays. The characteristic predicate of a relation is T rue if a pair is in the relation. Wetzel March 9. TOG is a part of the old Table Tool System developed at McMaster University and can be used to generate executable C-Code from Tabular Expressions. TOG is based on the idea that a relation can be described by expressing its characteristic predicate in terms of the values of the concrete program variables used by the relation [Pet95]. or include a placeholder instead of a value to allow the value to be entered during test execution. The results obtained by executing the generated code are then compared with the actual test results. 4 . The specified function must be written in C and must be executable on an ARM-embeddedsystem that is compatible with the tools provided by Ashling Microsystems Ltd. 1.Chapter 1: Introduction Diploma thesis M. The testcases must define values for all parameters and all global variables used for input by the specified function. Otherwise. and assumes that imported Tabular Expressions are both syntactically and semantically correct. 2004 To comply with the component-based-approach that is intended to be used for TTS. otherwise it is F alse [Par92]. This can be used as a test-oracle: if the characteristic predicate of a relation is true for the pair that consists of the input-values and the output-values of an executed testcase. If they match. TOG is not intended to test software that is running on embedded systems. There are two major differences between TOG and this work: 1. testresult-evaluation and specification-coverage for software executed on embedded systems. Tabular Expressions and the tools provided by Ashling Microsystems Ltd. It supports Integer-. Quantifiers and nested tables are not supported. either the specification or the implementation of the function are faulty. All those functions are intended to be realized in separate applications in the new TTS.and Boolean-operations. are combined in this work to facilitate automatic testing. the tool does not offer functions for creating or printing Tabular Expressions. The tool supports only 2-dimensional Normal. the function is implemented according to its specification.

Chapter 3: Conceptual Design explains the conceptual design of the tool that is implemented in this work. Appendix F: File formats specifies the format of each file type that is imported or generated by the tool. TOG parses the tablecell-expressions that are contained in Tabular Expressions. Appendix A: Term definitions defines the meaning of some terms that are used in a special sense in this thesis. 5 .5 Outline Chapter 2: Tabular Expressions describes the basic notation of Tabular Expressions and how they are used in this work. Appendix B: Constants describes the constants of the tool that may be adapted by users to change the behavior of the tool. and Appendix G: Trial application data contains the files that are used for the trial application of the tool. This work uses the external Computer Algebra System (CAS) Yacas to avoid having to write yet another parser and code-generator. Appendix D: Uses Relation depicts which methods depend on the correctness of which classes. which is described in Chapter 5: Trial application. Chapter 6: Conclusion draws some conclusions and suggests areas for future work. Wetzel March 9. 2004 2. Appendix C: LOC shows how the implemented code is distributed among packages and classes. Appendix E: GUI lists the GUI-elements of the tool and the preconditions of the operations that are associated with individual elements. Chapter 5: Trial application applies the tool to the test of a small example function. The details of its implementation are described in Chapter 4: Implementation. In order to be able to generate C-Code from Tabular Expressions.Chapter 1: Introduction Diploma thesis M. 1.

including software for nuclear power plants and avionics [DP91]. 2.2 Basic definitions of Tabular Expressions The following basic definitions of the syntax and semantics of Tabular Expressions are based on [Par92]. It starts with basic definitions of Tabular Expressions. Tabular Expressions have been successfully employed as a formal documentation method in numerous industrial software projects. followed by an example of a small Tabular Expression and a short introduction explaining when and how Tabular Expressions can be used in a software project.1 Tabular Expression background Tabular Expressions have been invented by Parnas et al. domain and range of an expression denoting a function can be clearly separated. 2. [KH78]. These parts are subsequently put into table cells of different dimensions. The last part of the chapter describes in detail which Tabular Expressions are supported by this work and what they are used for. designers. 6 . domain experts and maintenance staff. which can be used to avoid unnecessary repetitions.Chapter 2 Tabular Expressions This chapter describes how Tabular Expressions are utilized in this work. as a method to precisely document the intended behavior of software in a way that can be read and understood by programmers. This is based on the fact that Tabular Expressions reduce the complexity of expressions by splitting a one-dimensional expression into separate parts. [Abr97] and [Pet95]. Furthermore. A Tabular Expression is a multi-dimensional expression that is easier to read and understand than the more traditional one-dimensional scalar expressions.

and the result of T.3 Raw Table Skeleton The structure of a Tabular Expression can be described independently from the contents of its table cells. The execution of a program is a sequence of states of the machine.Chapter 2: Tabular Expressions Diploma thesis M. xi is used to denote this value instead of xi and xi . such that R ⊆ X × Y . If the sequence is finite. Maingrid cells are cells that are part of the Maingrid. xi and xi are called before. Y = Y1 × . final state) where final state is a correct stopping state for an execution starting at initial state. × Ym . A binary relation R is a set of ordered pairs. .2 Initial and final states A digital computer can be considered as a finite state machine (FSM).and after-values of xi . • The set of values that appears as the second element of a binary relation R is called its range. 2. while the value of xi in the final state of the execution of P is xi . .2.. 2.e. i. 7 .2.1 Relations A relation is a set of tuples.y). is called a function. X = X1 × . X and Y may be Cartesian products of different sets. If the value of a program variable remains constant during the entire execution. 2004 2. the relation has a unique pair (x. Wetzel March 9. Tabular Expressions contain sets of cells that are organized in multiple grids: • Headers are 1-dimensional grids • the Maingrid is a multi-dimensional grid • A Raw Table Skeleton is a collection of Headers and a Maingrid Table cells are cells that are either part of any Header or of the Maingrid. acceptable executions can be described using a binary relation S.2. × Xn . A binary relation with the additional property that for each element x in its domain. Header cells are cells that are part of any Header. the value of xi in the initial state of the execution of P is xi . S contains all pairs (initial state. with the first state being called the initial or starting state [Par94]. . the execution is a terminating execution and the last state is called the final or stopping state. A function F ⊆ X × Y is often denoted F : X → Y . A testcase T has been executed successfully only if S contains a pair consisting of the initial state as defined by T. The values of program variables in the different states of an execution are denoted as follows: if a program variable xi is part of the data structure of a program P. If only starting and stopping states are of interest and intermediate states are not restricted by a specification. . • The set of values that appears as the first element of a binary relation R is called its domain. The latter notation emphasizes the input-output nature of the mapping.

Hi = {hi j |j ∈ IS }. j = 0 . the semantics of each supported Tabular Expression type is described in Chapter 2. Because of this. . k 1 = 2 and k 2 = 3: h1 1 1 h2 H1 h2 h2 h2 1 2 3 g1.2 g2. . k } being the Index set of Hi • A Maingrid G is an indexed set of cells. table relation rules and a compose operation to describe the semantics of different types of Tabular Expressions in a coherent fashion. .3 H2 G Table 2. . Wetzel March 9.8: Interpretation of Tabular Expressions separately. . While the increased generality offered by those definitions could not be used in this work. H n . n. . 2004 In the following formal definitions. × IS n } being the Index set of G • A Raw Table Skeleton is a tuple T = (H 1 . with IS0 = {IS 1 × . . k i is the size of dimension i and ISj .1 g1. G= {gα |α ∈ IS 0 }. . . n is the number of dimensions a table has. a Tabular Expression might be used to specify a function that has the following properties: • its name is IntegerFunction1 • it has two Floating-point parameters param1 and param2 and returns a Floating-pointvalue which depends only on the parameter values: 8 .1 g2.Chapter 2: Tabular Expressions Diploma thesis M. G) The following table illustrates these definitions for a table with n = 2. This work supports only three types of Tabular Expressions.3 Example of a Tabular Expression For example. . table predicate rules. with IS = {1.2. and each of them has to be interpreted in a distinct way. using them would make creating and processing Tabular Expressions more complex. 2. .5.4 Semantics of Tabular Expressions [Abr97] defines a Cell Connection Graph (CCG). .3 g2. are index sets: j j i • A Header Hi is an indexed set of cells.2 g1.1: Raw Table Skeleton 2.

Chapter 2: Tabular Expressions Diploma thesis M. the return value is param1 ∗ param2 – if param1 is greater than or equal to const1 and param2 is not negative. the return value is −1 – if param1 is greater than or equal to const1 and param2 is negative. or larger code pieces like modules or even whole systems. Tabular Expressions can be created with or without the desired properties already written down in a structured form. There are usually many ways to express the desired properties with Tabular Expressions. the return value is param1 / param2 These properties can easily be translated into Condition-Action-pairs. They can even be put directly into a Tabular Expression. containing the smallest amount of redundant terms or having the most compact form.g. In both cases. it is easy to see if the desired behavior has already been specified for all input-value-combinations or not. 2004 – if param1 is less than a predefined constant const1. there is usually one that is particularly wellsuited for a given function regarding a desired quality.g. dimensionsizes and table-cellexpressions or • arranging table-cell-expressions in different ways. Tabular Expressions can be used to specify functions. Although many correct variations may exist. Wetzel March 9.2: NormalIntegerTable1 This table is a Normal function table with 2 dimensions. each of them having 2 as dimensionsize. • using Tabular Expressions with different dimensions. 9 . by assigning each distinct return value expression to one or more Maingrid-cells and distributing the conditional expressions into Header-cells in such a way that each combination of conditional expressions leads to the correct value being returned: IntegerFunction1 = param1 < const1 param1 >= const1 param2 < 0 −1 param1 ∗ param2 param2 >= 0 −1 param1/param2 Table 2. e. Possible variations include: • using different types of Tabular Expressions. e.

This work focuses on the application of Tabular Expressions during the test of software that is being developed for embedded systems. 10 . 2.Chapter 2: Tabular Expressions Diploma thesis M. a report can not be used as a complete function specification anymore. Parnas et al.1 Use of Tabular Expressions The syntax of Tabular Expressions—their shape and composition—is used together with two different semantics for two distinct purposes in this work: • Formal specification of a function: in this case. invented a method that employs Tabular Expressions during inspections in all project phases [PW95]. Wetzel March 9.5.5 Tabular Expressions in this work This section describes in detail the syntax and semantics of the Tabular Expressions that are supported by this work. 2004 2. Reports use the syntax of Tabular Expressions. because the information contained in some table cells expressions has been replaced by report statistics. To match the limited scope of this work. However.4 Applications of Tabular Expressions in projects Tabular Expressions can be used for several tasks and in almost all phases of a project. a Tabular Expression specifies the outwardly visible behavior of one C-function • Report: in this case. 2. a Tabular Expression contains either: – the specification-coverage of a set of raw or executed testcases – or the specification-coverage and testresult-evaluation of a set of executed testcases with regard to a formal specification. [DP85] describes how and when they can be applied: Project phase Specification Implementation Test Maintenance Task check if all necessary cases have been specified check if all specified cases have been implemented automatic evaluation of test results. because it is convenient and leads to an easier understanding. the contents of some table cells are replaced by report statistics. measurement of test quality [Pet95] precise documentation of intended behavior Additionally. if the formal specification they are based upon is at least partly displayed together with the report statistics. some of the definitions in [Par92] and earlier papers of Parnas are used in a constrained form.

5. global variables.5. All Tabular Expressions must contain at least the following information: • name and type of the specified function • type of the table • number of dimensions the table has • size of each dimension • Inverted tables only: number of the dimension whose Header is the Valueheader (see Chapter 2.5. type and order of the parameters of the specified function • name and type of the global variables that are used for input by the specified function • name and type of the global variables that are used for output by the specified function • name. they must be defined in the Tabular Expression. constants or auxiliary functions.Chapter 2: Tabular Expressions Diploma thesis M. Wetzel March 9. Yacas • Specifications: textual remarks If the specified function uses any parameters. 11 . text remarks containing the number of successfull testcases and the number of failed testcases (testresult-evaluation-reports only) Tabular Expressions may additionally contain the following information: • name. 2004 2. their syntax must be compatible with the Computer Algebra Systen used.2 Definition of Tabular Expressions Tabular Expressions consist of mandatory and optional parts in this work (see Appendix F: File formats for a detailed description of Tabular-Expression-files). i.e. However. which is the reason they are labeled as optional and not as mandatory information. Tabular Expressions do not necessarily have to use any of these. type and value of the constants that are used by the specified function • function definitions of the auxiliary functions that are used in table-cell-expressions.8.2: Inverted function tables) • Vector tables only: number of the dimension whose Header is the Vectorheader (see Chapter 2.8.3: Mixed Vector tables) • one Header for every dimension containing exactly as many table-cell-expressions as the size of this dimension is • one Maingrid containing exactly as many table-cell-expressions as the sizes of all dimensions multiplied with each other • Reports only: textual remarks containing the number of overall testcases and the number of unmatched testcases.

6 GHz. 10 secs. 2004 2. 45 secs and generating a testresult-evaluation-report for 2 testcases takes approx. • Inverted function tables (called Inverted tables in this work) • and mixed Vector tables (called Vector tables in this work). displaying it takes approx.3: Mixed Vector tables). Function relation tables. bigger tables take longer to be imported. Wetzel March 9. Normal and Inverted tables must be used to specify a function that returns either an Integeror a Floating-Point-value. No upper limits for the sizes of the different dimensions are enforced by the tool. displayed and processed by the tool. The first dimension is the number of rows a table has.Chapter 2: Tabular Expressions Diploma thesis M.5.3 Dimensions Only 2-dimensional Tabular Expressions are supported in this work.5. While the basic definitions cover any number of dimensions. that is not of type void. because those are the types most commonly used in formal specifications of software. importing a 50*50 formal specification takes approx. Both Headers of Normal tables contain the same type of cells.5. 2. while Vector tables have one normal Header and one special header called Vectorheader (see Chapter 2. The second dimension is the number of columns a table has. 4 secs. Characteristic predicate tables and Generalized decision tables—are of minor importance for software specifications and were left out on purpose to allow the work to be completed in 6 months.8.4 Types of Tabular Expressions The scope of this work was limited to support only the following 3 of the 10 types of Tabular Expressions that are described in [Par92]: • Normal function tables (called Normal tables in this work). visualizing Tabular Expressions with more than 2 dimensions is beyond the scope of this work. Additionally. The time needed for each action depends on the speed of the computer used for executing the tool: on a Pentium-4 Mobile with 1. All tables must have 2 Headers—one for every dimension—and one Maingrid. The size of either dimension must be an Integer-value greater than or equal to one. However. Predicate expression tables.8.2: Inverted function tables). Vector tables may be used to specify either void or non-void-functions. 12 .5. The other 5 types of Tabular Expressions that are described in [Par92]—Normal relation tables.e. mixed Vector tables are a general type whose definition includes 2 other specialized types—Vector function tables and Vector relation tables—bringing the count of supported types to 5 of 10. i. Inverted tables have one normal Header and one special header called Valueheader (see Chapter 2.

13 . Wetzel March 9. 2004 2.5. • only the 7-Bit-ASCII-characters [A-Za-z] are valid letters that may be used in identifiers • identifiers must begin with a letter • identifiers must be separated from each other by at least one character that is not allowed to appear in identifiers.5.5. if the function type is not void • parameters • constants • global variables: if and only if a global variable is used for both input and output. The same is true for maximum and minimum FloatingPoint-values.5. The mathematical expressions in table cells are called table-cell-expressions. a leading apostrophe must be added to reference the input-value and a trailing apostrophe must be added to reference the output-value The following restrictions apply to identifiers: • identifiers must be alphanumeric strings between 1 and 30 characters in length. function names may not be longer than 29 characters • the underscore is not allowed as part of identifiers.decimalplaces 2.1 Values The variable-types C-files and generated PathFinder-Groupfiles use for Integer-values (see Chapter 4.5. or by numbers that use the following syntax: [−]number.1: Storing variable values) determine the maximum length of Integer-values and whether they are signed or unsigned. Floating-Point-values may be either represented by fractions.4.2 Identifiers The following elements of the specified C-function may be used as identifiers: • the function name. but may appear in expressions • identifiers are case-sensitive The values referenced by identifiers may be either Integer-values or Floating-Point-values. however. 2.5 Table-cell-expressions This section defines which character-combinations are valid contents of table cells.Chapter 2: Tabular Expressions Diploma thesis M.

>=. y ˆ2 = y × y expressions inside of parentheses must be valid expressions All arithmetic operators can be used for both Integer.and Floating-Point-values. =. e. ∗. e. Not may be used together with any other Boolean operator. Wetzel March 9.5.g. ! = Semantics standard semantics The predicates can be used to compare Integer.and Floating-Point-values. Not Or Semantics standard semantics Non-exclusive OR Boolean operators are Case-sensitive.5. 2. the following expressions are valid expressions: • 5 < 5.g. =>.1 is T rue • 5 ! = 5.Chapter 2: Tabular Expressions Diploma thesis M. e.5.g. 2004 2. −.5.5.3 Arithmetic Operators The following arithmetic operators are supported: Operator +.4 Predicates The following predicates are supported: Predicate <. the following expressions are valid expressions: • (1 = 1)And N ot(1 = 2) is T rue • (1 ! = 1)Or N ot(1 = 1) is F alse 14 .5 Boolean operators The following boolean operators are supported: Operator And. >. the following expression is not a valid expression: • 1 < 3 < 5 is undefined 2.5.0 is F alse Multiple predicates must be separated by Boolean operators. / ˆ () Semantics standard semantics followed by exponent.

Chapter 2: Tabular Expressions Diploma thesis M. This section describes the syntax of table-cell-expressions for each of these types. The following characters must not be used in table-cell-expressions: • the latin small letter sharp s • the percent sign • the underscore • other whitespaces than spaces and tabs 2. 2004 2.1 Guard-cells Guard-cells contain predicate expressions that evaluate to T rue or F alse when a given set of values is used for the identifiers in the expression. Examples of valid table-cell-expressions for Value-cells are: • assignment to an Integer-variable or -function: 5 ∗ 4 + 21 • assignment to a Floating-Point-variable or -function: (27. Value-cells and Vectorheader-cells.7. only the 7-Bit-ASCII-characters used in values.5.6 Forbidden characters Apart from spaces and tabs. e. Wetzel March 9. The type of the numerical evaluation result must be compatible with the variable or function it is being assigned to.g.5.5.8765) − 24 15 . 2.7. Integer-values may be assigned to Floating-Point-variables. but not vice versa.2 Value-cells Value-cells contain expressions that evaluate to numerical values when a given set of values is used for the identifiers in the expression.6/4.5. identifiers.7 Distinct types of table cells Only three distinct types of table cells exist in all the Headers and Maingrids of the three supported table types: Guard-cells. Examples of valid table-cell-expressions for Guard-cells are: • input1 < 5 • (input1 ! =const1)And N ot(input2= −1) • T rue • F alse 2. predicates and operators may be safely used in table-cell-expressions.

g. The identifier may be followed by an equation sign or a vertical bar. the semantics is the same as if the identifier would be followed by an equation sign. Instead.5.5.5. A testcase defines a set of input-values for all parameters and global variables that are used by the function. or the name of the specified function (if it is not of type void).or a Floating-Point-value and do not change the values of global variables. 2004 2. it is checked which Header-cell evaluates to T rue for the inputvalues. as they are defined by this testcase: – if the table is complete and proper. they contain one identifier of a global variable that is used for output by the specified function each (with a trailing apostrophe if the global variable is used for both input and output). this testcase is counted as ’unmatched’ testcase 16 .3 Vectorheader-cells Table-cell-expressions of cells in the special Vectorheader of Vector tables do not evaluate to any value. e. 2. They have the following structure: • Header-cells must be Guard-cells • Maingrid-cells must be Value-cells Informally.e. i.8 Interpretation of Tabular Expressions This section describes how each of the supported table types is interpreted by the tool for a single testcase. exactly one Header-cell of either dimension evaluates to T rue – if it is not complete and there is a dimension for which no Header-cell evaluates to T rue.7. Examples of valid expressions for Vectorheader-cells are: • globalV ariableIdentif ier = : if the global variable globalVariableIdentifier is used only for output • globalV ariableIdentif ier : if the global variable globalVariableIdentifier is used for both input and output • f unctionN ame | : if the function is not of type void 2. For a set of testcases. they are interpreted as follows: • for both dimensions.1 Normal function tables Normal function tables are used to specify C-functions that return either an Integer. use global variables only for input and not for output. The values of constants must be defined in the specification itself. if neither an equation sign nor a vertical bar occurs in the cell. Wetzel March 9. The equation sign is the default.Chapter 2: Tabular Expressions Diploma thesis M. all steps have to be repeated for every testcase.8.

Inverted tables have the following structure: • Header-cells of the special Valueheader must be Value-cells • Header-cells of the other header must be Guard-cells • Maingrid-cells must be Guard-cells 17 . the number of failed testcases that match this Maingrid-cell is increased by one • the report statistics are written into the Maingrid-cells For an example of a Normal table.5. functions that would need a large Normal table to be specified properly can often be specified with a smaller Inverted table and vice versa. i. 2004 – if it is not proper and more than one Header-cell evaluates to T rue for a single dimension. Inverted tables are preferable for the specification of functions that have few distinct return value expressions. Wetzel March 9.8.Chapter 2: Tabular Expressions Diploma thesis M. which would have many equal table-cell-expressions if a Normal table would be used instead. as they are defined by this testcase: – if the function return value is equal to this value. In this case. and vice versa [ZS98]. use global variables only for input and not for output. An Inverted table can be automatically transformed into a Normal table that specifies the same function. Inverted tables make better use of the large Maingrid. However.2 Inverted function tables Inverted function tables share many attributes with Normal function tables and are used to specify the same type of functions: C-functions that return either an Integer. one of those cells may be arbitrarily selected • the Header-cells of both dimensions that evaluated to T rue specify one Maingrid-cell: – the Header-cell that evaluated to T rue in the Header of the first dimension defines the row of the sought-after Maingrid-cell – the Header-cell that evaluated to T rue in the Header of the second dimension defines the column of the sought-after Maingrid-cell • the number of testcases that match this Maingrid-cell is increased by one • (if the test result of an executed testcase has to be evaluated) the value the function returned during test execution is compared with the value the specified Maingrid-cell has for the set of input-values.or a FloatingPoint-value and do not change the values of global variables.e. the number of successful testcases that match this Maingrid-cell is increased by one – if the function return value is not equal to this value.2: NormalIntegerTable1. see Table 2. but many complex conditions. Generally speaking. 2.

otherwise. the row of the Maingridcell that evaluated to T rue specifies the sought-after Valueheader-cell • the number of testcases that match this Valueheader-cell is increased by one • (if the test result of an executed testcase has to be evaluated) the value the function returned during test execution is compared with the value the specified Valueheader-cell has for the set of input-values. Wetzel March 9. it is checked which Header-cell evaluates to T rue for the input-values. it defines a Maingridcolumn.Chapter 2: Tabular Expressions Diploma thesis M.3: InvertedIntegerTable1 is an Inverted table that specifies the same function as the Normal table Table 2. These Maingrid-cells are now evaluated and checked the same way as the Header containing Guard-cells was in the first step • the Maingrid-cell that evaluated to T rue specifies one cell of the Valueheader: – if the Header of the second dimension is the Valueheader. one of them may be arbitrarily selected • if the Header of the first dimension contains Guard-cells.3: InvertedIntegerTable1 18 . the number of failed testcases that match this Valueheader-cell is increased by one • the report statistics are written into the Valueheader-cells The following table Table 2. as they are defined by this testcase: – if the function return value is equal to this value. the Header-cell that evaluated to T rue in the first step defines a Maingrid-row.2: NormalIntegerTable1. which was used as an example above: IntegerFunction1 = param1 < const1 param1 >= const1 −1 True False param1 ∗ param2 False param2 < 0 param1/param2 False param2 >= 0 Table 2. exactly one Header-cell evaluates to T rue – if it is not complete and no Header-cell evaluates to T rue. as they are defined by this testcase: – if the table is complete and proper. the column of the Maingrid-cell that evaluated to T rue specifies the sought-after Valueheader-cell – if the Header of the first dimension is the Valueheader. the number of successful testcases that match this Valueheader-cell is increased by one – if the function return value is not equal to this value. they are interpreted as follows: • for the Header containing Guard-cells. this testcase is counted as ’unmatched’ testcase – if it is not proper and more than one Header-cell evaluates to T rue. 2004 Informally.

otherwise they must be Value-cells Informally. Wetzel March 9. as they are defined by this testcase: – if the table is complete and proper. this testcase is counted as ’unmatched’ testcase 19 . and using output-values of global variables in other cells might implicitly make one specific order correct and others incorrect. However. it is checked which Header-cell evaluates to T rue for the input-values. exactly one Header-cell evaluates to T rue – if it is not complete and no Header-cell evaluates to T rue. 2004 At the cost of one redundant term. otherwise each of its cells is associated with a column of Maingrid-cells • Header-cells of the other header must be Guard-cells • Maingrid-cells must be Guard-cells if the associated Vectorheader-cell contains a vertical bar. references to the output-values of global variables may only be used in one Vectorheader-cell each (and in the Maingrid-cells that are associated with it.4: InvertedIntegerTable2 This example shows that multiple transformations can be performed on Tabular Expressions without changing the specification properties.5. This is because a Tabular Expression does not specify the order in which values are assigned to variables. Other than Normal or Inverted tables.8.3: InvertedIntegerTable1 can be compacted (and mirrored). If this Header is the Header of the first dimension. Vector tables have the following structure: • Header-cells of the special Vectorheader must be Vectorheader-cells. and still specify the same function in Table 2. they can be used to specify C-functions that change the values of global variables.e. that use global variables both for input and output or only for output. if the Vectorheader-cell contains a vertical bar). 2.4: InvertedIntegerTable2: IntegerFunction1 = −1 param1 ∗ param2 param1/param2 True param1 < const1 (param1 >= const1)And(param2 < 0) (param1 >= const1)And(param2 >= 0) Table 2. they are interpreted as follows: • for the Header containing Guard-cells. i. each of its cells is associated with a row of Maingridcells.Chapter 2: Tabular Expressions Diploma thesis M. Table 2.3 Mixed Vector tables Vector tables can specify either C-functions of type void or C-functions that return a numerical value (Integer or Floating-Point).

otherwise. Wetzel March 9. one of them may be arbitrarily selected • the number of testcases that match the Header-cell that evaluated to T rue is increased by one • (if the test result of an executed testcase has to be evaluated) if the Header of the first dimension contains Guard-cells. the number of failed testcases that match this Header-cell is increased by one • the report statistics are written into the Header containing Guard-cells The following Vector table Table 2. otherwise. added to an auxiliary function aux1 that has param1 as parameter 20 . the cells of the Maingrid-row defined by the Header-cell that evaluated to T rue in the Header of the first dimension are evaluated. the cells of the Maingrid-column defined by the Header-cell that evaluated to T rue in the Header of the second dimension are evaluated: – if the Vectorheader-cell associated with this Maingrid-cell contains a vertical bar. as they are defined by this testcase If one or the other condition is true for every single Maingrid-cell in this row or column. and an additional global Floating-Point-variable output1 for output • the return value and the values of both output-variables depend on the values of the parameter and the input-variable: – if param1 is equal to the input-value of inputoutput1: ∗ the output-value of inputoutput1 is not changed.5: VectorFloatTable1 specifies a function that has the following properties: • its name is FloatFunction1 • it has one Integer parameter param1 and returns a Floating-point-value • it uses one global Integer-variable inputoutput1 for both input and output. 2004 – if it is not proper and more than one Header-cell evaluates to T rue.e. the number of successful testcases that match the Header-cell that evaluated to T rue in the Header containing Guard-cells is increased by one. it is checked whether this Maingrid-cell evaluates to T rue – otherwise it is checked if the output-value of the variable or function in the associated Vectorheader-cell is equal to the value this Maingrid-cell has for the set of input-values.Chapter 2: Tabular Expressions Diploma thesis M. i. is equal to the inputvalue of inputoutput1 ∗ the output-value of output1 is −1 ∗ the return value is param1 multiplied with an Integer-constant const1 – if the parameter param1 is not equal to the input-value of inputoutput1: ∗ the output-value of inputoutput1 must be greater than param1 ∗ the output-value of output1 is param1 ∗ the return value is the input-value of inputoutput1.

5: VectorFloatTable1 The equation sign after output1 in the second cell of the first header could be omitted.Chapter 2: Tabular Expressions FloatFunction1 = inputoutput1’ | output1 = FloatFunction1 Diploma thesis M. and an equation sign could be included after FloatFunction1 in the third cell of the first header. 21 . Wetzel param1 = ’inputoutput1 March 9. 2004 param1 ! = ’inputoutput1 inputoutput1’ = ’inputoutput1 −1 param1 ∗ const1 inputoutput1’ > param1 param1 ’inputoutput1 + aux1(param1) Table 2. without changing the semantics of the table.

1 Problem description As described in Chapter 1. the desired output data and the user requirements that have to be met.2: Purpose. to the documentation of software for embedded systems. a synopsis of the solution chosen to be implemented is given and illustrated.Chapter 3 Conceptual Design This chapter describes the conceptual design of the tool. Those are described in Chapter 4: Implementation. The prototype that had to be implemented during the conceptual design phase. is shortly described. This chapter does not include any implementation details. Raw input data that can be used by this tool includes: • Formal specifications using Tabular Expressions and specifying one C-function each • C-files containing the specified functions • Sets of raw testcases defining input-values for the specified functions The output generated by the tool has to be a report that uses Tabular Expressions and contains the following information: • for report type Specification-coverage: 22 . This is achieved by combining those methods with embedded systems tools that are developed by Ashling Microsystems Ltd. the purpose of this work is to apply the formalspecification-methods invented by Parnas et al. into a new tool. It starts with a description of the problem to be solved by listing the existing raw data. At the end of the chapter. 3. to make sure that the selected approach could be realized and the solution would meet all requirements. This is followed by an in-depth explanation of the decisions made in the conceptual design phase.

i.Chapter 3: Conceptual Design Diploma thesis M. their output-values are equal to the ones specified for this case ∗ how many testcases match this case unsuccessfully. ! =. which is specified by a formal specification that uses a Tabular Expression. <.and Floating-Point-variables are used for input and output – no additional imports apart from the C standard library are needed – only commands suitable for the target embedded system are used 23 . Wetzel March 9.and Floating-Point-arithmetic have to be supported – arrays and complex data types do not need to be supported – the following basic operators have to be supported: +. /. i.e. (. 2004 – for each case: how many testcases match this case. ∗. inverted function and mixed vector – the size of the table and the length of table-cell-expressions should not be limited – neither quantifiers nor nested tables need to be supported – Integer. satisfies the following requirements regarding the formal specification: – name and type of the function match – name. =>. ) – user-defined functions must be supported • the tool has to check if a C-function. type and order of parameters match – name.e. =. >. their output-values are not equal to the ones specified for this case – how many of the testcases used to generate the report match a case successfully – how many of the testcases used to generate the report match a case unsuccessfully The following user requirements must be met by the solution implemented in this thesis: • formal specifications have to use a 2-dimensional Tabular Expression with the following properties each: – possible table-types are normal function. i. −. <=.e. this behavior is specified for their combination of input-values – how many testcases are used to generate the report – how many of those testcases do not match any specified case • for report type Testresult-evaluation: all information that is included in Specificationcoverage-reports plus – for each case: ∗ how many testcases match this case successfully. type and declaration of global variables and constants match • the tool does not have to check if the C-function satisfies the following requirements: – only Integer.

Wetzel March 9. Incomplete testcases have to be rejected • the tool does not have to check if a raw testcase matches any specified case • apart from generating a report. 7-Bit-ASCII is sufficient • all communication between the tool and other applications can take place using ASCIIfiles • the tool does not have to support network communication • the tool must run on workstations with a Windows-operating-system 24 . and not be integrated in a framework • the tool has to interface with the hardware-products of Ashling Microsystems Ltd. and increase their general usefulness by integrating them into a development process that uses Tabular Expressions as part of formal specifications • the tool should be a working prototype showing possible applications of the used methods in real-life projects • the tool must be able to test single C-functions • the tool must support interactive testing. the tool does not have to create formal specifications or raw-testcases-files • no real-time constraints are placed upon the execution of the tool • the tool does not have to support Unicode. batch-processing does not need to be supported • apart from manually created samples. A question mark may take the place of a value to allow the value to be entered during test execution. 2004 • the tool has to check if raw testcases define values for every input-value defined in the formal specification of the function they are used to test. the tool has to support the following functions: – display of an imported formal specification on the screen – display of a generated or imported report on the screen – writing of a generated report to disk • the following functions do not have to be supported by the tool: – creation of tables – checking the syntax or semantics of tables – modification of tables – printing of tables • the tool should be a standalone-system.Chapter 3: Conceptual Design Diploma thesis M.

The first possibility—Code generation—has been dismissed prior to the start of this thesis. • Evaluation of a parse tree: this method does not generate code. and returns the evaluation result. However.2.1 Parsing table-cell-expressions The first major decision that has to be made is whether it is necessary to parse the table-cellexpressions in a Tabular Expression or not. The time and effort needed to implement a parser do not depend on the current stage of the project. those functions already might have been designed and implemented and cannot benefit from the existence of a parser anymore. there is a chance that some user requirements cannot be met without parsing the table-cell-expressions. while fulfilling all user requirements. 2004 3. planning to implement a parser from the start allows designing other functions to benefit from the parsing results. because writing a parser that is capable of understanding the permitted syntax and splitting the tablecell-expressions into tokens requires a lot of time. However. For both specification-coverage and testresult-evaluation. because it already had been tried and had been found to require more time than was available in this thesis. the probability of having to write a parser has to be estimated. which has the variables and constants that are part of the table-cell-expression as parameters. There are at least three ways to evaluate table-cell-expressions: • Code generation: this is the solution implemented by [Pet95]. If implementing a parser is not intended but becomes necessary at the end of the project. syntax and semantics checks to be performed on table-cell-expressions.2 Conceptual design decisions This section describes the decisions made during the conceptual design phase of this thesis. and how they lead to a solution for the given problem that is able to generate the desired output from the given input. or unmodified—to an external Computer Algebra System (CAS) that is able to evaluate the table-cell-expressions and return the evaluation result.Chapter 3: Conceptual Design Diploma thesis M. To facilitate a well-founded decision. but uses the facilities of the programming language to evaluate the syntax tree that is the result of parsing a table-cell-expression. e. Wetzel March 9.g. The only critical function where it might be necessary to parse the table-cellexpressions to meet the user requirements is the evaluation of table-cell-expressions during the generation of a report. 25 . which could be spent for other functions if the parser was not needed. 3. The table-cell-expressions are parsed and one function is generated for each of them. tablecell-expressions must be evaluated to T rue or F alse or to a numerical value during the generation of a report. This has a major impact on the project. • Using an external calculator: this method passes the table-cell-expressions—either parsed and with a modified syntax.

and some testcases. 3. It demonstrates that it is possible to generate the desired report with all required information by using Yacas to evaluate the table-cell-expressions without having to parse them at any time. because checking if the CAS meets all the requirements would only have been possible after obtaining it. To make sure Yacas meets all the requirements. a prototype is built that includes a formal specification using a simple Tabular Expression. These are major disadvantages that can only be tolerated if there is almost no additional work necessary to interface with the CAS.2 Structure of formal specifications The decision not to parse the table-cell-expressions requires some other information to be included in a formal specification apart from the Tabular Expression itself.Chapter 3: Conceptual Design Diploma thesis M. rendering the CAS unusable. and is freely available for all major operating systems. including Windows and Linux. It supports 100% of the syntax described in Chapter 2. has a simple interface. all the disadvantages of using an external program for the evaluation would still apply: introducing additional interfaces and having to implement the syntax of the CAS. This might have led to buying an expensive program that could not be used for the intended purpose. Because of this result. 2004 This leaves the choice between the second and the third option. 26 . In addition.5. to make the types and names of the identifiers used in the table-cell-expressions known to the tool. as well as the risk of encountering critical bugs or wanting to extend the tool by a function not supported by the CAS. Using a CAS that requires the table-cell-expressions to be parsed and their syntax to be altered in order to be understood by the CAS is almost as much work as evaluating a syntax tree with the facilities of the programming language [vM03]. There are quite a few systems that meet most requirements. To be able to evaluate table-cell-expressions successfully. values from either a testcase or the formal specification or both must be assigned to those identifiers in Yacas prior to the evaluation. but apparently only one that meets all: the Open-Source-project YACAS (Yet Another Computer Algebra System). This raises the question if there is a CAS with the following properties: • 100% compatibility with the syntax used by the subset of table-cell-expressions supported by this tool • simple interface • support for batch-processing and communication via files • relatively bug-free • running on Windows-operating-systems • already obtained or freely available The last point has to be considered. the third possibility—using Yacas as an external CAS—is chosen and no parser for table-cell-expressions is implemented. Wetzel March 9. supports batch-processing and file-communication.5: Table-cell-expressions.2.

storing constant values in every testcase would be a poor design. In order to be able to add a textual description or an unique identification to a formal specification. when. it is necessary to extract it from the original C-file first. Creating useful testcases would require intimate knowledge of the structure and semantics of the whole program. The values of constants should be defined in the formal specification. since it would be known only at runtime if. This is even more the case for functions that are used in table-cell-expressions. 27 . have to be defined in the formal specification.3 C-function In order to be able to test the specified function on an embedded system. Apart from the definition of those identifiers. Using the entire original C-file would make testing the specified function under defined conditions difficult. the types of the identifiers have to be defined together with their names in the formal specification. in a syntax that can be understood by Yacas. the number of its dimensions.2. 2004 The following groups of identifiers can be part of a table-cell-expression: • the name of the specified function. of a Floating-Point-value to an Integervariable. This is necessary to enable Yacas to evaluate table-cellexpressions that use those Auxiliary functions.Chapter 3: Conceptual Design Diploma thesis M. 3. the type of the table. To prevent illegal assignments. a formal specification must contain one Tabular Expression that defines the intended behavior of the specified C-function. on the other hand. Auxiliary functions.g. e. because they can be evaluated correctly by Yacas using its own internal definitions. rendering automatic or semi-automatic testing impossible. Beside the Maingrid and the Headers of the Tabular Expression itself. which can be divided into two categories: • Predefined functions in Yacas: functions like ArcTan() that are defined in the Yacaslibraries • Auxiliary functions: User-defined functions that do not exist in Yacas Predefined functions do not have to be defined in either testcases or the formal specification. it should be possible to include textual remarks in a formal specification. the size of each dimension and the locations of any special headers must be defined. referencing its return value • parameters of the specified function • global variables that are used as input by the specified function • global variables that are used as output by the specified function • constants used by the specified function • names of other functions called by the specified function The values that have to be assigned to the identifiers of the first four groups can be taken from testcases. However. Wetzel March 9. and in which context the specified function is executed.

a software-tool developed by Ashling Microsystems Ltd. Instead. it must be possible to control the test execution to facilitate calling the specified function once for each testcase in a set of testcases. Since software running on embedded systems normally cannot read data from or write data to files on disk1 .Chapter 3: Conceptual Design Diploma thesis M. the extraction of the specified function and the generation of a suitable C-Test-Harness have to be accomplished by the tool itself. but using it would limit the application of the tool to this relatively small number of embedded systems. Several existing tools are capable of automatic generation and execution of test-harnesses for Unit. This file can be read by PathFinder. both tasks can be achieved without having to write a full C-parser. However. which is also responsible for writing the test results to an output-file on disk. its parameters and the global variables and constants it uses. it is possible to automatically generate a C-TestHarness that is capable of successfully executing the specified function which is embedded into it. Additionally.. because it encapsulates the properties of different embedded systems and offers a common interface for accessing all of them in a coherent fashion. Since only the specified function itself is extracted. Should any of the requirements that are needed for the automatic extraction and generation not be met by the specified function. Since the names and types of the specified function. the generated C-Test-Harness has to be executed on an embedded system using hardware developed by Ashling Microsystems Ltd. TBrun from LDRA [LDR]. AsIDE is an IDE that is developed by Ashling Microsystems Ltd. the specified function has to be extracted from the original Cfile and embedded into an individually generated C-Test-Harness. Since neither TBrun nor any other tool available fulfills all those requirements. during or after its own execution to run successfully • initialization required by the specified function is restricted to the assignment of proper values to the global variables it uses as input Only if all of those prerequisites are fulfilled. and has integrated compilers that can be used for this task. In addition to compiling the generated C-Test-Harness into object-code. the following conditions must be met: • the specified function does not need additional imports apart from the C standard library • the specified function does not need any other functions to be executed prior to. the testdata cannot be embedded into the C-Test-Harness. 2004 To facilitate automatic testing. and almost all of them support C.g. The generated C-Test-Harness has to be compiled into object-code that can be executed on the target embedded system. 28 . the IDE of AsIDE can be used for manual corrections of the generated C-Test-Harness. Wetzel March 9. the testdata must be known to the software controlling the test execution. that is capable of controlling the execution of software on embedded systems [Mic03]. PathFinder is the most effective way to interface with the hardware-products of Ashling Microsystems Ltd. e. 1 The Semi-Hosting-Call-feature available on some ARM embedded systems actually supports reading and writing of files on the harddisk of a workstation connected to the embedded system.or Function-testing. are all defined in the specification. AsIDE is also able to generate a file containing the symbolic information of the generated C-Test-Harness.

conditions. Neither can the C-Test-Harness write the test results to an output-file on disk. importing the raw testcases into the tool allows checking them for completeness and the assignment of proper values before a Groupfile is generated. at least not without having to import the formal specification first. Since the Macro-language supports both the import of values from a file and the execution of generated scripts. Both actions—assigning the proper inputvalues to program variables for each testcase and writing the test results to disk—have to be accomplished by PathFinder. Using the PathFinder-Macro-language allows the generation of a single Groupfile that is capable of handling all of the following tasks: • starting and controlling the execution of the generated C-Test-Harness on the target embedded system 29 . leaving only the choice between importing the input-values from a testcases-file during test execution or integrating them in a generated script. This could not be done if the testcases-file had to be imported by the Groupfile during test execution.3: C-function. PathFinder itself can be controlled by a Groupfile. the complete function for importing a raw-testcases-file would have to be rewritten in a low-level Macro-language if the input-values had to be imported by the Groupfile during test execution. either by the C-Test-Harness or PathFinder • file generation: the testcases are included in a generated file. 2004 3.2.g.4 Testcases The input-values specified in raw testcases have to be assigned to the appropriate program variables during test execution to test the specified function with the values defined in one particular testcase. While the syntax for assigning the input-values to program variables in a Groupfile can be easily generated by the tool with the testcases already imported. executed testcases include the test results as output-values. There are two different approaches how those input-values can be obtained: • direct import from the original raw-testcases-file: the original testcases-file is read parallel to the test. This output-file contains executed testcases: in addition to the input-values that are also part of raw testcases. either in the C-TestHarness or in a script that can be executed by PathFinder In all cases. the contents of a testcases-file cannot be read by a C-Test-Harness that is executed on an embedded system. e. loops. starting and stopping program execution and setting of breakpoints in software that is running on the embedded system. either option—importing the input-values from a testcases-file or including them in a generated Groupfile—is possible. the function for importing and processing a raw-testcases-file must be implemented by the tool in any case. Wetzel March 9. downloading code into an embedded system.Chapter 3: Conceptual Design Diploma thesis M. because the tool should be able to determine the specification-coverage of a set of raw testcases. This language supports most basic programming constructs—variables. However. Additionally. the test results have to be written to an output-file on disk by either the CTest-Harness or PathFinder. As shown above in Chapter 3. a script written in a proprietary Macrolanguage [Mic04].2. I/O—and additionally contains operators to execute most PathFinderfunctions.

splitting the tool into two parts has the following advantages: • separation of concerns for users: the first tool part is used for test preparation. the second for report generation. the Groupfile can be generated with commands to read it from the keyboard and assign the value entered by the user to the program variable instead of assigning a predefined value. are needed by both tool parts • concurrency errors: if both tool parts are executed at the same time. the test execution and the report generation. only the second part has to be executed • simplification of both parts: both parts contain less functions. configuration-files—might occur • confusion of users: it might confuse users that the tool has two separate parts which must be executed independently • less efficient: if both tool parts are always used together without any breaks between the generation of test files. the first part could be terminated at any time after the generation of the test files. if only the specification-coverage of a set of raw testcases is wanted.2. problems with shared ressources—e. 3. the test execution and the generation of a report—the question arises whether it might be better to design the tool with two separate tool parts. having to switch between tool parts is less efficient than being able to perform all tasks within a single application On the other hand.5 Tool parts The invocations of the external programs AsIDE and PathFinder are both asynchronous calls and divide the data flow of the tool into two distinct parts: • the first part imports input data and generates the files necessary to execute the tests • the second part imports the test results and generates the desired output data Since the second part does not have to be immediately executed after the first part—there may be any period of time between the generation of the test files.g.Chapter 3: Conceptual Design Diploma thesis M. Wetzel March 9. 2004 • assigning the correct input-values to the appropriate program variables for each testcase before the specified function is called • writing the test results of each testcase to an output-file on disk If an input-value has been entered during test execution. Splitting the tool into two parts has the following disadvantages: • duplicate functions: some functions. and the second part could be executed at any time to generate a report. like the import of a formal specification and a raw-testcases-file. allowing a less complex graphical user interface (GUI) and reducing code complexity by reducing the number of different states the tool can be in 30 . clearly separating the tasks of the two parts. With the functions distributed on the parts as described above.

This is because splitting the parts enforces the application of Software-Engineering principles. 3. in order to avoid code duplication. Testresult-evaluation. The prototype described in Chapter 3. Wetzel March 9.Chapter 3: Conceptual Design Diploma thesis M. The generated report contains either only the specification-coverage. or the specification-coverage and the testresult-evaluation of the entire set of testcases. The reason for this is that determining the specification-coverage of a set of testcases only requires input-values. Regardless of the type of the report and the type of the testcases-file.2.and output-values. testcases containing such placeholders can not be used to determine a specification-coverage and must be rejected when being imported into the second part. A specificationcoverage-report can only give the sum of both for each case. the data produced by the execution of the generated C-Test-Harness on a target embedded system under the control of the generated PathFinder-Groupfile. which both raw and executed testcases include. 2004 • independent execution: both parts can be executed independently whenever their individual functionality is wanted. the GUI is not overloaded with functions that are not needed at the moment • different behavior possible: the behavior of a function may differ between one tool part and the other The last point can be used to realize a different behavior for the import of raw testcases: while values may be substituted by placeholders to allow the value to be entered during test execution when testcases are imported into the first part. and the external CAS Yacas.6 Report generation A report can be generated from a formal specification in combination with either a rawtestcases-file containing only input-values. or an executed-testcases-file containing both inputand output-values. An executed-testcases-file can be used to generate either a specificationcoverage-report or a testresult-evaluation-report. If it is taken into consideration that a good design can place as much functionality as possible into classes that are used by both tool parts. requires both input. it only differentiates further between successful and failed testcases that cover one case. 31 . the first and most important disadvantage separate tool parts have—duplication of functions—might even be considered an advantage. on the other hand. This is done for every testcase.2. while a raw-testcases-file can only be used to generate a specification-coverage-report. like Information Hiding invented by Parnas. splitting the tool into two parts is the logical conclusion. a report is generated by having Yacas evaluate the table-cell-expressions of a Tabular Expression after assigning each identifier the input.1: Parsing table-cell-expressions is used to make sure that a report with the desired information can be generated using only the available input data. A testresult-evaluation-report always contains the specification-coverage as well. depending on its type.or output-value as it is defined by this testcase. With the advantages outweighing the other disadvantages.

Together with a formal specification of the tested function. or asynchronous. Since all communication between the different parts of the system takes place using files.3.1: Conceptual design diagram shows all interfaces between the tool and external programs. The writing of the Yacas-input-file. If only specification-coverage is needed. Each step begins with either the execution of a tool-function or the invocation of an external program. i.3. The generated C-Test-Harness is compiled into object-code using AsIDE. The executed-testcases-file written by PathFinder during test execution is read by the second part of the tool. The tool generates a PathFinder-Groupfile containing the imported testcases.2 Detailed description Figure 3. i.3 Conceptual design solution The previous ideas and deliberations led to the following conceptual design of the tool. which remained unchanged throughout the entire project. A formal specification. The object-code is loaded onto the target embedded system and executed using PathFinder and the generated Groupfile. 32 . At the end of each step. Invocations of external programs can either be synchronous. a C-implementation of the specified function and a set of raw testcases have to be supplied as input data for the first part of the tool. Either of them may read one or more files. every arrow is a symbol for one step consisting of write. the invocation of Yacas and the reading of the Yacasoutput-file in steps 9–11 are repeated once for every testcase in the imported testcases-file before the report is generated and displayed on the screen. no implementation of the specified function has to be supplied. any results generated during the step are usually written to a diskfile.e. raw testcases can be used instead of executed ones.1 Overview The tool is going to be used in the testing phase of the software development process. The details of its implementation are described in Chapter 4: Implementation. and a C-Test-Harness in which the specified function is embedded. the tool does not wait for the termination of the invoked program and control passes back immediately to the user. In this case.and read-operations on files. reports containing the specification-coverage and the testresult-evaluation of the testcases can be generated and saved to disk for later use. Where no invocation is mentioned. Wetzel March 9. The report-file is the output of the entire system and can subsequently be used by all people involved in a software project. the tool waits for the termination of the invoked program. 2004 3.Chapter 3: Conceptual Design Diploma thesis M. a function of the current part of the tool is being executed.e. 3. 3. The writing of the generated report to disk in the last step is optional because the user does not have to write a generated report to disk.

Manual creation of a file containing raw testcases that match the formal specification.1: Conceptual design diagram The arrows are labeled according to the following sequence of operations. using a text-editor. Manual creation of a formal-specification-file.Chapter 3: Conceptual Design Diploma thesis M. 2004 Figure 3. the testcases-file and the C-function. using a text-editor or Integrated Development Environment (IDE) 3. which is expected to be the normal sequence when using the tool: 1. extraction of the specified function from the Cfunction. using a text-editor 2. Wetzel March 9. Manual invocation of the first part of the tool: import of the formal-specification-file. Manual implementation of a C-function that matches the formal specification. generation of a PathFinder-Groupfile that includes both the imported testcases. or external automatic generation of such a file 4. and operations for writing the results of executed testcases to a disk-file during test execution 33 .

Instead. Asynchronous invocation of PathFinder from either AsIDE or the tool: loading of the PathFinder-project-file that was built in the last step and running of the generated Groupfile. 2004 5. and does not use the first part of the tool at all. but may be used in an alternative sequence of operations instead.or specification-coverage-report and display of the generated report on the screen. Synchronous invocation of the external CAS Yacas: import of the file containing the table-cell-expressions and their evaluation. generation of a testresult-evaluation. Asynchronous invocation of AsIDE: manual correction of the generated C-Test-Harness if necessary. optionally writing of this report to a disk-file Two file descriptions in the figure are assigned to two arrows each. Synchronous invocation of the SymFinder-utility that is a part of AsIDE: build of a PathFinder-project-file from the target-specific object-code 8. 34 . Manual invocation of the second part of the tool: import of the formal specification and either the output-file containing executed testcases from the last step or the file containing raw testcases. This alternative sequence does not need a C-function to be already implemented. all input-values are written to an output-file on disk before calling the specified function. This alternative sequence consists of the steps ’1’. Generation of a C-Test-Harness that consists of the specified function and a main method calling the specified function inside a loop that is executed once for each testcase 6. for each executed testcase. ’10’ and ’11’ of the normal sequence described above. and into the second part of the tool at the beginning of step ’9’. The formal specification is usually the first thing being created: it is imported into the first part of the tool at the beginning of step ’4’. Wetzel March 9. Reading of the output-file written by Yacas. ’9’. and no executed-testcases-file is used. compilation and build of the C-Test-Harness to a platform-dependent object-file using a target-specific C-Compiler that is part of AsIDE 7. and all output-values are written to this output-file after calling the specified function 9. only the second part of the tool is used to import the formal specification and the raw-testcases-file and to determine the specificationcoverage.Chapter 3: Conceptual Design Diploma thesis M. writing of the table-cell-expressions that have to be evaluated by Yacas to a disk-file 10. The file containing raw testcases is also imported into the first part of the tool at the beginning of step ’4’. ’3’. writing of the evaluation results into an output-file on disk 11. but the formal-specification-file and the raw-testcases-file are imported into the second part of the tool only.

Yacas is free software licensed under the GNU Public License (GPL) and can be downloaded from http://sourceforge. Since almost 3/4 of the implemented code are about importing and generating files1 .4.1 Prerequisites The system is intended to operate on workstations running a 32-bit version of the Windowsoperating-system.0. 1 Of the approx. The display must at least support a resolution of 640 * 480 pixels with 256 colors. The last part of the chapter explains in detail further implementation features.2 02 or higher to run. a keyboard and a graphical VGA-color display attached. 4. 10800 lines of code the tool has (see Appendix C: LOC). The workstation must have a mouse.Chapter 4 Implementation This chapter describes the implementation of the solution depicted in Chapter 3: Conceptual Design. and 17% are contained in classes involved in handling data that is imported from files. The tool needs an installed Java Runtime Environment version 1. It is neither distributed with the tool nor is it embedded or linked into it. The tool must have the rights to execute Yacas with an input-file as parameter. The tool needs an installed Yacas version 1. The Java Virtual Machine must be 100% compatible with the reference implementation from Sun Microsystems Inc. The first part of the chapter gives some basic background information about the implementation. and the tool must have the rights to read and write files to the harddisk. followed by a description of the tool design. the main part of this chapter describes the classes that implement these file operations. 57% are contained in classes whose purpose is the reading and writing of files. which the users of the system can use to interact with the tool. and to read output-files generated by Yacas.55 or higher to generate reports. A harddisk with at least 500 KByte of free space for the program-files of the tool has to be available. 35 .net/projects/yacas.

2. it generates reports containing either only the specification-coverage. The classes that are shared by both tool parts are structured as follows: Package files dataStructures common exceptions Main content Classes for files that are imported or generated by the tool Classes for data structures holding data that is imported from files Classes containing the GUI. methods. the tool is divided into two parts: • the first part is called TestPreparation. 4.Chapter 4: Implementation Diploma thesis M. PathFinder can be obtained from Ashling Microsystems Ltd. This package has the following properties: 36 . As explained in Chapter 3. and to read and change the values of program variables during test execution. One example of such an application is AsIDE from Ashling Microsystems Ltd. or the specification-coverage and the testresult-evaluation of sets of imported testcases. both only need to be compatible with PathFinder to allow the tool to use them. all names of Java-packages. 2004 The tool needs an installed PathFinder version 1. and is the only class in a package that has the same name as the class. except TestPreparation and ReportGeneration. and the most sophisticated hierarchy.12 or higher that supports the manual input of Double-values during test execution. Wetzel March 9. It has the largest number of classes.2 Tool Design The tool is implemented in Java using the Open-Source-IDE Eclipse [Ecl]. The tool works together with any application capable of transforming the generated CTest-Harness into object code executable on the target embedded system and readable by PathFinder.5: Tool parts.1 Package files The files-package contains classes that are involved in the generation and import of files. In this thesis. which contain more than 50% of all code the tool has. With PathFinder hiding the implementation details of the target embedded system and the debug hardware. constants and data used by both parts Classes for extended exceptions that are used by the tool 4. -classes and -methods are printed in italic.2. which are either raw or executed All classes are used by both tool parts. only AsIDE has been used. it imports raw input-data and generates the files that are needed to test the specified function on the target embedded system • the second part is called ReportGeneration. The debug hardware must be able to set software breakpoints on the embedded system. Each of those two classes contains the main-method of one tool part. During the development of the tool.

PathFinder and Yacas – PathFinderOutputfile to store the location of the output-file written by PathFinder during test execution • all classes of this package are subclasses of ToolFile. which is a subclass of ToolFile. This method is called specifyLocation and is shared by all classes of this package. the package contains the following classes: – Application for external programs. the report-generation-algorithm would require those classes to be coupled tightly.g. e. If they were separated into different classes.3. The distinct behavior in each class is achieved by using Java-Polymorphism and overwriting the methods that define the behavior of specifyLocation—whether to select plain files or directories. existing or not-existing files—in the subclasses of ToolFile • all classes associated with physical files that are either imported or generated by the tool are subclasses of ToolDataFile. ToolDataFile provides attributes and methods that allow the opening and closing of physical files and the reading or writing of textlines to files • classes whose associated files have a similar format share a common superclass that provides methods for importing or generating files with this format: – FormalSpecificationFile. ToolFile also provides methods to set and get the values of these attributes and a method that allows the user to specify the location of the physical file by using a graphical filechooser-dialog.7: YacasFile).e. i. large amounts of data would need to be passed between them (see Chapter 4.g. e. the physical file associated with the file and a description of the file. 2004 • the package contains one class for every file that is imported or generated by the tool: – FormalSpecificationFile – CFile – RawTestcasesFile – CTestHarnessFile – Groupfile – ExecutedTestcasesfile – YacasFile – GeneratedReportFile – ImportedReportFile – ConfigFile There are two separate classes for imported and generated reports because they are not necessarily associated with the same physical file. Wetzel March 9.Chapter 4: Implementation Diploma thesis M. they are combined into a single class. ImportedReportFile and GeneratedReportFile are all subclasses of TabularExpressionFile – RawTestcasesFile and ExecutedTestcasesfile are subclasses of TestcasesFile 37 . • in addition. Even though the Yacas-input. which provides attributes common to all files.and -output-files are also separate physical files.

2 Package dataStructures The dataStructures-package contains classes holding data in memory that was imported from files. Data that is necessary for checking the imported data has to be provided as part of the Object-Array-parameter – HasDefault: this interface is implemented by all classes that contain valid default values for the location of the file associated with them – GeneratedFile: this interface extends HasDefault and is implemented by all classes associated with files that are generated by the tool.3: Classes for imported and generated files. 38 . implement one of the following interfaces: – ImportedFile: this interface is implemented by all classes associated with files that are imported by the tool. the package contains classes for the following substructures: – ToolVariable: a data structure used whenever a type or value has to be stored together with the name of an identifier (see Chapter 4.Chapter 4: Implementation Diploma thesis M. ImportedData also provides methods to set and get the values of those attributes and a viewData-method which is overwritten in its subclasses with the method used to display the data contained in the structure • structures for files that have a common superclass also have a common dataStructuressuperclass: FormalSpecification and Report are both subclasses of TabularExpression The properties of each class are described in Chapter 4. the source file the data was imported from.4. It has the following properties: • the package contains one class for every file type that is imported by the tool: – FormalSpecification – CFunction – Testcases – Report • in addition. These classes must implement an importData-method that returns the imported data as Object. These classes must implement a writeData-method. except Application. 4.2.g.3: Classes for imported and generated files together with the file type its data is imported from. both are subclasses of Testcase • all classes apart from those for substructures are subclasses of ImportedData. which provides attributes common to all data structures.1: Storing variable values) – RawTestcase and ExecutedTestcase for holding a single raw or executed testcase. Wetzel March 9. 2004 • all classes that are associated with physical files. Data that is necessary for generating the file has to be provided as part of the Object-Array-parameter The properties of each class are described in Chapter 4. e.

it contains all classes that are used by both tool parts and are not directly related to files.4: Exception handling.g.1: Association between Files and Java-Classes shows all files used by the system and assigns index numbers to all files that are either imported or generated by the tool. e.2: GUI) • GridLayoutExtension and TwinJFrame are needed for the display of Tabular Expressions (see Chapter 4. Wetzel March 9.3: Display of Tabular Expressions) 4. Index numbers that are followed by a single lowercase letter represent classes that do not only generate or import a single file.g.Chapter 4: Implementation Diploma thesis M.2. the common-package does not consist of classes that have a common structure or purpose. with the section number matching the index number. 2004 4. The number is the index of the Java-class in the files-package that implements the methods to import or generate this file. The syntax of all files that are imported or generated by the tool is described in detail in Appendix F: File formats. data structures or exceptions: • Constants contains all fixed values as static attributes that may be adapted to change the behavior of the tool. checks of imported numerical values for syntactical correctness • Gui contains all elements needed for the GUI of the tool (see Chapter 4. The classes are described in this section in the ascending order of their indices. This identifier is used to determine the type of the file and to check whether it can be imported as part of the chosen operation or not.4. e.4.3 Package exceptions The exceptions-package contains the following user-defined exceptions that extend the standard Java-Exception: • CanceledByUserException: this exception is thrown whenever an operation is canceled by the user • MultipleEnvironmentException and WrongSyntaxException may both be thrown at several places during the import of files. All files except the config-file contain a file-type-identifier defined in the Constants-class in the first line.3 Classes for imported and generated files Figure 4. Instead. 39 .2. the maximum length of identifiers or the precision that is used by Yacas for Floating-Point-arithmetic (see Appendix B: Constants) • Data contains the files and data structures used by the tool • Methods contains the methods that are used by more than one class as static methods. they have types of their own to achieve consistency of error messages without having to duplicate code The exception handling of the tool is described in Chapter 4.4.4 Package common Unlike the other packages. 4.

Each environment is parsed by a single method of TabularExpressionFile that is called when the opening line of this environment—its name followed by an opening 40 . but structured enough to allow the files to be parsed by the tool.1: Association between Files and Java-Classes 4.Chapter 4: Implementation Diploma thesis M.g. 2004 Figure 4. These goals are reached by dividing Tabular-Expressionfiles into so-called environments that may occur in an arbitrary order in the file. by simplifying both the structure of the environments and the file as a whole. e.3. Since there are no editors to create such files available at the moment. Wetzel March 9. the parameters of a function or the global variables it uses for input. Environments are parts of TabularExpression-files that define one aspect of a formal specification or report each. the format chosen for these files must be flexible enough to allow manual creation.1 FormalSpecificationFile Tabular-Expression-files containing formal specifications must include all information necessary to specify a C-function and to allow this specification to be used to evaluate the results of testcases testing this function. Grouping closely related information together in these distinct compartments reduces the complexity of parsing the file.

The order must be exactly the same as in the declaration of the specified function. 41 . Only the FUNCTION. constants have a type in addition to a value. ImportedReportFile and GeneratedReportFile. Each environment may only occur once.g. defining its name and type. OUTPUT V ARIABLES: contains one line for each global program variable the specified function uses for output. and the number of Maingrid-cells must match the product of the sizes of all dimensions. The method exits when it encounters the closing line of the environment—a closing curly bracket—and the parsing of the file is continued. see Chapter 2. which is the common superclass of FormalSpecificationFile. it must be included with the same name and type in both environments. Report-files use exactly the same format. the number and sizes of its dimensions and the indices of any special headers. In this case. Since this is the only major structural difference between Tabular-Expression-files containing formal specifications and those that contain reports. The Headerand Maingrid-cells are included as subenvironments of this environment. while the output-value is referenced by putting a trailing apostrophe directly after the name. The number of Header-cells in each dimension must match the size of this dimension. REMARKS: contains additional textual remarks. except that they must have a REMARKSenvironment that includes report statistics. To enforce using constants only when it is semantically correct. TABLE: contains all data that is directly related to a Tabular Expression. Wetzel March 9.5: Table-cell-expressions. 2004 curly bracket—is recognized during the parsing of the file. PARAMETERS: contains one line for each parameter the specified function has.Chapter 4: Implementation Diploma thesis M. If a global variable is used for both input and output by the specified function. INPUT V ARIABLES: contains one line for each global program variable the specified function uses for input. the inputvalue of the variable is referenced in table-cell-expressions by preceding its name with a leading apostrophe.5. The following environments may be included in a Tabular-Expression-file: FUNCTION: contains only a single line defining the name and type of the function. Those definitions must use a declaration-syntax that can be understood by Yacas. otherwise a MultipleEnvironmentException is thrown. e. the methods for reading and writing both files are part of the TabularExpressionFileclass.and TABLE-environments are mandatory for a formal-specificationfile. CONSTANTS: contains one line for every symbolic constant the specified function uses. its type. defining its name and type. For a definition which types of table-cell-expressions are required for each area of the different table types. AUXILIARY FUNCTIONS: contains definitions for auxiliary functions used in the specification. since the auxiliary functions have to be evaluated by Yacas when they are evaluated as part of a table-cell-expression. defining its name and type.

Formal-specification-files are used to validate all other imported files and therefore must be imported first. If not. C Style guides recommend putting the opening curly bracket in a line on its own. since such a line is classified as a normal operation and not as a function. This algorithm is not able to extract functions that have a semicolon in the line that contains the opening curly bracket of the function. 4. If no function with the appropriate name and type is found. If a new formal-specification-file is imported. it does check if the type of the function is compatible with the tabletype of a formal specification (see Chapter 2. Although the tool does not check the syntactical or semantical correctness of Tabular Expressions. an error occurs. Wetzel March 9. Since the name and type of the function are known. the C-file is parsed until a function is found that matches the previously imported formal specification in regard to its name. all lines are imported starting with the line containing the type. Instead. or at least inserting a newline after it [AA]. If a function with the correct name and type is found whose parameter syntax does not exactly match the formal specification.3: Vectorheader-cells). without any semicolons • check if the text between the opening and closing parentheses matches the parameters declared in the formal specification If all conditions are met. Apart from the syntactical correctness of the function declaration. the user is given the choice of importing this function or continuing the search.5.4: Types of Tabular Expressions) and if the vectorheader-cells of a vector table match the declared function type and output variables (see Chapter 2. any previously imported C-functions and testcases are removed from the tool because they might not be valid for the newly imported formal specification. not the entire content of a C-file is imported into the tool.5. the import is successful if all mandatory environments have been read when the end of the file is reached.7. type and parameters. However. a warning is being displayed to the user and he can choose to either continue or abort the search. then one closing parenthesis after arbitrary characters and then one opening curly bracket after optional whitespace following the name in this line or the next lines. the following algorithm can be used to parse the C-file: • parse all lines until one is found where the type and name are only separated by whitespaces.Chapter 4: Implementation Diploma thesis M.3. including newlines • check if there is one opening parenthesis after optional whitespace.2 CFile Unlike other imported files. 42 . until there are exactly as many closing curly brackets in the extracted string as opening curly brackets. it is checked if all global variables and constants that are defined in the formal specification are declared at the beginning of the C-file prior to the first function. 2004 Since Tabular-Expression-files do not have a special end-of-file indicator.

Testcases that do not fulfill this condition are classified as incomplete and are not imported into the tool.Chapter 4: Implementation Diploma thesis M. If no complete testcases are found in the file.3 RawTestcasesFile Since the information contained in a raw-testcases-file—input-values for the parameters and global variables that are used for input by the specified function—is a subset of the information contained in an executed-testcases-file. a warning message is being displayed to the user.0 to an Integer-variable leads to the rejection of the testcase during the import into the tool. A single raw testcase is defined as complete if it either assigns a valid value or a question mark to every parameter and input variable that is declared in the formal specification of the function the testcase is used to test. and should not be included in the specified function 4. If there are any incomplete testcases in a raw-testcases-file. the following requirements have to be met by the specified function: • no other imports than the C standard library stdio. While assigning 5. and he is given the choice to either import the complete testcases or cancel the import of the file. The tool checks whether a value is compatible with the type of the variable declared in the formal specification: Integer-variables must be assigned Integer-values and Floating-Pointvariables must be assigned Floating-Point-values. The description of the methods given in this section also applies to the import of executed-testcases-files. reading and writing of files. constants and parameters is needed for the execution of the specified function • the specified function does not need other methods to be executed to perform its task. To facilitate automatic generation and successful execution of a C-Test-Harness.h are needed by the specified function • no initialization apart from the setting of global input variables. assigning 5 instead of 43 . There is one difference between the import of raw testcases into the first and into the second part of the tool: testcases containing question marks instead of values are considered incomplete when imported into the second part of the tool. neither before nor during or after its own execution • the specified function must be able to run on an embedded system. No other parts of the C-file are imported into the tool. the same methods are used to import the inputvalues in both files. since they can not be used to determine the specification-coverage of a set of testcases.3. 2004 The algorithm extracts only the specified function from the C-file and imports it into the tool to allow the generation of a C-Test-Harness embedding the specified function in an environment where it might be tested on the target embedded system. parameter passing from the command line and direct user interaction may not be supported on the embedded system. the import is aborted and an error message is being displayed. Wetzel March 9. Those methods are located in the TestcasesFile-class and are used by both of its subclasses RawTestcasesFile and ExecutedTestcasesFile.

those that do not match the formal specification are considered incomplete and are rejected. Additionally. After the first line defining the type of the file. a local variable is declared that controls the termination of the loop and another that is incremented and decremented during the loop to allow the program execution to continue on defined operations after returning from the PathFinderBreakpointFunction.4 CTestHarnessFile A C-Test-Harness is generated to allow a specified function to be executed on an embedded system under conditions that are defined by a single testcase. it is not possible to include the testcases in the generated C-Test-Harness.2. The breakpoint before calling the specified function is used to assign the input-values. At the beginning of the C-Test-Harness. a raw-testcases-file is divided into single raw testcases that are separated from each other by a MajorSeparatorLine. to all program variables.4: Testcases. Negative values must not have any spaces between the minus sign and the number. the execution of two single C-operations returns the program to the increment/decrement-operation inside the loop. the C-Test-Harness has to provide facilities that allow the specified function to be executed once for each testcase that is included in the generated PathFinder-Groupfile. 2004 5. as they are defined by this testcase. Before the loop. This function consists only of a single return-statement and enables the Groupfile to set a breakpoint at its start.Chapter 4: Implementation Diploma thesis M.0 to a Floating-Point-variable results in PathFinder not being able to recognize it as a valid Floating-Point-value during test execution. the C standard library stdio. a function named PathFinderBreakpointFunction is called before the incrementation/decrementation of a counter. This is also the case if a question mark takes the place of a value and the value is entered during test execution. a local variable is declared to hold the return value of the specified function whenever it is called in the loop. An increment and a decrement operator are used instead of two increments to prevent number overflows from happening even for large numbers of testcases. If the 44 . while the values of those variables contain the test results after the execution of the specified function and can be queried at that breakpoint. Whenever this breakpoint is reached during test execution. This goal is achieved by including a main-method in the generated C-Test-Harness that calls the specified function inside a while-loop. In addition. Even if all testcases should be imported. all parameters of the specified function are declared as local variables in the main method. because the C-Test-Harness can not write the test results to an output-file on disk when it is executed on an embedded system. 4. the Groupfile must be enabled to query and change the values of all global program variables and parameters that are used by the specified function in the C-Test-Harness. unless it is of type void.3. As explained in Chapter 3. Before and after the call of the specified function.h is imported. If the expected first line occurs several times in the file— indicating that the output of a testcase generator has been appended to the file instead of overwriting it—the user is given the choice to either import only the last set of testcases or try and import all testcases. Depending on the type of the specified function. enabling the executing Groupfile to query or to change the values of program variables according to the current testcase. Instead. a string attribute defined in the Constants-class. Wetzel March 9.

The tool requires all testcases to contain decimal values and sets the input base accordingly.3. it is possible to generate a PathFinder-Groupfile that is able to execute the generated C-Test-Harness for all imported testcases. This can be achieved by setting software breakpoints before and after the specified function is called in the loop inside the main method of the generated C-Test-Harness. At the breakpoint after the execution of the specified function for the last testcase.5 Groupfile A PathFinder-Groupfile is a textfile written in the PathFinder-Macro-language (see Chapter 3. Instead. but only to functions. One problem with this approach is that PathFinder does not support setting breakpoints to C-labels. Before the specified function is called.Chapter 4: Implementation Diploma thesis M. a MacroVariable is declared. while all input. they have to be inserted manually after the generation of the C-Test-Harness. for each question mark replacing an input-value in a raw testcase.4: Testcases). The specified function is then executed under the conditions defined by this testcase. the value of the Macro-variable is then assigned to the program variable that is used as parameter or input-variable. 4. If a value is given in the testcase instead of a question mark. the generated Groupfile contains operations to read the value from user input during test execution and assign it to a Macro-variable.and output-variables are declared as global variables. if the execution of the program stops at the 45 . Wetzel March 9. the specified function as it has been extracted from the original C-file is inserted into the generated C-Test-Harness . 2004 specified function does need additional imports.2. For each global program variable and each parameter of the specified function. Since those commands enable PathFinder to control the download and execution of software running on embedded systems. This is necessary because PathFinder does not support assigning values entered by the user during test execution to program variables directly.and output-values. the function return value and the values of global program variables that are used as output-variables by the specified function are also written to the output-file and a new testcase is started. All constants defined in the formal specification are defined with their values as symbolic constants. After the declaration of variables and before the PathFinderBreakpointFunction and the mainmethod. After the execution of the specified function is finished. before the value of the Macro-variable is assigned to the program variable. hexadecimal or octal. the program variable of the C-Test-Harness that allows termination of the loop is set and the generated output-file with the executed testcases is closed. However. together with any other adjustments that might be needed. according to the values defined in the testcases. Those input-values are also written to the output-file generated by PathFinder during test execution. the input-values of this testcase are assigned to all program variables that are used as parameters and input-variables of the specified function. Such a scriptfile is able to control PathFinder and to execute most commands that can be issued through the PathFinder-GUI. the input base has to be set to either decimal. At the beginning of the Groupfile. this value is directly assigned to the Macro-variable. After the breakpoint before the execution of the specified function has been reached for this testcase. The output-file is an executed-testcases-file consisting of testcases that include both input.

Since the structure of the function with the breakpoint is exactly known. To facilitate this. Since this affects only the assignment of values to variables. This causes an error if the name of a program variable—a parameter or global variable used by the specified function—is the same as the name of a Macro-language-operation. Wetzel March 9. Apart from this number. the program has to return to the main function so that they can be set or queried before the specified function is executed or the next testcase begins. As in raw-testcases-files. the specified function in the generated C-Test-Harness would still use the unaltered names for global variables. single executed testcases have to define output-values for the global variables used for output by the specified function as well as input-values. the normal output of the Macrolanguage-operations contained in the Groupfile is suppressed to allow the user to concentrate on this essential information. The return value of the specified function must be included as output-value if the specified function is not of type void. the beginning and the end of the execution of the current testcase and the input of values by the user. the only applicable solution to this problem is to avoid variable names that might conflict with Macro-language-operations. the values of local program variables used in the main method of the generated C-Test-Harness are unknown and can neither be changed nor queried by the Groupfile. 4. renaming variables that have conflicting names might be a solution. The only difference is that in order to qualify as complete. a command of the Macro-language of PathFinder that advances a single high-level programming-language step during program execution is used twice to execute two steps of the C-program. thus allowing access to all program variables again.Chapter 4: Implementation Diploma thesis M.3. testcases are separated from each other by a MajorSeparatorLine. To access those variables. a string attribute defined in the Constants-class. and replacing those references with the altered names would make parsing the complete specified function necessary to distinguish conflicting variable names from parts of other program operators. 46 . the number of the current testcase is being displayed in the PathFinder Command-Window.and output-variables by a function. There can be no question marks instead of values. Until the PathFinder-parser is able to distinguish between variable assignments and other operations. 2004 beginning of a function.6 ExecutedTestcasesFile Executed-testcases-files have the same structure as raw-testcases-files. A list of all Macro-operations is contained in the PathFinder-User-Manual [Mic03]. Another problem is that PathFinder is not able to distinguish between a variable assignment and a Macro-language-operation when parsing a Groupfile. However. the output-values are separated from the input-values by a MinorSeparatorLine. Since the same global variables can be used as both input. because those testcases have been executed already and contain the values entered by the user during text execution in this case. The local variables used for parameters in the main method of the C-Test-Harness can be renamed without side effects. these commands return the program to defined places before and after the calling of the specified function in the loop of the main-method of the generated C-TestHarness. During test execution.

e.7 YacasFile The methods to generate Yacas-input-files and to import Yacas-output-files are included in the single class YacasFile instead of two separate classes. Otherwise.and output-files is to include a unique identifier in both. The report-generation-algorithm has the following structure: • create a new data structure capable of holding a report and fill it with data from the formal specification • for each testcase that has been imported into the tool. which is considered sufficient for this work. the algorithm could inadvertedly read the output-file of a former testcase that does not match the latest input-file and the current testcase. write an output-file. This has to be repeated for every testcase before a report is generated.7. or if the writing of the output-file is delayed by disk-caching mechanisms. the tool would have to hold former identifiers in a database to make sure that they are not used again. and this output-file must be read by the tool before control passes back to the user. 47 . i.1 Report-generation-algorithm A distinct feature of this class is that the invocation of Yacas during the report-generation algorithm is synchronous.3. If the specified output-file already exists.e. While those identifiers are not truly unique.g. Another option is to generate a large random number and use it as an identifier. to generate a 64-Bit identifier by concatenating two random 32-Bit Long-values2 . 2004 All other definitions for raw-testcases-files also apply to executed-testcases-files. resulting in invalid data being included in the generated report.3. This makes establishing a link between the input-file and the output-file that is generated by Yacas in response to the input-file necessary. PathFinder appends its output during test execution instead of overwriting the file. 4. The reason is that the reportgeneration algorithm described in this section would require separate classes to be tightly coupled. This is more likely to happen if Yacas has to perform time-consuming computations. However. so only the last set of testcases should be imported unless all testcases belong to the same formal specification. Yacas has to read an input-file. Wetzel March 9. e. the chance of the same identifier being used twice in direct succession is only 2−64 . a large interface would have to be created between them. to make sure an identifier is absolutely unique. i. do the following: – generate a Yacas-input-file that contains the following information: ∗ the identifier string ∗ the desired precision for Floating-Point-operations that should be used by Yacas ∗ all definitions of constants and auxiliary functions in the formal specification ∗ the input-values. as they are defined by this testcase for all parameters and input variables 2 The second value is required to be positive to make sure the result is a valid number.Chapter 4: Implementation Diploma thesis M. One way to identify matching pairs of input. 4. since the input-file only contains a single testcase as opposed to testcases-files that contain entire sets of testcases.

Chapter 4: Implementation

Diploma thesis M. Wetzel

March 9, 2004

∗ (if a Testresult-evaluation-report is generated) the output-values, as they are defined by this testcase ∗ all table-cell-expressions that have to be evaluated by Yacas for this type of report and this type of Tabular Expression (see Chapter 2.5.8: Interpretation of Tabular Expressions ) The identifier string and the evaluation results of the table-cell-expressions are to be written into an output-file that is generated by Yacas – invoke Yacas with the generated input-file as parameter – wait until an output-file with an identifier matching the current identifier is generated by Yacas and can be read; if this takes too long, allow the user to cancel the operation – read the output-file – update the report according to the information contained in the output-file • generate the report The generated report is displayed on the screen and can be saved to disk afterwards. 4.3.7.2 Ressource management

The algorithm-part that waits for the Yacas-output-file to be written after Yacas has been invoked is implemented as a loop: it is checked every loop turn if an output-file with the correct identifier exists and can be read. If a number of loop turns, which is defined in the Constants-class, has passed without a valid output-file being created by Yacas in response to the latest input-file, the user is given the choice to either cancel the report generation or to continue waiting for the output-file. However, if the operating system of the machine the tool is executed on does not allocate enough CPU time to the Yacas-process, but keeps all ressources allocated to the execution of the tool instead, the loop never terminates successfully. This is because the execution of the loop uses all the ressources that would be needed by Yacas itself, so that Yacas never gets enough ressources to perform the necessary computations to produce the output-file the loop is waiting for. This is prevented from happening by letting the thread that executes the tool sleep for a few milliseconds in every loop turn. The number of milliseconds the thread is put to sleep is also defined in the Constants-class. There is one more situation where a thread is deliberately paused: during the import of large Yacas-output-files. This is because a buffered reader is used to read the contents of the file, and a buffer underrun might occur otherwise if the tool imports parts of the output-file without having to perform any time-consuming computations on the imported data. The number of milliseconds the thread is put to sleep between read operations depends on the size of the formal specifications —the larger the difference (size of specif ication − buf f ersize), the longer the wait—and a factor that is defined in the Constants-class. All the attributes in the Constants-class that influence the length of sleep-intervals are dependant on the CPU- and I/O-speed of the machine the tool is executed on, and may be adapted to suit slower or faster machines. 48

Chapter 4: Implementation

Diploma thesis M. Wetzel

March 9, 2004

4.3.7.3

Bugs in Yacas

While Yacas fulfills all the requirements for a Computer Algebra System that are listed in Chapter 3.2.1: Parsing table-cell-expressions, the current version 1.0.55 has two bugs that make it more difficult to use for Floating-Point-arithmetic than it was expected. The first bug occurs when the result of a Floating-Point-operation in Yacas is a whole number: • 1.8 + 3.2 evaluates to 5. • 5. = 5 evaluates to T rue • however, 1.8 + 3.2 = 5 evaluates to F alse The last type of statement often occurs in Guard-cells (see Chapter 2.5.7.1: Guard-cells). This bug can be avoided by making Yacas transform the evaluated results of all equations and inequations—1.8+3.2 ! = 5 evaluates to T rue—into fractions and back to Floating-Pointnumbers: Eval(N (Rationalize(1.8 + 3.2))) = Eval(N (Rationalize(5))) evaluates to T rue. However, this solution needs the table-cell-expressions to be split at arithmetic predicates and each resulting part to be surrounded by those transformation-functions in the Yacasinput-file. Because 1.8 + 3.2 < 5 evaluates to T rue, both sides of all arithmetic predicates must be transformed, not only those of equations and inequations. Since Yacas is not able to evalute expressions that contain unbalanced parentheses, the tablecell-expressions must be parsed to divide them into valid subexpressions between unbalanced parentheses and arithmetic predicates. Those subexpressions can then be surrounded by transformation-functions. At the stage of the project when this bug was discovered, implementing a full-scale parser for table-cell-expressions was no longer an option. Instead, a smaller parser that was capable only of fulfilling this task had to be implemented. The following idea was used for the parsing-algorithm (the parsed table-cell-expression is denoted as ’string’ in the algorithm): • search for all arithmetic and boolean predicates—And, Or and Not must not be part of the transformed subexpressions either—in the string, and save their positions and types in arrays that are ordered by ascending positions • for every predicate, keep going left from its position in the string and copy all characters until either of the following conditions is met: – the beginning of the string is reached – the position of the last predicate is reached – the rightmost position that was reached by going to the right of the last predicate is reached – the copied substring would turn unbalanced by adding an opening paranthesis when the substring contains exactly as many opening as closing parantheses 49

Chapter 4: Implementation

Diploma thesis M. Wetzel

March 9, 2004

at the moment. Due to the syntax rules of table-cell-expressions, closing parantheses that make a balanced string unbalanced must be followed by an opening paranthesis before the next predicate can occur when going to the left • perform the same operation to the right of the predicate; keep going right from the predicate position and copy all characters until either of the following conditions is met: – the end of the string is reached – the position of the next predicate is reached – the copied substring would turn unbalanced by adding a closing paranthesis when the substring contains exactly as many opening as closing parantheses at the moment – unlike when going to the left, opening parantheses that make a balanced string unbalanced need not be followed by a closing paranthesis before the next predicate can occur when going to the right. This is due to the fact that the next predicate to the right did not have a chance to go left from its own position yet. If the end of the string or the next predicate is reached while the copied substring is unbalanced, all characters since the last balanced position are removed from the substring • the balanced subexpressions copied to the substrings when going to the left and right of the predicate are surrounded by the transformation-functions and then copied to the Yacas-input-file, while all remaining unbalanced parts—including the predicate itself—are just copied to the Yacas-input-file without transforming them The second bug occurs when the precision for Floating-Point-operations is set to either 5, 6, 7, 10, 11, 15 or 19. This precision is the number of decimal places Yacas guarantees to be valid when performing Floating-Point-operations. It is set once at the beginning of each Yacas-input-file to a value defined in the Constants-class. If the precision is set to 5, the following behavior occurs: N (1.8 − 12) evaluates to −10.19999. To avoid the bug, the precision should be set to at least 20. However, this has the negative side effect of making equality checks between Floating-Point-values that were calculated by the target embedded system during test execution and values that are calculated by Yacas fail in some cases. This is because the embedded system is limited to the range of the C-type it uses to represent Floating-Point-values. Even if double is used, only 14 decimal places can be guaranteed to be valid by the embedded system, while Yacas performs its Floating-Pointoperations with a precision of 20 valid decimal places. If a calculation leads to the last six decimal places not being zero in Yacas, checks for equality between values calculated by the embedded system and values calculated by Yacas will fail. The number of decimal places the result of a Floating-Point-calculation in Yacas has, can be limited to a number that is different from the precision used for the internal calculation. However, this option truncates the result of a calculation to the given number of decimal places, while the embedded system rounds the last valid decimal place. If this decimal place is increased as a result of the rounding by the embedded system, checks for equality with the truncated Yacas-value will fail again. 50

the second field is empty. the source of this bug in Yacas is yet unknown. reports can not be used as formal specifications anymore. This is done by adding two more fields.3.1: FormalSpecificationFile. which are separated from each other and the original table-cell-expression by a string that is defined in the Constants--class. it has the advantage of being completely independent from any deviations between the rounding performed by the embedded system and by Yacas. Those fields contain the overall number of testcases that covered the case defined by this table-cell. report-files are the only files that are both generated and imported by the tool.3. The identifier that is contained in the first line of a generated report depends on the type of the report: whether it is a specification-coverage-report or a testresult-evaluation-report. 2004 There are two ways to avoid this bug without making equality checks of Floating-Pointvalues impossible: • set the Yacas-precision to 14. and the number of successful testcases that covered this case. Since the information is contained in all report-files. 51 . the generated C-Test-Harness need not be tested on the embedded system again and previously generated executed-testcases-files can be used to generate the report. As it has been described in Chapter 4. the contents of some table-cells have another syntax in reports because reports store pieces of statistical information in some table-cells. the value of this attribute can be changed at any time without invalidating existing reports. only the value of the constant in the formal specification has to be adapted and a new report has to be generated with this formal specification. The length of the interval is defined by a constant that is included in the formal specification The first possibility–setting the general Floating-Point-precision in Yacas to 14—is easier to accomplish because equality checks between Floating-Point-values in formal specifications do not need to be changed. and there is a risk that it may occur in same cases even with the precision set to 14. The Yacas-bug should not occur then and equality checks are possible as long the embedded system and Yacas round the same way • substitute equality-checks of Floating-Point-values with interval checks. However. which would not be possible if the original table-cell-expressions were replaced by report statistics. as they do not depend on a particular value of the interval-constant in the formal specification.8 GeneratedReportFile Apart from config-files. However. Wetzel March 9. Although it is more time-consuming. To change the acceptance interval.4: Formal specification of function Float2. Another attribute that is defined in the Constants-class determines whether the original tablecell-expression is displayed when a report is viewed on the screen. If the report contains only the specificationcoverage of a set of testcases.Chapter 4: Implementation Diploma thesis M. altering the table-cell-expressions. However. The second possibility—augmenting formal specifications by replacing equality checks with interval-checks—is applied to the specification of the function Float2 in Figure 4. because of the altered table-cell-expressions. 4. all other files are either generated or imported by it. the only other structural difference between files containing formal specifications and those containing reports is that reports must have a REMARKS-environment.

However. If those locations are not saved when they are specified by a user.3: Display of Tabular Expressions for details). the same methods can be used to import both. the tool itself may be executed on any platform. To be able to use previous definitions. which is the common superclass of all three classes that import or generate Tabular-Expression-files: FormalSpecificationFile.3. 2004 4. PathFinder and Yacas—remain constant. Since the tool does not use an installation routine but is deployed as a collection of Java class-files in the directory structure defined by the packages. the locations of the external programs that are used by the tool— AsIDE. GeneratedReportFile and ImportedReportFile. since input. otherwise the previously saved configuration-file cannot be found. Wetzel March 9. This leaves a configuration-file as the only remaining option. report statistics are appended to some table-cell-expressions Those table-cells that contain report statistics are displayed with another background color. there is never an installation directory explicitly specified by the user. and even the locations where files of the same type are stored on disk rarely change. which is usually the root directory of the tool-packages. which is not desirable. and the original table-cell-expressions are either appended or replaced by report statistics (see Chapter 4. Without such a definition.Chapter 4: Implementation Diploma thesis M.3. Even though AsIDE and PathFinder only run on Windows. 4. they have to be specified every time the tool is used. Using a system-database limits the application of the tool to the platforms that support this database.9 ImportedReportFile Since report-files have the same structure as formal-specification-files. the tool has to be executed from the same directory afterwards. the configuration-file has to be saved to disk in the directory the tool is executed from. There are two basic approaches to make this data persistent between two executions of the tool: • in a configuration-file—short: config-file—on the harddisk or • in a system-wide database like the Registry on Windows-operating-systems. 52 .and output-files can be copied through a network from or to other workstations running Windows.10 ConfigFile In most environments. using the Windows-Registry to store specified locations would limit the tool to running on Windows platforms.4. There are three differences between report-files and formal-specification-files: • the filetype-identifier in the first line of a report-file determines whether the file contains a specification-coverage-report or a testresult-evaluation-report • it is mandatory that a report-file contains a REMARKS-environment • depending on the type of the report that is contained in a report-file. Those methods are part of the TabularExpressionFile-class.

53 . to copy to another location if the tool has to be executed from elsewhere Synchronization problems that may occur—if both tool parts are executed in parallel. The configuration-file stores the values of the following attributes: • filename and directory of each external program • directory where the latest file of each type has been imported by the tool • filename and directory of the latest generated file of each type • directory used for the Yacas-files The configuration-file is read by the tool at every startup. directories or files that do not exist anymore—are also replaced by default values at startup. A single configuration-file is used for both tool parts instead of one for each part because of the following reasons: • Using two separate files.g. At program exit. and is written by the tool at every program exit.Chapter 4: Implementation Diploma thesis M.g. changes made in the part that is exited first can be lost if the other part writes its own changes to disk—can be avoided by executing the tool parts sequentially.Serializable is not necessary. where they can be retrieved for the next execution of the tool. If it can not be read—e.4 Further implementation features This section describes major implementation decisions that are not directly related to the import or generation of a single file. one for each tool part. 4. Wetzel March 9. the use of mechanisms for storing entire objects on disk like Java.g. • One file is easier to maintain. This is an undesirable behavior because both tool parts are likely to import formal specifications or raw-testcases-files from the same location. if no configuration-file exists in the directory the tool is executed from. or by not making any changes that should be saved in the tool part that is exited first. e. 2004 Configuration-files can use plain ASCII-text as file format. or if an existing file is corrupted—these attributes are reset to their default values (see Appendix B: Constants) and may need to be changed by the user again. results in the specification of locations for imported files in one tool part not affecting the import of files of the same type in the other part. Locations can be easily saved and retrieved as ASCIIStrings in textfiles.. Invalid values that are read from an existing configuration-file—e. Since only locations and not whole objects have to be saved. the current values are then written to a new configuration-file in this directory.

The Constants-class (see Appendix B: Constants) contains six static String-attributes that can be used to adapt the behavior of the tool regarding the supported types. default is ’long’ for Integer and ’double’ for Floating-Point 4.1 Storing variable values All variable identifiers in formal specifications.and Floating-PointMacro-variables. Like identifiers and types. The current status of the tool part is being displayed using colored text labels that show 3 Functions of type void are also supported 54 .4.Chapter 4: Implementation Diploma thesis M. and to generate a PathFinder-Groupfile. However. This is because using a single class for all purposes instead of a hierarchy of separate classes. with each containing only a subset of attributes. default is ’long’ for Integer and ’double’ for Floating-Point • the strings used in generated PathFinder-Groupfiles for Integer. a C-function can only be imported after a formal specification has been successfully imported. All operations are directly accessible via buttons. default is ’int’ for Integer and ’real’ for Floating-Point • the strings used in imported C-files and generated C-Test-Harnesses for Integer. some buttons are only activated if certain prequisites are met—e. and only there evaluated.and Floating-Point-variables and -functions. To avoid such errors. making checks for equality of Floating-Point-values error-prone. The values are included as strings in the generated PathFinder-Groupfile and in the Yacas-input-file.g.4: Formal specification of function Float2 is recommended instead of checking for equality. testcases-files and reports are stored together with the referenced type and value in instances of the ToolVariable-class. minor differences between the Floating-Point-arithmetic performed by the target embedded system and the Yacas-arithmetic might still exist. values imported from testcases-files are stored as String-objects. The additional space required by the sometimes unused attributes—one Object-Pointer per instance at most—is relatively minor. reduces the complexity of methods searching for or comparing variables. which minimizes the risk of Floating-Point-arithmetic errors to happen that may be caused by number transformations.g. The tool supports two different types of variables and functions: Integer and Floating-Point3 .4. However. Even though some instances of ToolVariable do not contain a defined value—e. and that define the following strings: • the strings used in formal specifications to define the type of a variable or function. checking for a Floating-Point-value being inside a specified interval as shown in Figure 4. with all GUI-elements of each part fitting into the 640*480-window without having to scroll or to use a menu. both a formal-specification-file and a raw-testcases-file must have been imported successfully. Wetzel March 9.g. input-values in a testcases-file—a single class is used instead of multiple classes. 2004 4. The tool does not perform any arithmetical operations on variable values. C-functions. parameters in a formal specification—or a defined type—e.2 GUI Both tool parts are displayed using a single window each.

and black a successful specification of a location or file that has not been used yet(see Appendix E: GUI for a complete specification of all GUI-elements the tool has). 2004 which files have been imported or generated and which locations have been specified for external programs. Since many GUI-elements are shared by both tool parts and separating the GUI-elements into different classes would make a large interface between those classes necessary. Figure 4. a warning message is being displayed to the user and he can decide whether to exit immediately or cancel the exit to save the report first. this is not checked for the first tool part.2: Screenshot Tool part 1: TestPreparation 55 . all GUIelements are contained in the single Gui-class. Apart from the different GUI-elements in the window displayed on the screen. red the absence of a successful import or generation. However. The color of the text is used together with the text itself to show the status of the tool: blue represents the successful import or generation of a file. and the actionPerformed-method implemented by the Gui-class only queries the active elements to check the source of a triggered actionEvent. Wetzel March 9. If this is the case. To facilitate calling dataLossPrevention even if the user attempts to close the window.Chapter 4: Implementation Diploma thesis M. Since the first tool part does not generate data that is not saved to disk immediately. the Guiclass implements the WindowListener-interface in addition to the ActionListener-interface. the behavior of the tool parts differs in one point: if the user exits the second tool part ReportGeneration by either clicking the exit button or closing the window. a method called dataLossPrevention checks if a report has been generated that has not been saved to disk yet and would be lost at program exit. only the elements that are needed by the active tool part are initialized and used.

56 . However. Wetzel March 9. Given the limited amount of time that is available for the implementation of the TabularExpression-Viewer in this work—which is. In Tabular Expressions. and that can be realized with the available ressources: • Java Window-Layout-Managers that arrange all GUI-elements in a grid-like fashion: GridLayout and GridBagLayout • Java Tables: JTable Although JTable supports advanced features for 2-dimensional tables like headers remaining visible when large tables are scrolled. implementing a Viewer that is capable of displaying all kinds of Tabular Expressions under different operating systems is a difficult task that requires a large amount of time. rendering many of the advanced features supported by JTable useless or limiting their application to a single dimension. unlike in TCT or TIM. it is designed for tables with headers only alongside one dimension.Chapter 4: Implementation Diploma thesis M. all dimensions have headers and all of those are equally important. not a key component here—implementing a Viewer similar to TCT or TIM is not feasible.3 Display of Tabular Expressions As shown by Li with Table Construction Tool (TCT) in [Li96] and Kowalik with Table Input Method (TIM) in [Kow02]. 2004 Figure 4.4. Java has several features that can be used to implement a basic Viewer that is capable of displaying all Tabular Expressions supported by this work.3: Screenshot Tool part 2: ReportGeneration 4.

whose side length is defined by the largest element of either direction • GridBagLayout allows each element to have an arbitrary rectangular shape Since table-cell-expressions of Tabular Expressions are usually one-line expressions that may be several hundred characters long. GridBagLayout. It also overwrites the layoutContainer-method that does the actual layout of a Container on the screen with a version that assigns each row of GUI-elements the maximal height of its individual elements as height and each column the maximal width of its elements as width. This results in a table with the desired properties—minimal extension in either dimension. It overwrites the methods preferredLayoutSize and minimumLayoutSize. However. with one method that returns the preferred size and supports rows and columns with individual heights and widths.4: Formal specification of function Float2 is displayed using the GridLayoutExtension-class. Wetzel March 9. which return the preferred and the minimum size of a Container filled with GUI-elements. Using the simple GridLayout would result in all table cells having a square shape with the length of the square determined by the longest table-cell-expression. The following Figure 4. it is much more complex than GridLayout and requires a lot of code to be written and many manual adjustments to be made. creating rows and columns and the impression of a table • both support making either the whole table or individual elements scrollable by putting them into a JScrollPane • GridLayout forces all elements to have the same square shape. Putting each individual table cell into a JScrollPane would enable even large tables to be displayed wholly on the screen. 2004 The other option is using one of the Java Layout-Managers that arrange table-cell-expressions as single GUI-elements in a grid. even for the relatively minor enhancements of the functionality offered by GridLayout that are needed by the tool. The desired behavior—fully utilizing the screen by letting every table row and column have their independent minimal height and width. either the relatively simple GridLayout or the more complex GridBagLayout: • both support the drawing of vertical and horizontal lines between elements. this would make reading and comprehending the table difficult. maximal readability—being displayed on the screen without having to manually adjust the individual heights and widths of each individual element. This leads to the conclusion that writing an extended version of GridLayout that allows each row and column of elements to have independent minimal heights and widths would be more efficient than using the complex GridBagLayout for this task. Even if scrolling the table was possible.Chapter 4: Implementation Diploma thesis M. The enhanced GridLayoutExtension is implemented as a subclass of the GridLayout-class. 57 . average cells take much more horizontal than vertical space. and making the whole table scrollable—can not be achieved using GridLayout. which would have been necessary if GridBagLayout had been used. supports the assignment of individual dimensions to each element. on the other hand. but at the cost of making the individual table cells so small that they could not be read even with the help of scrolling.

This option is dismissed for the following reasons: • without parsing table-cell-expressions (see Chapter 3.2.Chapter 4: Implementation Diploma thesis M.1: Parsing table-cell-expressions). 2004 Figure 4. If they are not updated. there is no way to split them at correct locations • splitting them at intervals defined by parameters.g. the table-cell-expression might not match the 58 . this size might be altered by resizing the window without the table-cell-expressions necessarily being updated. the width of the GUI-element. diminuishes the readability of each table-cell-expression and of the Tabular Expression as a whole • if the table-cell-expressions are split according to the size of the GUI-element. e.4: Formal specification of function Float2 One possibility for using the original GridLayout has not been discussed yet: the splitting of one-line table-cell-expressions into multiple lines to utilize the square shape of the individual elements. Wetzel March 9.

the table-cells that contain these report statistics are displayed with another background color that depends on the following values: TC = Number of testcases that covered this case TCsuccess = Number of successful testcases that covered this case Specification-coverage-report (see Figure 5.4: Testresult-evaluation-report for an example): Background-color = TCsuccess = TC TCsuccess != TC TC = 0 yellow yellow TC > 0 light green light red 59 . each operation resizing the window would require time-consuming string operations to be performed on every single table-cell-expression. The only difference between viewing a formal specification and viewing a report is that in a formal specification.3: Specification-coverage-report for an example): Background-color = TC = 0 yellow TC > 0 light green Testresult-evaluation-report (see Figure 5. it first disposes of its twin frame before it disposes of itself. with the tool allowing multiple Tabular Expressions to be displayed at the same time.3. If they are updated. In a testresult-evaluation-report. resulting in visible delays for large Tabular Expressions For those reasons. multiple instances of windows displaying the same Tabular Expression are not affected. since only windows that are created at the same time are twin frames. a new TwinJFrame-class is created that is a subclass of the original JavaJFrame and extends it by establishing a connection between two frames. Because of this. it might be confusing having to find and close windows that belong together if those windows are not connected in any way apart from the same filename in the window header.1: FormalSpecificationFile) from being displayed in the same window. However. both windows displaying the different elements of one Tabular Expression are closed if either of them is closed by the user. the number of successful testcases is also shown in each of those table-cells. If either frame is closed. the table-cell-expressions of some table-cells are replaced by or appended with strings showing the number of testcases that covered this case (see Chapter 4.Chapter 4: Implementation Diploma thesis M. even long table-cell-expressions are not split but are displayed in their original one-line form. One solution is to display all additional data in textual form in another window. since it would have to use the same grid layout. 2004 size of the GUI-element any more. Wetzel March 9. In a report. all table-cells are displayed with their table-cell-expressions. In a report.3. However. This way.9: ImportedReportFile). The use of a Java Window-Manager to display the Tabular Expressions inhibits the additional data that is contained in a formal specification (see Chapter 4.

no exception has been thrown—are the results of the operation copied from backup data to regular data that can be used by further operations.4 Exception handling Java Exceptions are used by the tool to indicate that something went wrong during the execution of an operation. Wetzel March 9. Only when an operation is completed successfully—i. 2004 4. All operations of the tool are performed on backup data first. This means that all errors severe enough to make the successful completion of an operation impossible have to throw an exception. but successful completion of the operation is still possible. In all of those cases. all operations that can be executed by users are surrounded by the try-catch-block in the Gui-class. the user has the choice to either abort the operation or continue it.Chapter 4: Implementation Diploma thesis M. Those exceptions are caught by a special catch-block that catches only exceptions of this type. there are several situations during the execution of an operation where minor errors might occur and a warning has to be displayed to the user. To allow the user to understand—and possibly remedy—the situation. As all other exceptions.4. resulting in the display of an error message even if the user willingly aborted the operation and already knows the reason why the error occured. A CanceledByUserException is thrown in the following situations: • the selection of a file in the graphical filechooser-dialog is aborted • the import of a testcases-file is aborted because it contains incomplete testcases • the import of a C-function is aborted because it does not exactly match its formal specification • the generation of a report is aborted because the Yacas-output-file could not be read • the exit of the tool is aborted because a generated report has not been saved to disk yet 60 . To make sure all exceptions are handled.e. an exception has to be thrown to indicate the failure of the operation and prevent the regular data to be overwritten by the invalid backup data. If he chooses to abort the operation. before they can be caught by the general catch-block. those exceptions must include detailed error messages that are displayed on the screen. To prevent this from happening. this exception will be caught in the try-catchblock surrounding the operation in the Gui-class. The catch-block catches all exceptions and displays their error messages on the screen. and thus prevents them from being displayed as errors. However. a special exception type CanceledByUserException is thrown whenever an operation is not completed successfully because it is aborted by the user.

and a report is generated using the output-file that was written during the test execution.55 Installation path E:\Code E:\Programme\Java C:\PFARM\AsIDE\win\aside.0 1.1 Computer specification An IBM Thinkpad A31 with the following configuration is used as test machine: Processor RAM OS Intel Pentium-4 Mobile 1.0.6 GHz 768 MB DDR-RAM Windows XP Professional 5.1.exe C:\PFARM\pfarm.1. the tool is used to test a small example function with a set of testcases that is generated by a testcase-generator.2 Software The following software is installed on the test machine: Application The Tool Java SDK AsIDE PathFinder Yacas Version number 1.55\yacas. 5.4. 5.1 Test machine configuration This section describes the hardware. partition names and installation paths may vary on other machines.1.exe E:\Programme\Yacas\1.0. 61 .exe This is the configuration of the test machine only.and software-configuration of the machine that is used to test the tool.2 (+ interactive Double-input) 1.2 02 1.1.Chapter 5 Trial application In order to evaluate the methods that are described in this thesis. The generated C-Test-Harness is compiled and then executed on an embedded system.2 1.

c contains the specified function. the value of inout1 in the second testcase and the value of param1 in the third testcase are replaced by question marks to test the manual input during test execution. Both files are stored in the directory E:\TestData together with the formal specification and the C-file. A testcase-generator implemented in Java is used to generate raw testcases. changing to the root directory of the tool E:\Code and then using the following command: java testPreparation/TestPreparation It is assumed that no configuration-file exists in this directory yet. To ensure all specified cases are covered.Random are used to generate the random numbers. The C-file C Float2.util. is used for the test.4: Formal specification of function Float2) is used as formal specification.0 (both included) is chosen. 5. multiplied with 200. After the generation. The file Spec Float2. The content of both files is included in Appendix G: Trial application data.2 Test data This section describes the data that is used for the test. Apart from the initialization by the constructur Random(). and the result is assigned as input-value to the global variable inout1 • a random Double-value between 0.1: Storing variable values). The raw-testcases-file RawTestc100 Float2. an interval specified by a constant delta defines the acceptable range of the function-return-value for each case. A second raw-testcases-file RawTestc1000 Float2. It is connected to the test machine via an USB-cable.3. and the result is assigned as input-value to the parameter param1 The nextInt.0 and 1.and nextDouble-methods of Java. 5. Wetzel March 9.3 Test execution This section describes the execution of the test by using the different software tools. the random seed it not changed in any way.txt is generated with 1000 testcases. the testcases are generated with the following properties: • a random Integer-value between 0 and +11 (both included) is chosen.4. added to -1.txt (see Figure 4.txt is generated with 100 testcases according to the syntax described in Appendix F: File formats. added to -100.3 Embedded System A LPC2100 Evaluation Board that is manufactured by Ashling Microsystems Ltd.Chapter 5: Trial application Diploma thesis M. 2004 5. and that the following 62 .1. Instead of trying to compare the Floating-Point function-return-values with exact values (see Chapter 4.1 First part of the tool: TestPreparation The first part of the tool is executed by switching to a Command-Line-Environment. 5.

the first tool part can be either exited to invoke AsIDE and PathFinder manually from outside the tool.txt in E:\TestData • Button ’Import C-function’: import C-file C Float2. 2004 locations have to be specified by clicking on the respective buttons in the window with the first tool part: • Button ’Specify AsIDE-location’: specify aside. Wetzel March 9.c in E:\TestData • Button ’Generate testharness’: generate C-Test-Harness CTH Float2.txt in E:\TestData • Button ’Specify PathFinder-outputfile-location’: specify PathFOut100 Float2. For this test.grp in E:\TestData • Button ’Import raw testcases’: import previously generated raw-testcases-file RawTestc1000 Float2. the locations specified in the first part may be lost and can not be used in the second part of the tool. the first part of the tool is not needed anymore and can be exited.grp in E:\TestData Existing files with the name and location of either specified PathFinder-output-file have to be deleted before PathFinder is executed. both are invoked from within the tool using the following buttons: • Button ’Invoke AsIDE ’: invoke AsIDE with the generated C-Test-Harness as parameter • Button ’Invoke PathFinder ’: invoke PathFinder After both tools have been invoked.txt in E:\TestData • Button ’Specify PathFinder-outputfile-location’: specify PathFOut1000 Float2. After those steps have been executed.put in E:\TestData as name and location of the PathFinder-output-file • Button ’Generate Groupfile’: generate PathFinder-Groupfile PFGroup1000 Float2.Chapter 5: Trial application Diploma thesis M. If the first part of the tool is not exited before the second part is executed. or the tool can be used to invoke them.exe in C:\PFARM\AsIDE\win as location of AsIDE • Button ’Specify PathFinder-location’: specify pfarm. the following steps have to be executed by clicking on the respective buttons in the window with the first tool part: • Button ’Import specification’: import formal-specification-file Spec Float2.exe in C:\PFARM as location of PathFinder To generate the files that are needed for testing the specified function on the embedded system. 63 .put in E:\TestData as name and location of the PathFinder-output-file • Button ’Generate Groupfile’: generate PathFinder-Groupfile PFGroup100 Float2.c in E:\TestData • Button ’Import raw testcases’: import previously generated raw-testcases-file RawTestc100 Float2.

The contents of this file have to be copied and pasted into the Csourcefile of the newly generated project.Chapter 5: Trial application Diploma thesis M. The generated . AsIDE is no longer needed and can be exited. The executed commands and their results appear to the right side of the lower part of the screen (see Figure 5. which is a part of AsIDE. 2004 Figure 5. it is successfully compiled and subsequently built into a PathFinder-projectfile by the SymFinder-tool.3. ’Hello World!’-application • Makefile options: create C-project without a makefile A window with the generated C-Test-Harness should already be open if AsIDE was invoked from within the tool. The new project has to be built using the menu-command Build–Build. 64 . overwriting its previous contents. After the successful generation of this file.1: Screenshot AsIDE). a new EVBA7-project has to be created: • Menu-command: Project–New–Ashling GNU LPC2100 EVBA7-Project • Project type: Executable C. Wetzel March 9. If no syntactic errors exist in the C-Test-Harness.1: Screenshot AsIDE 5.cso-file can be read directly by PathFinder.2 AsIDE To compile the generated C-Test-Harness.

65 . download and verify of the code. The default selected options —filetype .cso. After that. it has to be stopped first by clicking the icon with the white exclamation mark in the icon bar1 (see Figure 5. the view of the C-code and the Command-window are activated by using the menu-commands Windows–High Level and Windows–Command. the PathFinder-projectfile that was generated by AsIDE can be downloaded onto the embedded system using the menu-command File–Load.2: Screenshot PathFinder 5. Now the generated PathFinder-Groupfile PFGroup100 Float2.3. Before the C-Test-Harness is executed on the embedded systems. in that order.Chapter 5: Trial application Diploma thesis M.2: Screenshot PathFinder ). download both code and symbols—remain unchanged. Wetzel March 9. 2004 Figure 5.grp has to be executed by rightclicking on the PathFinder-Command-window. and then selecting Run Groupfile and the generated file. 1 When the embedded system is not running.3 PathFinder If the embedded system is running. this icon is replaced by an icon with a blue arrow.

’10.put in E:\TestData • Button ’Determine specification coverage’: generate and view a specification-coveragereport of the imported formal specification and testcases (see Figure 5.Chapter 5: Trial application Diploma thesis M. After the execution of PFGroup100 Float2. The output-files written during the test executions can now be used for the generation of reports in the second part of the tool.put in E:\TestData • Button ’Evaluate test results’: generate and view a testresult-evaluation-report of the imported formal specification and testcases 66 . 5.3: Specificationcoverage-report) • Button ’Evaluate test results’: generate and view a testresult-evaluation-report of the imported formal specification and testcases (see Figure 5. Wetzel March 9. 2004 During the execution of the Groupfile. For inout1 in the second testcase.0. ’10’ is entered. PathFinder can be exited. for param1 in the third testcase.55 as location of Yacas To generate reports from the formal-specification-file and the PathFinder-output-files. After both have been executed.4: Testresult-evaluation-report) • Button ’Import executed testcases’: import executed-testcases-file PathFOut1000 Float2. the user is prompted to enter values for those variables where questions marks have been inserted into the raw-testcases-file. the other generated Groupfile PFGroup1000 Float2.3. the location of Yacas has to be specified using the following button before a report can be generated: • Button ’Specify Yacas-location’: specify yacas.grp is finished.2’ is entered. the following steps have to be executed by clicking the respective buttons in the second part of the tool: • Button ’Import specification’: import formal-specification-file Spec Float2.txt in E:\TestData • Button ’Import executed testcases’: import executed-testcases-file PathFOut100 Float2.grp is executed.exe in E:\Programme\Yacas\1. If the second part of the tool has not been executed from this directory before.4 Second part of the tool: ReportGeneration The second part of the tool is executed by either using the Command-Line-Environment that was previously used to execute the first part and directly issuing the following command java reportGeneration/ReportGeneration or by switching to another Command-Line-Environment. changing to the root directory of the tool E:\Code first and then executing the command.

2004 Figure 5.3: Specification-coverage-report Figure 5.4: Testresult-evaluation-report 67 .Chapter 5: Trial application Diploma thesis M. Wetzel March 9.

txt: < 1 s • generation of PathFinder-Groupfile PFGroup1000 Float2. the first harddisk I/O may take 1–2 seconds before a file can be selected. 2004 5. This is due to the harddisk returning from energy-save-mode.Chapter 5: Trial application Diploma thesis M. 68 . The meantime between the clicking of a button and the completion of the operation is measured in hours (h).c: < 1 s • import of raw-testcases-file RawTestc100 Float2. Any time that is spent waiting for user input is substracted from this value. If an operation is completed within the same second as it has been started.grp: 1 h 20 m 30 s Second tool part: • import of formal-specification-file Spec Float2. First tool part: • import of formal-specification-file Spec Float2.put: < 1 s • generation of testresult-evaluation-report for 1000 testcases: 5 m 3 s In both tool parts. The performance of operations which spend most of the time with User-Interaction and do not process much data—e. Wetzel March 9.put: < 1 s • generation of specification-coverage-report for 100 testcases: 20 s • generation of testresult-evaluation-report for 100 testcases: 32 s • import of executed-testcases-file PathFOut1000 Float2.txt : < 1 s • import of executed-testcases-file PathFOut100 Float2.txt: < 1 s • import of C-file C Float2. ’< 1 s’ is given as meantime.c: < 1 s • generation of C-Test-Harness CTH Float2. minutes (m) and seconds (s) with a digital wristwatch.g. Since no real-time constraints are placed upon the tool and performance is only an issue where long delays threaten to have a negative impact on the usability of the tool. the specification of locations in the tool—is not measured.grp (without delays caused by user input of values): 8 m 42 s • execution of Groupfile PFGroup1000 Float2.grp : < 1 s AsIDE: • build of C-Test-Harness to PathFinder-project-file: 2 s PathFinder: • execution of Groupfile PFGroup100 Float2. this precision is considered sufficient.txt: < 1 s • generation of PathFinder-Groupfile PFGroup100 Float2.4 Performance metrics This section describes how much time the execution of each operation took on the test machine.grp : < 1 s • import of raw-testcases-file RawTestc1000 Float2.

Importing a saved report takes about the same time as importing a formal specification with the same size. additional testcases could have been added to an existing set of testcases by executing them and then copying their results into an existing executed-testcases-file. and that reports only need to be generated once and can then be saved to disk and later imported again. 2004 5. a new CTest-Harness has to be generated with the updated function first. If any cases would not have been covered by the executed set of testcases. all testcases whose combination of input-values fulfilled the condition (param1 >= const2) And (’inout1 = 0)—failed to yield the expected result. The next report would then include all testcases without having to execute the original testcases on the embedded system again.Chapter 5: Trial application Diploma thesis M.5 Results The performance metrics show that the performance of the tool is satisfactory: even having to wait five minutes for a report is acceptable if it is taken into consideration that it takes 80 minutes to execute the tests.c shows that the specified function returns param1/const1 if this condition is fulfilled. the value of the deltaconstant in the formal specification can be decreased and new reports be generated after importing an updated formal-specification-file and the executed-testcases-file into the second part of the tool.. The testresult-evaluation-reports show that all testcases covering the fourth cell of the Header of dimension 1—i.e. To check the precision of the Floating-Point function-return-values. this time depends only on the number of table-cells and does not depend on the number of testcases. only the formal specification has to be corrected and new reports can be generated after importing the updated formal-specification-file and the executed-testcases-file into the second part of the tool. instead of returning param1/const2 as it is specified in the formal specification. and must then be executed again on the embedded system using PathFinder and the original Groupfile. If the implementation of the specified function is correct and the formal specification is faulty.txt and the C-file C Float2. A comparison between the formal-specification-file Spec Float2. It is not necessary to execute the C-Test-Harness on the embedded system again. if the formal specification is correct and the implementation is faulty. Wetzel March 9. 69 . However.

i. By logging and archiving spontaneous tests. analyzes the course of the project. the tool can be used to start creating a set of testcases with the desired specification-coverage even before the Implementation-phase has begun.e. If the tool is used to evaluate test results. 6. deviations between documentation and implementation result in testcases that fail to yield the expected results.g.and Testing-phases of a project. Automatic testresult-evaluation by the tool makes the time-consuming and error-prone tasks of manually defining the expected output for each testcase and comparing it to the actual test result unnecessary. the implementation might be changed without updating the documentation. Finally. A side effect that comes with the application of the tool to a software development process is enforced consistency between documentation and implementation. suggests future improvements to the tool. as shown in Chapter 5: Trial application. which are compared to the actual test results of the implementation. It has been observed that one of the factors that degrade the value of program documentation over time is the fact that consistency between documentation and implementation is not enforced. This is due to the fact that the expected outputs. because they are documented and can be repeated. testresult-evaluation-reports can serve as indicators for faulty implementation parts.1 Application of Results This work is applicable to the testing of single functions in any phase of an embedded systems software development process. the usefulness of such tests is increased. While the most obvious application is in the Implementation. These logs can also be used to measure the quality of tests that were executed by someone else. where values are being entered by a tester during test execution. e. Only if documentation 70 . are generated directly from documentation. The tool can be applied to measure and improve test quality by performing a specificationcoverage-analysis first and then optimize the testcase distribution by adding testcases to fill gaps or removing redundant testcases.Chapter 6 Conclusion This chapter discusses the results of using this work to automatically test software on embedded systems. by a team member or an external company hired to do the testing. and draws some conclusions.

Chapter 6: Conclusion

Diploma thesis M. Wetzel

March 9, 2004

and implementation are consistent, can the outputs of executed testcases match the expected output that is generated from documentation. Using the tool in an embedded systems software development project, where formal specifications exist for single functions, can lead to a reduction of costs related to testing, while the quality of tests is improved. The documentation of software for embedded systems is a prime application area for Tabular Expressions, because such software rarely contains complex graphical interfaces. In safety-critical or mission-critical applications, the additional project time required for writing formal specifications immediately pays off due to a reduction of bug-related costs. The tool augments the White-box Code-coverage tools developed by Ashling Microsystems Ltd. with a Black-box Specification-coverage tool that is purely based on documentation, giving Ashling Microsystems Ltd. a competitive edge and showing a new application for Tabular Expressions in the increasingly important field of embedded systems software.

6.2

Critical Reflexion

All features the tool was intended to have—and some features that were not in the initial scope of this work—have been realized. Although Yacas was able to fulfill its requirements, the two bugs that were discovered and published by the author of this thesis at the end of the project are still not fixed and make using Yacas for Floating-Point-arithmetic more difficult than it was expected (see Chapter 4.3.7: YacasFile). If a precise specification of the table-cell-expression-syntax, as it should be supported by the tool, had been available, or if there had been enough time to create one, writing a parser and evaluating the table-cell-expressions with the tool might have been advisable. However, in the absence of both, there was—and still is— no other Computer Algebra System available that fulfills all of the requirements listed in Chapter 3.2.1: Parsing table-cell-expressions. If one is developed and should be used instead of Yacas, the only adaptation that has to be made to the tool is to write and use another Java-class instead of YacasFile that handles the communication with this CAS and is able to create a Report-object from a FormalSpecificationand a Testcases-object. Due to the application of the Information-Hiding-principle invented by Parnas to the Module-Design of the tool, all design desicions that depend on Yacas being used as external CAS are encapsuled in the YacasFile-class. Even in the face of the bugs in Yacas, the design decisions that were made in the conceptual design phase of the tool remained valid throughout the entire project; the intended solution could be implemented without deviations. The general conditions of this work as they were defined during its preparation proved to be appropriate: it would have been hardly possible to complete the design and implementation of the tool at Ashling Microsystems Ltd. in Ireland in less than five months. On the other hand, spending more time in Ireland to complete the practical work would not have left enough time for writing this thesis after travelling back to Germany. 71

Chapter 6: Conclusion

Diploma thesis M. Wetzel

March 9, 2004

6.3

Limitations and Future Work

Like many other methods that are used for program documentation, Tabular Expressions are better suited to some types of programs than they are to others. The behavior of programs that manipulate data structures in any other way than changing variable values is difficult to specify with this method. The same applies to the behavior of programs that put constraints on intermediate execution states [Pet95]. This work can be applied only to terminating functions whose effects on data structures can be specified using Tabular Expressions. In addition, it must be possible to derive the success or failure of a tested function from the contents of its data structures in the initial and final states of its execution. Even though the tool fulfills all its requirements, it has been designed as a prototype to show the possible applications of the methods used in this work. Therefore it lacks some of the features that would be required of a commercial product, and users of the tool should be aware of the following limitations: • Only manual creation of input-files: the tool does not support the creation of inputfiles, neither of formal-specification-files nor of testcases-files. • No checks for correctness: the tool does not check the syntactic or semantic correctness of Tabular Expressions. • No information about individual testcases: the tool does not provide information about which testcases failed and which were executed successfully; only overall statistics and statistics for invididual cases are shown. This feature was not part of the scope of this project because it would require a system for storing information about individual testcases to be implemented. • Batch-processing is not supported: the tool does not support command-line parameters and can not be executed in batch-mode; only graphical interaction is supported. The Batch-processing facilities provided by AsIDE and PathFinder are used only to pass input-files as parameters. While commercial products must be able to execute tests and evaluate test results without any human interaction to allow for huge testsuites being run overnight, this is not required of a prototype that is intended to demonstrate possible applications of the used methods. • Constants need to be changed in code: the attributes of the Constants-class that determine many aspects of the behavior of the tool have to be changed in the code if they need to be adapted, and the Constants-class must be recompiled afterwards. The tool does not support them to be changed during the execution of the tool, nor can they be imported from an external file. • Limited equality checks of Floating-Point-values: to avoid the Yacas-bugs described in Chapter 4.3.7: YacasFile, equality checks of Floating-Point-values should be replaced by interval checks. • Only C is supported: the specified function must be written in C, and only a C-TestHarness can be generated 72

Chapter 6: Conclusion

Diploma thesis M. Wetzel

March 9, 2004

Those limitations should be addressed in future versions of the tool, e.g. by taking the following steps: • Integration into new Table Tool System (TTS): by integrating the tool into the new TTSframework that is being developed by the Software Quality Research Lab (SQRL) at the University of Limerick, the tool can use functions to create, modify and check Tabular Expressions that are provided by other applications in this framework. Furthermore, TTS includes methods to parse and store table-cell-expressions, which allows Yacas to be replaced by an internal evaluation without having to implement another parser in the tool. • Testcase management: SQRL intends to implement a testcase management system that is capable of generating testcases and storing data about individual testcases. The tool can then display and record the success or failure of each individual testcase, allowing an easier tracking of failed testcases. • Facilitate Batch-processing: it should be possible to trigger the execution of every important operation with command-line parameters. Since both AsIDE and PathFinder fully support Batch-processing via command-line parameters, including this functionality in the tool would allow time-consuming tasks to be controlled by scripts and executed whenever ressources are available. • Use of new integrated Ashling Microsystems Ltd. tool-suite: during the writing of this thesis, Ashling Microsystems Ltd. and LDRA announced a cooperation agreement to integrate their tools into a common integrated toolset. Once their tools work together, the tool will be able to benefit from the features offered by the LDRA-tools, e.g. Unit-Testing with TBrun. Prior to this cooperation, TBrun could not use PathFinder to perform tests on embedded system due to missing communication facilities. • Include a tool function to change constants: the tool should provide a function to change constants and make those changes persistent. If it is not possible to change all constants within the tool itself, it should be possible to change them in an external configuration-file without having to recompile any classes at least. • If Yacas—or any other external CAS—is continued to be used for evaluating table-cellexpressions, the tool should include an option to automatically replace equality checks of Floating-Point-values in formal specifications with Interval-checks. The length of the intervals should depend on the tool and not on the specification to make the specification independant from the arithmetic differences between the external CAS and the embedded system. • Support for other programming languages: with C being the predominant language of embedded systems software at the moment, there seems to be little need to support other programming languages. However, if another programming language should be used, the CFile-class would have to replaced by a class capable of parsing a source file of this programming language and extracting the specified function. The CTestHarnessFile-class would need to be replaced by a class capable of generating a syntactically and semantically correct Test-harness, which could then be compiled and executed on the target embedded system. 73

Chapter 6: Conclusion Diploma thesis M. the application of the methods described in this work to software for embedded systems. 2004 It is expected that further suggestions for improvements in future versions of the tool will result from applying the tool and the methods in this work to small research and industrial projects. Wetzel March 9. Despite being a prototype and therefore lacking some features that might be desirable in a production environment. The existence of such tools greatly increases the potential value of formal specifications. Those benefits are likely to increase even further with the application of future versions of the tool that do not share the limitations of this prototype. the application of the tool makes the time-consuming and errorprone tasks of manually creating test-suites and evaluating test results unncessary. According to [Pre92]. will help to increase the quality and reduce the costs of software that is being developed for this increasingly important market. these tasks are jointly responsible for the high costs involved in testing. especially in safety-critical and mission-critical applications.4 Conclusion The development and trial application of this tool have shown that is it feasible to automatically test software functions on embedded systems and evaluate the test results using a formal specification of the tested function. so applying the methods described in this work aids in reducing test costs while helping to achieve a higher test quality. and the gains that can be achieved by the application of the tools in software development projects more than fully compensate the extra costs involved in writing formal specifications. which helps to reduce maintenance costs by providing maintenance programmers with an accurate and consistent description of the intended behavior of the program. 6. While Tabular Expressions may not be suited to the documentation of every program type. In addition. using tests based on documentation enforces consistency between documentation and implementation throughout the entire project. 74 .

if not. the testcase has failed. Terms related to Tabular Expressions are defined by Parnas in his papers. • have a special meaning or • need to be explained for other reasons to fully understand the document. in [Par92]. a case is defined by a set of input-values for all variables used in a Tabular Expression. • Executed testcase: A testcase that has already been executed with PathFinder and includes both input. • Formal specification: A specification that uses Tabular Expressions to precisely describe the outwardly visible behavior of one C-function. • Determine specification-coverage: The evaluation of a Tabular Expression for a set of testcases to see which cases have been tested how often. If the values are the same. The following terms have a special meaning in this document: • Case: Used in the context of specification-coverage and tables. a combination of Guard-cells evaluates to T rue. • Evaluation of test results: The comparison of the results of a set of testcases with the values defined in the specification for those cases. Using a definition that does not require Tabular Expressions. Testresultevaluation-reports always contain the specification-coverage as well. a case is the distinct behavior of a function that is specified for some combinations of input-values.Appendix A Term definitions This appendix contains definitions for terms used in this work that either: • are used in a different context than normally. selecting one Value-cell (for Inverted and Normal Tables) or one Guard-cell (for Vector Tables). e.and output-values for the formal specification of the function it is used to test. I . Evaluated with these input-values. • External program: An existing application that is used by the tool and whose implementation is not part of this work. the case has been tested successfully by the testcase.g. This selected cell is the case.

• Raw testcase: A testcase containing input-values for the formal specification of the function it is used to test. • Tool parts: The two parts the tool consists of. • Tool: The computer program implemented in this work.or Floating-pointvalue for a given set of input. testcases can be either executed or raw. • Imported testcases: The set of testcases that was imported last into the tool. • Input-values: A set of values for all Parameters and Input-variables of a formal specification. • Output-values: A set of values for all Output-variables of a formal specification. a function-return-value must be also included. if the described feature is not specific to one part only. In the second tool-part. II . used if the fact should be stressed that the tool is intended as a working prototype showing the possible applications of the used methods in real-life-projects. including the code. Synonym for ’both tool parts’. If the specified function is not of type void. 2004 • Guard-cell: A table cell whose expression evaluates to T rue or F alse for a given set of input-values. Wetzel March 9. while in the first tool-part only the import of raw testcases is possible. • ReportGeneration: The name of the second tool-part. A question mark can take the place of a value if the value is to be entered during test execution. • Prototype: Synonym for ’tool’. • TestPreparation: The name of the first tool-part. • Meaningful line: A line in a file that is neither a comment line nor an empty line. • System: The tool and the external programs used by it. • Thesis: This Diploma thesis. • Table cell expression: The mathematical expression contained in a table-cell. • Value-cell: A table cell whose expression evaluates to an Integer.Appendix A: Term definitions Diploma thesis M. • Tabular Expression : The maingrid and the headers of a table.and output-values. • Specified function: The C-function specified by a formal specification. • Work: This thesis and all produced documents.

* so this flag can be changed any time without loss of data */ boolean replaceExpressionWithReportStatistics = true. // the separator. and are not displayed. III .Appendix B Constants This appendix contains the static attributes defined in the Constants-class that may be adapted by users to change the behavior of the tool. The modifiers public static final are common to all attributes. double 16) * the number of digits in testcase-input-values also should be * limited to this number */ int validFloatDecimalPlaces = 14.and commentLines are used in files generated // and imported by the toolParts String majorSeparatorLine = "=====". /* this defines the number of decimal places Yacas will use for its * evaluations * it should be 2 less than the number of digits the used PathFinder* type for float-values returns to avoid errors (PathFinder-’float’ * returns 6 digits. /* this is the string that separates report results from original * expressions in some cells * it must not appear in table-cell-expressions */ String reportExpressionSeparator = "ß". the report statistics replace the original * table-cell-expressions * if it is false. String minorSeparatorLine = "-----". String commentLine = "//". /* if this flag is true. the original table-cell-expressions are appended * and shown in curly braces in the cells as part of the report * note that the original expressions are always saved in the files.

2004 // this is the minimal general precision required for Yacas to // circumvent the floating-point-bug int yacasMinimumErrorFreeGeneralPrecision = 20. // these are strings used in the generated C-file String testHarnessLastTestcaseVariable = "last testcase". a warning message appears each time * a new report is going to be generated or imported and the * previously generated one has not been saved yet * it has no effect on the warning messages at closing the program */ boolean activateDataLossPrevention = true. String functionVariableTypeReal = "real". the tool will parse Table-Guard-Cells * to make sure equations involving float-values yield valid results * Since this is a time-consuming operation. // these are the types of variables and functions permitted // in the formal specification String functionVariableTypeInt = "int". Wetzel March 9.and output-variable */ String praeValueString = "’". // these are the types used in the imported and generated C-files String functionVariableCIntType = "long". /* if this flag is set to true. String postValueString = "’". /* if this flag is set to true. to distinguish between the value * before the function execution and after it. String functionVariablePathFinderRealType = "double". * The use is only permitted if this variable is declared as both * input. it can be turned off * by setting the flag to false */ boolean parseTableGuardCells = true. /* PathFinder limits the lengths of identifiers to 30 characters * it must be possible to append a ’ ’-character to function * identifiers => length one less */ int variableIdentifierMaxLength = 30. String functionVariableCRealType = "double". IV .Appendix B: Constants Diploma thesis M. int functionIdentifierMaxLength = variableIdentifierMaxLength . /* these strings must precede/postcede a variable identifier * in the formal specification. // these are the types used in the generated PathFinder -Groupfile String functionVariablePathFinderIntType = "long".1.

2 */ boolean displayWarningAtSpacesInPathFinderOutputfile = true. // raw testcases may contain a ?-character instead of a value.rep". String defaultGeneratedReport = "Report. /* these are default filenames for files generated by the toolParts * the default location is the directory the tool is executed from */ String defaultConfigFile = "Tool.put".put". String defaultGeneratedGroupfile = "TestExec.cfg". String testHarnessBreakpointFunction = "PathFinderBreakpointFunction".1. a warning message is shown if a groupfile * with an outputfile containing spaces in its path is about to be * generated. V . try setting this constant to a lower value */ int readYacasOutputfileBufferDelay = 20. the shorter is the waiting time! * if report generation of large specifications causes errors without * error-messages. // if imported into toolPartOne String testcaseRawUndefinedInputValue = "?". /* if this flag is true. /* used in the formula to determine how long the read-operation of a * Yacas-file has to wait before reading to prevent buffer underrun * the higher the value. // how long each loop-turn sleeps before trying to read // the yacas-file again int readYacasOutputfileSleepInterval = 10.c".grp". // how many loop-turns the tool waits before prompting the user int readYacasOutputfileTreshold = 300. String defaultPathFinderOutputfile = "PathFOut.Appendix B: Constants Diploma thesis M. which results in an error in PathFinder version 1.put". String defaultYacasOutputfile = "YacasOut. 2004 String testHarnessInternalCounterVariable = "internal counter". String defaultYacasInputfile = "YacasIn. String defaultGeneratedCTestHarness = "TestFunc. Wetzel March 9.

Apart from the overall number of lines. the number of empty lines. Table C. each package and all packages of the tool together. VI . comment lines and other lines is also displayed.Appendix C LOC This appendix lists the number of lines that are contained in each Sourcefile.1: LOC has been created with a custom-written tool that is implemented in Java.

java ToolDataFile.java Methods.java GeneratedReportFile.java — CFunction.java Groupfile.java — — # lines 38 38 40 40 77 411 262 295 211 77 35 101 449 31 35 96 73 103 1243 457 248 292 1684 6180 45 40 53 138 107 60 38 66 35 300 880 55 172 138 1851 277 104 220 1576 335 77 2589 10836 empty 4 4 5 5 8 40 32 41 23 11 3 16 63 3 4 14 11 13 121 48 28 42 174 695 5 4 8 17 20 10 5 13 3 42 124 11 28 19 275 27 10 28 188 43 10 306 1302 March 9.java Report. 2004 comment 8 8 8 8 18 59 30 26 25 10 12 12 62 10 11 12 14 16 102 44 33 25 200 721 14 12 13 39 9 12 8 11 11 23 73 9 13 21 190 68 15 32 152 47 15 329 1295 other 26 26 27 27 51 312 200 228 163 56 20 73 324 18 20 70 48 74 1020 365 187 225 1310 4764 26 24 32 82 78 38 25 42 21 235 683 35 131 98 1386 182 79 160 1236 245 52 1954 8239 Table C.java ExecutedTestcase.java CFile.java — ReportGeneration.java RawTestcasesFile.java Testcases.java TestcasesFile.java Data.1: LOC VII .java TabularExpression. Wetzel Sourcefile TestPreparation.java TabularExpressionFile.java ImportedData.java TwinJFrame.java — Constants.java ToolFile.java — Application.java ImportedReportFile.java PathFinderOutputfile.java CTestHarnessFile.java Testcase.java HasDefault.java MultipleEnvironmentException.java Gui.java FormalSpecification.java GridLayoutExtension.java ToolVariable.java ConfigFile.java RawTestcase.Appendix C: LOC Package testPreparation testPreparation reportGeneration reportGeneration files files files files files files files files files files files files files files files files files files files files exceptions exceptions exceptions exceptions dataStructures dataStructures dataStructures dataStructures dataStructures dataStructures dataStructures dataStructures dataStructures dataStructures dataStructures common common common common common common common — Diploma thesis M.java ImportedFile.java WrongSyntaxException.java ExecutedTestcasesFile.java — CanceledByUserException.java FormalSpecificationFile.java YacasFile.java GeneratedFile.

every public method in the tool that uses methods or attributes of other classes except static attributes in the Constants-class. and standard Java-classes. static methods in the Methods-class.Appendix D Uses Relation ’Uses Relation’-documents are proposed by Parnas in [DP85] to show which modules of a system depend on the correctness of which others. and standard Java-classes is listed in the first two columns of the figure together with the class it belongs to. they are used by methods that are called by the method in this row • ”*” means that the method in this row is a part of the class in this column. The classes that are used by methods of other classes are vertically printed in the first row of the figure. In Figure D.e. static methods in the Methodsclass. Public methods that are not contained in the first two columns do not use methods or attributes of other classes except static attributes in the Constants-class. The classes TestPreparation and ReportGeneration that contain the main-methods of the two tool parts are not included in the class-list because they are not called by any other methods.1: Uses Relation. i. The exception-classes do not have any public methods apart from their constructors. The table-cells have the following syntax: • ”X” means that either methods or attributes of the class in this column are used directly by the method in this row • (x)” means that either methods or attributes of the class in this column are used indirectly by the method in this row. and therefore uses it automatically VIII .

Wetzel March 9.Appendix D: Uses Relation Diploma thesis M. 2004 Figure D.1: Uses Relation IX .

In both tool parts. the other one containing all the other information included in the specification like name. or the filename of the imported C-file displayed in blue color. Input. Viewing a specification or report results in two additional windows being opened: one containing the headers and maingrid of the table. Several reports and formal specifications can be viewed in multiple windows simultaneously. or the filename of the imported Testcasefile displayed in blue color. user-defined auxiliary functions and remarks. • If and which C-file has been imported: either ’none imported’ displayed in red color if no C-file has been imported yet. the import of a specification clears imported testcases and C-functions to prevent the generation of files or reports with inconsistent data. Each part of the tool runs in a single window that contains all information and interaction elements. Closing one of these viewing windows results in the other one being closed also. E.and Output-variables. type and Parameters of the function.1 First part of the tool The following non-editable information is displayed in the window in which the first part of the tool is executed : • If and which formal specification has been imported: either ’none imported’ displayed in red color if no specification has been imported yet. Viewing other imported data opens only one additional window. or the filename of the imported specification displayed in blue color.Appendix E GUI This appendix lists all GUI-elements of either tool part. Constants. • If and which Testcase-file has been imported: either ’none imported’ displayed in red color if no Testcase-file has been imported yet. X .

2004 • If and which Testharness-file has been generated: either ’none generated’ displayed in red color if no Testharness-file has been generated yet. or the filename of the generated Testharness-file displayed in blue color. • If and which PathFinder-location has been specified: either ’not specified’ displayed in red color if the location of PathFinder has not been specified yet. • If and which formal specification has been used for the last generated Testharnessfile: either ’none’ displayed in black color if no specification has been imported yet. this filename in blue color if the last Testharness has been generated with this specification or this filename in red color if the current specification has not been used for the generation of the last testharness. The button ’View testcases’ changes its label to ’View raw testcases’ as soon as a Rawtestcases-file has been imported. The window also contains the following buttons. • If and which C-file has been used for the last generated Testharness-file: see formal specification for Testharness-file • If and which PathFinder-Groupfile has been generated: either ’none generated’ displayed in red color if no PathFinder-Groupfile has been generated yet. XI . Buttons whose preconditions are not fulfilled are grayed out and can not be selected. which are displayed as plain buttons without additional graphics.Appendix E: GUI Diploma thesis M. The names of the buttons are displayed as centered text in the buttons. the filename of the current specification displayed in black color if no Testharness has been generated yet. Wetzel March 9. • If and which AsIDE-location has been specified: either ’not specified’ displayed in red color if the location of AsIDE has not been specified yet. or the filename of the generated PathFinder-Groupfile displayed in blue color. or the specified filename displayed in blue color. • Which location has been specified for the Config-file: the directory where the tool saves the Config-file at program exit displayed in blue color. • If and which formal specification has been used for the last generated PathFinderGroupfile : see formal specification for Testharness-file • If and which Testcase-file has been used for the last generated PathFinder-Groupfile : see formal specification for Testharness-file • Which filename has been specified for the PathFinder-output-file: the filename displayed in black color if no PathFinder-Groupfile with this PathFinder-output-file has been generated yet. or the specified filename displayed in blue color. or displayed in blue color otherwise.

Appendix E: GUI Diploma thesis M. C-Test-Harness generated PathFinder-location specified Table E. C-file imported Specification-file imported. Testcase-file imported AsIDE-location specified.1: GUI-elements of Tool part 1 XII . 2004 Name of Button Import specification Import & view specification View specification Import raw testcases Import & view raw testcases View testcases Import C-Function Import & view CFunction View C-Function Generate testharness Generate Groupfile Specify PathFinderoutputfile-location Specify AsIDElocation Invoke AsIDE Specify PathFinderlocation Invoke PathFinder Specify Configfiledirectory Restore Configfiledirectory-defaults Exit program Action associated with Mouse-klick on Button Left- Preconditions Import formal specification file Import formal specification file and view imported data View imported specification Import Raw-testcases-file Import Raw-testcases-file and view imported data View imported testcases Extract specified function from C-file Extract specified function from C-file and view imported data View extracted specified function Generate C-Test-Harness-file Generate PathFinder-Groupfile Set filename and location for PathFinder-outputfile Set filename and location of external program AsIDE Invoke external program AsIDE with generated testharness as parameter Set filename and location of external program PathFinder Invoke external program PathFinder without any parameters Set location for Config-file Restore default location for Config-file Exit the program and write Config-file Specification-file imported Specification-file imported Specification-file imported Any testcases-file imported Specification-file imported Specification-file imported C-file imported Specification-file imported. Wetzel March 9.

Appendix E: GUI

Diploma thesis M. Wetzel

March 9, 2004

E.2

Second part of the tool

The same rules that apply to the buttons in the first part of the tool also apply to the buttons in the window in which the second part of the tool is executed. The button ’View testcases’ changes its label to ’View raw testcases’ or ’View executed testcases’ depending on which type of testcases-file has been imported last. The button ’View report’ changes its label to ’View current report’ or ’View imported report’ depending on whether a report has been generated or imported last. The following non-editable information is also displayed in the window: • If and which formal specification has been imported: : either ’none imported’ displayed in red color if no specification has been imported yet, or the filename of the imported specification displayed in blue color. • If and which Raw-testcases-file has been imported: either ’none imported’ displayed in red color if no Raw-testcases-file has been imported yet or the last imported testcasesfile contained executed testcases, or the filename of the imported Raw-testcases-file displayed in blue color. • If and which Executed-testcases-file has been imported: either ’none imported’ displayed in red color if no Executed-testcases-file has been imported yet or the last imported testcases-file contained raw testcases, or the filename of the imported Executedtestcases-file displayed in blue color. • If and which Yacas-location has been specified: either ’not specified’ displayed in red color if the location of Yacas has not been specified yet, or the specified filename displayed in blue color. • If and which location has been specified for the Yacas-input- and outputfiles: the directory the tool creates the Yacas-input-files in and reads the Yacas-output-files from displayed in blue color. • If and which report has been generated or imported: either ’none imported’ displayed in red color if a report has been neither generated nor imported, ’GENERATED’ displayed in blue color if the current report has been generated, or the filename of the imported report displayed in blue color if the current report has been imported. • If and which report-file has been written to disk: either ’not written to disk’ in red color if the current report (regardless if it was generated or imported) has not been saved to disk yet, or the name of the file on disk the current report has been saved to. • If and which location has been specified for the Config-file: the directory where the tool saves the Config-file at program exit displayed in blue color.

XIII

Appendix E: GUI

Diploma thesis M. Wetzel

March 9, 2004

Name of Button
Import specification Import & view specification View specification Import raw testcases Import & view rawtestcases View testcases Import executed testcases Import & view executed testcases Specify Yacaslocation Specify Yacas-filesdirectory Restore Yacas-files defaults Determine specificationcoverage Evaluate test results

Action associated with Mouse-klick on Button

Left-

Preconditions

Import formal specification file Import formal specification file and view imported data View imported specification Import Raw-testcases-file Import Raw-testcases-file and view imported data View imported testcases Import Executed-testcases-file Import Executed-testcases-file view imported data and

Specification-file imported Specification-file imported Specification-file imported Any testcases-file imported Specification-file imported Specification-file imported

Set filename and location of external program Yacas Set location for Yacas-input- and outputfiles Restore default location for Yacasinput- and -outputfiles Determine specification-coverage generate and view report , Yacas-location specified, Specification-file imported, any testcases-file imported Yacas-location specified, Specification-file imported, Executed-testcases-file imp.

Determine specification-coverage and evaluate test results, generate and view report Import report-file Import report-file and view imported data View the latest generated or imported report Write the latest generated or imported report to disk Set location for Config-file Restore default location for Config-file Exit the program and write Config-file

Import report Import & view report View report Write report to disk Specify Configfiledirectory Restore Configfiledirectory-defaults Exit program

Report generated or Report imported Report generated or Report imported

Table E.2: GUI-elements of Tool part 2

XIV

Appendix F

File formats
This appendix defines the formats of all files that are either generated or imported by the tool. The following constraints are put upon all files described in this section: • Type: Unless otherwise stated, all files are ASCII-Textfiles containing only 7-Bit-ASCIIcharacters. • Filenames: Names and paths of files that have to be processed in any way by AsIDE or PathFinder must be limited to 7-Bit-ASCII-characters and must not contain spaces. • Newlines: All files use one Carriage-Return- and one Line-Feed-character together as newline-indicator, as is the standard on Windows platforms. • Case-sensitive: All files and String-comparisons are case-sensitive unless otherwise stated. The following constraints are put upon the types and the identifiers used as names of the specified function , Parameters, Constants, Input- and Output-variables in the formal specification, the C-file containing the specified function and the testcases: • Length: PathFinder limits the length of identifiers to 31 characters. One character is needed by the tool, which leaves 30 characters for names of Constants, Parameters, Input- and Output-variables. Function names are limited to 29 characters in length. • Composition: Only alphanumeric characters are allowed as part of identifiers. The underscore is not permitted as part of identifiers since Yacas treats it as a special operator. • Uniqueness: Identifiers used as names of the specified function , Parameters, Constants, Input- and Output-variables must be unique (case-insensitive). The only exception are variables used as both Input- and Output-variables, in which case the same identifier has to appear as both (case-sensitive). In this case the input-value of the variable is referenced in a table-cell-expression by putting a leading apostrophe before its name, while the output-value is referenced by putting a trailing apostrophe after its name. For example, if variable X is used as both Input- and Output-variable, in a table-cellexpression ’X would reference the input- and X’ the output-value of the variable. XV

Tabs are also allowed. On errors occuring during the parsing of a file. the value of the program-Constant determining the number of valid float decimal places should be 2 less than the number of decimal places PathFinder returns (6 for ’float’. while a < token > is to be included literally into the file. In all cases. be it variables or testcases. which is fixed to 2 in this prototype. the C-type ’long’ and the PathFinder-type ’long’ are used.or empty lines between phrases may be inserted to increase readability. Input. additional comment. the reading operation is canceled and the user may continue to work with the system as if the erroneous reading operation had not occured. the tool has no restrictions concerning the number of finite elements it supports of any given type. Unless otherwise noted. More spaces may be inserted before. no attempts at solving parsing errors are made. Wetzel March 9. they are for better readability only. which is mentioned for every one of those environments. Input. Whenever possible.and Output-variables may only have the type ’real’ or ’int’. Newlines must not be inserted between the angle brackets. To achieve correct results when using floating-point-values in equations. Unless otherwise stated. Input-values of testcases should be limited to this number of valid float decimal places also. • Supported types: Parameters. A list with all PathFinder-Groupfile-commands can be obtained from the PathFinder-Usermanual. where the type and the name of a variable has to be entered.Appendix F: File formats Diploma thesis M. Unless otherwise noted. Constants.and Output-variables must not be equal to PathFinder-commands which can be used in a PathFinder-Groupfile (caseinsensitive). the number of the line at which the error occured is displayed. while empty lines must consist only of whitespaces. the C-type ’double’ and the PathFinder-type ’double’ are used. A < token > indicates a placeholder-string which has to be substituted with an appropriate value. between and after tokens to increase readability. XVI . for example if mandatory information is missing from the file. Both are ignored during parsing except in environments where lines are imported 1:1 into the tool without parsing. a detailed error message with the likely source of the error is also displayed. For ’int’-variables. 2004 • Conflict-free: The identifiers of Parameters. Phrases embedded into angle brackets must be separated from other phrases by newlines. The angle brackets must no be included in the files. With the tool being a prototype. The type of the specified function may be either ’real’. or concerning the maximum of scalar numbers. For ’real’-variables. apart from the restrictions that are imposed by the available memory space. The first non-whitespace-characters of Comment lines must be two slashes. One exception is the number of dimensions. the number of spaces between words in the file does not matter except that at least one space must be at every place where there is one inside the angle brackets. 16 for ’double’). ’int’ or ’void’. Phrases indicating which information has to be supplied in the files are put inside angle brackets. An example would be < type name > .

Since there is no tool available at the moment for creating formal specifications using tabular expressions. Unless otherwise noted. The file consists of the following environments... closing environment lines. FUNCTION This environment contains only one meaningful line with the result type of the specified function and its name: < type name > This environment may contain empty and comment lines.1 Formal specification Text-Editor Tool part 1 Created by: Read by: This file contains a formal specification of a function using the tabular expressions described in [Par92]. PARAMETERS This environment contains the parameters of the specified function in the following form (one line per parameter): XVII .1 CONSTANTS 0. empty lines and comment lines. the examples which are used in this work must be created with a text editor in this format.1 AUXILIARY FUNCTIONS 0.1 REMARKS 0. The report generated by the tool uses the same format... The function name and type must satisfy the constraints described in Appendix F. If there are any other lines.1 PARAMETERS 0. lines inside an environment.1 OUTPUT VARIABLES 0.. i.1 INPUT VARIABLES 0.. lines other than empty ones or comment lines that are not part of an environment. 2004 F..1 TABLE 1. an error occurs.e.1 Environments are opened with a line containing the name of the environment and an opening curly bracket separated by one or more spaces.maximum occurences of environment in file FUNCTION 1.Appendix F: File formats Diploma thesis M. The very first line of the file must be exactly the following string: < FILETYPE: SPECIFICATION > The rest of the file consists of opening environment lines.. the order of lines inside an environment is not important. Wetzel March 9.. which may appear in an arbitrary order in the file: Name Minimum. and are closed with a line containing only a closing curly bracket. Every line between those two lines is interpreted as part of the environment.

CONSTANTS This environment contains global variables which have the same constant values for all testcases of the specified function and are used as additional input beside the Parameters and the input variables. because those testcases do not define values for Outputvariables and Yacas therefore cannot evaluate the expressions in the table-guard-cells. trying to determine the specification-coverage of a set of raw testcases results in an error. Apart from the usual name and type constraints described in Appendix F.and Output-variables must satisfy additional constraints concerning the uniqueness of names described in Appendix F. They are listed in the following form with one line per output variable: < type name > This environment may contain empty and comment lines. Wetzel March 9. The parameter name and type must satisfy the constraints described in Appendix F.Appendix F: File formats Diploma thesis M. Apart from the usual name and type constraints described in Appendix F. Unlike these. INPUT VARIABLES This environment contains global variables which are used by the specified function as additional input beside the Parameters and have to be initialised before the specified function is called. their values are determined in the formal specification and XVIII . This environment is optional. variables used as both Input. It is important that the only permitted use of Output-variables is in table-value-cells. If they are used in table-guard-cells. since a specified function need not use any global variables as output. since a specified function need not use any global variables as input. They are listed in the following form with one line per input variable: < type name > This environment may contain empty and comment lines. The order of the lines is important and must be exactly the same as the order in the specified function itself. 2004 < type name > This environment may contain empty and comment lines.and Output-variables must satisfy additional constraints concerning the uniqueness of names described in Appendix F. variables used as both Input. since a specified function need not have any parameters. OUTPUT VARIABLES This environment contains global variables used by the specified function as additional output beside the return value. This environment is optional. This environment is optional.

=. They are listed in the following form (one line per constant): < type name = value > This environment may contain empty and comment lines. This environment is optional. • Although a maximum line length of at least 67. > All lines inside this environment are copied 1:1 into the Yacas-input-files including whitespaces. <=. Wetzel March 9. AUXILIARY FUNCTIONS This environment contains user defined functions which are used in the table environment in a syntax compatible with the Computer Algebra System (CAS) Yacas used by the tool. Not. • Nested tables are not supported. the following restrictions apply: • Quantifiers are not supported. ∗. To avoid precedence errors. (. empty and comment lines. )).ˆ. 2004 not in the testcases. no parsing is done by the tool. The %-operator is not allowed in expressions. The ß-character is not allowed in expressions either. <. Yacas-function definitions have the following syntax (one line per function): < functionname(comma-separated-list of parameter identifiers):=expression. braces should be used always XIX . >. since a specified function need not use any constants.000 is supported by the system. Yacas restricts the maximum number of tokens (operators and identifiers counted together) of a single table-cell-expression to 1988. • A valid expression is a syntactically correct expression that uses infix notation and consists of the following elements.9) – boolean-operators defined in the Yacas-syntax: And. since Yacas treats it as a special operator. since a tabular expression need not have any user-defined auxiliary functions. because it is used as a separator-character in report-files (see Appendix F. ! =. This environment is optional.Appendix F: File formats Diploma thesis M. /. =>. −. which may be separated by spaces or tabs: – identifiers of declared variables and constants – integer and floating-point-values – basic arithmetic operators(+. Or. TABLE This environment contains the core of the formal specification in the form of a tabular expression. Value is the string representation of the value the constant shall have and is to be entered without any quotes or other markers. Regarding the types of tabular expressions described in [Par92].

. As in vector function tables. the evaluation result of those ’valueheader’-cells is interpreted as function return value and its type must be compatible with the function type. All maingrid-cells must be value-cells. i.Appendix F: File formats Diploma thesis M. However. the equation sign is taken as default. • In vector function tables. all maingrid-cells and all header-cells apart from one header declared as ’valueheader’ must be guard-cells. The cells of the ’valueheader’ must be value-cells.or floatingpoint-value. • The tables must be syntactically and semantically correct and complete. • Guard-cells must either be empty (which has the same semantics as if they contained ’False’) or contain a predicate-expression that evaluates to ’True’ or ’False’ • Value-cells must contain a valid expression that evaluates to an integer. all header-cells must be guard-cells and all maingrid-cells must be value-cells. Wetzel March 9. the function name must be included in one of those cells if the function-type is not ’void’.5’ or ’2’ for functions returning a floating-point-value)..g. the maingrid-cells associated with this cell must be guard-cells which should contain the ’vectorheader’-identifier at least once.. • Only normal function tables. • Mixed vector tables have the same basic structure as vector function tables. parameterN) > . • In inverted function tables. omitting both vertical bar and equation sign has the same semantics as including the equation sign. The evaluation-result of those maingrid-cells is interpreted as after-execution-value of the Output-variable in the associated ’vectorheader’cell or as function-return-value. In this case. 2004 – calls to user-defined-functions which are defined in the Auxiliary Functionenvironment in a correct Yacas-syntax – calls to functions predefined with this name and syntax in Yacas like Round() or Trunc() (Yacas is case-sensitive and predefined functions are usually capitalized or multicapitalized like ArcTan()) • The use of functions in tabular expressions must follow the standard syntax for function calls: < functionname(parameter1. The evaluation result of those maingrid-cells is interpreted as function return value and its type must be compatible with the function type (e. XX . In the case of the identifier being followed by a vertical bar. followed by an optional equation sign. The cells of the ’vectorheader’ must contain exactly one identifier of a variable declared as Output-variable each. otherwise it must not be included in any of those cells. ’1’ for functions returning an integer-value and ’1. Additionally. • In normal function tables. inverted function tables.e. and its type must be compatible with the type of the Output-variable or function. . all header-cells apart from one header declared as ’vectorheader’ must be guard-cells. vector function tables and mixed vector tables are supported.. identifiers in ’vectorheader’-cells case may be followed by either a vertical bar or an equation sign in mixed vector tables.

only tables of type ’vector’ can specify ’void’-functions.2) is the element in the first row.. element(1. viewing reasons suggest dimensionsizes far below 100. < dimensionsizes dimensionsize1 dimensionsize2 . The first dimension counts the rows of the table. dimensionsizeN > This line determines the size of all dimensions the table has. It must contain exactly as many dimensionsizes as the number of dimensions specified by the dimensions-line. < valueheader number > This line must be included if the table is of the type ’inverted’. ’inverted’ and ’vector’ of the table types described in [Par92]. but never without one or with both together. The number indicates which header (or rather.and Output-variables. 2004 If the predicate expression of the maingrid-guard-cell associated with a ’vectorheader’cell that includes a vertical bar evaluates to ’True’. The type of the table must be compatible with the type of the specified function : tables of type ’normal’ and ’inverted’ cannot specify functions of type ’void’. If the table does have any other type. ’dimensionsize’ is also the maximum element index used in the dimension it belongs to. the header belonging to which dimension) has value cells instead of guard cells. but assumes it is both correct and complete.Appendix F: File formats Diploma thesis M. It contains the following maeningful lines which must be supplied in this order (empty and comment lines are allowed): < tabletype type > This line determines the type of the table. while the second dimension counts the number of columns. References to after-execution-values may only occur in ’vectorheader’-cells and in maingrid-guard-cells whose associated ’vectorheader’-cell contained a reference to this value and a vertical bar. The tool supports only 2dimensional tables. • Only functions specified by vector tables may use Output-variables. the presence of this line causes an error. For example. While in theory the size of a dimension is only limited by the available memory-space. ’Identifier references the before-execution-value. The number indicates which XXI . • If variables are declared as both Input. This is the only environment which has sub-environments itself. The tool does not check the table for syntactic or semantic correctness and completeness. The tool supports only the types ’normal’. < vectorheader number > This line must be included if the table is of the type ’vector’. while Identifier’ references the after-execution-value. Wetzel March 9. Since indizes for table cell elements start from 1. second column of the maingrid of the table.. the output-value of the Outputvariable or function in the ’vectorheader’-cell satisfies the specification. < dimensions number > This line determines the number of dimensions the table has. they may be used in table-cell-expressions with either a leading or trailing apostrophe. Dimensionsizes must be integer-numbers.

(1. empty and comment lines.1)). the header belonging to which dimension) does not contain guard cells. For example. (1. the next lower dimension is again increased by one.3). The following environments may be supplied in an arbitrary order: < HEADER number { > This line is the opening line of the header environment for the header belonging to dimension ’number’.Appendix F: File formats Diploma thesis M.. With each newline the index belonging to the highest dimension is increased by one until it reaches its ’dimensionsize’. XXII . The first line contains the tabular expression belonging to the first cell of this header. no parsing is done by the tool. On reaching the dimensionsize of the highest dimension again. the cells must contain valid variable identifiers of Outputvariables. in which case the next lower dimension index is increased by one. The order of the lines is important. Then the highest dimension index goes again from 1 up to its dimensionsize while all others stay constant.3). and so on. The lines inside this environment all have the form: < tabularexpression > All lines inside this environment are copied 1:1 into the Yacas-input-files including whitespaces. 2004 header (or rather. The function name must be included in one cell if the function is not of type ’void’. unless it has already reached its dimensionsize.2). The environment ends with a line containing only a closing curly bracket. Wetzel March 9. otherwise it must not be included in any of those cells. in which case the next lower dimension index is increased by one. except for tables of type ’vector’ if this header is the special ’vectorheader’: in this case. while all other indizes stay constant. unless it has already reached its dimensionsize. with the innermost going from 1 to dimensionsize for the highest dimension and the outermost doing the same for the lowest dimension. (2. A table environment must contain exactly one header environment for each dimension.3) would have 6 lines. empty and comment lines. this index is set again to 1 and the index of the next lower dimension is increased by one. one for each dimension. No parsing is done by the tool. < MAINGRID { > This line is the opening line of the maingrid environment for the table cells belonging to the main grid of the table.2).1). (2. The behavior is that of 2 or more nested loops.1). If the table does have any other type.e. a 2-dimensional table with the dimensionsizes (2. with their table-cell-expressions in the direction from the beginning of the file to the end of the file belonging to the following main-grid-elements: (1. (2. The first line contains the tabular expression belonging to the table cell with the lowest index in all dimensions (i. The lines inside this environment all have the form: < tabularexpression > All lines inside this environment are copied 1:1 into the Yacas-input-files including whitespaces. Then. the second line contains the tabular expression belonging to the second cell of this header and so on. (1. the presence of this line causes an error.

Wetzel March 9.h are needed for the specified function XXIII .Appendix F: File formats Diploma thesis M.1): • The name of the function • The type of the function • The parameters of the function: type. This environment is optional. the function has to satisfy the following requirements: • It must be able to run on an embedded system. The very first line of the file must be exactly the following string: < FILETYPE: C-FILE > Apart from the constraints on names and types described in Appendix F. name and order • All global variables used by the function must be defined either as Constants. For example.or Output-variables or both in the specification. the overall number of testcases executed or the number of testcases which did not fit any specified case may be included as a remark when a report is generated using this file format.2 C-File Text-Editor Tool part 1 Created by: Read by: This file must contain at least the function specified by the formal specification. parameter passing from the command line and direct user interaction may not yield valid results and should therefore not be included in the specified function • It must not use a function with the name ’PathFinderBreakpointFunction’ • It must be at least two lines long: one-line-functions are not supported If automatic generation of a test-harness should be accomplished. since the user does not have to include remarks in the formal specification. Reading and writing of files. additional requirements have to be met by the specified function : • No other imports than the C standard library stdio. 2004 REMARKS This environment contains lines the user wishes to be displayed on the screen when the file is viewed. F. empty and comment lines. no parsing is done by the tool. are displayed in the second window opened by the viewing function. All lines inside this environment including whitespaces. The function has to match the specification in all of the following aspects (the constraints placed upon the specification are described in Appendix F. or as Input.

neither before nor during nor after its execution The type and name of the function must be correct to allow the specified function to be extracted automatically by the tool. constants and parameters is needed for the execution of the specified function • The specified function does not need other methods to perform its task. a warning message is displayed to the user and he is given the choice to import the found function anyway or to continue the search. All variables included as Input. Apart from those requirement-checks. If not all variables included as Input. Declarations and definitions must have the following syntax to be recognized as such by the tool: < [extern—static] variable-type variable-name[=definition value][whitespaces]. If they do not match the specification exactly. including date of creation. filename of the specification and the filename of the C-File the specified function was imported from: < // comment > XXIV . The line with the closing curly bracket of the function must not be the same line that also included the opening curly bracket of the function. The latter option is especially important for the extraction of an overloaded specified function . 2004 • No initialization apart from the setting of global input variables. The function definition must have the following syntax to be recognized as such by the tool (parts inside [] square brackets are optional): < any modifiers [whitespaces] function-type [whitespaces] function-name [whitespaces]([parameter list])[whitespaces]{function body} > Whitespaces may include newlines. F. The syntax of the parameter list regarding type.[whitespaces] > Constants included in the specification are not checked in any way in the C-File.Appendix F: File formats Diploma thesis M. a warning message is displayed to the user. Wetzel March 9. If any of the other requirements are not fulfilled. or if the type of a C-declaration or definition did not match the type specified for this variable in the specification. it might be necessary to apply the necessary changes to the generated C-Test-Harness by hand using a text-editor.or Output-variables in the specification are declared or defined before the first function declaration. including comment lines.3 C-Test-Harness Tool part 1 AsIDE or other IDE and C-compiler for target embedded system Created by: Read by: This file contains the specified function inside a test harness generated by the tool.or Output-variables in the specification should be defind or at least declared at the beginning of the C-File above all functions. name and order of the function-parameters should be correct. Should any requirements not have been met. for global variable declarations and definitions. The following lines are included in this file: • C-Comment-lines beginning with a slash followed by an asterisk and ending with an asterisk followed by a slash. no further checks are made by the tool to ensure the implementation of the specified function in the C-File matches the specification. the tool tries to generate the C-Test-Harness nonetheless. The tool searches all lines above the first function declaration.

. > – <}> • A main method of type ’void’ without parameters which includes the following lines: – Opening line: < void main() { > – Declaration of the name of the specified function with a leading underscore (if type of function is not ’void’) and of all parameters as local variables with types and names matching the ones given in the specification: < type name > – Declaration and initialization of two local variables needed during test execution: < int lastTestcase = 0 > < int internalCounter = 0 > – Opening line of a loop: < do { > – Call of breakpoint-function: < PathFinderBreakpointFunction().and Output-variables included in the specification as global variables with the types and names noted in the specification.Appendix F: File formats Diploma thesis M. . > – Decrement of internal counter-variable: < internalCounter--. this name is declared as a global variable only once and without leading or trailing apostrophes: < type name > • The complete specified function copied from the original C-File • A function needed for setting a breakpoint during test execution: – < void PathFinderBreakpointFunction() { > – < return. > XXV . parameternameN). > – Call of the specified function . setting the local variable functionname to the return value of the specified function (if type of function is not ’void’): < functionname = functionname(parametername1.. > – Call of breakpoint-function: < PathFinderBreakpointFunction(). > – Closing line of loop: < } while (lastTestcase == 0). If a name is listed in the specification as both an Input-variable and an Output-variable. Wetzel March 9. using the local variables as parameters (if the specified function has any parameters).h> > • Declaration of all Constants as symbolic constants: < #define name value > • Declaration of all Input.. 2004 • An import-statement for the C standard library: < #include <stdio. > – Increment of internal counter-variable: < internalCounter++.

or semi-automatic-generation Tool part 1 (normal sequence). but must have the form []decimalNumber. the symbol information has to be included in that generated file or another file which can be imported by PathFinder . The very first line of the file must be exactly the following string: < FILETYPE: RAW-TESTCASES > Whenever this line occurs later in the file. it is assumed that it starts a new set of testcases. if needed for every testcase. If only needed once. the user is prompted to enter a value for this undefined variable during execution of this testcase. In this case. the user is asked if he wants to import all sets of testcases or only the last one. F. Each testcase consists of lines defining one Parameter or Input-variable each: < name = value > The name must be included as either Parameter or Input-variable in the specification.4 Imported raw testcases Text-Editor or any mean of automatic.minus sign and the number for negative values. Wetzel March 9. The object code must then be built into a file which can be read by PathFinder. adding the following elements by hand may be necessary: • Additional imports needed by the specified function apart from the C standard library • Methods needed for initialization prior to calling the specified function . for example by using the SymFinder-utility developed by Ashling Microsystems Ltd. There must not be any whitespaces between the . If this line occurs more than once in the whole file. Tool part 2 (alternative sequence) Created by: Read by: This file contains one or more sets of testcases which were created by the user. 2004 – Closing line of main method: <}> If either the automatic generation does not work because the original C-file does not satisfy all requirements or for any other reason. insertion of these methods-call inside the loop before the breakpoint-label • Methods called by the specified function The file (either generated or generated and improved by hand afterwards) may then be compiled by any C-compiler capable of creating object code for the target embedded system. Instead of assigning a fixed value. In this case. which creates a PathFinder-project-file. The value must be a string representation (without quotes) of a value suitable for the type of the variable specified in the specification. insertion of these method-calls before the loop. a single question mark may take the place of ’value’ on the right side of the assignment.. Floating-point-values must not be fractions or use exponents.decimalNumber. XXVI . The dot and at least one decimal place are mandatory. the automatically generated C-Test-Harness may be corrected and improved by hand with any text-editor or Integrated Development Environment suitable for editing C-files.Appendix F: File formats Diploma thesis M. To facilitate the use of breakpoints and setting of program variables during test execution.

If a testcase does not include one line for every Parameter and Input-variable included in the specification it is used to test that either assigns it a value or has a question mark instead. Wetzel March 9. F.Appendix F: File formats Diploma thesis M. comment > • Resetting the command-window of PathFinder : < CLS > . XXVII . The following content of this file relies on the syntax of the Macro-language of PathFinder and may need to be adapted should this Macro-language ever change: • Comment-lines beginning with ’. After every import-operation. However.’ and including date of creation and the filenames of the formal specification. This is also the case for manual input of float-values during test executions. Testcases which do not fit any case specified in the formal specification for whatever reason are not filtered out. which is not possible for testcases with undefined variable values. the tool tries to read the other testcases contained in the file. with the output-file being imported later by the tool. the imported testcases and the generated outputfile: < . The import is considered successful when at least one complete testcase could be imported. The testcases are separated from each other by major separator lines beginning with the substring ’=====’: < ===== > These lines may also occur before or after the string separating different sets of testcases. While testcases containing one or more lines with question marks instead of values on the right side of assignments are valid for use by the first part of the tool in the normal operator sequence to generate a PathFinder-Groupfile . but their number is shown as part of a generated report. but they do not have to. the number of successfully imported and the number of rejected testcases is displayed. It contains the imported testcases and sets the program variables in each loop-turn accordingly. This is because they would be used to determine their specification-coverage in the second tool part. Otherwise. The number of decimal places should not exceed the value of the program-constant determining the number of valid floating-point decimal places.0’ results in an error in PathFinder . All variables contained in the C-Test-Harness are written to a output-file together with their values in each loop-turn. 2004 entering ’5’ for a floating-point-variable instead of ’5. checks for equality performed by Yacas are unlikely to succeed.5 PathFinder-Groupfile Tool part 1 PathFinder Created by: Read by: This file is generated by the first part of the tool and controls the test execution of the generated C-Test-Harness within PathFinder . it is considered incomplete and is rejected by the tool. they are considered incomplete and are rejected when imported directly into the second part of the tool in the alternative operator sequence.

61D > < STRCAT %MAJOR SEPARATORLINE. 45D > < STRCAT %MINOR SEPARATORLINE. The filename may be specified in the first part of the tool: < OPEN FILE filename > • Initialization of the output-file: XXVIII .and output-values to decimal: < BASE D > • A Declare-block for declaring the macro-variables used in the PathFinder-Groupfile : – Opening line of the Declare-block: < DECLARE > – A Newline-String containing the linefeed-character: < LOCAL STRING %CRLF > – A String defining a minor separator line for the output-file: < LOCAL STRING %MINOR SEPARATORLINE > – A String defining a major separator line for the output-file: < LOCAL STRING %MAJOR SEPARATORLINE > – Definition of all program variables as macro variables (% before the name. %CRLF > • Setting the minor separator line which is written to the output-file separating the Inputand Output-variables of a testcase: < BINCPY %MINOR SEPARATORLINE. 45D. < . %CRLF > • Opening the output-file for writing (if the file already exists. 61D. 45D. 2004 • Writing a headline for the test execution: < . the output is appended. • Disabling printing of executed commands: < COMMAND OFF > . • Setting the base of input. 61D. type int becomes LONG. 45D. > . 0dH > • Setting the major separator line which is written to the output-file separating testcases: < BINCPY %MAJOR SEPARATORLINE. type real becomes DOUBLE): < LOCAL type %name > – Closing line of the Declare-block: < ENDDECLARE > • Setting the Newline-String which is appended to the end of every line written to the output-file: < BINCPY %CRLF. < .========================== > . 61D. < ECHO OFF > .. 61D. which should be avoided by moving or erasing the old file prior to test execution).. Wetzel March 9. 45D.========================== > .Starting Test-execution.Appendix F: File formats Diploma thesis M.

Appendix F: File formats Diploma thesis M. – Set the other macrovariables to the values defined in the testcase for their corresponding program variables: < %variablename = variablevalue > – Set the values of the program variables used as Parameters and Input-variables to the values of the corresponding macro-variables: < variablename = %variablename > – Write the current values of the program-variables included as Parameters or Inputvariables in the specification to the output-file: < PRINT FILE ”variablename = ” variablename %CRLF > XXIX .. – Perform two High-level single steps after arriving at the breakpoint (ending at the internalCounter-increment operation inside the main-method): < STEP H > < STEP H > – Prompt the user for entering values with the keyboard for all those macro-variables corresponding to variables which had a question mark on the right side of the assignment instead of a value in the file containing the testcases: < ECHO ON > . Wetzel March 9. < . %variablename > < ECHO OFF > . < PRINT USER %CRLF ”Enter variable-type-value for variable %variablename undefined in testcase: ” > < INPUT USER %variablename > < PRINT USER ”Value of variable variablename for testcase number of testcase: ”. %CRLF > – Writing the name of the generating PathFinder-Groupfile as comment lines: < PRINT FILE ”//GENERATED BY filename of PathFinder-Groupfile ” > – Writing an empty line: < PRINT FILE %CRLF > • Setting of the breakpoint in the C-Test-Harness at the breakpoint function: < S &PathFinderBreakpointFunction > • Starting the test execution (perform a soft reset and go): <GR> • For each imported testcase: – Writing a headline for the testcase: < ECHO ON > . – Stopping the execution of the PathFinder-Groupfile until program execution has reached the next breakpoint: < WAIT > . < ECHO OFF > .. 2004 – Writing an identifier into the first line of the outputfile: < PRINT FILE ”FILETYPE: EXECUTED-TESTCASES”. > .starting execution of testcase ” + number of testcase + ” .

finished execution of testcase ” + testcaseCounter > .> . < ... < .———————————. < ECHO ON > . 2004 – Write a minor separator line: < PRINT FILE %MINOR SEPARATORLINE > – Continue test execution until the next breakpoint (i.Appendix F: File formats Diploma thesis M. < . Wetzel March 9.Finished Test-execution > . • Halt the processor: < HALT > XXX .e. < ECHO OFF > . – Perform two High-level single steps after arriving at the breakpoint (ending at the internalCounter-decrement operation inside the main-method): < STEP H > < STEP H > – Write the names and current values of the program-variable holding the return value of the specified function (if function is not of type ’void’) and the ones included as Output-variables in the specification to the output-file: < PRINT FILE ”variablename = ” variablename %CRLF > – Write a major separator line: < PRINT FILE %MAJOR SEPARATORLINE > – If the last loop-turn (i. > – Writing a bottom line for the testcase: < ECHO ON > . the specified function is not be called again): ∗ Delete the breakpoint: < C ALL > ∗ Close the output-file: < CLOSE FILE > ∗ Set the internal variable queried at the end of the loop to 1 (’True’): < lastTestcase = 1.======================= > . < .======================= > . • Write a bottom line for the test execution: < .e. – Go into next loop-turn or finish test execution: <G> • Re-enable display of executed commands in command window: < COMMAND ON > . execute specified function): <G> – Stopping the execution of the PathFinder-Groupfile until program execution has reached the next breakpoint: < WAIT > .

each with the names and values of all Input-variables. the user is prompted to either import all sets or only the last set. if testcases have been created earlier for the same specification but were executed with XXXI .and Output-variables of each testcase and a major separator line after the end of each testcase: • One line stating the name and value for each Parameter and Input-variable (the names are the ones listed in the specification): < variablename = variablevalue > • A minor separator line beginning with the substring -----: < //----. Output-variable and the variable holding the return value of the specified function . For better understanding.Appendix F: File formats Diploma thesis M. the syntax is listed here again in a comprehensive fashion.6 Executed testcases PathFinder-Groupfile executed within PathFinder Tool part 2 Created by: Read by: This file is generated by the PathFinder-Groupfile . the syntax of this file depends entirely on the syntax of the PathFinderGroupfile and the ’PRINT FILE’ operations the generated PathFinder-Groupfile contains. Each executed testcase consists of the following lines:one meaningful line for each Parameter. Input-variable. which is in turn generated by the tool. If more than one set of testcases is found in the file. Parameters. Output-variables and the return value of the specified function as specified in the formal specification matching the test harness which was executed. with a minor separator line separating the Input. If this line occurs more than once in the whole file. If he decides to import all sets. 2004 F. testcases created with another specification are rejected as incomplete by the tool since all testcases are matched against the formal specification. it is assumed that it starts a new set of testcases. It contains a set of executed testcases. The very first line of the file must be exactly the following string: < FILETYPE: EXECUTED-TESTCASES > Whenever this line occurs later in the file. Because of this. However. the user is asked if he wants to import all sets of testcases or only the last one. It is important to note that the PathFinder-Groupfile appends its output instead of creating a new file if the file with the filename specified in the first part of the tool already exists.4. Wetzel March 9.> • One line stating the name and value of the variable holding the return-value of the specified function (if the specified function is not of type ’void’) and each Outputvariable (the names are the ones listed in the specification): < variablename = variablevalue > • A major separator line beginning with the substring =====: < //===== > The same restrictions apply to the format of variable-values than in Raw-testcases-files (Appendix F.

resulting in a report with wrong numbers being displayed.g. an identifier is included to make identification of matching pairs possible. the tool skips one testcase and counts the results of one twice. The file contains the following lines: • A line setting the precision Yacas should use when evaluating floating-point-expressions to either the minimum value needed to avoid the floating-point-bug occuring in Yacas version 1. When Yacas is called from within the tool. F. whichever one is higher. To avoid this. The identifier is a randomly generated 64-bit-value with the random generator initialised with the current system time at the start of the tool.. delays in disk-writing because of caching mechanisms could result in reading a Yacasoutput-file which is not the result of the last invocation of Yacas . regardless which value is specified as general precision in this line: < Precision(digits). another version of the specified function ). Since the same name is used for the Yacas-input-files and for the Yacas-output-files for every testcase. Although the general structure of the file is the same regardless whether only the specification-coverage of any testcases or both specification-coverage and testcaseresult-evaluation of executed testcases shall be computed.Appendix F: File formats Diploma thesis M. Both values are specified as constants in the program.55 or to the value specified for the floating-point-precision. the filename of this file is provided as a commandline-parameter. 2004 a different test-harness (e. additional lines are included in the latter case. Otherwise. > XXXII . one outputfile should be used by only a single test-harness. Wetzel March 9. > • A line telling Yacas to write the evaluation results of the expressions following expressions in the file into an output-file on disk: < ToFile(”outfilename”) [ > • One line for writing the identifier-string into the Yacas-output-file: < WriteString(”identifier-string”).7 Yacas-input-file Tool part 2 Yacas Created by: Read by: This file is generated by the second part of the tool for each testcase as input file for Yacas and contains the expressions Yacas should evaluate. Note that all Yacas-computations using the ’N()’-operation additionally include the specified value for floating-point-precision as second parameter. thus yielding unexpected results. the generated report reflects the union of all those testcases. The syntax of the file must be compatible with Yacas .0. In this unlikely case. so there is a chance of 1 divided by 264 that the same identifier is generated again and the wrong file might be read twice.

followed by a newLine-character each: see Value-cell-syntax of normal function tables XXXIII .floating-pointprecision)) top-level-predicate Eval(N(Rationalize(expression on right side of top-levelpredicate). and Input-variable contained in the specification. The function return value is assigned to the function name (without trailing underscore): < variablename:=variablevalue. followed by a newLine-character each: < Write(Eval(N(Rationalize(expression on left side of top-level-predicate). > • For ’inverted function’ tables: – Guard-cells: one line for every header-cell-expression (from all headers apart from the one holding value-cells) and every maingrid-cell-expression writing its evaluation result (’True’ or ’False’) into the Yacas-output-file. > – Value-cells (for testcase-result-evaluation only): one line for every maingrid-cell-expression writing whether its evaluated expression is equal to the function return value or not. > • All the lines contained in the auxiliary function-environment of the specification are copied 1:1 into this file. one line for setting the value of every Output-variable and for the function return value (if the function is not of type ’void’) is added. followed by a newLine-character each: < Write(Eval(N(Rationalize(maingrid-expression).floating-point-precision)) = Eval( N(Rationalize(function-return-value from executed testcase). the input-value has to be assigned to ’variablename (name with a leading apostrophe) and the output-value to variablename’ (name with a trailing apostrophe). followed by a newLine-character each: see Guard-cell-syntax of normal function tables – Value-cells (for testcase-result-evaluation only): one line for every header-cell-expression of the header holding value-cells writing whether its evaluated expression is equal to the function return value or not. 2004 • One line for writing a newline-Character into the Yacas-output-file after the identifierstring: < NewLine().floating-point-precision))).Appendix F: File formats Diploma thesis M. > • For ’normal function’ tables: – Guard-cells: one line for every header-cell-expression writing its evaluation result (’True’ or ’False’) into the Yacas-output-file. If a name is used as both an Inputand Output-variable. Wetzel March 9. Constant. > < NewLine(). If testcase-result-evaluation of executed testcases is done as well. > < NewLine(). they are supposed to contain valid Yacas-function-defitions • One line to set the value of every Parameter.floating-point-precision))).

followed by a newLine-character each: see Guard-cell-syntax of normal function tables. except that the function-returnvalue is substituted by the Output-value of the variable in the corresponding vectorheader-cell from the executed testcase • For ’mixed vector’ tables: – Guard-cells: the same as with vector function tables – Value-cells (for testcase-result-evaluation only): the same as with vector function tables • One line completing the write-command to the output-file in Yacas : < ]. All expressions should have been evaluated to ’True’ or ’False’: < evaluationresult > F. the intended syntax of the output-file is listed here: • The first line includes only the identifier. Wetzel March 9.8 Yacas-output-file Yacas Tool part 2 Created by: Read by: This file is produced by Yacas according to the operations contained in the Yacas-inputfile. 2004 • For ’vector function’ tables: – Guard-cells: one line for every header-cell-expression (from all headers apart from the special vector-header) writing its evaluation result (’True’ or ’False’) into the Yacasoutput-file. For better understanding. followed by a newLine-character each: see Guard-cell-syntax of normal function tables – Value-cells (for testcase-result-evaluation only): one line for every maingrid-cell-expression writing whether its evaluated expression is equal to the value of the variable in the corresponding vectorheader-cell.9 Report Tool part 2 Tool part 2 or any other application capable of reading the format Created by: Read by: XXXIV . in the same order as the table-cell-expressions in the input-file.Appendix F: File formats Diploma thesis M. > F. Its structure and syntax is completely dependent on the input-file and how Yacas performs the operations contained therein. which allows matching this output-file to one specific input-file and testcase in the tool: < identifier > • The other lines all include the evaluation of one table-cell-expression each.

in the case of the PathFinder-outputfile). the overall number of successful testcases and the number of testcases that did not fit any specified case) is included in the remarks-environment. empty string otherwise ßorginal expression > F. which must be the following string in this file: For reports without testcase-result-evaluation: < FILETYPE: REPORT-COVERAGE > For reports with testcase-result-evaluation: < FILETYPE: REPORT-EVALUATION > This is because both the report and the specification use tabular expressions and should be able to be displayed by the same application. it applies to the cells of the header containing guard-cells. for ’inverted’ tables. For ’normal’ tables.Appendix F: File formats Diploma thesis M. while the expressions of some cells in the table-environment (dependent on the type of the table) are appended by strings showing the number of testcases which fell into this case (and the number of successful testcases if the testcase results were evaluated as well). depending which user-executable function was used to generate the report. Although they are not displayed when viewing a report. followed by one line for the filename of this file each: XXXV . The file contains the following lines in exactly this order: • One line for the location on disk the last file of each following type was imported from: – Formal specification – C-File containing a specified function – Raw testcases – Executed testcases – Report • One line for the location on disk the last file of each following type was generated in (or specified. Wetzel March 9. Tool part 2 Created by: Read by: This file makes user-provided values for filenames and locations of generated and imported files and external programs persistent between subsequent executions of the tool. It is generated at each program-exit with the current values and imported at each program-startup. this applies to the maingrid-cells. Tool part 2 Tool part 1. it applies to the cells of the header containing value-cells and for ’vector’ tables. The syntax of those lines is: < number of testcases which fell into this case ßnumber of successful testcases which fell into this case if report is of type REPORT-EV ALUATION. Some additional information (at least the overall number of executed testcases. separated by the report statistics of each cell by small latin letter sharp s-characters. The format is exactly the same as the one for the formal specification described in Appendix F. the original expressions of those cells are stored in the file as well.1 except the first line.10 Config-file Tool part 1. 2004 This file contains the report including the specification-coverage of any given set of testcases and maybe the evaluation of the testcase-results (only possible for executed testcases in the normal operator sequence).

. Wetzel March 9. 2004 – C-Test-Harness – PathFinder-Groupfile – Report – PathFinder-output-file • One line for the location on disk which was specified last for the: – Yacas-input.) which were specified last for: – AsIDE – PathFinder – Yacas If any information is not defined. location B. an empty string is saved to the file instead. XXXVI .and output-files • One line for the location followed by one line for the filename (in the order location A. filename A.Appendix F: File formats Diploma thesis M..

G.txt: FILETYPE: SPECIFICATION // FUNCTION real Float2 PARAMETERS real param1 INPUT VARIABLES int inout1 OUTPUT VARIABLES int inout1 CONSTANTS int const1 = 5 real const2 = 23.1 Formal specification This section contains the content of the formal-specification-file E:\TestData\Spec Float2.000000000001 XXXVII . the raw-testcases-file was generated.0 real delta = 0.Appendix G Trial application data This appendix contains the formal specification and the C-file that were used for the trial application.

delta < Float2) And (Float2 < param1 / const2 + delta) G.delta < Float2) And (Float2 < param1 / ’inout1 + delta) aux1(const1) (param1 / const2 . Wetzel March 9.delta < Float2) And (Float2 < param1 + delta) ’inout1 .Appendix G: Trial application data Diploma thesis M. REMARKS This is a specification of a demo function TABLE tabletype vector dimensions 2 dimensionsizes 4 2 vectorheader 2 HEADER 2 inout1’ = Float2 | HEADER 1 (param1 < const2) And Not(’inout1 = -1) (param1 < const2) And (’inout1 = -1) (param1 >= const2) And (’inout1 ! = 0) (param1 >= const2) And (’inout1 = 0) MAINGRID ’inout1 * const1 (param1 * ’inout1 .c: XXXVIII .delta < Float2) And (Float2 < param1 * ’inout1 + delta) const1 (param1 . 2004 AUXILIARY FUNCTIONS aux1(x):= -x.const1 (param1 / ’inout1 .2 C-file This section contains the content of the C-file E:\TestData\C Float2.

double Float2 ( double param1) long inoutsave.000000000001 long inout1. inout1 -= const1. return param1 / const1. else if ((param1 < const2) && (inout1 == -1)) inout1 = const1. if ((param1 < const2) && (inout1 != -1)) inoutsave = inout1. XXXIX . else if ((param1 >= const2) && (inout1 == 0)) inout1 = -const1.Appendix G: Trial application data Diploma thesis M. else if ((param1 >= const2) && (inout1 != 0)) inoutsave = inout1. inout1 = inout1 * const1. 2004 FILETYPE: C-FILE // #define const1 5 #define const2 23. Wetzel March 9.0 #define delta = 0. return param1 * inoutsave. return param1 / inoutsave. return param1.

Wetzel March 9. 2004 XL .Appendix G: Trial application data Diploma thesis M.

L. 2004. Software requirements for the a-7e aircraft. 15(10):859– 866.L.ldra. Technical report. The humble programmer. Assessment of safety-critical software in nuclear power plants.org.Bibliography [AA] National Aeronautics and Space Administration.htm. W. Li. 2002. Evaluating generalized tabular expressions in software documentation. Dijkstra. Tabular representation of relations. Parnas. 1985. 1994. pages 354–359. v2. Nuclear Safety. 1992. ANSI/ IEEE Std. [Mic03] Ashling Microsystems.L. 2003. [LDR] [Li96] LDRA.8. D. 1983.gsfc. XLI .co. Technical report. Institute of Electrical and Electronics Engineers. Abraham. Research Institue of Ontario (TRIO). Kowalik.J. Parnas.gov/website/documents/online-doc/94-003. www. Unit-testing with tbrun.eclipse. United States Naval Research Laboratory. www. Kallander. Parnas J. J. D. Table input method. Ashling’s development tools for embedded systems with arm cores. 1978. A rational design process: How and why to fake it. [Kow02] J.W. C sel. Ieee standard glossary of software engineering terminology.uk/pages/TBrun. Eclipse. Table construction tool. G. In Proceedings of IFIP World Congress 1994. [Mic04] Ashling Microsystems. 1996.K. [Abr97] R. J. Madey D. 1972. C.E. [ANS83] ANSI/IEEE. Technical report. 729-1983. Asmis.nasa.L. 1997. Arm development tools user manual.L. [Par92] [Par94] D. [Dij72] [DP85] [DP91] [Ecl] [KH78] E. style guide. Parnas. Communications of the ACM. P. Mathematical description and specification of software. Clements D. Heninger. American National Standards Institute.pdf.L. Technical Report 260. 1991. Shore K. Parnas. The integrated development environment eclipse.

On testing non-testable programs. pages 132–136.I.L. Software Engineering A Practitioner’s Approach. 1998.S. R.[Par03] [Pet95] [Pre92] [PW95] [vM03] D. Parnas and D. Weiss. October 2003. 1982. Peters. The Computer Journal.K. Mc-Graw-Hill Book Company. Parnas. 1992. [ZS98] J. Shen. Generating a test oracle from program documentation. D. Personal communication. third edition. Weyuker. [Wey82] E. Pressman. 1995. von Mohrenschildt. 25(4):465– 470. Zucker and H.J. . Improving software quality . D. Table transformations: Theory and tools. 1995.L. In 8. M.M. Active design reviews: Principles and practice. International Conference on Software Engineering. Technical report.the sqrl approach. 2003.

and that I have only used the referenced sources. diese Arbeit selbst¨ andig verfasst und nur die angegebenen Quellen benutzt zu haben. Wetzel) . I hereby declare to have finished this thesis on my own. (M.Erkl¨ arung Declaration Hiermit versichere ich.

Sign up to vote on this title
UsefulNot useful