Specification Transformation Navigation - Informatik - FB3

Transcription

!
"#$%&"'()*+
,-./!0"
""!!
Bernd Krieg-Brückner
Preface
As we began preparing this Festschrift in late 2008 and sent out invitations to
submit to Bernd’s friends and present and former members of his group, we
had no way of anticipating the huge resonance to this. We ended up receiving
no less than 33 submissions, including 19 full technical papers. Out of these we
accepted 33 submissions, including 19 full technical papers, for publication in
the Festschrift – a staggering 100% acceptance rate!
Our deepest thanks goes to all the authors for providing the interesting and
humorous contributions. We wish all of you to enjoy the Colloquium. Our congratulations go to Bernd, both on occasion of his birthday, but also regarding his
fruitful and productive scientific life. All the best for the next 60 (or so) years,
Bernd!
February 2009
The Festschrift committee
Bernd Gersdorf
Berthold Hoffmann
Christoph Lüth
Till Mossakowski
Sylvie Rauer
Thomas Röfer
Markus Roggenbach
Lutz Schröder
Shi Hui
Mattias Werner
Table of Contents
Introduction
Specification, Transformation, and Navigation – Research Topics of
Bernd Krieg-Brückner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Berthold Hoffmann, Till Mossakowski, Thomas Röfer, Bernd
Gersdorf
Promotionen und Habilitationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mattias Werner
1
13
Greetings
Glückwünsche zum Sechzigsten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Wolfgang Bibel
15
Greetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Erwin R. Catesbeiana, jr.
17
google bilder: bernd krieg brückner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Martin Gogolla
18
Grußwort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modar Ibraheem
19
Greetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Christoph Lüth
20
Greetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Klaus Lüttich
22
Greetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Peter Mosses
23
Pencil Sharpener . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Frieder Nake
24
Birthday Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Zhenyu Qian
26
Grußwort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pedro de la Cruz Ramos
28
Félicitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sylvie Rauer
29
Greetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Don Sannella
30
To Bernd Krieg-Brückner on the Occasion of his 60th Birthday . . . . . . . . .
Andrzej Tarlecki
32
Grußwort zum 60. Geburtstag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mattias Werner
34
Technical Papers
De Bello Bremense – et effectibus eius in Saravica . . . . . . . . . . . . . . . . . . . . .
Serge Autexier, Dominik Dietrich, Dieter Hutter
35
On Inconsistency and Unsatisfiability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Erwin R. Catesbeiana
40
The VSE Refinement Method in Hets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mihai Codescu, Bruno Langenstein, Christian Maeder, Till
Mossakowski
51
Encapsulating Lazy Behavioral Subtyping . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Johan Dovland, Einar Broch Johnsen, Olaf Owe, and Martin
Steffen
72
A Paradox in Estimating Uncertainty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Udo Frese, Oliver Birbach
88
(A) Vision for 2050 — Context-Based Image Understanding for a
Human-Robot Soccer Match . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Udo Frese, Tim Laue, Oliver Birbach, Jörg Kurlbaum, Thomas
Röfer
On the whereabouts of CSP-CASL – A Survey . . . . . . . . . . . . . . . . . . . . . . . 121
The Processes & Data Gang – Andy Gimblett, Temesghen Kahsai,
Liam O’Reilly, Markus Roggenbach
Enhanced Formal Verification Flow for Circuits Integrating Debugging
and Coverage Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Daniel Große, Görschwin Fey, Rolf Drechsler
Program Graph Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Berthold Hoffmann
Type-Safe Red-Black Trees with Java Generics . . . . . . . . . . . . . . . . . . . . . . . 168
Stefan Kahrs
Compensating the Computational Bias of Spreadsheets . . . . . . . . . . . . . . . . 184
Andrea Kohlhase, Michael Kohlhase
Formal Management of CAD/CAM Processes . . . . . . . . . . . . . . . . . . . . . . . . 201
Michael Kohlhase, Johannes Lemburg, Lutz Schröder, Ewaryst
Schulz
Graph Transformation Units to Model Model Transformation – First Ideas 217
Hans-Jörg Kreowski
Test Automation Problems and Their Reduction to Bounded Model
Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Jan Peleska
Regularity based on categorical algebra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Horst Reichel
15 Years of Rolland . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Thomas Röfer, Christian Mandel, Axel Lankenau, Bernd Gersdorf,
Udo Frese
On Classical and Quantum Process Algebra as Abstract Data Types . . . . 273
Ruqian Lu, Lixing Li, Yun Shang, Xiaoyu Li
AG.com – Bremer Informatik-Arbeitsgemeinschaften in der gymnasialen
Sekundarstufe I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Holger Schlingloff
Using Orientation Calculi and Route Graphs to Interpret Route
Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Hui Shi
Top-down vs. Bottom-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
Burkhart Wolff
Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Specification, Transformation, and Navigation
– Research Topics of Bernd Krieg-Brückner
Berthold Hoffmann1 , Till Mossakowski1,2,3 ,
Thomas Röfer3 , and Bernd Gersdorf3
1
FB-3 – Fachbereich Mathematik und Informatik,
Universität Bremen, Postfach 330 440, D-28334 Bremen
{hof,till}@informatik.uni-bremen.de
2
Albert-Ludwigs-Universität Freiburg, Institut für Informatik,
Georges-Köhler-Allee 52, D-79110 Freiburg
[email protected]
3
Deutsches Forschungszentrum für Künstliche Intelligenz GmbH,
Sichere kognitive Systeme, Enrique-Schmidt-Str. 5, D-28359 Bremen
{Till.Mossakowski,Thomas.Roefer,Bernd.Gersdorf}@dfki.de
Scientific Career. Bernd Krieg Brückner studied electrical engineering at the
universities of Hannover and Erlangen. He received his master of computer science at Cornell University in 1971, with a thesis on the implementation of blockoriented languages.
He worked for the research project “Computer-aided Intuition-guided Programming” (CIP ) at TU München, where he received his PhD in 1978, for a
thesis on program specification and transformation. Then he joined Jean Ichbiah’s design team for the Ada programming language.
After a stay at the universities of Stanford and Berkeley in 1979-1980, he
returned to TU München, before he became a professor of computer science at
Universität Bremen in 1982. Here he participated in numerous research projects
in the areas of program specification, transformation, on spatial cognition and
robot navigation (since 1990), and on ambient-assisted living (since 2007). He
was a member of the university’s Zentrum für Kognitionswissenschaften (center for cognitive sciences), and the Technologie-Zentrum Informatik (technology center for computer science), he takes part in the Sonderforschungsbereich
(Collaborative Research Center) “Spatial Cognition: Reasoning, Action, Interaction”, and he co-founded the Bremen branch of Deutsches Forschungszentrum
für Künstliche Intelligenz (German Research Center for Artificial Intelligence).
Research Topics. Three keywords occur frequently in Bernd’s research:
– Specification
– Transformation
– Navigation
The following paragraphs give more details about Bernd’s contributions to these
areas, mention languages and tools developed in these project, and, finally, list
his publications.
1
2
Berthold Hoffmann
Specification and Transformation. Ever since Bernd participated in the CIP
project, he has been interested in the formal specification of program properties,
and in the transformation of specifications and programs so that their correctness
would be preserved, while their operational behaviour is improved. The ultimate
goal of this research is the development of provably correct efficient programs. To
support this goal, one needs languages wherein specification and transformations
can be defined, and tools that analyse specifications and execute transformations.
Language and Tools. Bernd has been involved in the design of quite a number
of specification and programming languages. CIP-L, the language developed in
the cip project at TU München, covers a wide spectrum of levels, ranging from
logical specification to low-level imperative programming. The imperative programming language Ada was developed for the US department of defence. Bernd
designed generics (parameterised packages) and co-authored the formal definition of the language. Bernd designed, with David Luckham, Frieder von Henke,
and Olaf Owe, the specification language Anna for “Annotating Ada Programs”
by assertions and equational properties. For the esprit-project “Program Development by Specification and Transformation” (ProSpecTra), Bernd coordinated the design of another wide-spectrum language, the “ProSpecTra subset
of Anna and Ada” PAnn
d A. Within the same project, a transformation language
TrafoLa was designed based on the object language PAnn
d A. Both languages
have been implemented in the Propsctra system.
The Propsctra experiences have been further elaborated in the project
KORSO. Here, for the first time, the transformation rules themselves and a
calculus for them came into play. The language SpecTraL (co-authored with
Don Sannella) was an ambitious wide-spectrum specification and programming
language, covering all stages of the software development process (from loose
requirements to implementation). SpecTraL was one of the first languages
covering both parameterised specifications and parameterised programs (and
distinguishing them). While SpecTraL has not gone beyond an initial design,
some of its ideas later revived in Casl (see below).
Bernd was also active in forming a European community: he was the coordinator of the COMPASS working group — COMPASS means “a COMPrehensive
Algebraic approach to System Specification and development”. This EU-funded
working group comprised of 19 international partners, and brought together most
European scientists in the area of algebraic specification methods. The volume
[80] was a direct outcome, and an important preparation for, again, Casl.
But before coming to that, the next step was to look for applications and
industrial partners. In the national research project UniForM, a generic framework, instantiated with specific tools for methods to handle communicating distributed systems and real-time requirements, has been developed. Bernd’s vision
of software development by stepwise transformation was realised in the transformation application system TAS. It probably was the first system which had all
transformation rules proved logically correct by a theorem prover.
3
In COMPASS (and also in the IFIP working group 1.3, of which Bernd
is a member), the need for a unification among dozens of existing specification
languages was noticed. Therefore, the Common Framework Initiative (CoFI), an
open initiative with more than 50 researchers from different research groups, was
founded. The outcome was Casl, the Common Algebraic Specification Language.
Bernd played an active role in the process of coming to an agreement on a
common design and was chairman of the CoFI language design task group. In
Bernd’s group in Bremen, several extensions of Casl have been designed, and
the main analysis and proof tool for Casl and extensions, the Heterogeneous
Tool Set Hets, is maintained.
Now the world is not (only) about formal stuff. In the project MMiSS (MultiMedia Instruction in Safe Systems), which provided hypermedia course materials
for teaching formal methods, formal and informal methods have been combined.
For example, a slide or a text can contain a piece of formal specification, and
tools can recognise and exploit this. Currently, Bernd leads the research project
FormalSafe, where the results of the previous efforts are combined into a new tool
DocTip that provides an integration of and a change management for informal
and formal documents. That is, development here not only means transformation
and refinement in the classical formal sense, but also dependency tracing among
evolving formal and informal documents. A proof of concept will be the application of this methodology to the area of safe robotics — this simultaneously
provides a link to the next main research area.
Navigation. Rumour has it that Bernd got interested in the research topic of
Navigation (on the homepage of his working group, this area is called Cognitive
Robotics) because of his wife Dorothea, who is a biologist specialised in the area
of bees. Beside the prominent bee language, the waggle dance, researchers are
also interested in the bee’s astonishing navigational capabilities, and how it is
achieved with such a small brain.
When Bernd entered the area within the FNK interdisciplinary priority program “Cognitive Autonomous Systems” in 1990, artificial neural networks were
one of the major topics in AI research (again). Bernd was one of the founding
members of the Center for Cognitive Sciences (ZKW) in 1992. In the center,
cognitive processes of insects and lower animals were modelled using artificial
neural networks. Bernd became chairman of the DFG Graduate College “Spatial
Orientation and Organisation of Action of Autonomous Systems” that was initiated by the members of the ZKW. Later, Bernd left the ZKW when members
started to conduct research with monkeys. However, within the Graduate College, a device was born that will always be associated with Bernd’s work in the
area of navigation: the Bremen Autonomous Wheelchair “Rolland” (the name
was also invented by Bernd). The research performed with the several instances
of Rolland is described in one of the contributions to this Festschrift.
In 1996, Bernd entered the DFG priority program with the project “Semilocal 3-D Landmarks Based on Image Sequences for Navigation in Dynamic
Environments”, which later was simply called “Robot Navigation”. The project
4
Berthold Hoffmann
ran the full six years of the priority program. Within this project, Bernd developed the concept of the Route Graph as a layered representation for navigational
knowledge. The Route Graph was also the starting point for Bernd to approach
the topics of navigation and robotics from the perspective of Formal Methods.
The DFG project “Formal Fault-Tree Analysis, Specification and Testing of Hybrid Real-Time Systems with Application to Service Robotics” (SafeRobotics)
that Bernd started together with Jan Peleska is another example for this direction.
The success of the priority program resulted in two follow-up projects. One
of them was the DAAD International Quality Network “Spatial Cognition” in
2002-2004, the other, much bigger one is the joint DFG SFB/TR 8 research
center “Spatial Cognition – Reasoning, Action, Interaction” of the universities
of Bremen and Freiburg. It started in 2003 and is one of first trans-regio SFBs
in Germany. Besides being one of the founding members (together with Christian Freksa and Bernhard Nebel), Bernd is principal investigator in four of the
projects in the SFB. In “A1-[RoboMap] – Maps for Robot Navigation”, the concept of the Route Graph was used to navigate the wheelchair Rolland, while it
was and is analysed from a more formal perspective in “I4-[SPIN] – Specification for the Integration of Spatial Concepts”. In “I3-[SharC] – Shared Control
via Dialogues”, dialogues between man and machine in a navigation scenario
are formally modelled. The results of A1-[RoboMap] are currently used to develop an industrial prototype within the transfer project “T1-[Rolland] – Safe
Wheelchair with Driving Assistance”.
Bernd entered a second DFG priority program in 2001, namely “Cooperating
Teams of Mobile Robots in Dynamic Environments”, or short RoboCup, with the
project “Automatic Recognition of Plans and Intentions of Other Mobile Robots
in Competitive, Dynamic Environments” together with the working group of
Christoph Schlieder. This activity resulted in the foundation of the RoboCup
team GermanTeam in the Four-Legged League (now Standard Platform League)
that won the world championship three times.
As the leader of DFKI’s research area Safe and Secure Cognitive Systems,
Bernd started the BMBF Project “SAMS – Safety Component for Autonomous
Mobile Service Robots” in 2006. In the project, a TÜV-certified component is
developed that stops an automated guided vehicle in time to avoid potential
collisions, based on its current speed and the readings of a laser range sensor.
The key idea of the project is to establish the use of formal methods in TÜV
certifications. The project can be seen as a successor of the project SafeRobotics.
Also within the DFKI, the EU project “SHARE-it – Supported Human Autonomy for Recovery and Enhancement of cognitive and motor abilities using
information technologies” started in 2007. In this project, the DFKI develops
a number of assistants based on Rolland and – Bernd’s idea – the Intelligent
Walker (iWalker) to help the elderly.
Ambient-Assisted Living. In 2005, one of the dreams of Bernd became true.
The construction of a new computer science building began, and he became
5
responsible for the design of the new building, now know as “Cartesium”. It
contains a building automation system that covers admission control, automatic
doors, light control, the alarm system, roller shutters, and the heating system,
together with wired and wireless computer networks. The largest lecture room
“Rotunde” (inspired by the “Event-Rotunde Tutzing”) is further equipped with
a comprehensive multi media system. With the student project “Smart Office
Building”, he turned this building into a large laboratory for intelligent office
building services with energy management based on room reservations.
The start of the EU project “SHARE-it – Supported Human Autonomy for
Recovery and Enhancement of cognitive and motor abilities using information
technologies” in 2007 was the definite step into the Ambient Assisted Living
Community. Bernd began the construction of the “Bremen Ambient Assisted
Living Lab” (BaalL), an apartment with an almost complete domestic installation, intelligent household devices and furniture, media control, all within the
Cartesium as a laboratory for Ambient Assisted Living. Inspired by the “Design
for All” principle, the BaalL serves all inhabitants, from children to the elderly
and the physically and mentally impaired. The integration of speech control with
the use of mobility platforms such as Rolland and IntelligentWalker is unique.
He participates in the “Bremen Health Region” (Gesundheitsregion Bremen),
cooperates with the EU sponsored project “i2home”, and is an active member
in the working group “Interface Integration and Interoperability” within “VDEInnovationspartnerschaft AAL” to develop a vision for the world of AAL in the
year 2020.
References
1. B. Krieg. Formal Definition of the Block Concept and some Implementation Models. Master’s thesis, Cornell University, 1971.
2. F. Geiselbrechtinger, W. Hesse, B. Krieg, and H. Scheidig. Lo, the basic layer
of the wide spectrum language L. In W. Brauer, editor, 3. Jahrestagung GI,
number 1 in Lecture Notes in Computer Science, pages 188–197. Springer-Verlag,
Heidelberg, 1973.
3. F. Geiselbrechtinger, W. Hesse, B. Krieg, and H. Scheidig. Language layers,
portability and program structuring. In L.A. Maarsen W.L. v.d. Poel, editor,
Machine Oriented Higher Level Languages, pages 79–104. Elsevier Science, 1974.
4. B. Krieg, R. Gnatz, and R. Höllerer. S0, a low level systems implementation
language. In Günther et al., editor, Proc. Int. Computing Symp. 1973 (Davos),
pages 285–290. North Holland, 1974.
5. B. Krieg. A class of recursive coroutines. In Proc. IFIP Congress 74 (Stockholm),
pages 408–412. North Holland, 1974.
6. B. Krieg-Brückner. Prevention of side-effects from functions. Machine Oriented
Languages Bulletin, IFIP WG 2.4(6), 1977.
7. F. L. Bauer, M. Broy, R. Gnatz, W. Hesse, B. Krieg-Brückner, H. Partsch, P. Pepper, and H. Wössner. Towards a wide spectrum language to support program
specification and program development. SIGPLAN Notices, 13(12):15–24, 1978.
8. F.L. Bauer, M. Broy, R. Gnatz, W. Hesse, and B. Krieg-Brückner. Towards a wide
spectrum language to support program specification and program development.
6
Berthold Hoffmann
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
In Proc. 5. GI-Fachtagung Programmiersprachen (Braunschweig), pages 73–85.
Springer-Verlag, Heidelberg, 1978.
F.L. Bauer, M. Broy, R. Gnatz, W. Hesse, and B. Krieg-Brückner. A wide spectrum language for program development. In B. Robinet, editor, Program Transformations: Proc. 3rd International Symposium on Programming (Paris), pages
1–15. Dunod; Paris, 1978.
B. Krieg-Brückner. Concrete and Abstract Specification and Program Development by Transformation. Dissertation, TU München; Institut für Informatik,
1978. Technical Report TUM-INFO-7805.
F.L. Bauer, M. Broy, R. Gnatz, W. Hesse, B. Krieg-Brückner, P. Partsch, P. Pepper, and H. Wössner. Towards a wide spectrum language to support program
specification and program development. In F.L. Bauer and M. Broy, editors,
Program Construction, number 69 in Lecture Notes in Computer Science, pages
273–289. Springer-Verlag, Heidelberg, 1979.
Paul F. Albrecht, Phillip E. Garrison, Susan L. Graham, Robert H. Hyerle, Patricia Ip, and Bernd Krieg Brückner. Source-to-source translation: Ada to Pascal
and Pascal to Ada. In Proceedings of the ACM-SIGPLAN symposium on the
Ada programming language, pages 183–193, New York, NY, USA, 1980. ACM.
Manfred Broy and Bernd Krieg-Brückner. Derivation of invariant assertions during program development by transformation. ACM Trans. Program. Lang. Syst.,
2(3):321–337, 1980.
Jean Ichbiah, John G. P. Barnes, J. C. Heliard, Bernd Krieg-Brückner, Olivier
Roubine, and Brian A. Wichmann. Modules and visibility in the Ada programming language. In On the Construction of Programs, pages 153–192. 1980.
Bernd Krieg-Brückner and David C. Luckham. Anna: towards a language for
annotating ada programs. In SIGPLAN ’80: Proceedings of the ACM-SIGPLAN
symposium on Ada programming language, pages 128–138, 1980.
F.L. Bauer, M. Broy, W. Dosch, T. Gnatz, B. Krieg-Brückner, A. Laut, D.C.
Luckmann, M., T.A. Matzner, B. Möller, H. Partsch, P. Pepper, K. Samelson,
R. Steinbrüggen, M. Wirsing, and H. Wössner. Programming in a wide spectrum
language: A collection of examples. Science of Computer Programming, 1(1–
2):73–114, 1981.
J.D. Ichbiah, B. Krieg-Brückner, A. Wichmann, H.F. Ledgard, J-C. Heliard, J.-R.
Abrial, J.P.G. Barnes, M. Woodger, C. Roubine, P.N. Hilfinger, and R. Firth. Reference manual for the Ada programming language: Proposed standard document.
In Duijvestijn and Lockemann [19].
Bernd Krieg-Brückner. Ada and the german pay phone: An illustrative example
of parallel processing. In Duijvestijn and Lockemann [19], pages 122–134.
A. J. W. Duijvestijn and Peter C. Lockemann, editors. Trends in Information
Processing Systems, volume 123 of Lecture Notes in Computer Science. Springer,
1981.
J.D. Ichbiah, B. Krieg-Brückner, A. Wichmann, H.F. Ledgard, J-C. Heliard, J.-R.
Abrial, J.P.G. Barnes, M. Woodger, C. Roubine, P.N. Hilfinger, and R. Firth. Reference Manual for the Ada Programming Language. Number ANSI/MIL-STD1815A-1983 in Ada Companion Series. American National Standards Institute;
Washington, 1983.
B. Krieg-Brückner. Consistency checking in Ada and Anna: a transformational
approach. Ada LETTERS, 3(2):46–54, 1983.
F.L. Bauer, M. Broy, R. Gnatz, W. Hesse, B. Krieg-Brückner, P. Partsch, P. Pepper, and H. Wössner. Towards a wide spectrum language to support program
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
7
specification and program development (russian translation). In W.H. Arafanova,
editor, Anforderungen und Spezifikationen in der Programmentwicklung; eine Aufsatzsammlung, Matematitscheskoje Objespjetschenije EWM, pages 28–46. MIR;
Moskau, 1984.
B. Krieg-Brückner. Types in the programming language Ada. In M.L. Brodie,
J. Mylopoulos, and J.W. Schmidt, editors, On Conceptual Modelling; Perspectives
from Artificial Intelligence, Data Bases and Programming Languages, pages 385–
408. Springer-Verlag, Heidelberg, 1984.
B. Krieg-Brückner. Language comparison and source-to-source translation. In
P. Pepper, editor, Program Transformation and Programming Environments, volume F8 of NATO ASI Series, pages 299–304. Springer-Verlag, Heidelberg, 1984.
F.L. Bauer, R. Berghammer, M. Broy, W. Dosch, R. Gnatz, F. Geiselbrechtinger,
E. Hangel, W. Hesse, B. Krieg-Brückner, A. Laut, T.A. Matzner, B. Möller,
F. Nickl, H. Partsch, P. Pepper, K. Samelson, and M. Wirsin. The Munich Project
Cip, Vol. 1: The Wide Spectrum Language Cip-L. Number 183 in Lecture Notes
in Computer Science. Springer-Verlag, Heidelberg, 1985.
F.W. von Henke, D.C. Luckham, B. Krieg-Brückner, and O. Owe. Semantic
specification of Ada packages. In J.G.P. Barnes and G.A. Fisher Jr., editors, Ada
in Use, Proc. Ada Int’l Conf. 85 (Paris), Ada Companion Series, pages 185–198.
Cambridge University Press, 1985.
B. Krieg-Brückner. Transformation of interface specifications. In Kreowski [28],
pages 156–170.
Hans-Jörg Kreowski, editor. Recent Trends in Data Type Specification, 3rd Workshop on Theory and Applications of Abstract Data Types, Bremen, November 1316, 1984, Selected Papers, volume 116 of Informatik-Fachberichte. Springer, 1985.
V.D. Donzeau-Gouge, J.-C. Heliard, G. Kahn, B. Krieg-Brückner, and B. Lang.
Formal definition of the Ada programming language. Preliminary version, Honeywell Inc., CII Honeywell Bull and INRIA; Le Chesnay, 1980.
Bernd Krieg-Brückner. Integration of program construction and verification: The
ProSpecTra methodology. In Habermann and Montanari [31], pages 173–194.
A. Nico Habermann and Ugo Montanari, editors. Software Development and
Ada, volume 275 of Lecture Notes in Computer Science. Springer, 1987.
B. Krieg-Brückner. Formalisation of developments: an algebraic approach. In
Rogers [34], pages 491–501.
B. Krieg-Brückner, B. Hoffmann, H. Ganzinger, M. Broy, R. Wilhelm, U. Möncke,
B. Weisgerber, A.D. McGettrick, I.G. Campbell, and G. Winterstein. Program
development by specification and transformation. In Rogers [34], pages 301–312.
M.W. Rogers, editor. Results and Achievements, Proc. Esprit Conf. ’86. North
Holland, 1986.
B. Krieg-Brückner, H. Ganzinger, R. Wilhelm, M. Broy, U. Möncke, B. Weisgerber, A.D. McGettrick, I.G. Campbell, and G. Winterstein. Program development
by specification and transformation in Ada/Anna. In P. Wallis, editor, Ada:
Managing the Transition, Proc. Ada Europe Conf. 86 (Edinburgh), Ada Companion Series, pages 249–260. Cambridge University Press, 1986.
B. Krieg-Brückner. An introduction to Ada language (adaptation to Chinese by
Chen Zushun et. al.). Computer Research and Development, 25(2):37–53, 1987.
B. Krieg-Brückner. Systematic transformation of interface specifications. In L. G.
T. L. Meertens, editor, Program Specification and Transformation, Proc. IFIP
TC2 Working Conf. (Tölz’86), pages 269–291. North Holland, 1987.
8
Berthold Hoffmann
38. D.C. Luckham, F.W. von Henke, B. Krieg-Brückner, and O. Owe. Anna, a Language for Annotating Ada Programs: Reference Manual. Number 260 in Lecture
Notes in Computer Science. Springer-Verlag, Heidelberg, 1987.
39. B. Krieg-Brückner. Algebraic formalisation of program development by transformation. In H. Ganzinger, editor, Proc. European Symp. On Programming ’88,
Heidelberg, 1988.
40. B. Krieg-Brückner. The ProSpecTra methodology of program development. In
J. Zalewski, editor, Proc. IFIP/IFAC Working Conf. on Hardware and Software
for Real Time Process Control (Warsaw), pages 257–271. North Holland, 1988.
41. P. de la Cruz, B. Krieg-Brückner, and A. Perez Riesco. From algebraic specifications to correct Ada programs. In A. Alvarez, editor, Proc. Ada Europe Conf. 89
(Madrid), Ada Companion Series. Cambridge University Press, 1989.
42. B. Krieg-Brückner (ed.). Compass, a comprehensive algebraic approach to system
specification and development: Objectives, state of the art, references. InformatikBericht 6/89, Fachbereich Mathematik u. Informatik; Universität Bremen, 1989.
43. B. Krieg-Brückner. Algebraic specification and functionals for transformational
program and meta-program development. In J. Diaz and F. Orejas, editors, Proc.
TAPSOFT’89 (Barcelona), number 352 in Lecture Notes in Artificial Intelligence,
pages 36–59. Springer-Verlag, Heidelberg, 1989.
44. B. Krieg-Brückner. Algebraic specification with functionals in program development by transformation. In H. Hünke, editor, Proc. Esprit Conf. ’89, pages
302–320. Kluwer Academic Publishers; Dordrecht, The Netherlands, 1989.
45. B. Krieg-Brückner. Program development by specification and transformation
(revised version, invited paper). Technique et Science Informatiques: Special Issue
on Advanced Software Engineering in Esprit, pages 134–149, 1990.
46. B. Krieg-Brückner. Compass, a comprehensive algebraic approach for system
specification and development, Esprit basic research working group 3264. EATCS
Bulletin, 40:144–157, 1990.
47. B. Krieg-Brückner. Program development by specification and transformation. In
G. Kahn, editor, Proc. Summer School on Programming Environments in Esprit
(Sophia Antipolis), 1990.
48. B. Krieg-Brückner. Transformational meta-program development. In M. Broy
and M. Wirsing, editors, Methods of Programming, number 544 in Lecture Notes
in Computer Science, pages 19–34. Springer-Verlag, Heidelberg, 1991.
49. B. Krieg-Brückner, E.W. Karlsen, J. Liu, and O. Traynor. The ProSpecTra
methodology and system: Uniform transformational (meta-) development. In
Søren Prehn and W.J. Toetenel, editors, VDM’91, Formal Software Development
Methods, Vol. 2: Tutorials, number 552 in Lecture Notes in Computer Science,
50. B. Krieg-Brückner and D. Sannella. Structuring specifications in-the-large and inthe-small: Higher-order functions, dependent types and inheritance in SpecTraL.
In Proc. TAPSOFT’91, number 494 in Lecture Notes in Computer Science, pages
51. E.W. Karlsen, B. Krieg-Brückner, and O. Traynor. The ProSpecTra system: A
unified development framework. In M. Nivat, C. Rattray, T. Rus, and G. Scollo,
editors, Algebraic Methodology and Software Technology (AMAST’91), Workshop
in Computing, pages 421–433. Springer-Verlag, Heidelberg, 1992.
52. O. Traynor, J. Liu, and B. Krieg-Brückner. Knowledge-based transformational
programming. In In Proc. 4th International Conf. on Software Engineering and
Knowledge Engineering, Capri, Italy, 1992.
9
53. B. Krieg-Brückner. Introduction [to program development by specification and
transformation]. In Hoffmann and Krieg-Brückner [57].
54. Bernd Krieg-Brückner.
A language family for programming and metaprogramming. In Hoffmann and Krieg-Brückner [57], pages 147–148.
55. B. Krieg-Brückner, E.W. Karlsen, J. Liu, and O. Traynor. Uniform transformational development. In Hoffmann and Krieg-Brückner [57].
56. J. Liu and B. Krieg-Brückner. Transformation. In Hoffmann and Krieg-Brückner
[57].
57. Berthold Hoffmann and Bernd Krieg-Brückner, editors. Program Development
by Specification and Transformation, The ProSpecTra Methodology, Language
Family, and System, volume 680 of Lecture Notes in Computer Science. Springer,
1993.
58. B. Krieg-Brückner, J. Liu, B. Wolff, and H. Shi. Towards correctness, efficiency
and reusability of transformational developments. In H. Reichel, editor, Informatik – Wirtschaft – Gesellschaft, 23. GI Jahrestagung 1993, Dresden, Fachgespräch ”Spezifikation und Semantik”, Informatik aktuell, pages 241–252. SpringerVerlag, Heidelberg, 1993.
59. B. Krieg-Brückner, J. Liu, H. Shi, and B. Wolff. Towards correct, efficient and
reusable transformational developments (extended version). In Programmentwicklung durch Spezifikation und Transformation – Bremer Beiträge zum Verbundprojekt Korso (Korrekte Software) [61].
60. B. Krieg-Brückner and W. Menzel. System architecture framework for Korso. In
Programmentwicklung durch Spezifikation und Transformation – Bremer Beiträge
zum Verbundprojekt Korso (Korrekte Software) [61].
61. B. Krieg-Brückner (Hrsg.). Programmentwicklung durch Spezifikation und Transformation – Bremer Beiträge zum Verbundprojekt Korso (Korrekte Software);
Band 2. Informatik Bericht 10/94, Fachbereich Mathematik u. Informatik; Universität Bremen, 1994.
62. B. Krieg-Brückner, J. Liu, H. Shi, and B. Wolff. Towards correct, efficient and
reusable transformational developments. In M. Broy and S. Jähnichen, editors,
Korso: Methods, Languages, and Tools for the Construction of Correct Software.
Final Report, number 1009 in Lecture Notes in Computer Science, pages 270–284.
63. B. Krieg-Brückner. Seven years of Compass. In M. Haveraaen, O. Owe,
and O.-J. Dahl, editors, Recent Trends in Data Type Specification. Proc. 11th
ADT/ Compass Workshop (Oslo 1995), number 1130 in Lecture Notes in Computer Science, pages 1–13. Springer-Verlag, Heidelberg, 1996.
64. Z. Qian and B. Krieg-Brückner. Typed object-oriented functional programming
with late binding. In Proc. 10th European Conf. on Object-Oriented Programming,
Heidelberg, 1996.
65. Z. Qian and B. Krieg-Brückner. Object-oriented functional programming and type
reconstruction. In M. Haveraaen, O. Owe, and O.-J. Dahl, editors, Recent Trends
in Data Type Specification. Proc. 11th ADT/ Compass Workshop (Oslo 1995),
number 1130 in Lecture Notes in Computer Science, pages 458–477. SpringerVerlag, Heidelberg, 1996.
66. Z. Qian and B. Krieg-Brückner. An approach to object-oriented functional programming. In A. Pnueli and H. Lin, editors, Proc. 1995 Int’l. Workshop on Logic
and Software Engineering, pages 71–89. World Scientific Publishing; Singapore,
1996.
10
Berthold Hoffmann
67. M. Gogolla M. Cerioli, H. Kirchner, B. Krieg-Brückner, Z. Qian, and M. Wolf,
editors. Algebraic System Specification and Development: Survey and Annotated
Bibliography, volume 3 of Monographs of the Bremen Institute of Safe Systems
(BISS). Shaker Verlag, Aachen, 2nd edition edition, 1997.
68. M. Cerioli, A. Haxthausen, B. Krieg-Brückner, and T. Mossakowski. Permissive
subsorted partial logic in Casl. In M. Johnson, editor, Algebraic Methodology and
Software Technology, 6th International Conference, AMAST’97, number 1349 in
Lecture Notes in Computer Science, pages 91–107. Springer-Verlag, Heidelberg,
1997.
69. J. Kollmann, A. Lankenau, A. Bühlmeier, B. Krieg-Brückner, and T. Röfer. Navigation of a kinematically restricted wheelchair by the parti-game algorithm. In
Spatial Reasoning in Mobile Robots and Animals, pages 35–45. AISB-97 Workshop; Manchester University, 1997.
70. S. Werner, B. Krieg-Brückner, H.A. Mallot, K. Schweitzer, and C. Freksa. Spatial
cognition: The role of landmark, route, and survey knowledge in human and robot
navigation. In M. Jarke, K. Pasedach, and K. Pohl, editors, Informatik’97, pages
71. B. Krieg-Brückner. A taxonomy of spatial knowledge for navigation. In U. Schmid
and F. Wysotzki, editors, Qualitative and Quantitative Approaches to Spatial Inference and the Analysis of Movements. TU Berlin; Computer Science Department;, 1998. Technical Report 98-2.
72. B. Krieg-Brückner, T. Röfer, H.-O. Carmesin, and R. Müller. A taxonomy of
spatial knowledge for navigation and its application to the Bremen autonomous
wheelchair. In C. Freksa, C. Habel, and K. F. Wender, editors, Spatial Cognition,
number 1404 in Lecture Notes in Artificial Intelligence, pages 373–397. SpringerVerlag Berlin, 1998.
73. A. Lankenau, O. Meyer, and B. Krieg-Brückner. Safety in robotics: The Bremen
autonomous wheelchair. In Proceedings of the 5th Int. Workshop on Advanced
Motion Control (AMC ’98), pages 524–529, 1998.
74. T. Mossakowski, Kolyang, and B. Krieg-Brückner. Static semantic analysis and
theorem proving for Casl. In F. Parisi-Pressice, editor, Recent Trends in Algebraic Development Techniques, 12th International Workshop, WADT’97, number
1376 in Lecture Notes in Computer Science, pages 333–348. Springer-Verlag, Heidelberg, 1998.
75. B. Krieg-Brückner. UniForM perspectives for formal methods. In D. Hutter,
W. Stephan, P. Traverso, and M. Ullmann, editors, Applied Formal Methods –
FM-Trends 98. International Workshop on Current Trends in Applied Formal
Methods, number 1641 in Lecture Notes in Computer Science, pages 251–265.
76. B. Krieg-Brückner, J. Peleska, E.-R. Olderog, D. Balzer, and A. Baer. UniForM
Workbench, Universelle Entwicklungsumgebung für Formale Methoden; Schlussbericht, volume 9 of Monographs of the Bremen Institute of Safe Systems (BISS).
Shaker Verlag, Aachen, 1999.
77. B. Krieg-Brückner, J. Peleska, E.-R. Olderog, and A. Baer. The UniForM workbench, a universal development environment for formal methods. In J.M. Wing,
J. Woodcock, and J. Davies, editors, FM’99, Formal Methods. Proceedings, Vol. 2,
number 1709 in Lecture Notes in Computer Science, pages 1186–1205. SpringerVerlag, Heidelberg, 1999.
78. Christoph Lüth, Haykal Tej, Kolyang, and Bernd Krieg-Brückner. TAS and
IsaWin: Tools for transformational program development and theorem proving.
In Finance [79], pages 239–243.
11
79. Jean-Pierre Finance, editor. Fundamental Approaches to Software Engineering (FASE’99) Proceedings, volume 1577 of Lecture Notes in Computer Science.
Springer, 1999.
80. E. Astesiano, H.-J. Kreowski, and B. Krieg-Brückner, editors. Algebraic Foundations of System Specification. IFIP State-of-the-Art Reports. Springer-Verlag,
Heidelberg, 2000.
81. D. Basin and B. Krieg-Brückner. Formalization of the development process. In
E. Astesiano, H.-J. Kreowski, and B. Krieg-Brückner, editors, Algebraic Foundations of System Specification, IFIP State-of-the-Art Reports. Springer-Verlag,
Heidelberg, 2000.
82. T. Mossakowski, A. Haxthausen, and B. Krieg-Brückner. Subsorted partial
higher-order logic as an extension of Casl. In C. Choppy, D. Bert, and P. Mosses,
editors, Recent Trends in Algebraic Development Techniques, 14th International
Workshop, WADT’99, Bonas, France, volume 1827 of Lecture Notes in Computer
Science, pages 126–145. Springer Verlag, London, 2000.
83. S. Werner, B. Krieg-Brückner, and T. Herrmann. Modelling navigational knowledge by route graphs. In C. Freksa, C. Habel, and K.F. Wender, editors, Spatial
Cognition II, volume 1849 of Lecture Notes in Artificial Intelligence, pages 295–
317. Springer-Verlag, Heidelberg, 2000.
84. E. Astesiano, M. Bidoit, B. Krieg-Brückner, H. Kirchner, P. D. Mosses, D. Sannella, and A. Tarlecki. Casl - the common algebraic specification language.
Theoretical Computer Science, 286:153–196, 2002.
85. B. Krieg-Brückner, D. Hutter, A. Lindow, C. Lüth, A. Mahnke, E. Melis, P. Meier,
A. Poetzsch-Heffter, M. Roggenbach, G. Russell, J.-G. Smaus, and M. Wirsing.
Multimedia instruction in safe and secure systems. In M. Wirsing, D. Pattinson,
and R. Hennicker, editors, Recent Trends in Algebraic Development Techniques,
volume 2755 of Lecture Notes in Computer Science, pages 82–117. SpringerVerlag, Heidelberg, 2003.
86. A. Lankenau, T. Röfer, and B. Krieg-Brückner. Self-localization in large-scale
environments for the Bremen autonomous wheelchair. In C. Freksa, W. Brauer,
C. Habel, and K. F. Wender, editors, Spatial Cognition III, number 2685 in Lecture Notes in Artificial Intelligence, pages 34–61. Springer-Verlag Berlin, 2003.
87. CoFI Language Design Group, B. Krieg-Brückner, and P.D. Mosses. Casl syntax
/ Casl summary. In P.D. Mosses, editor, Casl Reference Manual, volume 2960
of Lecture Notes in Computer Science. Springer-Verlag Heidelberg, 2004.
88. B. Krieg-Brückner, U. Frese, K. Lüttich, C. Mandel, T. Mossakowski, and R. Ross.
Specification of an Ontology for Route Graphs. In Freksa et al. [94], pages 390–
412.
89. B. Krieg-Brückner, A. Lindow, C. Lüth, A. Mahnke, and G. Russell. Semantic
interrelation of documents via an ontology. In G. Engels and S. Seehusen, editors, DeLFI 2004, Tagungsband der 2. e-Learning Fachtagung Informatik, 6.-8.
September 2004, Paderborn, Germany, volume 52 of Lecture Notes in Informatics,
90. K. Lüttich, B. Krieg-Brückner, and T. Mossakowski. Tramway Networks as Route
Graphs. In E. Schnieder and G. Tarnai, editors, FORMS/FORMAT 2004 – Formal Methods for Automation and Safety in Railway and Automotive Systems,
pages 109–119, 2004.
91. K. Lüttich, T. Mossakowski, and B. Krieg-Brückner. Ontologies for the Semantic
Web in Casl. In J. L. Fiadeiro, P. Mosses, and F. Orejas, editors, Recent Trends in
Algebraic Development Techniques, 17th International Workshop (WADT 2004),
12
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
Berthold Hoffmann
volume 3423 of Lecture Notes in Computer Science, pages 106–125. SpringerVerlag Berlin, 2005.
A. Mahnke and B. Krieg-Brückner. Literate ontology development. In Robert
Meersman, Zahir Tari, and Angelo Corsaro et al., editors, On the Move to Meaningful Internet Systems 2004: OTM 2004 Workshops, volume 3292 of Lecture
Notes in Computer Science, pages 753–757. Springer-Verlag Berlin, 2004.
R. Ross, H. Shi, T. Vierhuff, B. Krieg-Brückner, and J. Bateman. Towards dialogue based shared control of navigating robots. In Freksa et al. [94], pages
478–499.
Christian Freksa, Markus Knauff, Bernd Krieg-Brückner, Bernhard Nebel, and
Thomas Barkowsky, editors. Spatial Cognition IV: Reasoning, Action, Interaction,
volume 3343 of Lecture Notes in Computer Science. Springer, 2004.
Bernd Krieg-Brückner. Towards multimedia instruction in safe and secure systems. In Hutter and Stephan [96], pages 379–395.
Dieter Hutter and Werner Stephan, editors. Mechanizing Mathematical Reasoning, Essays in Honor of Jörg H. Siekmann on the Occasion of His 60th Birthday,
volume 2605 of Lecture Notes in Computer Science. Springer, 2005.
Bernd Krieg-Brückner and Hui Shi. Orientation calculi and route graphs: Towards
semantic representations for route descriptions. In M. Raubal, H. Miller, A. Frank,
and M. Goodchild, editors, Geographic Information Science - Fourth International
Conference, GIScience 2006, volume 4197 of Lecture Notes in Computer Science.
Springer-Verlag Berlin, 2006.
Hui Shi and Bernd Krieg-Brückner. Modelling route instructions for robust
human-robot interaction on navigation tasks. International Journal of Software
and Informatics, 2(1):33–60, 2008.
Hui Shi and Bernd Krieg-Brückner. Qualitative semantic representation of spatial
knowledge in dialogue systems. KI Zeitschrift, 3:59–61, 2008.
B. Krieg-Brückner, H. Shi, C. Fischer, T. Röfer, J. Cui, and K. Schill. Welche
Sicherheitsassistenz brauchen Rollstuhlfahrer? In 2. Deutscher AAL-Kongress.
VDE-Verlag; Berlin-Offenbach, Germany, 2009.
B. Krieg-Brückner, B. Gersdorf, Mathias Döhle, and Kerstin Schill. Technik für
Senioren in spe im Bremen Ambient Assisted Living Lab. In 2. Deutscher AALKongress. VDE-Verlag; Berlin-Offenbach, Germany, 2009.
13
14
Glückwünsche zum Sechzigsten
Wolfgang Bibel
Technische Universität Darmstadt
eAdresse: [email protected]
Lieber Bernd,
Zu Deinem sechzigsten Geburtstag wünsche ich Dir von Herzen alles Gute.
Vor allem Gesundheit, die in diesem erreichten Alter immer wichtiger wird.
Da ich Dir ja über zehn Jahre voraus bin, kann ich Dir aus eigener Erfahrung
verheißen, daß auch die kommenden Jahre so erfüllt sein können wie die vorangegangen. Eigentlich sogar noch erfüllter, weil man ja gelernt hat, Wichtiges
von Unwichtigem zu unterscheiden und sich auf das zu konzentrieren, auf das es
einem persönlich wirklich ankommt.
Du bist Anfang der Siebziger Jahre kurz nach mir aus Amerika zurückgekommen. Von da an waren wir bis zu Deiner Rückkehr in die USA ein Jahrzehnt im
gleichen Institut an der TU in München. Ich kann mich noch gut und gerne an
die schönen Gespräche bei der täglichen Kaffeerunde erinnern. Dabei konnte ich
lernen, daß Du von anderem Holz geschnitzt warst als die vielen “Bäuerlinge”. Die
Übernahme des Namens Deiner Frau in Deinen Namen anläßlich Eurer Hochzeit
mußte im damaligen Bayern als regelrechter Kulturschock empfunden werden.
Mir hat dies als sichtbares Zeichen Deines aufgeschlossenen und unabhängigen
Geistes außerordentlich imponiert.
Die Verhältnisse waren in München leider so, daß wir fachlich so gut wie
keinen Kontakt pflegen konnten. Dabei hätten wir aufgrund unserer gemeinsamen Interessenlage beispielsweise an formalen bzw. logischen Methoden der
Programmierung, schon damals fruchtbar zusammenarbeiten können. Durch den
Kleingeist pseudomächtiger Institutsdirektoren wurde dies ausgeschlossen. Ich
war mir aber immer sicher, daß Du die mir seinerzeit von Bauer und seinen
Bäuerlingen zuteil gewordene tyrannische Behandlung in Deinem Inneren nie
gebilligt hast. Schon das war mir damals Hilfe und gab mir Stärke zum Durchhalten, wofür ich Dir noch heute dankbar bin.
Inzwischen hast Du Dich durch Dein Engagement im DFKI selbst offen zu der
Fachrichtung bekannt, derentwegen ich seinerzeit so unterdrückt wurde, nämlich
der KI. So sind wir zwar jeweils eigene, im Grunde aber doch analoge Wege
gegangen. Umso mehr freue ich mich, daß Dein Weg einen so außerordentlich erfolgreichen Verlauf genommen hat, ohne daß Du Dich dafür je verbiegen mußtest.
Dafür bezeuge ich Dir meinen höchsten Respekt.
15
16
Wolfgang Bibel ist derzeit Professor im Ruhestand für Intellektik am Fachbereich für Informatik
der Technischen Universität Darmstadt. Zugleich ist
er Adjungierter Professor an der University of British
Columbia in Vancouver, Kanada. Seine über 250 Publikationen, darunter etwa 20 Bücher, befassen sich mit
einer Vielfalt von Themen der Künstlichen Intelligenz bzw. Intellektik, mit deren Anwendungen und mit
Technologieperspektiven. Er gilt als einer der Mitbegründer der KI in Deutschland und Europa und wurde
für seine wissenschaftlichen Leistungen mit zahlreichen
Ehrungen bedacht. Er war 1972-1982 an der Technischen Universität München Kollege von Bernd KriegBrückner.
Dear BKB,
Ever since Lutz won my heart at the Freimarkt on April 1st, 2003, I tried
to be a source of inspiration for you, like Erwin (Sr) was and is for your group.
Unfortunately, without my consent Lutz handed me over to Markus and sent me
cold heartedly into exile in the backwaters of Wales. Frankly, I must say Markus
is not playing in the same league as you when it comes to humour, beards, and
generosity. For example, at a recent conference in Norway (where Markus only
got a paper in thanks to my overwhelming reasoning power) he would not even
let me sip on his Aquavit. God bless Holger, that in South Africa I got a little
glass of wine at the conference dinner.
Now I heard, dear BKB, that you are having your birthday. I persuaded
Markus to take me to your celebrations. Please, don’t let him take me back with
him! I have already earned scientific acknowledgements for enhancing Markus’
and Holger’s knowledge on product lines, for pointing out the possibility of onthe-fly evaluation, for contributing deep insights into the nature of fixed point
induction, for advice on semantical questions about Csp, and for being an entertainment to the children in the Candy-Puzzle. I was also engaged in the supervision of doctoral students in Swansea, whom I watched over their shoulders
whilst preventing them from procrastinating too much, and who unboundedly
appreciate me for my ongoing pastoral support to Markus.
I am flexible and can work in various areas, catching bees in full flight during
their navigation, constructing autonomous wheelchairs for French frogs who lost
their legs, and even standardizing these strange formal methods which you love
so much. Best of all, my services are cheap compared to those of Erwin (Sr).
In deep affection, Erwin R. Catesbaiana (Jr)
17
herzlichen glückwunsch, bernd! martin
2008-12-13 google bilder: bernd krieg brückner
Martin Gogolla is professor for Computer Science at
University of Bremen, Germany, heading the Database
group and a colleague of Bernd Krieg-Brückner since
1994. He knows Bernd Krieg-Brückner since 1984
where he met him in Bremen at the Workshop on
Abstract Data Types. His interests include software
development with object-oriented approaches, formal
methods in system design, semantics of languages, formal specification and international computer science
standards (e.g., OCL 2.0 as part of UML 2.0). Both
have collaborated in international (e.g., COMPASS)
and national projects (e.g., MMISS).
18
Grußwort
Modar Ibraheem
Universität Bremen
Lieber BKB,
ich erinnere mich jetzt spontan an den ersten Treff mit dir. Damals hatte ich
alle deutsche Wörter und Sätze vorbereitet, die man wahrscheinlich in der ersten
Rede brauchen könnte.
Du hattest angefangen, mit mir in Deutsch zu reden, hatte ich aber kaum nichts
verstanden. Nach ’Switching into English’ hatte ich nochmal zu wenig gekriegt.
In diesem Moment hätte ich dich fragen können, ob du Arabisch sprechen könntest, die Sprache deines Gesichts hatte mich aber das nicht brauchen lassen.
Diese Sprache konnte man ja einfach verstehen und schnell lernen und war jedoch keine schreckliche deutsche Sprache.
Mein Deutsch hattest du möglicherweise ein ’Unikat’ gesehen, welches neben
Mark Twain’s Unikat in Heidelberger Schloss aufgenommen werden sollte. Diese
Kunst hatte mich aber nicht zu viel wie er gekostet und kann dem Besucher
sogar kostenlos verkauft werden.
Nach diesem Treff sollte der neue 26-järige Doktorand seinen 58-järigen Betreuer
duzen und sogar ohne Titel anreden. Das war ja zu viel und sehr überraschend
für einen orientalischen Mensch.
Bevor ich nach Deutschland gekommen war, hatte ich versucht, das Alphabet
dieser Gesichtssprache durch dein Foto im Netz kennenzulernen. Damals hatten
der weiße Bart und die schwarze Brille keinen klaren Eindruck bei mir hinterlassen. Nur drei Wörter von dir hatten verdeutlicht, was sich hinter der Brille
versteckt. ’Nur kein Stress’ hattest du mir nach einer Verspätungsgeschichte gesagt. Dieser und nur dieser Zauberstab konnte mich damals beruhigen.
Nun, nach ca. zwei Jahre an deiner Arbeitsgruppe kann man viele schöne
Bilder, Erinnerungen, Momente der Schwäche, anderen der Hoffnung und Stärke
und viel mehr erzählen. Diese zwei Lebensjahre waren so lang wie ein deutscher
Satz in einer Zeitungsspalte und so kurz wie Augenschlag.
Na ja, ansonsten gibt es eigentlich viel mehr zu sagen, ich will aber am Ende
dir und deiner Familie alles Gute - vor allem jedoch Gesundheit wünschen.
Ich hoffe, dass deine Wünsche für das neue Lebensjahr in Erfüllung gehen.
Modar Ibraheem, has received his bachelor degree
from the Department of Electrical Engineering, AlBaath University-Syria in 2003. After graduation he
worked as assistant teacher in Albaath University. He
then got a scholarship from the ministry of Higher
Education in Syria in order to get his PhD degree.
Currently he is a PhD student in Bernd-Krieg Brückners group. His proposal focus on image processing and
sensor fusion for robot navigation.
19
Es war einmal ein junger PhD-Student, dessen Doktorarbeit in der rauchigen Stadt neigte sich seinem Ende zu, und Geld war auch keines mehr
da. So ging er traurig seines Weges, und wußte nicht wohin, als er einen
Professor am Wegesrand traf. “Warum so traurig, junger Freund?” fragte ihn der freundliche Graubart. “Ach, mein PhD ist nun bald am Ende,
und nun bin ich auf der Suche nach neuen Abenteuern”, antwortete unser junger Doktorand. “Dann komm mit mir nach Bremen. Ich habe
dort eine offene Stelle, auf der kannst du forschen und lehren nach deines Herzens Lust. Etwas besseres als den Tod findest du überall.”
So oder ähnlich1 war es, als ich mich damals um eine Stelle im Forschungsprojekt UniForM an der Universität Bremen bewarb. Aus Bremen war mir im
wesentlichen nur der SV Werder geläufig, aber die Universität kannte ich nur
vom Hörensagen. Dreizehn Jahre später bin ich immer noch in Bremen, und das
hat natürlich wesentlich mit der Person von Bernd zu tun. Wie wenige andere
versteht er es, in seiner Arbeitsgruppe ein Klima zu schaffen, in dem ein selbstbestimmtes, und damit wissenschaftlich befriedigendes Arbeiten ermöglicht wird.
Er hat in seinen Mitarbeitern immer sowohl den Menschen als auch den eigenständigen Wissenschaftler gesehen, nie nur bloße Erfüllungsgehilfen für seine
wissenschaftlichen Ambitionen. Besonders beeindruckend finde ich, dass er immer noch vor Ideen sprüht, und neue Forschungsrichtungen in Angriff nimmt,
anstatt wie es andere an seiner Stelle vielleicht tun würden, mit immer denselben
Arbeiten in neuem Aufguss der Pension entgegenzuforschen.
Ich wünsche Dir noch viele weitere Jahre erfüllten und erfolgreichen Schaffens!
1
Schriftstellerische Freiheiten eingeschlossen.
20
21
Christoph Lüth obtained his Diplom in Computer
Science from the Technical University of Berlin, and
his Ph.D. from the University of Edinburgh. After his
Ph.D. he went to Bremen, where he received his Habilitatition. Since 2006, he is the vice director of newly
established Safe and Secure Cognitive Systems research lab of the German Research Center for Artificial
Intelligence (DFKI).
He met Bernd in one of the COMPASS meetings, in
which group both his supervisor from Edinburgh, Don
Sannella, and Bernd were active. This lead to his applying for the UniForM position in Bremen, and the
rest, as they say, is history.
Dear Bernd,
I have joined your group in 2002 as a developer for the Casl Tool Set (Cats)
and the Heterogeneous Casl Tool Set (Hets) within the Multiple project. From
the very beginning you offered me to attend various summer schools, workshops
and conferences, where I interdisciplinarily experienced topics like algebraic specification, spatial cognition and formal methods. During my rehearsals of presentations at the Extra Meeting you gave me valuable hints on the structuring of
my presentations and on my speeches.
In 2003 the transregional collaborative research center “Spatial Cognition”
opened in Bremen and Freiburg and you gave me the chance to work in Till’s
and your project SPIN, where we developed formal representations of spatial
relations based on your Route Graph concepts within Casl. During this four year
period in which I worked within the research center I had various opportunities
to develop my own way of contributing different aspects of using Casl for the
structured development of ontologies.
In 2006 I decided to leave your group for working in the industry. Still, you
encouraged me to finish my dissertation in the first half of 2007 by reading,
discussing and commenting my drafts.
For your upcoming birthday and the following years at the University of
Bremen I wish you all the best.
Yours sincerly, Klaus
Klaus Lüttich was a researcher / Ph.D. student at
the research group of Bernd Krieg-Brückner from 2002
until 2007. Since 2007 he is working as a product manager for bremen online service (bos) GmbH & Co. KG
and since 2008 he is also the head of team of the team
Professional Services. Since 1999 bos is a software enterprise that develops and implements e-government
solutions. The main focus is on secure data transport
and digital signatures.
22
Warmest greetings, Bernd, on the occasion of your 60th birthday!
If my memory serves me well, I first met you at a WADT, about 25 years
ago: the 3rd WADT in Bremen (1984)? At the time, my main research area
was the semantics of programming languages. Actually, our paths crossed in
that connection even earlier, in 1979, while you were involved in the design and
formal definition of Ada, since my semantics implementation system (SIS) was
initially being used in connection with its denotational semantics.
It wasn’t until the end of the 1980s that I started to meet you more frequently:
you were coordinator for ESPRIT WG COMPASS, and you kindly invited me to
join. I guess we share many good memories from the joint WADT/COMPASS
meetings in the early 1990s – Dourdan, Caldes de Malavella, S. Margherita,
Sintra, and Oslo are hopefully all still as fresh in your mind as in mine?
Although it was good to meet you at workshops so often, I was fortunate
to develop a much closer relationship with you from 1995, when we both became deeply involved in starting CoFI, the Common Framework Initiative. Your
insight and energy as coordinator of the CoFI Language Design Task Group
were crucial to the success of the initiative, leading to the design of Casl, the
Common Algebraic Specification Language. When the time came to choose the
name for the new language, however, you wrote “I don’t like [the name] Casl
very much as it sounds like ‘little cheese’ in German”! (characteristically adding
“of course I will bend to overwhelming majority, though”). Fortunately, the accepted pronunciation of Casl is now ‘castle’, so I hope that the outcome of all
those Language Design meetings doesn’t sound so cheesy to you any more. . .
Best wishes for the years to come!
Peter Mosses, Swansea
Peter Mosses is professor at the Department of Computer Science, Swansea University.
23
Pencil-sharpener
Frieder Nake
Department of Mathematics and Computer Science, Universität Bremen
We don’t really know what makes us connect a specific set of habits or
characteristics with a person. In trivial cases, it is easy, like: He is even shorter
than I am. Or: He looks as if he was heavier than me. His hair is definitely a
hundred times more than mine, let alone his beard. Of a different kind is: He
dares getting up on stage to sing a song.
I have never seen a person whose leg is constantly vibrating up and down at
the speed and persistence this man is forcing his leg to go. As if it was torture
to him to just sit on a chair for, say, three minutes without walking. But then,
why does he sit when he is lecturing instead of standing up and moving back
and forth in front of class? Should someone tell him what his leg is doing? But
what for? He may not be aware of the habit. Telling him might be attacking his
identity. The typical BKB leg is just one of those things.
Prior to his arrival at our progressive computer science department, I learned
that his scientific background was the Ada project in Munich. What a difficult
situation, I thought, would this create! Ada was about the most horrible development in programming languages that you could think of by the time. Tony
Hoare had convincingly warned the software world. I was doing a seminar on
Ada, where we tried to understand the discrepancy between the DoD’s financing
this project and their open attitude in publicizing each step and decision.
I have never told BKB how important in my life his appearance was. His job
description was ”programming languages and compiler”, or similar. This fact
helped me to drop this aspect from my job’s definition and fully concentrate
on computer graphics. Soon after, BKB moved into software engineering, from
where he jumped to cognitive science. This was a change of great importance in
his academic career, I believe. I thought he was crazy. However, I learned from
his example that academia can be a really fast moving field. All it needs is that
you are young, daring, and ambitious enough, and that not too many are around
to contest you.
I also learned from him that you must, at the university of the late 20th
century, be able to raise lots of money. BKB became an outstanding figure for
me because he did everything exactly the opposite way I would do it.
There was a time, dear friendly face, when we shared a number of students
between us. I enjoyed that time because it brought me close to an area of which
I would otherwise have had a vague idea only. As so many processes in a life’s
time, this came to an end when fresh young professors arrived, and BKB switched
again, to robotics and something they call soccer.
I could go on like this, chatting about the memories I have of this remarkable
— and controversial — appearance who comes under the sign, “BKB”. The
whole world of programming probably knows him by this sign. I may be the
24
25
only one in possession of a pencil sharpener from him. Through this precious
little gift he told me a surprising lesson: Es gibt sie noch, die guten Dinge. I wish
you can keep up this belief in times ahead of us.
Frieder Nake is a professor and a colleague of Bernd
Krieg-Brückner at the computer science department,
University of Bremen. He is interested in computer
graphics, computer art, digital media, theory of computer science, and has contributed to all these fields.
Since 2005 he has also been teaching at University
of the arts, Bremen. His academic career took him
from Stuttgart to Toronto, Vancouver, and Bremen,
and from mathematics to art and semiotics.
#""
!""
26
27
Zhenyu Qian received his Ph.D. in Computer Science from Bremen University in 1991 and his Habilitation degree in 1996 under supervision of Bernd-Krieg
Brückner. After that, he worked as Privat Dozent for
a short period, before he moved to Kestrel Institute
in California to work as Staff Computer Scientist. In
2000, he joined a startup company XDegrees working on peer-to-peer storage software system. After the
company was acquired by Microsoft, he moved on cofounding a startup company EPIN Technologies Ltd.
in Silicon Valley and China and served as Vice President, first focusing on WiFi technologies and business, then transitioned to computer media and advertisement technologies and business. In 2005, Zhenyu
Qian joined Microsoft. He currently serves as Principal Group Manager responsible for product strategic
planning, development and deployment in Mobile, Local and Map Search areas in China, Japan and Korea.
Pedro de la Cruz Ramos
Dear Bernd,
It is a pleasure and a honour for me to give you my congratulations on the
occasion of your 60th birthday.
I had the luck to participate with you in the PROSPECTRA Project, as
part of the ALCATEL spanish team, and I still remember that period as one
of the best times in my life, not only because it gave me the possibility to
participate in an exciting and advanced research work, but also because I had
the opportunity to meet extraordinary people and make excellent friends; among
them, and specially, you.
I still remember how your presence, labour, personality, intelligence and wisdom, impregnated and inspired all the aspects of the project. In particular for
me, a young and inexpert engineer by that time, the experience, and notably
your influence, was decisive not only for my professional career, but also for my
personal life. Our collaboration has deeply and positively influenced all aspects
of my further life.
Me and my family want to join your colleagues, friends and relatives, to
transmit you our best wishes for the occasion as well as for your current and
future work and personal life. We also want to make them extensive to all your
family and friends. We wish you peace, joy and happiness in all aspects of your
life. You deserve it.
Your disciple and friend,
Pedro
Pedro de la Cruz Ramos obtained his degree in
Telecommunications Engineering by the Polytechnical
University of Madrid (UPM) in 1982. Then he worked
for some years in the UPM, first as granted researcher
and then as assistant professor. In 1987 he joined Alcatel Standard Eléctrica (then renamed Alcatel España),
where he worked in several positions related to Software Engineering, his first job being as Local Team
Leader in the SPRIT Prospectra Project, in collaboration with the University of Bremen under the direction and leadership of Bernd Krieg-Brückner. He left
Alcatel in 2003 to stablish its own company, Cuántalis
Europa S.A., dedicated to Telecom Expenses Management (TEM). He left Cuántalis in 2008 to join ALTENTIC, where he currently works as Consultant on Information and Communication Technologies. He is currently assigned to the Multiplattform Software Management System (SGS) project in ISBAN, the Banking Software Engineering company of the spanish Santander Bank Group.
28
Sylvie Rauer
University of Bremen, Email: [email protected]
Aujourd’hui est un grand jour de fête en ton honneur, Bernd, pour tes 60
ans ! C’est un grand plaisir pour moi de participer à cette grande fête lors de
laquelle tous pourront te temoigner tout le respect et l’affection qu’ils eprouvent
pour toi. Permets-moi de t’adresser mes voeux les plus sincères, une sante de fer
et une longue, longue. longue vie !
Cordialement
Sylvie
Sylvie Rauer depuis 15 ans j’ai la chance de travailler
dans ton équipe et j’en suis fière et très heureuse.
Responsable du secrétariat je m’efforce de remplir les
tâches administratives le mieux possible, d’organiser
tous les voyages d’affaires du groupe, ainsi que tous
les congrès. J’ai grand plaisir à aider et à accueillir
les chercheurs étrangers qui rejoignent notre équipe.
Ce travail est terriblement polyvalent et permet dêtre
autonome ce qui me plâit beaucoup, j’apprécie aussi
la confiance que tu me témoignes. En somme j’aime
beaucoup mon travail.
29
Dear Bernd,
I remember meeting you 25 years ago at a workshop in Brussels on formal
methods in Ada, and then a year later at WADT in Bremen. I guess these
encounters were what prompted you to suggest that I apply for a chair in Bremen
a few years later. I finally arrived in Bremen 19 years ago.
Despite the passage of time, I remember very well how helpful you were
during that period of my life and how energetic you were in smoothing the way
for me. In the end I decided to return to Edinburgh, and I think that was the
right decision for me, but still it was an interesting and important experience
and I don’t regret it at all. I am grateful for your suggestion that I apply for the
position and for all your help along the way.
I also enjoyed our collaboration at that time and since, on Prospectra,
Spectral, Compass and CoFI/Casl. The little I witnessed of your coordination of the Prospectra project was my first introduction to European project
management. I particularly remember an impressive project plan on your office
wall, with perhaps 100 tasks and dependencies between them. I thought it was
a joke, but you told me with a straight face: no, all of the tasks up to this line
here had been completed, and the project team was now working on these tasks
over here. I remembered that diagram when I coordinated my own European
project, Mobile Resource Guarantees, in 2002–2005. Here was my project plan
for this small (two-site) project, not including the administrative tasks:
1a
1f
1c
1b
1d
10a
1e
2a/b
7d
10b
7a
2c
2d
7c
7e
2f
2e
3e
3a
3b
3c
3d
5a/b
5c
8a
8b
8c
8d
3f
8e
6b
4d
4a
6a
4b/c
4e/f
6g
9b/c
4g
This turned out to be slightly too many tasks in the end for two partners, and
too many deliverables, but with the focus on tasks we did end up achieving a
lot more than we would have done otherwise.
I wish you all the best on your 60th birthday!
Don Sannella, Edinburgh
30
31
Don Sannella did his PhD at Edinburgh University
in 1982 where he remained until 1990 when he took
a position as Professor at the University of Bremen.
He decided to return to Edinburgh in late 1990, however, and has remained there ever since. He was briefly
involved with Bernd’s PROSPECTRA project in the
late 1980s, and during his time in Bremen he collaborated with Bernd on the design of the SPECTRAL
specification language. He was a member of the ECfunded COMPASS working group, which Bernd coordinated, and collaborated with Bernd and many others
on the design of the CASL specification language. His
research interests include functional languages, mechanised reasoning, and foundations for algebraic specification and formal software development including correctness of modular systems. His recent research has
focused on security and static analysis. He is editor-inchief of the journal Theoretical Computer Science, vice
president of the European Association for Theoretical Computer Science, and served as ETAPS steering
committee chairman from its inception until 2001. He
is currently Head of the Informatics Graduate School
in Edinburgh with overall responsibility for PhD education.
To Bernd Krieg-Brückner
on the Occasion of his 60th Birthday
Andrzej Tarlecki1,2
1
2
Institute of Informatics, University of Warsaw
Institute of Computer Science, Polish Academy of Sciences
Lieber Herr Professor Krieg-Brückner,
Dear Bernd,
Among many abilities I have always admired you for are your extensive linguistic skills — unfortunately, mine are so much below that these greetings just
have to be in my (un)Polished English, sorry!
It used to be that only our old professors were reaching the age when one
organises festschrift events for them. These days though, it so happens that
younger and younger colleagues celebrate their impressive anniversaries. I am
not quite sure why, when and how this happened, we all are still very young!
After all it has been less than 40 years since you started your scientific work,
and only about a quarter of century since we met. I wondered when exactly the
latter happened, and I recalled the 3rd International Workshop on Theory and
Applications of Abstract Data Types in Bremen in cold November 1984. It must
have been then. And then there have been numerous further ADT workshops,
other conferences and events, seminars, visits, project. Two projects have to
be mentioned: work within COMPASS and on CASL was marked with so many
meetings, presentations, heated scientific discussions, and even occasional good
quarrels. They generated a great deal of ideas, some of them to materialise in
good research, results and publications. All these owe so much to you! Not to
worry, I refrain from spelling out the technical achievements of the past, even if
they still influence what we do today.
Instead, let me hasten to add that all our meetings came not only with serious
joint work, but also with lighter (even if sometimes heavy) dinners, drinks, chats,
holiday stories, discussions about everything. This social side is necessary to
make our live of travelling academics bearable. Your good humour, optimism
and excellent taste always marked such occasions as well, and made them so
enjoyable and memorable!
My congratulations to you for many years of excellent work and excellent
humour, and very best wishes for many more even better ideas to come! And, in
the best of my selfish interest, for many more occasions to meet, work and have
good time together!
Mit herzlichen Grüßen,
Andrzej Tarlecki
32
33
Andrzej Tarlecki received his PhD in 1982 and DSc
(habilitation) in 1987 from the Institute of Computer
Science of the Polish Academy of Sciences, where he
has been employed at various levels from Researcher
to Professor (since 1997: part-time employment). Since
1992 his main affiliation is with the Institute of Informatics of the University of Warsaw (since 2000 as
Professor ordinarius; Director of the Institute in 19962005). He received the scietific title of Professor of
mathematical sciences from the President of Poland
in 1998.
His research addresses various aspects of the theory
of software specification, verification and development,
and related topics in logic, universal algebra and category theory. This includes generalization, clarification
and further elaboration of some fundamental ideas of
algebraic specification and program development, design of high-level specification languages Extended ML
and CASL, and work on the theory of institutions and
its applications.
Grußwort zum 60. Geburtstag
Mattias Werner
Fachbereich Mathematik und Informatik, Universität Bremen
[email protected], http://www.informatik.uni-bremen.de/˜mawe/
Lieber Bernd,
als einer der dienstältesten Mitarbeiter Deiner Arbeitsgruppe möchte auch ich Dir alles
Gute zu Deinem 60. Geburtstag wünschen. Im Jahr 1988 begann mein Hauptstudium
bei Dir im Projekt PILS, dann folgte unsere Diplomarbeit GIOTTO und im Jahr 1991
wurden Michael Fröhlich und ich WIMI in Deinem Forschungsprojekt KORSO. Dabei
folgtest Du wie wir uns sagen ließen ganz der Tradition, Mitarbeiter immer zu zweit einzustellen. Es entstand unsere Software daVinci, die mittlerweile uDraw(Graph) heißt.
In der damals ca. 10 Mitarbeiter umfassenden AG übernahm ich bald die Betreuung
des Rechnernetzes, zunächst mit zwei Kollegen und dann als Wissenschaftlich Technischer Angestellter eigenverantwortlich. In dieser langen Zeit hat sich viel verändert.
War es zu Beginn selbstverständlich, nur Rechner und Server der Firma Sun mit deren
eigenem Betriebssystem zu kaufen, sind heute die für uns damals undenkbaren Laptops auf PC Basis mit Linux und sogar Windows selbstverständlich. Sun findet man nur
noch im Serverraum. Während damals unser Server gigantische 500 MB Plattenplatz
hatte, haben wir heute das TB längst überschritten. Einzig konstant dabei bliebst Du
mit Deinem Sekretariat, wo immer nur Apple Macintosch in Frage kam. Angefangen
in der 5. Ebene des MZH zog die Arbeitsgruppe bald in die 8. Ebene, doch für Dich
war es immer das Ziel ein eigenes Gebäude zu konzipieren und so haben wir heute
ein technisch sehr innovatives Gebäude Cartesium, dessen teilweise von Dir erdachte Technik so manchem Handwerker nur ein ungläubiges Staunen entlockt hat. Heute
umfasst die AG fast 40 Personen an der Universität Bremen und am DFKI. Die Liste
der Ehemaligen ist fast genauso lang. Ich habe stets bewundert, mit welchem Einsatz
und Geschick Du es immer wieder geschafft hast, neue Finanzierungen für die Stellen
aller Mitarbeiter aufzutreiben, so dass die AG wachsen und viele promovieren oder sogar habilitieren konnten. Ich danke Dir, dass ich diese Entwicklung als Dein Techniker
mitmachen durfte und hoffe, dies noch viele weitere Jahre tun zu dürfen.
Mattias Werner
Mattias Werner received his Dipl. Inf. in computer science from
Universität Bremen, Germany in 1991. In the same year he started to work as a researcher in the group of Prof. Krieg-Brückner.
Since 1996 he is a researcher and technical assistent and therefor
responsible for all the computer hardware in Bernd Krieg-Brückner’s lab at Universität Bremen and in the German Research Center
for Artificial Intelligence (DFKI) department SKS. He is one of the
developers of the graph drawing software uDraw(Graph).
34
36
2
Appassionato Der Anfang
Die genauen Umstände, wie wir zum ersten Mal mit Bernd in Kontakt kamen,
lassen sich wohl nie mehr im Detail klären. Man schreibt das Jahr 1998, die Entwicklungen am alten INKA-Beweissystem waren seit längerer Zeit in eine Sättigungsphase übergegangen und der Sinn stand nach der Bewältigung gröÿerer
Aufgaben: die Behandlung komplexer Verikationsaufgaben mit ihren dazugehörigen Verwaltungsmechanismen wurde zum zentralen Thema in einem DFKIinternen BMBF-Projekt. Es war die Geburtsstunde der Developmentgraphen 1 .
Auf der Suche nach einem goutierenden Publikum kam das Interesse schnell auf
ein EU-Projekt namens CoFI, das sich die Entwicklung einer Common Algebraic
Specication Language, kurz CASL, zum Ziel gesetzt hatte. Das Projekt bot einige Vorzüge: Eine Überarbeitung der Eingabesprache von INKA war längst
überfällig und dieses CASL schien zumindest ein guter Kandidat dafür zu sein,
die beteiligten Personen stammten nicht aus dem typischerweise introvertierten
Umfeld des Automated Reasoning, und das Projekt hatte sogar Geld, um Reisen zu bezahlen! Ein erster Testballon wurde ugs nach Amsterdam auf eines
dieser CoFi-Meetings geschickt (und kam auch bald unversehrt wieder zurück),
danach ging es daran, das Eintrittsgeschenk in Form einer Umsetzung von CASLStrukturen in Developmentgraphen zu produzieren. Das Resultat kam auf dem
Workshop for Algebraic Development Techniques auf den Tisch. Der Veranstaltungsort, das etwas abgelegenes Schlöÿchen Bonas im Süden Frankreichs, bot genügend andere kulinarische Attraktivitäten, um auch die seelischen Qualen eines
Developmentgraphenvortrags bewältigen zu könnnen. Jedenfalls waren danach
INKA und der Developmentgraph feste Gröÿen in der Welt der CASL-Tools. Im
Umfeld dieser Aktivitäten kam der erste persönliche Kontakt mit Bernd zustande; die CASL-Toolsetgemeinde hatte sich in Bremen verabredet und als frisch
gebackene Gemeindemitglieder waren wir natürlich eingeladen, unsere Werkzeuge zu zeigen. Der Name des Veranstaltungsorts Mehrzweck-Hochhaus versprach
zwar eine Atmosphäre, die von dem Betonzweckbau aus den 70er Jahren auch in
vollstem Maÿe erfüllt wurde, aber ganz oben, auf der Chefetage gleichsam, war
man über solche Dinge weit erhaben. Bernds Interesse an Developmentgraphen
war nahezu unerschöpich. Es sollte der Begin einer inzwischen jahrzehnte
langen Zusammenarbeit werden.
3
Furioso MMISS
Im Herbst 2000 gab es eine Ausschreibung des BMBF zu neuen Medien in der
Bildung und damit auch die Gelegenheit, innerhalb eines gemeinsamen Projekts, quasi oziell, zusammenzuarbeiten. Das BMBF wollte in einer groÿ angelegten Aktion die Entwicklung, Erprobung sowie Einführung innovativer multimedialer Lehr- und Lernformen unterstützen. Nachdem so manche Partnerunverträglichkeit im Vorfeld ausgeräumt wurde, stand das Konsortium. Wegen
1
Der Begri des Developmentgraphen gab es im KIV-System bereits früher, war aber
in seiner Semantik stark eingeschränkt.
37
den Ausschreibemodalitäten war die Universität des Saarlandes Projektpartner,
das DFKI war ein Subcontractor gespeist aus Unterverträgen der Unis des
Saarlandes und Bremens. Der saarländische Hauptbeitrag bildete die Weiterentwicklung des ActiveMath-Systems. Wie bei vielen Projekten, in denen gleichzeitig ein Werkzeug und dessen Anwendung entwickelt werden soll, begann schon
bald der Diskurs, ob denn das Werkzeug auch rechtzeitig zur Vorbereitung des
Lehrinhaltes zur Verfügung stehen würde, oder man nicht vielleicht zwischenzeitlich eine andere Lösung parallel fahren sollte. Sichere Systeme war schon
immer ein Leitthema für Bernd und so wurde das Sicherheitsnetz in Form von
MMISS-LaTeX geknüpft: die Verwendung von LaTeX-Macros als explizite Strukturierungsmittel und XML-Ersatz. Die Idee war einfach: Dokumente sollten in
MMISS-LaTeX geschrieben werden, die Druckform erhält man durch LATEXen,
die semantischen Informationen durch die konsequente Verwendung der Macros.
Die Lösung stieÿ naturgemäÿ nicht bei allen Projektpartnern auf helle Begeisterung und schon bald machte das böse Wort von MMISS-Ergebnissen die Runde.
Bernds Diplomatiekünste waren daher in manchen Projektsitzungen gefragt,
um den angeregten Diskussionen Herr zu werden. Und apropos Projektsitzungen: schmücken sich heutzutage viele World-Wide-Manager mit Projektmeetings
in der VIP-Longue mancher internationaler Fluggesellschaft in Frankfurt, New
York oder London, so war der Hauptbahnhof in Fulda das wichtigste Projektziel
in MMISS. Saarbrücken wollte nicht nach Bremen reisen und umgekehrt: für
eine eintägige Veranstaltung waren die Fahrzeiten von mehr als sechs Stunden
pro Strecke einfach zuviel. Bernd kam daher auf die Idee, die Fahrzeiten dadurch
zu halbieren, dass man sich in der Mitte traf. Ein erster Versuch mit Frankfurt
war mangels vernünftiger Räumlichkeiten kein Erfolg, aber der nächste Versuch
mit Fulda Hbf erwies sich als tragfähig, und so traf man sich von Zeit zu Zeit im
ersten Stock eines Bahnhofgebäudes, das den Charme einer altgedienten Polizeidienststelle ausstrahlte, zur gemeinschaftlich begangenen MMISS-Handlung.
Bernd hatte seine Liebe zu Ontologien entdeckt und präsentierte sein formales Konzept für MMISS-Ontologien für Lehrinhalte - am Beispiel seines eigenen
Dokuments über Ontologien. Hier endlich konnte sich der wahre Theoretiker bewähren, der selbstverständlich noch im Traum die verschiedenen Objekt- und
Metaebenen auseinander halten kann, oder aber wie hier der Didaktiker
Bernd, der es dann doch zum guten Schluÿ schate, die Anwesenden von seinem
Konzept zu überzeugen.
Ein Resultat war, dass das Projektteam ins Kloster bzw. ins Wasser ging,
oder, um es genau zu sagen, in die Benediktinerinnenabtei Frauenwörth am
Chiemsee, in der nicht ganz zufälligerweise zur gleichen Zeit der
tagte, dem man nur allzu gerne die MMISSErgebnisse servierte. Das Projekt endete mit einer groÿen (um dem MMISSBrauch nicht Tür und Tor zu önen) Demonstration an der International University of Bremen und der Hauptbahnhof in Fulda kehrte zu jener Bedeutungslosigkeit zurück, die ihm auch schon vor den MMISS-Zeiten beschieden war.
Seien es Ontologien für strukturierte, natürlichsprachliche Dokumente oder
Konsistenzbedingungen für solche Dokumentsammlungen; in der Endphase des
Algebraic Development Techniques
Workshop for
38
Projektes wurden viele Ideen geboren, die sich aber in der verbliebenen Projektlaufzeit nicht mehr verwirklichen lieÿen. Sie sollten als Samen einer späteren,
zukünftigen Zusammenarbeit einige Zeit vor sich hin schlummern müssen. Der
Grund war, dass sich die Sicherheit (im Sinne einer Security) zunehmend als
zentrales Forschungsgebiet am DFKI im Fachbereich DMAS herauskristallisierte. Die Teilbereiche Multiagentensysteme und Deduktion sollten BMBF- und
SAB-technisch enger kollaborieren und das Ergebnis waren Sichere Agenten
und anschlieÿend Sichere Webservices. Das Gebiet der Developmentgraphen
überwinterte und gedieh derweil im typischerweise frostfreien Bremen.
4
Ostinato DFKI in Bremen
Ende 2004 keimte langsam ein neuer Sproÿ der Zusammenarbeit. Das DFKI war
nach manchen turbolenten Jahren Ende des Milleniums wieder auf Expansionskurs gegangen und langsam machte die Rede von neuen Standorten die Runde.
Erhaben über den üblich undurchdringlichen DFKI-Nebelschwaden war plötzlich die Spitze eines Leuchtturms zu sehen. Bernd hatte die günstige Gelegenheit
genutzt und brachte Bremen als neuen zukünftigen Standort ins Rennen, die Robotik ein für jedes KI-Institut gern gesehenes medienwirksames Aushängeschild
mit im Gepäck. Es folgte für Bremen die mühsame Zeit der Einarbeitung in die
Gepogenheiten im DFKI und in die wundersame Welt der DFKI-Ontologien bestehend aus LAV, T46a und anderen Mirakeln des Projektcontrollings. Der neue
Standort, oder wie er am Anfang heiÿen würde, das neue DFKI-Labor Bremen
sollte gut projektbestückt in seine zweijährige Probezeit gehen.
Mittlerweile neigte sich in Saarbrücken eine andere Epoche dem Ende zu.
Jörg Siekmann war langsam aber unentweichlich dabei, dem berufstätigen Beamtenalter zu entwachsen. Seine Nachfolgerfrage war lange Zeit umnebelt, bis
dann mal kurz die mexikanische Sonne herauskam, um dann aber nach einer nicht
enden wollenden Dämmerung zu versinken und das Problem wieder in absolute
Finsternis zu tauchen. Es war unklar, in welcher Konstellation der Forschungsbereich DMAS weitergeführt würde, zudem gab es jetzt mit Bernds Eintritt in
das DFKI einen zweiten Forschungsbereich, der sich Sicherheit auf die Fahnen
geschrieben hatte. Der Bremer Rolland jedenfalls winkte aus der Ferne und bot
seinen Schutz an2 . Es reifte das Modell zweier Sicherheitsabteilungen, die eine
in Bremen und die andere in Saarbrücken, die miteinander eng verknüpft die
Sicherheitsbrückenköpfe des DFKI bilden sollten.
5
Pieno Conclusio
Der anfänglich nicht so schlechte Eindruck von Bernd bestätigte sich und man
lernte Bernd im Lauf der zurückliegenden 10 Jahre als herzlich und groÿzügig
2
die Tatsache, dass es sich hierbei nicht um den allseits bekannten streitbaren Roland
(vryheit do ik ju openbar) sondern um einen Rollstuhl handeln sollte, war nicht
allen Beteiligten stets bewusst.
39
kennen, im Gegensatz zu seiner eher spartanischen Büroeinrichtung. Hervorzuheben hierbei ist unter anderem, dass, wenn man als Gast in Bremen war, Bernd,
trotz seines engen Terminkalenders und ausstaert mit der letzten kalifornischen Apfel-Technik, es sich oft nicht nehmen lies, einen persönlich am Hotel
abzuholen oder zum Bahnhof zu bringen. Bei den vielen gemeinsamen Essen,
am liebsten natürlich chinesisch, entpuppte sich sein Schalk und derart vielseitiges Interesse, so dass er sich dafür sogar eine zweite Persönlichkeit in Person
des Drehbuchautors, Regisseurs und Schauspielers Bernd Bellum hatte zulegen
müssen.
Wir wünschen Dir, lieber Bernd alles Gute zu Deinem 60. Geburtstag.
Serge Autexier
received his doctoral degree from
Saarland University under the supervision of Jörg
Siekmann. Together with Christoph Benzmüller and
he was leading Jörg Siekmann's OMEGA group at
Saarland University, which integrated into the DFKI Safe and Secure Cognitive Systems Lab of Bernd
Krieg-Brückner, whom he knows since the end of the
1990s from the European project CoFi. His research
focuses on management of change in general and proof
assistance systems with the objective to oer to users
who are not experts in formal logic support that only
formal logic based techniques can reliably provide.
Dominik Dietrich, born in 1980, received his Diploma in Computer Science PhD from the Saarland University in 2006 under supervision of J. Siekmann. Since
2008 he is a PhD student in Bernd Krieg-Brückner's
group. His research interests include automated reasoning with focus on proof planning and deep inference,
and formal software development.
Dieter Hutter
is a principle researcher at the German Research Center of Articial Intelligence. He started his career in the area of deduction systems developing strategies for inductive theorem provers. After
receiving his Ph.D in 1991 his interest focused on formal methods working, rst on the deductive support
for formal methods and later on evolutionary formal
program development and change management. Since 2000 he is also engaged in developing information
ow control techniques for multi-agent systems and
web services. In 2008 he took the opportunity to join
Bernd Krieg-Brückner's group and moved to the newly founded DFKI site in Bremen. Currently he heads
the department for Safe and Secure Systems - Development Technologies at the DFKI.
On Inconsistency and Unsatisfiability
Erwin R. Catesbeiana
University of Bremen, Email: [email protected]
Abstract. We study inconsistency and unsatisfiability and their relation to soundness, completeness, paraconsistency and conservative extension in an arbitrary logical system (formalised as institution equipped
with an entailment system).
1
Introduction
The study of logical inconsistencies has a long tradition that goes back to at least
Aristotle. Indeed, Aristotle examined contemporary philosophical arguments and
revealed inconsistencies. For example, Anaxagoras imagined the mind to be the
initiating principle of all things, and suspending on its axis the balance of the
universe; affirming, moreover, that the mind is a simple principle, unmixed, and
incapable of admixture, he mainly on this very consideration separates it from all
amalgamation with the soul; and yet in another passage he actually incorporates
it with the soul. This inconsistency was pointed out by Aristotle, but it remains
unclear whether he meant his criticism to be constructive, and to fill up a system
of his own, rather than destructive of the principles of others.1
Aristotle himself created a rich source of what perhaps not can be called
inconsistencies, but false theorems: a number of his Syllogisms exhibit the existential fallacy, i.e. have implicit existential assumptions, which means that they
are unsound when read literally. For example, the Fesapo syllogism:
No humans are perfect.
All perfect creatures are mythical.
Some mythical creatures are not human.
After Aristotle came a long period of logical desert, with only Scholastic
arguments, which only was left in the 19th century with the discoveries of Boole,
Frege and others. Actually, Frege created a rich and powerful logical system
called “Begriffsschrift”. It was discovered to be inconsistent by Russell in the
early 20th century, by a proof that resembles the barber paradox: assume that
there is a town with a barber that shaves all people who do not shave themselves.
Then the barber shaves himself iff he does not — a contradiction.
The origin of this inconsistency is the power of self-application, i.e. the possibility to apply predicates to themselves. For example, monosyllabic is an adjective that does not hold of itself, where as polysyllabic does. Now let non-selfreferential be the adjective expressing that an adjective does not hold for itself.
1
See http://www.ccel.org/ccel/schaff/anf03.iv.xi.xii.html.
40
41
That is, monosyllabic is non-self-referential (and polysyllabic isn’t). Is non-selfreferential non-self-referential? It is the merit of the modern web ontology language OWL-full to have provided, in the early 21st century and more than 120
years after Frege, a logic where again predicates can be applied to themselves.
In the modern use of logic in theoretical computer science, the notion of
inconsistency (and its companion unsatisfiability) gains importance in the area
for formal specification and software development with formal methods — our
jubilarian Bernd Krieg-Brückner has been quite active in this research area. A
central idea is that in an early phase of the development process, initial requirements are first formulated informally and then are formalised, such that intended
logical consequences can be checked, and inconsistencies (that prevent the development of a correct implementation) can be found. And indeed, not only
programs are notoriously buggy, but also their specifications tend to be incorrect and inconsistent. Modern specification languages like CafeOBJ and CASL
come with libraries of specifications that also provide examples of such inconsistencies. Indeed, these languages are feature-rich and complex, which eases
the development of non-trivial2 inconsistent theories. In this context, we should
also mention the research on upper ontologies, which are usually quite large and
inconsistent first-order theories.3 Indeed, in the SUMO ontology, several inconsistencies have been found [5]. The SUMO $100 Challenges4 explicitly call for
demonstrating the consistency or inconsistency of (parts of) SUMO. Needless so
say that so far, only an inconsistency has been found.
2
Institutions and Logics
The study of inconsistency and unsatisfiability can be carried out largely independently of the nature of the underlying logical system. We use the notion
of institution introduced by Goguen and Burstall [3] in the late 1970ies. It approaches the notion of logical system from a relativistic view: rather than treating
the concept of logic as eternal and given, it accepts the need for a large variety
of different logical systems, and ask for the central principles of logical systems.
They arrived at a mathematical formalisation of that notion which is really ingenious and lead to rich and flourishing theory that is laid out in hundreds of
research papers, and most recently also in a book [1].
While the notion of institution takes a model.theoretic perspective, it was
later complemented by the more proof-theoretic notion of entailment system
(also called Π-institution) [8, 2].
What are the essential ingredients of a logical system? It surely has a notion of sentence, and derivability relation on sentences that allows to derive
conclusions from a given set of assumptions. Moreover, at the model-theoretic
2
3
4
Of course, the set of logical consequences of an inconsistent theory is always trivial.
However, the axioms of the theory itself may have varying complexity and subtlety
of interaction in order to lead to the inconsistency.
Although there are more efficient ways of writing up such theories . . .
See http://www.cs.miami.edu/~tptp/Challenges/SUMOChallenge/.
42
side, there is a notion of model and a satisfaction relation between models and
sentences, denoted by |=. The latter leads to the relation of logical consequence
(all models satisfying the premises also satisfy the conclusion); this relation is
also denoted by |=. A logic is sound, if Γ ϕ implies Γ |= ϕ, and complete, if
the converse implication holds.
Moreover, an important observation is that all this structure depends on the
context, i.e. the set of non-logical (or user-defined) symbols around. These contexts are called signatures and formalised just as object of an abstract category.
The reader not familiar with category theory or not interested in the formal
details can safely skip the rest of this section and just keep in mind the above
informal motivations.
Definition 1. An entailment system consists of
– a category SignE of signatures and signature morphisms,
– a functor SenE : SignE −→ Set giving, for each signature Σ, the set of sentences SenE (Σ), and for each signature morphism σ : Σ −→ Σ , the sentence
translation map SenE (σ) : SenE (Σ) −→ SenE (Σ ), where often SenE (σ)(ϕ) is
written as σ(ϕ),
Σ ⊆ P(Sen(Σ)) × Sen(Σ) for each Σ ∈ |Sign|, such that the following
properties are satisfied:
1. reflexivity: for any ϕ ∈ Sen(Σ), {ϕ} Σ ϕ,
2. monotonicity: if Ψ Σ ϕ and Ψ ⊇ Ψ then Ψ Σ ϕ,
3. transitivity: if Ψ Σ ϕi for i ∈ I and Ψ ∪ {ϕi | i ∈ I} Σ ψ, then Ψ Σ ψ,
4. -translation: if Ψ Σ ϕ, then for any σ : Σ −→ Σ in Sign, σ(Ψ ) Σ σ(ϕ).
– for each signature Σ ∈ |SignE |, an entailment relation (Sen(Σ), EΣ ),
– for each signature morphism σ : Σ1 −→ Σ2 , a sentence translation map
SenE (Σ1 ) → SenE (Σ2 ) preserving E . By abuse of notation, we will also
denote this map with σ.
A theory is a pair (Σ, Γ ) where Γ is a set of Σ-sentences. An entailment
theory morphism 5 (Σ, Γ ) −→ (Σ , Γ ) is a signature morphism σ : Σ −→ Σ
such that Γ Σ σ(Γ ).
Let Cat be the category of categories and functors.6
Definition 2. An institution I = (SignI , SenI , ModI , |=I ) consists of
– a category SignI of signatures,
– a functor SenI : SignI −→ Set (as for entailment systems),
5
6
also called interpretation of theories.
Strictly speaking, Cat is not a category but only a so-called quasicategory, which is
a category that lives in a higher set-theoretic universe [4]. However, we do not care
about this here. Indeed, these foundational questions are ignored by most mathematicians and computer scientists, since ignoring them provides a rich source of
inconsistencies.
43
– a functor ModI : (SignI )op −→ Cat giving, for each signature Σ, the category
of models ModI (Σ), and for each signature morphism σ : Σ −→ Σ , the
reduct functor ModI (σ) : ModI (Σ ) −→ ModI (Σ), where often ModI (σ)(M )
is written as M |σ ,
– a satisfaction relation |=IΣ ⊆ |ModI (Σ)| × SenI (Σ) for each Σ ∈ SignI ,
such that for each σ : Σ −→ Σ in SignI the following satisfaction condition
holds:
M |=IΣ σ(ϕ) ↔ M |σ |=IΣ ϕ
for each M ∈ ModI (Σ ) and ϕ ∈ SenI (Σ).
We will omit the index I when it is clear from the context.
A logic is an entailment system paired with an institution agreeing on their
signature and sentence parts. Usually, a logic is required to be sound, that is,
Γ Σ ϕ implies Γ |=Σ ϕ. If also the converse holds, the logic is complete.
A theory is defined as for entailment systems. An institution theory morphism
(Σ, Γ ) −→ (Σ , Γ ) is a signature morphism σ : Σ −→ Σ such that Γ |=Σ σ(Γ ). Let Th(I) denote this category. Each theory (Σ, Γ ) inherits sentences
from SenI (Σ), while the models are restricted to those models in ModI (Σ) that
satisfy all sentences in Γ . It is easy to see that I maps theory morphisms to
corridors in this way. By taking Th(I) as “signature” category, we arrive at the
institution I T h of theories.
Example 3. Classical propositional logic (CPL) has the category Set of sets
and functions as its signature category. Σ-sentences are given by the following
grammar
ϕ ::= p | ¬ϕ | ϕ1 ∧ ϕ2 | ϕ1 ∨ ϕ2 | ϕ1 → ϕ2 | | ⊥
where p denotes propositional variables from Σ. Sentence translation is the obvious replacement of propositional variables.
Σ-models are functions from Σ to {T, F }. A (unique) model morphism between two models exists if the values of variables change only from F to T , but
not vice versa. Given a signature morphism σ : Σ1 −→ Σ2 , the σ-reduct of a
Σ2 -model M2 : Σ −→ {T, F } is given by composition: M2 ◦ σ. This obviously
extends to reducts of morphisms.
Satisfaction is inductively defined by the usual truth table semantics. Since
reduct is composition, it is straightforward to prove the satisfaction condition.7
The entailment relation is the minimal relation satisfying the properties listed
in Table 1, plus the property ¬¬ϕ ϕ.
This logic is sound and complete.
7
A precise argument is as follows: the Boolean operations form a signature such that
Sen is the free algebra functor for algebras over that signature (these algebras are
Boolean algebras without laws). {T, F } also is such an algebra, denoted by Bool,
and for a model M , sentence evaluation is εBool ◦ Sen(M ), where ε is the counit.
Then the satisfaction condition is εBool ◦Sen(M )◦Sen(σ) = εBool ◦Sen(M ◦σ), which
is just functoriality of Sen.
44
A Heyting algebra H is a partial order (H, ≤) with a greatest element and
a least one ⊥ and such that any two elements a, b ∈ H
– have a greatest lower bound a ∧ b and a least upper bound a ∨ b, and
– there exists a greatest element x such that a ∧ x ≤ b; this element is denoted
a ⇒ b.
In a Heyting algebra, we can define a derived operation ¬ by ¬a := a ⇒ ⊥. A
Heyting algebra morphism h : H1 −→ H2 is a map preserving all the operations.
Example 4. Heyting-algebra based intuitionistic propositional logic (IPL-HA)
inherits the signature category and sentences from CPL.
A Σ-model (ν, H) consist of a Heyting algebra H together with a valuation
function ν : Σ −→ |H| into the underlying set |H| of H. Σ-model morphisms
h : (ν1 , H1 ) −→ (ν2 , H2 ) are Heyting algebra morphisms h : H1 −→ H2 such that
h1 ◦ν1 (p) ≤ ν2 (p) for each p ∈ Σ. Again, model reduct is defined by composition,
and this easily extends to morphisms.
Using the Heyting algebra operations, it is straightforward to extend the
valuation ν of a Σ-model (ν, H) from propositional variables to all sentences:
ν # : Sen(Σ) −→ |H|. (ν, H) satisfies a sentence ϕ iff ν # (ϕ) = . The satisfaction
condition follows similarly as for CPL.
The entailment relation is the minimal relation satisfying the properties listed
in Table 1. This turns IPL-HA into a sound and complete logic.
3
Logical connectives
Within an abstract logic, it is possible to define logical connectives purely be
their proof-theoretic and model-theoretic properties. We start with proof theory
and adapt the standard definitions from [7].
connective
defining property
proof-theoretic conjunction ∧
Γ ϕ ∧ ψ iff Γ ϕ and Γ ψ
proof-theoretic disjunction ∨ ϕ ∨ ψ, Γ χ iff ϕ, Γ χ and ψ, Γ χ
proof-theoretic implication →
Γ, ϕ ψ iff Γ ϕ → ψ
proof-theoretic truth Γ proof-theoretic falsum ⊥
⊥ϕ
proof-theoretic negation ¬
Γ, ϕ ⊥ iff Γ ¬ϕ
Table 1. Properties of proof-theoretic connectives
Note that these properties characterise connective essentially by their prooftheoretic behaviour; they mostly even directly correspond to proof rules. Below,
45
we will also introduce semantic connectives. A logic is said to have a prooftheoretic connective if it is possible to define an operation on sentences with the
properties specified in Table 1. For example, both IPL-HA and CPL have all
proof-theoretic connectives.
We also can define internal connectives at the semantic level. A logic is said
to have a semantic connective if it is possible to define an operation on sentences
with the specified properties.
connective
defining property
semantic disjunction ∨
M |= ϕ ∨ ψ iff M |= ϕ or M |= ψ
semantic conjunction ∧ M |= ϕ ∧ ψ iff M |= ϕ and M |= ψ
semantic implication → M |= ϕ → ψ iff M |= ϕ implies M |= ψ
semantic negation ¬
M |= ¬ϕ iff M |= ϕ
semantic truth M |= semantic falsum ⊥
M |= ⊥
Table 2. Properties of semantic connectives
While CPL has all semantic connectives (indeed, they coincide with the
proof-theoretic ones), IPL-HA only has semantic conjunction, truth and falsum.
4
Inconsistency and Unsatisfiability
In the sequel, let us fix a logic L (in the above sense), which a priori need neither
be sound nor complete.
The notion of unsatisfiability is quite clear:
Definition 5. A theory is unsatisfiable if it has no models.
Indeed, the notion of inconsistency is more interesting than unsatisfiability8 ,
since it enjoyed some historical development. According to Aristotle, inconsistency means that both some sentence as well as its negation can be proved.
Definition 6. Assume that L has a negation connective (not necessarily being a
proof-theoretic or semantic negation9 ), and let T be a theory in L. T is Aristotle
inconsistent, if there is some sentence ϕ with T ϕ and T ¬ϕ.
This notion has several disadvantages. Firstly, it presupposes the notion of
negation, which is not available in all logics. More importantly, it classifies paraconsistent logics as inconsistent, which can only be apologised by the fact that
paraconsistent logics were not known at Aristotle’s time.
8
9
Although the Rolling Stones devoted a song to unsatisfiability.
However, let us assume that if there is a proof-theoretic negation, then this is used.
Otherwise, the notion of inconsistency of course depends on the chosen connective.
46
A modern definition of inconsistency overcoming this problem was coined by
David Hilbert. Hilbert was the founder of the famous “Hilbert programme”, the
aim of which was to prove the consistency of all of mathematics by reducing
it to the consistency of a small number of finitary principles, for which there
is enough faith into their consistency. Hilbert’s programme greatly failed, as
was shown by Gödel’s second incompleteness theorem (actually, the name is
misleading: it should be called Gödel’s Great Inconsistency Theorem):
Theorem 7 (Gödel). There is a first-order theory T of zero, successor, addition and ordering on the natural numbers (which is actually quite simple and
weak), such that for any extension T of T , if T can prove its own consistency
(encoded as a statement on natural numbers), then T is inconsistent.10
Hence, although Hilbert’s programme was a powerful and striking idea, in the
end it could not be successful. As a result, the question whether the theories like
ZF C (that are used as a foundation of mathematics and theoretical computer
science!) are consistent or inconsistent is open. Indeed, the only way to firmly
resolve this open question would be to prove the inconsistency of ZF C.11 All
what we have so far are relative results, such as the famous result by Gödel:
ZF C is inconsistent iff ZF is inconsistent.12
which means that when looking for an inconsistency proof for ZF , we equally
well may use the stronger (and hence easier to prove inconsistent) system ZF C.
But even though Hilbert’s programme failed, Hilbert left us with a modern
definition of inconsistency:
Definition 8 (Hilbert). Assume that L has a falsum constant (not necessarily
being a proof-theoretic or semantic falsum13 ). T is ⊥-inconsistent, if T ⊥.
Still, this definition does not work with logics that do not have a falsum,
for example positive or equational logic. Hilbert therefore also found a notion of
inconsistency that has the least prerequisites (no logical connectives are needed)
and that simultaneously is most powerful (in terms of logical strength of inconsistent theories):
Definition 9 (Hilbert). T is absolutely inconsistent, if T ϕ for any sentence
ϕ of same signature as T . This is also known as the principle ex contradictione
quodlibet (from a contradiction, one can follow everything).
10
11
12
13
For first-order logic, the various notions of inconsistency discussed so far are equivalent; hence we can be unspecific here.
For an initial attempt in this direction, see [6].
Actually, Gödel proved the corresponding statement about unsatisfiability, but by
Gödel’s completeness theorem for first-order logic, inconsistency and unsatisfiability
are equivalent, see our Prop. 12 below.
Again, let us assume that if there is a proof-theoretic falsum, then this is used.
Otherwise, the notion of inconsistency depends on the chosen constant.
47
We should also mention a notion of inconsistency introduced by Emil Post:
a propositional theory T is Post-inconsistent, if it can derive a propositional
variable (not occurring in the axioms of T ; the signature possibly needs to be
enlarged to get such a variable). Unfortunately, this notion is too much tied to
a specific logical system to be of interest here.
The different notions of inconsistency14 are related as follows:
Proposition 10. 1. absolute inconsistency implies ⊥-inconsistency and Aristotle inconsistency.
2. In presence of proof-theoretic falsum, absolutely inconsistency and ⊥-inconsistency
are equivalent.
3. In presence of proof-theoretic falsum and negation, all three notions of inconsistency re equivalent.
Proof. 1. obvious
2. Directly from the definition of proof-theoretic falsum.
3. By 1. and 2., it remains to show that Aristotle inconsistency.implies absolutely inconsistency. By definition of proof-theoretic negation, from Γ ¬ϕ we
get and Γ ∪ {ϕ} ⊥. Together with Γ ϕ, this leads to and Γ ⊥.
5
Soundness and Completeness, with an Application to
Paraconsistency
Inconsistency and unsatisfiability also play a great role in determining whether
a logic is sound or complete.
We begin with a simple lemma showing that falsum and truth are two sides
of the same coin:
Lemma 11. In presence of proof-theoretic negation, falsum and truth,
¬⊥ and ¬ ⊥.
Soundness and completeness, while defined in terms of entailment, can be
characterised completely in terms of inconsistency and unsatisfiability.
Proposition 12. Let L be a logic with both proof-theoretic and semantic negation, truth and falsum. (Then, by Prop. 10, all notions of inconsistency are
equivalent, hence we can be unspecific in the sequel.)
1. A logic is sound iff every inconsistent theory is unsatisfiable.
2. A logic is complete iff every unsatisfiable theory is inconsistent.
14
We
credit
http://home.utah.edu/~nahaj/logic/structures/systems/
inconsistent.html for an excellent overview of these notions.
48
Proof. (1), “⇒” Let T be inconsistent, i.e. T ⊥. By soundness, T |= ⊥, hence
T is unsatisfiable.
(1), “⇐” Let T ϕ, then T ∪ {¬ϕ} is inconsistent, hence, by the assumption,
also unsatisfiable. But this means that T |= ϕ.
(2), “⇒” Let T |= ϕ. Then T ∪ {¬ϕ} is not satisfiable, hence by the assumption, it is inconsistent. From T ∪ {¬ϕ} ⊥, we obtain T ∪ {¬ϕ} ¬¬⊥ and
hence T ∪ {¬⊥} ϕ. By Lemma 11, T ∪ {} ϕ. By the properties of and
transitivity, we get T ϕ.
(2), “⇐” Let T be unsatisfiable, i.e. T |= ⊥. By completeness, T ⊥, hence
T is inconsistent.
It should be stressed that these proofs become less elegant when reformulated
in terms of consistency and satisfiability, as some over-cautious logicians do —
they tend to be easily frightened by inconsistencies15 . The more natural relation
is indeed that between inconsistency and unsatisfiability.
Definition 13. A logic is paraconsistent if it admits a theory that is Aristotle
inconsistent but absolutely consistent.
Proposition 14. 1. A paraconsistent logic cannot have proof-theoretic negation.
2. A sound and complete paraconsistent logic cannot have model-theoretic negation.
Proof. 1. By Prop. 10.
2. Let T be an Aristotle inconsistent theory, i.e. T ψ and T ¬ψ for some
sentence ψ. By soundness, T |= ψ and T |= ¬ψ. By the definition of modeltheoretic negation, T is unsatisfiable. But then for any sentence ϕ, T |= ϕ, thus
by completeness, also T ϕ. Hence, T is absolutely inconsistent.
6
Conservative Extensions
Definition 15. A theory morphism σ : T1 −→ T2 is model-theoretically conservative, if each T1 -model has a σ-expansion to a T2 -model. It is consequencetheoretically conservative, if for each sentence ϕ of same signature as T1 ,
T2 |= σ(ϕ) implies T1 |= ϕ.
It is proof-theoretically conservative, if the same holds for , i.e. for each sentence ϕ of same signature as T1 ,
T2 σ(ϕ) implies T1 ϕ.
The relation between these notions is as follows:
15
This goes as far as the Wikipedia website for “Inconsistency” being redirected to
“Consistency”!
49
Proposition 16. Model-theoretic conservativity implies consequence-theoretic
conservativity (but not vice versa). In a sound and complete logic, consequencetheoretic and proof-theoretic conservativity are equivalent.
Proof. Concerning the first statement, let T2 |= σ(ϕ). We need to show T1 |= ϕ.
Let M1 be a T1 -model. By model-theoretic conservativity, it has an expansion
M2 to a T2 -model; hence also M2 |= σ(ϕ). By the satisfaction condition, M1 =
M2 |σ |= ϕ.
The second statement is obvious.
The importance of conservativity is that it allows to reduce inconsistency
(resp. unsatisfiability) of a smaller theory to that of larger one, using the following obvious result:
Proposition 17. 1. Model-theoretically conservative theory morphisms reflect
unsatisfiability.
2. Proof-theoretically conservative theory morphisms reflect inconsistency.
Typically, the target of a conservative theory morphism is larger than (or even
an extension of) the source. At first sight, it may sound strange to reduce the
goal of showing inconsistency of a given theory to that of showing it for a larger
one. However, note that generally, larger theories have more axioms, and hence
it is more likely to prove that they are inconsistent. (Indeed, the largest theory
consisting of all sentences is always inconsistent.) Moreover, small inconsistent
theories can be boring: who is interested in the smallest inconsistent theory
consisting just of falsum? For example, Frege’s Begriffsschrift (which is a conservative extension of falsum) is much more interesting.
7
Conclusion
We have summarised and discussed recent research aimed at proving inconsistency of specifications in a structured and institution-independent way. These
efforts form part of a larger program aimed at proving the inconsistency of the
empty specification, i.e. inconsistency of the meta-framework underlying most
of the formalisms under consideration, Zermelo-Fraenkel set theory with choice
(ZFC) and hence, by the independence of the axiom of choice as mentioned
above, of ZF set theory without choice. In particular, recent research in pure
mathematics has been concerned with finding sufficient conditions for the inconsistency of ZF. E.g. it has been shown that the inconsistency of ZF can be
reduced to (and is therefore equivalent to) provability in ZF of
– the existence of natural numbers a, b, c and n ≥ 3 such that an + bn = cn
(Andrew Wiles [13])
– the existence of natural numbers (a, b, x, y) = (2, 3, 3, 1) such that xa −y b = 1
(Preda Mihăilescu [9])
– the existence of a simply connected closed 3-manifold not homeomorphic to
S 3 (Grigori Perelman [10–12])
50
Moreover, ongoing work in automated theorem proving, Thomas Hales’ FlysPecK project (http://code.google.com/p/flyspeck/), is directed at reducing the
inconsistency of ZF to existence of a sphere packing of average density strictly
less than π/18. In summary, there is good hope that the paradise of mathematics,
a widely accepted inconsistent set of foundations, will soon be re-opened.
References
1. R. Diaconescu. Institution-Independent Model Theory. Birkhäuser, 2008.
2. J. Fiadeiro and A. Sernadas. Structuring theories on consequence. In D. Sannella
and A. Tarlecki, eds., 5th WADT, vol. 332 of LNCS, pp. 44–72. Springer Verlag,
1988.
3. J. A. Goguen and R. M. Burstall. Institutions: Abstract model theory for specification and programming. Journal of the Association for Computing Machinery,
39:95–146, 1992. Predecessor in: LNCS 164, 221–256, 1984.
4. H. Herrlich and G. Strecker. Category Theory. Allyn and Bacon, Boston, 1973.
5. I. Horrocks and A. Voronkov. Reasoning support for expressive ontology languages
using a theorem prover. In Proceedings of the Fourth International Symposium
on Foundations of Information and Knowledge Systems (FoIKS), number 3861 in
Lecture Notes in Computer Science, pp. 201–218. Springer, 2006.
6. R. E. Kamouna. A paradox ⇒ SAT is (NOT) NP-complete & ZFC is inconsistent.
http://arxiv.org/abs/0806.2947.
7. J. Lambek and P. J. Scott. Introduction to Higher Order Categorical Logic. Cambridge University Press, 1986.
8. J. Meseguer. General logics. In Logic Colloquium 87, pp. 275–329. North Holland,
1989.
9. P. Mihăilescu. Primary cyclotomic units and a proof of catalan’s conjecture. J.
Reine angew. Math., 572:167–195, 2004.
10. G. Perelman. The entropy formula for the ricci flow and its geometric applications.
arXiv:math.DG/, 2002.
11. G. Perelman. Ricci flow with surgery on three-manifolds. arXiv:math.DG/0303109,
2002.
12. G. Perelman. Finite extinction time for the solutions to the ricci flow on certain
three-manifolds. arXiv:math.DG/0211159, 2003.
13. A. Wiles. Modular elliptic curves and fermat’s last theorem. Ann. Math., 141:443–
551, 1995.
The VSE Refinement Method in Hets
Mihai Codescu1 , Bruno Langenstein2 , Christian Maeder1 , and Till
Mossakowski1,3,4
1
1
German Research Center for Artificial Intelligence (DFKI GmbH), Bremen,
Germany
2
DFKI GmbH, Saarbrücken, Germany
3
SFB/TR 8 Spatial Cognition, Bremen and Freiburg, Germany
4
Albert-Ludwigs-Universität Freiburg, Germany
Introduction
Bernd Krieg-Brückner’s research group originally (in the early 1980ies) carried
the title “programming languages and compiler construction”. Indeed, Bernd
had been a co-designer of the programming language Ada. But already in this
phase, he interests extended to a further topic: formal specification. He worked
on Anna [12], a language allowing for annotating Ada programs with formal
specifications.
More than ten years later, Bernd was founding a member of the “Common
Framework Initiative for Algebraic Specification and Development” (CoFI),
which originated in the COMPASS project and the IFIP working group 1.3.
The aim was to reach an agreement, among approximately 50 researchers from
all over Europe, on a common specification language called Casl (the Common
Algebraic Specification Language) [1, 3, 7]. Indeed, Bernd has played an essential role in the language design process, especially in the critical phase where
everything was unclear and everybody put his or her favourite features on the
table.5
Again nearly ten years later, Bernd has initiated the founding of a new branch
of the German research center for artificial intelligence (DFKI) in Bremen. Some
four years later, this is now a great success, with many different research areas
and industry cooperations. The present work arose in the context of the project
“FormalSafe” funded by the German ministry of research. Indeed, part of this
project consists of a cooperation of DFKI Saarbrücken with DFKI Bremen in
the area of formal methods. While DFKI Saarbrücken has long experiences with
the development and use of the industrial-strength verification tool VSE, DFKI
Bremen has developed the experimental and flexible verification tool Hets. We
want to combine the best of both worlds by establishing a connection between the
5
After three years of design discussion, in Spring 1998, another one of dozens meetings of the CoFI language design group took place. At a time point when nearly
everything was settled and everyone was completely exhausted, Bernd announced:
“unfortunately, I just have realised that we have to revert a design decision and go
back to non-linear visibility.” Everyone sighed. But then Bernd revealed that it was
an April joke — and the following laughter was very refreshing indeed.
51
52
VSE prover and the Hets proof management. For VSE, this brings additionally
flexibility: VSE specifications can now be verified not only with the VSE prover,
but also with provers like SPASS and Isabelle which are interfaced with Hets.
On the other hand, Hets benefits from VSE’s industrial experience, including
a practical relation between specification and programming languages.
2
Presentation of Hets
Hets is a multi-logic proof management tool that heterogeneously integrates
many languages, logics and tools on a strong semantic basis.
The origins of Hets date back to 1997, when a tool for the newly developed
specification language Casl was needed. Cats, the Casl tool set (see Fig. 1),
provided a parser and a static analysis for Casl specifications, as well as an
encoding of Casl into the theorem prover Isabelle/HOL. With Cats, simple
consequences of specifications could be verified, but proof support for e.g. refinements between specifications was lacking — although a first connection to the
“development graph manager” built in Saarbrücken was set up.
Fig. 1. Architecture of the Casl tool set
53
2.1
CASL
Casl had been designed from the outset as the central language in a family of
languages. Hence, soon sublanguages and extension of Casl, like the higherorder extension HasCasl, the coalgebraic extension CoCasl, the modal logic
extension ModalCasl the reactive extensions Casl-Ltl and Csp-Casl and
others emerged. Then, naturally the question arose: how to extend Cats to
these languages? Luckily, the Casl follows a separation of concerns — it has
been designed in four different layers [1, 3, 7]:
basic specifications are unstructured collections of symbols, axioms and theorems, serving the specification of individual software modules. The specific
logic chosen for Casl here is first-order logic with partial functions, subsorting and induction principles for datatypes;
structured specifications organise large specifications in a structured way, by
allowing their translation, union, parameterisation. restriction to an export
interface and more. Still, structured specifications only cover the specification
of individual software modules;
architectural specifications allow for prescribing the structure of implementations, thereby also determining the degree of parallelism that is possible
in letting different programmers independently develop implementations of
different subparts;
specification libraries allow the storage and retrieval of collections of specifications, distributed over the Internet.
2.2
Institutions
A crucial point in the design of these layers is that the syntax and semantics
of each layer is orthogonal to that of the other layers. In particular, the layer
of basic specifications can be changed to a different language and logic (e.g. an
extension of Casl, or even a logic completely unrelated to Casl), while retaining
the other layers. The central abstraction principle to achieve this separation of
layers is the formalisation of the notion of logical system as institutions [9], a
notion that arose in the late 1970ies when Goguen and Burstall developed a
semantics for the modular specification language Clear [5].
We recall this central notion here, assuming some basic knowledge of category theory. The reader not familiar with category theory can safely skip this
definition, and just remember that an institution provides
– a notion of signature, carrying the context of user-defined (i.e. non-logical)
symbols, and a notion of signature morphisms (translations between signatures);
– for each signature, notions of sentence and model, and a satisfaction relation
between these;
– for each signature morphism, a sentence translation and a model reduction
(the direction of the latter being opposite to the signature morphism), such
that satisfaction is invariant under translation resp. reduction along signature morphisms.
54
More formally, an institution I consists of:
– a category SignI of signatures;
– a functor SenI : SignI → Set,6 giving a set Sen(Σ) of Σ-sentences for
each signature Σ ∈ |SignI |, and a function Sen(σ) : Sen(Σ) → Sen(Σ ),
denoted by σ, that yields σ-translation of Σ-sentences to Σ -sentences for
each signature morphism σ : Σ → Σ ;
7
– a functor ModI : Signop
I → Cat, giving a category Mod(Σ) of Σ-models
for each signature Σ ∈ |SignI |, and a functor Mod(σ) : Mod(Σ ) → Mod(Σ),
denoted by |σ , that yields σ-reducts of Σ -models for each signature morphism σ : Σ → Σ ; and
– for each Σ ∈ |SignI |, a satisfaction relation |=I,Σ ⊆ ModI (Σ) × SenI (Σ)
such that for any signature morphism σ : Σ → Σ , Σ-sentence ϕ ∈ SenI (Σ) and
Σ -model M ∈ |ModI (Σ )|:
M |=I,Σ σ(ϕ) ⇐⇒ M |σ |=I,Σ ϕ
[Satisfaction condition]
A very prominent example is the institution F OL= of many-sorted firstorder logic with equality. Signatures are many-sorted first-order signatures, i.e.
many-sorted algebraic signatures enriched with predicate symbols. Models are
many-sorted first-order structures, and model reduction is done by translating a
symbol that needs to be interpreted along the signature morphism before looking
up its interpretation in the model that is being reduced. Sentences are first-order
formulas, and sentence translation means replacement of the translated symbols.
Satisfaction is the usual satisfaction of a first-order sentence in a first-order
structure.
The institution CF OL= adds sort generation constraints to F OL= . These
express that some of the carriers sets are generated by some of the operations
(and possibly the other carrier sets). SubP CF OL= , the Casl institution, further
equips CF OL= with subsorting and partial functions (which, however, will not
play a role in this paper).
With the notion of institution providing the abstraction barrier between the
layer of basic specifications on the one hand and the other layers on the other
hand, it was quite natural (though also a great challenge) to realise this abstraction barrier also at the level of tools. The necessary re-implementation of Cats
lead to the Heterogeneous Tool Set Hets. Hets provides an object-oriented
interface for institutions, realised through a Haskell type class. New institutions (together with their concrete syntax, parsers, static analysis tools) can be
plugged in with moderate effort. Moreover, Hets provides generic interfaces that
ease the connection of individual institutions to proof tools. There are interfaces
capturing both interactive and automatic tools.
Hets allows for relating specifications written in different logics, e.g. Casl
specifications can be imported for Casl extensions, or refinements can occur
across different logics. In order to support this, Hets treats logic translations,
6
7
The category Set has all sets as objects and all functions as morphisms.
Cat is the quasi-category of categories and functors.
55
formalised as institution comorphisms (and morphisms), as first-class citizens.
An institution comorphism captures the idea of encoding or embedding between
two institutions. It provides
– a translation of signatures (and signature morphisms),
– a translation of sentences,
– a translation of models (going backwards to the direction of the comorphism),
such that satisfaction is invariant under translation of sentences resp. models.
More formally, an institution comorphism ρ : I → I consists of:
– a functor ρSign : Sign → Sign ;
– a natural transformation ρSen : Sen → ρSign ; Sen , that is, a family of func Sign
(Σ)), natural in Σ ∈ |Sign|; and
tions ρSen
Σ : Sen(Σ) → Sen (ρ
Mod
: (ρSign )op ; Mod → Mod, that is, a family
– a natural transformation ρ
: Mod (ρSign (Σ)) → Mod(Σ), natural in Σ ∈ |Sign|,
of functions ρMod
Σ
Sign
such that for any Σ ∈ |Sign|, the translations ρSen
(Σ))
Σ : Sen(Σ) → Sen (ρ
Sign
Mod
(Σ)) → Mod(Σ) of models preserve the
of sentences and ρΣ : Mod (ρ
satisfaction relation, i.e., for any ϕ ∈ Sen(Σ) and M ∈ Mod (ρSign (Σ)):
Mod
M |=ρSign (Σ) ρSen
Σ (ϕ) ⇐⇒ ρΣ (M ) |=Σ ϕ
[Satisfaction condition]
Hets is based on a logic graph of institutions and comorphisms, which is a
parameter to the tools acting at the structured, architectural and library layers.
The logic graph can be changed and extended without the need even to recompile
those logic independent analysis tools. The architecture of Hets is shown in
Fig. 2. Hets’ development graph component, inspired by the tool Maya (a
cousin of VSE, also developed in Saarbrücken) provides a proof management
for heterogeneous specifications, relying on proof tools for the individual logics
involved.
2.3
Refinement
The methodology of formal software development by stepwise refinement describes the ideal process (which in practice is more a loop with continuous feedback) as follows: starting from initial informal requirements, these are translated
to a formal requirement specification, which is then further refined to a formal
design specification and then to an executable program.
Simple refinements between specifications can be expressed as so-called views
in Casl, which are just theory morphisms. The degree of looseness diminishes
along a refinement (technically, the model class shrinks). For more complex refinements involving architectural decompositions (i.e. branching points in the
emerging refinement tree), a refinement language has been designed [13]. Sometimes (e.g. when refining arrays to stacks with pointers), an observational interpretation of specification is needed. This has been developed in theory to some
degree [4], but not implemented in Hets yet.
56
Architecture of the heterogeneous tool set Hets
Text
Tools for heterogeneous
specifications
Logic graph
Tools for specific logics
Haskell
Isabelle
Parser
Text
Abstract syntax
HasCASL
Parser
Static Analysis
VSE
CspCASL
CoCASL
Static Analysis
(Signature, Sentences)
SoftFOL
ModalCASL
Interfaces
CASL
XML, Aterm
Conservativity checkers
Model finders
Model checkers
RelScheme
Global Environment
Interfaces
CASL-DL
Theorem provers
Rewriters
Abstract syntax
XML, Aterms
WWW, GUI
DL
Propositional OWL-DL
Grothendieck logic
(Flattened logic graph)
Heterogeneous
development graphs
Heterogeneous inference engine
Decomposition of proof obligations
Management of proofs
Heterogeneous proof trees
Fig. 2. Architecture of Hets
3
Presentation of VSE
The V erification S upport E nvironment (VSE) is a tool that supports the formal development of complex large scale software systems from abstract high
level specifications down to the code level. It provides both an administration
system to manage structured formal specifications and a deductive component
to maintain correctness on the various abstraction levels (see Fig. ??). Taken
together these components guarantee the overall correctness of the complete
development. The structured approach allows the developer to combine specifications in an algebraic functional style with state based formal descriptions of
concurrent systems.
3.1
History of VSE
VSE has been developed in two phases on behalf the German Bundesamt für
Sicherheit in der Informationstechnik (BSI) to satisfy the needs in software developments according to the upcoming standards ITSEC and Common Criteria.
Since then VSE has been successfully applied in several industrial and research
projects, many of them being related to software evaluation [10, 2, 11, 6].
57
;"
;#
!"
"
;
Fig. 3. Architecture of VSE
3.2
The VSE Methodology
VSE supports a development process that starts with a modular formal description of the system model and possibly together with separate requirements or
security objectives. Logically the requirements have to be derivable from the system model. Therefore, the requirements lead to proof obligations that must be
discharged by using the integrated deductive component of VSE.
In a refinement process the abstract system model can be related to more
concrete models. This is in correspondence with a software development that
starts from a high level design and then descends to the lower software layers
such that in a sense higher layers are implemented based on lower layers. Each
such step can be reflected by a refinement step in VSE. These steps involve
programming notions in the form of abstract implementations, that can later be
exploited to generate executable code. Each refinement step gives rise to proof
obligations showing the correctness of the implementations. Refinements also
can be used to prove consistency of specifications, because they describe a way
how to construct a model. This plays a major role for the formal specifications
required for Common Criteria, which only need to cover higher abstraction levels.
In addition to the vertical structure given by refinement steps, VSE also allows the specification to be structured horizontally to organise the specifications
on one abstraction level. Each single (sub)specification can be refined vertically
or further decomposed horizontally, such that the complete development is rep-
58
resented by a development graph. The deductive component is aware of this
structure. And this is an important aspect for the interactive proof approach, as
the structure helps the user to prove lemmas or prove obligations that require
properties from various parts of the specification.
3.3
Specification Formalisms in VSE
Formal development in VSE is currently based on two formalisms: Abstract data
types are used to describe data structures and functional computations on them.
A variant of temporal logic similar to TLA is provided as a specification language for state based systems that consist of concurrent components. While
abstract data types can already be used in the temporal logic specifications, a
new formalism will be available in the near future, that allows the developer to
combine state based aspects with abstract data types. This new formalism aims
at formalising implementations of abstract datatypes with the help of pointer
structures.
Functional Modelling Abstract data type specifications in VSE are essentially
first-order theories (often simply called theories) extended with sort generation
constraints. They are similar to CASL specifications and a similar set of structuring operations is provided that consists of enrichment, union, parametrisation
and instantiation.
In addition, the VSE specification language supports a refinement approach
based on explicit submodels and congruences [14]. (This is in contrast to Casl’s
observational refinement [4], where the congruence is generated implicitly.) Refinements associate an abstract data type specification, called the export specification of the refinement, with an implementation. The implementation is based
on another theory, called the import specification and contains several functional
procedures written in an imperative language. These procedures use the functions and predicates of the import specifications. A so called mapping relates
each sort of the export specification to a sort of the import specification, while
the functions and procedures are mapped to procedures in the import specification.
A refinement describes the construction of a model for the signature of the
export specification (export model) from a model of the import specification
(import model). The functions and predicates are interpreted by the computations of the procedures. The elements of the carrier sets of the export model are
constructed from the carrier sets of the import model. The implementations are
allowed to represent a single value in the export specification by several values
of the import specifications. For example, when implementing sets by lists, a
set might be represented by any list containing all elements of the set in any
order. Furthermore, we do not require that all values of a sort in the import
specification really represent a value of the export specification. In the example
below where we will implement natural numbers by binary words, we will exclude
words with leading zeroes. In order to describe the construction of the carrier
59
sets, the refinement contains two additional procedures for each sort: procedure
defining a congruence relation and a procedure defining a restriction. The restriction terminates on all elements, that represent export specification values.
The congruence relation determines the equivalence classes that represent the
elements of the export model.
A refinement is correct, if for every import model the export model constructed according to the refinement is actually a model of the export theory.
The VSE system generates proof obligations that are sufficient for the correctness.
3.4
The Deductive Component of VSE
Corresponding to the two specification formalisms, the deductive component of
VSE supports two logics: dynamic logic for abstract data type refinement and a
slightly adapted form of TLA for the state based systems. For both logics VSE
uses a sequent calculus in the style of [8].
Integration of automation with user interactions is achieved by the so called
heuristic loop. A set of heuristics is tried in turn. In case of success the heuristic
will apply a rule and increase the proof tree. In case of failure the next heuristic
is called. Heuristics can be interactive and ask the user for help, for example to
select an appropriate instantiation. There is also a last resort heuristic which
allows the user to select a rule from the set of all applicable rules.
4
Institution of Dynamic Logic
VSE provides an interactive prover, which supports a Gentzen style natural deduction calculus for dynamic logic. This logic is an extension of first-order logic
with two additional kinds of formulas that allow for reasoning about programs.
One of them is the box formula [α]ϕ, where α is a program written in an imperative language, and ϕ is a dynamic logic formula. The meaning of [α]ϕ can
be roughly put as “After every terminating execution of α, ϕ holds.”. The other
new kind of formulas is the diamond formula αϕ, which is the dual counter
part of a box formula. The meaning of αϕ can be circumscribed as “After some
terminating execution of α, which satisfies ϕ”.
4.1
Signatures
The starting point for dynamic logic signatures are the signatures of first-order
logic with equality (FOL= ) that have the form ΣFOL= = (S, F, P ) consisting of
a set S of sorts, a family F of function symbols and a family P of predicate
symbols. Because we need to name procedures, we add a S ∗ × S ∗ -sorted family
P R = (P Rv,w )v,w∈S ∗ of procedure symbols, leading to signatures of the form
Σ = (S, F, P, P R). We have two separate lists v and w of the argument sorts of
the procedure symbols in P Rv,w , in order to distinguish the sorts of the input
parameters (v) from those of the output parameters (w).
60
A signature morphism between two signatures maps sorts, operation symbols,
predicate symbols and procedure symbols in a way such that argument and result
sorts are preserved.
4.2
Sentences
Let Σ = (S, F, P, P R) be a dynamic logic signature with P R = (P Rv,w )v,w∈S ∗ .
First we define the syntax of the programs that may appear in dynamic logic
formulas. The set PΣ of Σ-programs is the smallest set containing:
–
–
–
–
–
–
–
–
abort, skip
x := τ
α; β
declare x : s = τ in α
declare x : s =? in α
if ε then α else β fi
while ε do α od
p(x1 , x2 , ..., xn , y1 , y2 , . . . , ym ) ,
where x, x1 , x2 , . . . , xn , y1 , y2 , . . . , ym are variables, τ a Σ-term of the same sort s
as x, ε a boolean Σ-formula (i.e. a Σ-Formula without quantifiers, boxes and diamonds), α, β ∈ PΣ , p a procedure symbol, such that the sorts of x1 , . . . , xn , y1 , . . . , ym
match the argument and result sorts of p.
These kinds of program statements can be explained informally as follows:
abort is a program that never terminates. skip is a program that does nothing. x := τ is the assignment. declare x = σ in α is the deterministic form
of a variable declaration which sets x to the value of σ. Its nondeterministic
form var x =? in α sets x to an arbitrary value before executing α. α; β is the
composition of the programs α and β, such that α is executed before β. The
conditional if ε then α else β fi means that α is executed if ε holds, otherwise β
is computed. Finally, the loop while ε do α od checks the condition ε, in case of
validity executes α and repeats the loop.
There are three kinds of sentences that may occur in a Σ-dynamic logic
specification.
1. Dynamic logic formulas are
– any (S, F, P )-first-order formula ϕ
– for any Σ-formula ϕ and a Σ-program α the formulas [α]ϕ and αϕ.
2. Procedure definitions are expressions of the form:
defprocs
procedure p(x1 , . . . , xn , y1 , . . . , ym )α
...
defprocsend
where p ∈ P Rv,w for some v, w ∈ S ∗ , x1 , . . . , xn , y1 , . . . , ym are variables
of the corresponding sorts in v, w, and α ∈ PΣ is a Σ-program with free
variables from the set {x1 , . . . , xn , y1 , . . . , ym }.
61
3. Restricted sort generation constraints express that a set of values defined by
restriction procedure can be generated by the given set of procedures, the
constructors. Sort generation constraints in the export specification will give
rise to proof obligations stated as a sentence of this kind. Syntactically a
restricted sort generation constraints takes the form
generated type s ::= p1 (. . . )|p2 (. . . )| . . . |pn (. . . ) restricted by r ,
(1)
where s is a sort symbol, p1 ,. . . ,pn are functional procedure symbols, the
dots in p1 (. . . ) etc. has to be replaced by a list of the argument sorts, and r
is a procedure symbol taking one argument of sort s. The meaning is, that
all elements of sort s that fulfil the restriction r, i.e. for which r terminates,
can be generated by the constructors p1 , p2 , . . . , pn .
4.3
Models
Let Σ = (S, F, P, P R) be a dynamic logic signature. A (dynamic logic) Σ-model
M is obtained from any FOL= (S, F, P )-model M F OL by supplementing it with
a mapping from the family P R of procedure symbols to relations, such that for
P R = (P Rv,w )v,w∈S ∗
–
–
–
–
Ms = MsF OL ,
(fw,s )M = (fw,s )M F OL ,
(pw )M = (pw )M F OL and
for all pr ∈ P Rv,w : prM ⊆ Mv × Mw is a relation.
4.4
Satisfaction of Dynamic Logic Formulas
Semantics is defined in a Kripke-like manner. For a given signature Σ and a
Σ-model M the (program) states are variable valuations, i.e. functions from the
fixed infinite set of variables to M , such that for each sort s variables of sort s
are mapped to values of Ms . The semantics of a program α with respect to a
model M is a predicate .αM . on two program states. qαr can be read as: If
α is started in state q it may terminate after having changed the state to r.
– qskipM q
– not qabortM r
–
–
–
–
–
–
–
σ q,M if v ≡ x
qx := σM r ⇔ r = λv.
q(v) otherwise
M
qα; β r ⇔ for some state s : qαs and sβr
qdeclare x : s = σ; αM r ⇔ qx := σ; αr
qdeclare x : s =?; αM r ⇔ for some a ∈ sM : q[x ← a]αr
qif ε then α else β fir⇔ (q |= ε and qαr) or (q |= ¬ε and qβr)
qwhile ε do α odr ⇔ q(if ε then α else skip fiM )∗ r and r |= ¬ε
qpr(x1 , . . . , xn ; y1 , . . . , ym )M r ⇔ prM (q(x1 ), . . . , q(xn ); r(y1 ), . . . , r(ym ))
62
where for any program α, (αM )∗ is the reflexive transitive closure of the relation
q(y) if y = x
, and
αM , and the state q[x ← a] is defined as q[x ← a](y) =
a
if y = x
σ q,M is the evaluation of the term σ with respect to the model M and state q.
The satisfaction relation for first-order logic (FOL= ) operators is as usual.
For the box operator we stipulate
M, q |= [α]ϕ iff for all program states r : qαM r implies M, r |= ϕ
and αϕ is defined as ¬[α]¬ϕ.
4.5
Satisfaction of Procedure Definitions
The procedures in our model will not have any side effects (except for modifying
the output parameters).
Unwinding a procedure call by replacing it by the body of the procedure and
substituting the formal parameter variables by the actual parameters should not
change the result of a program. Therefore, for a signature Σ a Σ-model M is a
model of a procedure declaration
defprocs procedure pr(x1 , . . . , xn , y1 , . . . , ym )α defprocsend
without recursion if
M |= ∀x1 , . . . , xn , r1 , . . . , rm :
(pr(x1 , . . . , xn ; y1 , . . . , ym )y1 = r1 ∧ · · · ∧ ym = rm )
⇔ αy1 = r1 ∧ · · · ∧ ym = rm
holds. We then write M ||= π. It is obvious how this can be extended to declarations of more than one procedure.
In the presence of recursion this is not sufficient to make the procedure definitions non-ambiguous and adequate to conventional semantics of programming
languages. Therefore, from several models complying with the definitions the
minimal model with respect to some order will be chosen. The order compares the
interpretations of the procedures symbols, such that the order relation M1 ≤ M2
holds for two models M1 and M2 for the same signature Σ = (S, F, P, P R), iff
prM1 ⊆ prM2 for all pr ∈ P R and the interpretations of sort, function and
predicate symbols are identical. Then we define that M satisfies π (M |= π), iff
M ||= π, and for all other models M only differing in the interpretations of the
procedure symbols pr1 , . . . , prk , M ||= π implies M ≤ M .
4.6
Satisfaction of restricted sort generation constraints
A restricted sort generation constraint as in (1) is said to hold, iff
r(a)true → uniform restr s (a)true
63
holds, where uniform restr s is a uniform restriction procedure constructed from
the procedures enumerated in the constraint. This is a procedure that nondeterministically constructs a value using the constructors. Only if the result equals
the input, the procedure terminates. According to the semantics, the existence
of one sequence of nondeterministic decisions that leads to the termination of
the program, is sufficient to consider the program to terminate.
As an example consider the constraint
generated type nat ::= i 0|i suc(nat) restricted by restr nat .
The corresponding uniform restriction uniform restr nat is defined by:
procedure uniform restr nat (x)
declare y : nat :=?;
y := i 0();
if x = y then
declare z : nat :=?;
uniform restr nat (z);
y = i succ(z);
if x = y then abort fi
fi
4.7
Calculus
The common rules for first-order logic are used in VSE. In addition, rules for the
modal operators are required. We only present some examples of the rules used
in VSE for dynamic logic to give an impression how the dynamic logic proofs
can be done:
In most cases, assignments on the right hand side are dealt with by this rule:
Γ, x = τ ϕx←x , Δ
Γ x := τ ϕ, Δ
where ϕx←x is the formula obtained by renaming all occurrences of the variable
x with the fresh variable x .
The following rule for conditionals introduces a distinction between the case
when the condition ε holds and its opposite case.
Γ, ε α ϕ, Δ
Γ, ¬ε β ϕ, Δ
Γ if ε then α else β fi ϕ, Δ
For all other kinds of statement there are also rules in VSE. Applying the
appropriate rules is in many respects like executing a the program except that
instead of computing a value in the program variables, equations between program variables and terms are derived. Therefore, this approach is called symbolic
execution. The heuristics in VSE support the selection of rules according to this
approach.
64
5
VSE Refinement as an Institution Comorphism
When integrating VSE and its notion of refinement into Hets, we want to avoid
the need for a special treatment of this refinement (one could consider adding
special refinement links in development graphs). Rather, our central idea is to
encode VSE refinement as ordinary refinement in Hets, with the help of a
comorphism that does the actually restriction-quotient construction. With this
approach, only the Hets’ logic graph needs to be extended by a logic and a
comorphism (actually, we will see that two comorphisms are necessary), while
the logic-independent part of Hets can be left untouched.
We define a comorphism CASL2V SERef ine from CF OL= to CDyn= . Each
signature (S, F, P ) is mapped to the CDyn= theory ((S, ∅, ∅, P R), E). P R contains (1) for each sort s, a symbol restr s ∈ P R[s],[] for the restriction formula on
the sort (the restriction predicate is then obtained as the set of values for which
restr s terminates) and a symbol eqs ∈ P R[s,s],[bool] for the equality on the sort
and (2) for each function symbol f : w → s ∈ Fw,s , a symbol f : w → s ∈ P Rw,[s]
and for each predicate symbol p : w ∈ Pw , a symbol p : w → [bool] ∈ P Rw,[bool] .
The procedure symbols are not assigned any definition and thus any implementation can be later plugged in using a CDyn= signature morphism.
The set of axioms E contains sentences saying that for each sort s, (1) eqs is
a congruence and it terminates for inputs satisfying the restriction and (2) the
procedures that implement functions/predicates terminate for inputs satisfying
the restriction and their results also satisfy the restriction. These properties are
to be proven when providing an actual implementation.
Given a signature (S, F, P ) and a model M of the theory ((S, ∅, ∅, P R), E),
we define the translation of M to a (S, F, P )-model, denoted M . The interpretation of a sort s in M is constructed in two steps. First we take the subset
Mrestr s ⊆ Ms of elements, for which the restriction terminates. Then we take the
quotient Mrestr s /≡ according to the congruence relation ≡ defined by eqs , such
that for all x1 , x2 ∈ sM x1 ≡ x2 is equivalent to M |= eqs (x1 , x2 ; y)y = true.
For each function symbol f , we define the value of Mf in the arguments x1 , ..., xn
to be the value returned by the call of procedure Nf on inputs x1 , .., xn , that is
Mf (x1 , ..., xn ) = b if and only if Nf (x1 , ..., xn ; y)y = b. The axioms (2) in E
ensure that Mf is total and well-defined. Similarly, for each predicate symbol p,
Mp (x1 , ..., xn ) holds iff Np (x1 , .., xn ; y)y = true.
Sentence translation is based on translation of terms into programs that
compute the representation of the term. Basically, each function application is
translated to a procedure call of the implementing procedure, and new output
variables are introduced.
– a variable x is mapped to x := x, where the left-hand side x is the output
variable and the right-hand side x is the logical variable;
– an constant c is mapped to c(; y), where c is now the procedure implementing
the constant and y is a new output variable;
– a term f (t1 , .., tn ) is mapped to α1 ; ..αn ; a := f (y1 , .., yn ), where αi is the
translation of ti with the output variable yi and a is a new output variable
65
Then
– a equation t1 = t2 is translated to
α1 ; α2 ; eqs (y1 , y2 ; y)y = true
where αi is the translation of the term ti , with the output variable yi (one
could also eliminate the assignments through substitutions);
– a predicate p(t1 , .., tn ) is translated to
α1 ..αn p(y1 , .., yn ; y)y = true
where αi is the translation of the term ti , with the output variable yi (one
could again eliminate the assignments through substitutions);
– Boolean connections of formulas are translated into the same connections of
their translated formulas;
– for universally and existentially qualified formulas one also has to make sure
that the bound variables are assigned a value that satisfies the restriction.
The complete translation is obtained by adding as hypotheses to the translation of the formula a list of formulas of type s(y)true, where y is a free variable
of the formula, of sort s.
Sort generation constraints are translated to sort generation restricted constraints over implementing procedures.
Assume we have in the abstract specification of natural numbers a sort generation constraint:
generated type nat ::= 0 | suc (nat)
Then in the resulting VSE theory, the sort generation restricted constraint
generated type nat ::= 0 | suc(nat) restricted by restr nat .
is introduced, where 0 and suc are now the procedures implementing the constructors and restr nat is the restriction procedure on sort nat.
If we implement natural numbers as binary words and have a restriction
procedure on sort bin that terminates for words with non-leading zeros:
type bin ::= b zero | b one | s0(pop :?bin)| s1(pop :?bin);
PROCEDURE nlz : IN x;
FUNCTION i zero :→ bin;
FUNCTION i succ : IN bin → bin;
then in HETS we get as proof obligation
generated type bin ::= i zero|i succ(nat) restricted by nlz
which will be discarded using the VSE mechanism of introducing a uniform
restriction which checks if an element of bin can be generated using the procedures i zero, i suc of the sort generation constraint and then proving that
whenever the restriction nlz holds on a bin value, the uniform restriction also
holds.
66
5.1
Structuring in Context of Refinement
Consider the situation where a theory of a library (e.g. the natural numbers) or
a parameter theory that will be instantiated later occurs both in the abstract
and the refined specification. Such common import specifications should not be
refined, but rather kept identically — and this is indeed the case in VSE.8
To handle this situation in the present context, the import of a first-order
specification into a dynamic logic one is not done along the trivial inclusion
comorphism from CF OL= to CDyn= — this would mean that the operations
of the import need to be implemented as procedures. Instead, we define a comorphism, CASL2V SEImport, which, besides keeping the first-order part, will
introduce for the symbols of import specification new procedure symbols, similarly to CASL2V SERef ine. The difference is that this time the interpretation
of procedure symbols is not loosely specified, but definitions are introduced in
such a way that semantics is not affected: procedures are defined to be implementing each symbol as itself. In the case of sorts, this requires that no element
is restricted and equality procedure on the sort is the set-theoretic equality. In
the case of functions, the procedure simply returns the value of the function in
the given arguments, while in the case of predicates, the procedure returns true
if the corresponding predicate holds. Sentences are translated identically, and
the model reduct keeps interpretation of symbols.
For example, let us consider the situation in the diagram below, where the
natural numbers are imported both in the abstract and the concrete specification
(and the (heterogeneous) refinement link is represented by the double arrow):
N atG
GG
ww
w
GG
ww
GG
w
w
G#
w
{w
+3 Impl
Abstr
Assume there is a sort nat in N at. When translating Abstr to CDyn= along
the refinement comorphism, we make no distinction between the sorts defined in
Abstr and the imported ones, so in the resulting translated theory we will have
symbols for the restriction on sort nat and for equality. The second comorphism,
used for imports, introduces the same symbols in Impl and imposes that they
are implemented as themselves: no element of nat is restricted and the identification is implemented as the strong equality. Thus, the expected behaviour is
obtained: Impl provides default implementations, introduced by the importing
comorphism, such that the sort nat can be regarded as kept, modulo wrapping
into procedures.
8
This resembles a bit the notion of imports of parameterised specifications in Casl,
where the import is shared between formal and actual parameter and is kept identically.
67
6
Example: Implementing natural numbers by binary
words
As an example, we present the implementation of natural numbers as lists of
binary digits, abridged from [14]. The abstract specification, nats, is the specification of natural numbers with 0, successor and addition with the usual Peano
axioms. The implementation, nats-impl, provides procedures for implementation of natural numbers as binary words, which are imported as data part along
CASL2V SEImport from the first-order specification bin (omitted here). We
illustrate the way the procedures are written with the example of the restriction
procedure, nlz, which terminates whenever the given argument has no leading
zeros. Notice that the equality is in this case simply the equality on binary words.
The view binary arith expresses the fact that binary words, restricted to
those with non-leading zeros, represent a refinement of natural numbers, where
each symbol of nats is implemented by the corresponding procedure in the symbol mapping of the view. In figure 5, we present the proof obligations generated
by the refinement comorphism and the translation of a sentence of the abstract
specification along the same comorphism.
7
Conclusions
We have integrated VSE’s mechanism of refining abstract specifications into
procedural implementations into Hets. Via a new logic and two comorphisms,
one of them doing the usual restriction-quotient construction, we could avoid
entirely the introduction of new types of “refinement links” into Hets, but
rather could re-use the present machinery of heterogeneous development graphs
and thus demomstrate its flexibility.
Recently, the interface between VSE and Hets has been extended from flat
basic specifications to structured specifications, such that Hets sends whole
development graphs to VSE. Of course, certain structuring mechanisms like heterogeneous translation and hiding are transformed away before the graph is sent
to VSE.
Future work will try to exploit synergy effects between VSE and Hets e.g.
by integrating automatic provers like SPASS into the refinement proof process.
The refinement method could also be extended from first-order logic to the richer
language Casl, which also features subsorting and partial functions.
Acknowledgements
Work on this paper has been supported by the German Federal Ministry of
Education and Research (Project 01 IW 07002 FormalSafe). We thank Werner
Stephan for conceptual discussions and Erwin R. Catesbeiana for pointing out
a class of specifications particularly easily usable as targets of refinements.
68
spec nats =
free type nats ::= zero n | succ n(nats)
op
add n : nats × nats → nats
%% axioms ...
end
logic VSE
spec nats impl =
bin with logic CASL2VSEImport
then PROCEDURES
hnlz : IN bin; nlz : IN bin; i badd : IN bin, IN bin, OUT bin, OUT bin;
i add : IN bin, IN bin → bin; i succ : IN bin → bin; i zero : → bin;
eq : IN bin, IN bin → Boolean
• DEFPROCS
PROCEDURE hnlz (x )
BEGIN
IF x = b zero THEN ABORT
ELSE IF x = b one THEN SKIP ELSE hnlz (pop(x )) FI
FI
END;
PROCEDURE nlz (x )
BEGIN IF x = b zero THEN SKIP ELSE hnlz (x ) FI END
DEFPROCSEND
%% PROCEDURE i zero(x) ...
end
view binary arith :
{ nats with logic CASL2VSERefine } to nats impl =
nats → bin, gn restr nats → nlz, gn eq nats → eq,
gn zero n → i zero, gn succ n → i succ, gn add n → i add
end
Fig. 4. Natural numbers as binary words.
69
%% Proof obligations introduced by the view
%% i-Termination
%% for i zero
∀ gn x : bin • <:i zero(gn x : bin):> <:nlz (gn x ):> true
%% ii-Congruence
%% termination
∀ gn x, gn y : bin; gn b : Boolean
• <:nlz (gn x ):> true ∧ <:nlz (gn y):> true
⇒ <:eq(gn x : bin, gn y : bin, gn b : Boolean):> true
%% reflexivity
∀ gn x : bin; gn b : Boolean • <:nlz (gn x ):> true
⇒ <:eq(gn x : bin, gn x : bin, gn b : Boolean):>
gn b = (op True : Boolean)
%% compatibility with i add
∀ gn x, gn y : bin; gn b, gn b1, gn b2 : Boolean; gn x1, gn y1, gn x2, gn y2 : bin
• ((<:nlz (gn x1 ):> true) ∧ (<:nlz (gn y1 ):> true)
∧ (<:eq(gn x1 : bin, gn y1 : bin, gn b1 : Boolean):> gn b1 = (op True : Boolean))
∧ (<:nlz (gn x2 ):> true) ∧ (<:nlz (gn y2 ):> true)
∧ <:eq(gn x2 : bin, gn y2 : bin, gn b2 : Boolean):> gn b2 = (op True : Boolean))
⇒ <:i add (gn x1 : bin, gn x2 : bin, gn x : bin):>
<:i add (gn y1 : bin, gn y2 : bin, gn y : bin):>
<:eq(gn x : bin, gn y : bin, gn b : Boolean):>
gn b = (op True : Boolean)
%% iii-export axioms
%% translation of : forall m : nats . add n(m, zero n) = m
∀ gn x0, gn x1, gn x2, gn x3 : bin; gn x4 : Boolean;
m : bin
• <:nlz (m):> true
⇒ <:gn x1 := m ;
gn x2 := i zero;
gn x0 := i add (gn x1, gn x2 );
gn x3 := m;
gn x4 := eq(gn x0, gn x3 ):>
gn x4 = (op True : Boolean)
Fig. 5. Generated proof obligations
70
References
1. E. Astesiano, M. Bidoit, B. Krieg-Brückner, H. Kirchner, P. D. Mosses, D. Sannella,
and A. Tarlecki. Casl - the common algebraic specification language. Theoretical
Computer Science, 286:153–196, 2002.
2. S. Autexier, D. Hutter, B. Langenstein, H. Mantel, G. Rock, A. Schairer,
W. Stephan, R. Vogt, and A. Wolpers. VSE: Formal methods meet industrial
needs. International Journal on Software Tools for Technology Transfer, Special
issue on Mechanized Theorem Proving for Technology, 3(1), september 2000.
3. Michel Bidoit and Peter D. Mosses. Casl User Manual, volume 2900 of LNCS
(IFIP Series). Springer, 2004. With chapters by T. Mossakowski, D. Sannella, and
A. Tarlecki.
4. Michel Bidoit, Donald Sannella, and Andrzej Tarlecki. Observational interpretation
of casl specifications. Mathematical Structures in Computer Science, 18(2):325–371,
2008.
5. R.M. Burstall and J.A. Goguen. The semantics of CLEAR, a specification language. In Proceedings of the Abstract Software Specifications, 1979 Copenhagen
Winter School, LNCS 86, pages 292–332. Springer, 1980.
6. Lassaad Cheikhrouhou, Georg Rock, Werner Stephan, Matthias Schwan, and
Gunter Lassmann. Verifying a chipcard-based biometric identification protocol
in VSE. In Janusz Górski, editor, Computer Safety, Reliability, and Security, 25th
International Conference, SAFECOMP 2006, Gdansk, Poland, September 27-29,
2006, Proceedings, volume 4166 of Lecture Notes in Computer Science, pages 42–56.
Springer, 2006.
7. CoFI (The Common Framework Initiative). Casl Reference Manual, volume 2960
of LNCS (IFIP Series). Springer, 2004.
8. Gerhard Gentzen. Untersuchungen über das logische Schließen I & II. Mathematische Zeitschrift, 39:176–210, 572–595, 1935.
9. J.A. Goguen and R.M. Burstall. Institutions: Abstract model theory for specification and programming. Journal of the ACM, 39(1):95–146, 1992.
10. Dieter Hutter, Bruno Langenstein, Georg Rock, Jörg Siekmann, Werner Stephan,
and Roland Vogt. Formal software development in the verification support environment. Journal of Experimental and Theoretical Artificial Intelligence, 12(4):383–
406, December 2000.
11. Bruno Langenstein, Roland Vogt, and Markus Ullmann. The use of formal methods
for trusted digital signature devices. In James N. Etheredge and Bill Z. Manaris,
editors, FLAIRS Conference, pages 336–340. AAAI Press, 2000.
12. D.C. Luckham, F.W. von Henke, B. Krieg-Brückner, and O. Owe. Anna, a Language for Annotating Ada Programs: Reference Manual. Number 260 in Lecture Notes in Computer Science. Springer-Verlag; D-69121 Heidelberg, Germany;
http://www.springer.de, 1987.
13. T. Mossakowski, D. Sannella, and A.Tarlecki. A simple refinement language for
Casl. In Jose Luiz Fiadeiro, editor, WADT 2004, volume 3423 of Lecture Notes in
Computer Science, pages 162–185. Springer; Berlin; http://www.springer.de, 2005.
14. Wolfgang Reif. Correctness of generic modules. In Anil Nerode and Michael A.
Taitslin, editors, LFCS, volume 620 of Lecture Notes in Computer Science, pages
406–417. Springer, 1992.
71
Mihai Codescu obtained his M.Sc at Şcoala Normală
Superioară Bucureşti, Romania, under supervision of
R. Diaconescu. Since November 2006 he joined BerndKrieg Brückner’s group as a PhD candidate. His research interests are formal methods and mathematical
logic.
Bruno Langenstein received his Diploma from the
University of Karlsruhe (TH) in 1991. After a short intermezzo as a software developer, he joined the Formal
Methods group at DFKI Saarbrücken lead by Werner
Stephan and Dieter Hutter. This research group now
has strong ties to Bernd Krieg-Brückner’s research
group in Bremen. Until today Bruno Langenstein has
participated significantly in the development of VSE
and of formal models for various industrial projects.
His research interests are formal methods with a focus
on their practical application.
Christian Maeder received his PhD from the Technical University Berlin in 2001 under supervision of Peter Pepper. In 2002 he joined Bernd Krieg-Brückner’s
group to work on Casl, HasCasl and Hets in varying
project contexts, initially employed at the University
of Bremen and since May 2006 at DFKI Bremen. His
main interests are functional programs and their verification.
Till Mossakowski met Bernd Krieg-Brückner the
first time in 1986 when he started to study computer
science, and later took part in the student’s project
PILS about implementation of a functional programming language, supervised by Bernd. He received his
PhD from the University of Bremen in 1996 under supervision of Hans-Jörg Kreowski. He then moved to
Bernd’s group (with different employment statuses),
where he also obtained his Habilitation degree with a
work on heterogeneous formal specification. Currently,
he is senior researcher in Bernd’s group at DFKI Bremen and on leave for a substitute professorship in artificial intelligence at the Albert-Ludwigs-University,
Freiburg im Breisgau. His research focus is formal
methods and heterogeneous specification, applied both
to formal software development and to qualitative spatial reasoning (the latter within the special research
center “Spatial Cognition”).
Encapsulating Lazy Behavioral Subtyping Johan Dovland, Einar Broch Johnsen, Olaf Owe, and Martin Steffen
Dept. of Informatics, University of Oslo, Norway
{johand,einarj,olaf,msteffen}@ifi.uio.no
Abstract. Object-orientation supports incremental program development by extending the class hierarchy gradually. Subclassing and late bound method calls
allow very flexible reuse of code, thereby avoiding code duplication. Combined
with incremental program development, this flexibility poses a challenge for program analysis. The dominant solution to this problem is behavioral subtyping,
which avoids re-verification of verified code but requires that all properties of
a method are preserved in subclasses. Program analysis becomes incremental,
but behavioral subtyping severely restricts code reuse. Lazy behavioral subtyping relaxes this restriction to the preservation of properties that are required by
the call-site usage of methods. Previous work developed corresponding inference
systems for languages with single- and multiple-inheritance hierarchies, but although incremental the approach could make it necessary to revisit previously
analyzed classes in order to establish new properties. This paper combines the
proof system for lazy behavioral subtyping with behavioral interfaces to support
incremental reasoning in a modular way. A class may be fully analyzed at development time by relying on interface information for external method calls. Separating classes and interfaces encapsulates the objects in a cleaner way and leads to
a simplification of the formal reasoning system. The approach is presented using
a simple object-oriented language (based on Featherweight Java) extended with
interfaces and illustrated by an example using a Hoare-style proof system.
1
Introduction
Object-orientation supports an incremental style of program development in which new
classes and subclasses may gradually be added to previously developed class hierarchies; these new subclasses typically extend and specialize existing code from superclasses, potentially overriding existing methods. In that way, the code associated with a
late bound method call depends on the run-time class of the callee object, and its effects
are not statically decidable. Subclassing combined with late binding lead to a very flexible mechanism for code reuse, as illustrated through a plethora of design patterns [15],
but pose a challenge for program analysis. The intricacies of late-binding, inheritance,
encapsulation, and other advanced features of object-oriented languages spawned a lot
of research to clarify the semantical foundations, and especially to capture such features
in a type-safe manner. This led to the development of expressive type systems and calculi. In this line of research, Qian and Krieg-Brückner developed a language combining
This research is partially funded by the EU project IST-33826 CREDO: Modeling and analysis
of evolutionary structures for distributed services (http://credo.cwi.nl).
73
features of object-oriented and functional languages in a unified, typed calculus [26],
where much of the expressive power is needed to capture late-binding and overloading.
The static, type-theoretic foundations of mainstream object-oriented languages are
now largely understood, but verification support for object-oriented languages still poses
significant challenges. There are two main approaches in the literature to the verification
of class hierarchies with late bound method calls. Behavioral subtyping was originally
proposed by America [2] and Liskov and Wing [20] and later used in, e.g., Spec [19].
This is an open world approach: it facilitates reasoning about programs in an incremental way which fits well with the incremental development style of object-oriented
programs. Roughly speaking, the basic idea of behavioral subtyping is that any property
of a supertype should also hold for all subtypes. The approach focuses on the declared
properties of a type, and applied to the object-oriented setting, any property of a superclass should also hold for all subclasses. The idea is appealing, as it provides substitutability not just for the static signatures of objects, as in standard subtyping, but also
at the behavioral level. Behavioral subtyping, however, imposes severe restrictions on
subclassing, limiting how code may be reused in ways which break with programming
practice [27]. For example, the class hierarchies of Java libraries do not obey the behavioral subtyping discipline. Alternatively, one can accept the practice of unrestricted
code reuse and overriding, and capture that in a reasoning system. For instance, Pierik
and de Boer [25] have proposed a complete proof system for object-oriented programs
which is able to address much more flexible code reuse. However, it is a closed world
approach: it requires the full class hierarchy to be available at analysis time to ensure
that any binding meets the requirements imposed by the usage of values of the type.
The approach focuses on the required properties of a type. It overcomes the limitations
of behavioral subtyping, but breaks with incremental reasoning.
Lazy behavioral subtyping has been proposed by the authors to preserve the appealing features of behavioral subtyping, i.e., incremental reasoning, but allow more flexible
code reuse in a controlled way. Lazy behavioral subtyping balances the required properties reflecting the call-site use of a method with its provided properties, and the basic
insight is that the properties that need to be preserved depend on the use of a method
rather than on its declared contract. Previous use, therefore, imposes restrictions on future redefinitions in order to maintain the incremental reasoning property. The approach
is supported by an inference system which tracks declaration site specifications and call
site requirements for methods in an extensible class hierarchy [13]. This inference system, which is independent from the underlying specific program logic of a given reasoning system, ensures that proven properties are not violated due to method redefinition in
new subclasses, and that required properties of a method always hold for redefinitions.
The approach has later been extended to deal with multiple inheritance [14].
These previous papers present a slightly simplistic version of lazy behavioral subtyping, concentrating on the core mechanisms for flexible code reuse without breaking
the principle of incremental reasoning. In particular, we considered a language without
interfaces i.e., classes played the roles of types for objects and of generators of objects
instances at the same time. As a consequence, external method calls could recursively
lead to new proof obligations in previously analyzed classes. In this paper, we aim to
combine lazy behavioral subtyping with a notion of modularity for external calls, so
74
P ::= K L {t}
MS ::= m (x) : (p, q)
M ::= m (x) {t}
K
L
e
t
::=
::=
::=
::=
interface I extends I {MS}
class C extends C implements I { f M MS inv p}
f | this | b | new C() | e.m(e) | m(e)
f := e | return e | skip | if b then t else t fi | t;t
Fig. 1. The language syntax, where I, C and, m are interface, class, and method names
(of types Iid, Cid, and Mid, respectively), and p and q are assertions. Vector notation
denotes lists, as in the expression list e.
that lazy behavioral subtyping applies to internal code reuse and additional proof obligations are avoided for classes which have already been analyzed. For this purpose, the
type hierarchy will be separated from the class hierarchy, and behavioral interfaces are
introduced to type object variables and references. Thus, a class which inherits a superclass need not inherit the type of the superclass, and may thereby reuse code more freely.
As this approach can be encoded in the general method of lazy behavioral subtyping,
the soundness of the proof system of this paper follows directly from the soundness of
the pure lazy behavioral subtyping method (see [13]).
The remainder of the paper is structured as follows. Section 2 presents a variant of
Featherweight Java as the language we use for our development. Section 3 presents the
data structures needed to keep track of the different proof obligations, and Section 4 the
inference system to analyse a class hierarchy. The method is illustrated on an example
in Section 5, and Section 6 discusses the context of this work.
2
The Programming Language
We consider a programming language based on Featherweight Java [18], but extended
with (behavioral) interfaces. A program P consists of a set K of interfaces, a set L of
classes, and an initial statement t. The syntax is given in Fig. 1 and explained below.
2.1
Behavioral Interfaces
A behavioral interface consists of a set of method names with signatures and semantic
constraints on the use of these methods. In Fig. 1, an interface I may extend a list I of superinterfaces, and declare a set MS of method signatures, where behavioral constraints
are given as specifications (pre, post) of pre- and postconditions to the signatures. An
interface may declare signatures of new methods not found in its superinterfaces, and
it may declare additional specifications of methods declared in the superinterfaces. The
relationship between interfaces is restricted to a form of behavioral subtyping. An interface may extend several interfaces, adding to its superinterfaces new syntactic and
semantic constraints. We assume that the interface hierarchy conforms with these requirements. The interfaces thus form a type hierarchy: if I extends I, then I is a subtype
of I and I is a supertype of I . Let denote the reflexive and transitive subtype relation,
75
which is given by the nominal extends-relation over interfaces. Thus, I I if I equals
I or if I extends (directly or indirectly) I.
An object supports an interface I if the object provides the methods declared in I
and adheres to the specifications imposed by I on these methods. Fields are typed by
interfaces; if an object supports I then the object may be referenced by a field typed by I.
A class implements an interface if its code is such that all instances support the interface.
The analysis of the class must ensure that this requirement holds. Objects of different
classes may support the same interface, corresponding to different implementations of
its behavior. Only the methods declared by I are available for external invocations on
references typed by I. The class may implement additional auxiliary methods.
The substitution principle for objects applies to the level of interfaces: an object
supporting an interface I may be replaced by another object supporting I or a subtype
of I. A subclass C of C need not satisfy the interface I of the superclass. If I is not
implemented by C , the substitution principle ensures that an instance of C cannot be
used where an object of type I is expected. If a field x is declared with interface I,
the actual object referenced by x at run-time will satisfy the behavioral specification of
I. However, as object references are typed by interface, the run-time class of a called
object is hidden by the behavioral interface of that object. Consequently, all external
method calls are late bound.
2.2
The Imperative Language
The imperative part of the language consists of classes which may implement an interface, inherit from a superclass, and define fields f , methods M, and method specifications MS (see Fig. 1). The superclass is given by the extends clause in the
class header, and the interface supported by instances of the class is given by the
implements clause. The syntactic parts of a class are referred to by the functions
inh, att, mtds, and impl, returning the superclass name, attributes, methods, and interface, respectively. Let ≤ denote the reflexive and transitive subclass relation, such that
C ≤ C if C equals C, or C extends (directly or indirectly) C.
For analysis purposes, a class may specify an invariant inv p, where p is a predicate
over the fields of the class (implemented directly or inherited). As the interface of a class
C hides the implementation details of C, the class invariant is also hidden. An external
call x.m(), where x refers to an instance of class C, cannot assume that the invariant
of x holds when the method starts execution. In the imperative language, expressions e
include program variables f and Boolean expressions b, external calls e.m(e), and self
calls m(e). If m does not return a value, or if the returned value is of no concern, we
may use e.m(e) and m(e) directly as statements for simplicity (ignoring the assignment
of the return value to a program variable). Note that the list of actual parameter values
may be empty and that the formal parameters x and the reserved variable this (for self
reference) are read-only variables. Statements include assignment f := e, return e
which returns an expression e to the caller, conditionals, and sequential composition.
For simplicity, all method calls in this language are late bound. Method binding searches
the class hierarchy from the actual class of the called object in the usual way.
A user given specification m (x) : (p, q) applies to the definition of m in C or to
the inherited definition of m (without redefinition) from the superclass of C. Thus, a
76
subclass may provide additional specifications of methods inherited from superclasses.
For convenience, we use the syntax m (x) : (p, q){t} to both define and specify m.
3
Class Analysis
An essential part of the verification of a class is to ensure that the methods defined by
the class support the behavioral specification of the interface implemented by the class.
Methods are verified in terms of proof outlines [23]; i.e., m(x) : (p, q){t} such that t is a
method body decorated with pre/post requirements on method calls and PL {p} t {q}
is derivable in the given program logic PL if the requirements hold for the method calls
in t. Let body(C, m) denote the decorated method body of m in C. The body is either
found in a definition of m in C, or inherited from a superclass of C.
Notation. Given assertions p and q, the type APair ranges over assertion pairs (p, q). If
p is the pre- and q the postcondition to some method, the pair (p, q) is a specification
of that method. For an interface I, public(I) denotes the set of method identifiers supported by I; thus, m ∈ public(I) if m is declared by I or by a supertype of I. A subtype
cannot remove methods declared by a supertype, so public(I) ⊆ public(I ) if I I. If
m ∈ public(I), the function spec(I, m) returns a set of type Set[APair] with the behavioral
specifications supported by m in I, as declared in I or in a supertype of I. The function
returns a set since a subinterface may provide additional specifications of methods inherited from superinterfaces; if m ∈ public(I) and I I, then spec(I, m) ⊆ spec(I , m).
Consequently, entailment (denoted ) is defined between sets of assertion pairs.
Definition 1 (Entailment). Assume given assertion pairs (p, q) and (r, s), and sets U =
{(pi , qi ) | 1 ≤ i ≤ n} and V = {(ri , si ) | 1 ≤ i ≤ m}, and let p be the assertion p with all
fields f substituted by f , avoiding name capture. Entailment is defined by
i) (p, q) (r, s) (∀z . p ⇒ q ) ⇒ (∀y . r ⇒ s ),
where z and y are the logical variables in (p, q) and (r, s), respectively
V
ii) U (r, s) ( 1≤i≤n (∀zi . pi ⇒ qi )) ⇒ (∀y . r ⇒ s ) .
V
iii) U V 1≤i≤m U (ri , si ) .
The relation U (r, s) corresponds to Hoare-style reasoning, proving {r} t {s} from
{pi } t {qi } for all 1 ≤ i ≤ n, by means of the adaptation and conjunction rules [3].
Entailment is reflexive and transitive, and V ⊆ U implies U V .
Lazy behavioral subtyping is a method for reasoning about redefined methods and late
binding which may be explained as follows. Let m be a method defined in a class C.
The declared behavior of this method definition is given by the specification set S(C, m),
where S is the specification mapping taking a class and a method name as arguments.
We assume that for each (p, q) ∈ S(C, m) there is a proof outline for body(C, m) such
that PL {p} body(C, m) {q}. For a self call {r} n(e) {s} in the proof outline, the assertion pair (r, s) is a requirement imposed by C on possible implementations of n to
which the call can bind. (Requirements made by external calls are considered below.)
Each such requirement, collected during the analysis of C, is included in the set R(C, n),
77
where R is the requirement mapping. Lazy behavioral subtyping ensures that all requirements in the set R(C, n) follow from our knowledge of the definition of method n in C;
i.e., S(C, n) R(C, n). If n is later overridden by some subclass D of C, the same requirements apply to the new version of n; i.e., S(D, n) R(C, n) must be proved. This
yields an incremental reasoning strategy.
In general, we let S↑(C, m) return the accumulated specification set of m in C. If m
is defined in C, this is the set S(C, m). If m is inherited, the set is S(C, m) ∪ S↑(C.inh, m),
which captures that a subclass may provide additional specifications of methods that
are inherited from superclasses. The requirements toward m that are recorded during
the analysis of superclasses are returned by the set R↑(C, m) such that R↑(C, m) =
R(C, m) ∪ R↑(C.inh, m).1 For each class C and method m defined in C, the lazy behavioral subtyping calculus (see Sec. 4) maintains the relation S↑(C, m) R↑(C, m).
If C implements an interface I, the class defines (or inherits) an implementation of
each m ∈ public(I). For each such method, the behavioral specification declared by I
must follow from the method specification, i.e., S↑(C, m) spec(I, m). Now consider
the analysis of a requirement stemming from the analysis of an external call in some
proof outline. In the following, we denote by x : I.m the external call x.m where x is
declared with static type I. As the interface hides the actual class of the object referenced
by x, the call is analyzed based on the interface specification of m. For an external call
{r} x : I.m() {s}, the requirement (r, s) must follow from the specification of m given
by type I, expressed by spec(I, m) (r, s). Soundness in this setting is given by the
following argument. Assume that the call to x.m can bind to m on an instance of class
C, and let I = C.impl. Type analysis then ensures that I I. During the analysis of C,
the relation S↑(C, m) spec(I , m) is established. The desired S↑(C, m) spec(I, m)
then follows since spec(I, m) ⊆ spec(I , m) when I I.
The invariant p of a class C is taken as a pre/post specification of each method
visible through the supported interface of C. Thus, the invariant is analyzed by proving
the specification (p, p) for each such method m. In this manner, the invariant analysis
is covered by the general approach of lazy behavioral subtyping as the declaration of
an invariant can be considered as an abbreviation for a pre/post specification of each
method. Note that this approach does not require that the invariant holds whenever m
starts execution; the specification expresses that if the invariant holds prior to method
execution, then it will also hold upon termination. This approach to invariants works
when analyzing extensible class hierarchies [27], even if the invariant of a subclass is
different from the superclass invariant. The superclass invariant need not hold in the
subclass, but methods defined in the superclass can be inherited by the subclass.
4
The Inference System
Classes and interfaces are analyzed in the context a proof environment. The proof environment tracks the specifications and requirements for the different classes, and the
1
Note that for the language considered in this paper, the set of requirements could be made
more fine-grained by removing requirements stemming from redefined method definitions.
However, in a language with static calls, this simplification would no longer apply.
78
A ::= P | C : O · P
P ::= K | L | P · P
O ::= ε | anReq(M) | anSpec(MS) | verify(m, R)
| anOutln(t) | intSpec(m) | inv(p, m) | O · O
Fig. 2. Syntax for analysis operations.
interface specifications to which each class must adhere. Let Cid, Iid, and Mid denote
the types of class, interface, and method names, respectively.
Definition 2 (Proof environments). A proof environment E of type Env is a tuple
L, K, S, R where L : Cid → Class, K : Iid → Interface are partial mappings and S, R :
Cid × Mid → Set[APair] are total mappings.
Subscripts are used to refer to a specific environment; e.g., SE is the S-mapping
of E . Now, environment soundness is defined. The definition is adapted from [13] by
taking interfaces into account. Condition 3 below captures interface implementations,
requiring that each method satisfies the behavioral specification given by the interface.
Definition 3 (Sound environments). A proof environment E is sound if it satisfies the
following conditions for each C : Cid and m : Mid.
1. ∀(p, q) ∈ SE (C, m) . ∃bodyE (C, m) . PL {p} body(C, m) {q}
∧ ∀{r} n {s} ∈ bodyE (C, m) . RE (C, n) (r, s)
∧ ∀{r} x : I.n {s} ∈ bodyE (C, m) . spec(I, n) (r, s)
2. S↑E(C, m) R↑E(C, m)
3. ∀n ∈ public(I) . S↑E(C, n) spec(I, n), where I = C.impl.
There are four operations to update a proof environment; these load a new class L
or interface K, and extend the commitment and requirement mappings with a pair (p, q)
for a given method m and class C. We define an operator ⊕ : Env × Update → Env,
where the first argument is the current proof environment and the second argument is
the environment update, as follows:
E ⊕ extL(C, D, I, f , M) = LE [C "→ D, I, f , M], KE , SE , RE E ⊕ extK(I, I, MS) = LE , KE [I "→ I, MS], SE , RE E ⊕ extS(C, m, (p, q)) = KE , KE , SE [(C, m) "→ SE (C, m) ∪ {(p, q)}], RE E ⊕ extR(C, m, (p, q)) = LE , KE SE , RE [(C, m) "→ RE (C, m) ∪ {(p, q)}]
In the calculus, judgments have the form E A , where E is the proof environment
and A is a sequence of analysis operations (see Fig. 2). The main inference rules are
given in Fig. 3. The operations and the calculus are discussed below. We emphasize
the differences wrt. the calculus in [13], which reflect the introduction of interfaces and
class invariants. In the rules, I ∈ E and C ∈ E denote that KE (I) and LE (C) are defined, respectively. For brevity, we elide a few straightforward rules which formalize a
lifting from single elements to sets or sequences of elements. For example, the rule for
anReq(M) (see the premise of (N EW C LASS )) generalizes the analysis of a single method
done in (N EW M TD ). The omitted rules may be found in [13] and are similar to the decomposition rules (D ECOMP I NT ) and (D ECOMP I NV ) for interface and invariant requirements.
79
I∈
/E
I = nil ⇒ I ∈ E
E ⊕ extK(I, I, MS) P
E (interface I extends I {MS}) · P
I∈E
(N EW I NT )
C∈
/E
D = nil ⇒ D ∈ E
E ⊕ extL(C, D, I, f , M) C : anSpec(MS) · anReq(M) · inv(p, publicE (I)) · intSpec(publicE (I)) · P
E (class C extends D implements I { f M MS inv p}) · P
E C : verify(m, R↑E(PE (C).inh, m)) · O · P
(N EW M TD )
E C : anReq(m(x){t}) · O · P
E C : verify(m, (p, q)) · O · P
E C : anSpec(m(x) : (p, q)) · O · P
(N EW C LASS )
(N EW S PEC )
S↑E(C, m) (p, q)
E C : O · P
(R EQ D ER )
PL {p} bodyE (C, m) {q}
E ⊕ extS(C, m, (p, q)) C : anOutln(bodyE (C, m)) · O · P
E ⊕ extR(C, m, (p, q)) C : verify(m, (p, q)) · O · P
E C : anOutln({p} m {q}) · O · P
I∈E
(R EQ N OT D ER )
(L ATE C ALL )
specE (I, m) (p, q)
E C : O · P
E C : anOutln({p} x : I.m {q}) · O · P
(E XT C ALL )
S↑E(C, m) specE (C.impl, m)
E C : O · P
E C : intSpec(m) · O · P
(I NT S PEC )
E C : verify(m, (p, p)) · O · P
E C : inv(p, m) · O · P
E C : inv(p, m1 ) · inv(p, m2 ) · O · P
E C : inv(p, m1 ∪ m2 ) · O · P
(I NV )
(D ECOMP I NV )
E C : intSpec(m1 ) · intSpec(m2 ) · O · P
E C : intSpec(m1 ∪ m2 ) · O · P
E P
E C : ε · P
(D ECOMP I NT )
(E MP C LASS )
Fig. 3. The inference system, where P is a (possibly empty) sequence of classes and
interfaces. For simplicity, m denotes a method call including actual parameters and nil
the empty list.
A program is analyzed as a sequence of interfaces and classes. For simplicity, we
require that superclasses appear before subclasses and that interfaces appear before they
80
are used. This ordering ensures that requirements imposed by superclasses are verified
in an incremental manner on subclass overridings. Rules (N EW I NT ) and (N EW C LASS ) extend
the environment with new interfaces and classes; the introduction of a new class leads
to an analysis of the class. The specification and requirement mappings are extended
based on the internal analysis of each class. We assume that programs are well-typed.
Especially, if a field x is declared with type I and there is a call to a method m on x, then
m is assumed to be supported by I. Rule (N EW C LASS ) generates an operation of the form
C : O , where O is a sequence of analysis operations to be performed for class C. Note
that (N EW I NT ) and (N EW C LASS ) cannot be applied while a C : O operation is analyzed,
which ensures that C : O is analysed before a new class is analyzed. A successful
analysis of C yields an operation C : ε which is discarded by (E MP C LASS ).
For a class C implementing an interface I, (N EW C LASS ) generates four initial operations anSpec, anReq, inv, and intSpec. Operation anSpec is analyzed by (N EW S PEC ),
initiating a verification of the user given specifications with regard to their respective
implementations. For each method m defined in C, anReq collects the inherited requirements toward m which are analyzed in (N EW M TD ). Rule (I NV ) analyses the class invariant
as a pre/post specification of each externally visible method in C. Finally, (I NT S PEC ),
ensures that the implementation of C satisfies the behavioral specification of I.
Specifications are verified by (R EQ D ER ) or (R EQ N OT D ER ). If a method specification follows from previously proven specifications of the method, the specification is discarded
by (R EQ D ER ). Otherwise, (R EQ N OT D ER ) leads to the analysis of a new proof outline for the
method. In such proof outlines, external calls {r} x : I.m() {s} are handled by (E XT C ALL ),
which ensures that (p, q) follows from the specification spec(I, m) of m in I. Internal
calls are handled by (L ATE C ALL ), which ensures that the method definitions to which the
call may be bound satisfy the requirement (p, q).
5
Example
In this section we illustrate our approach by a small account system implemented by
two classes: PosAccount and a subclass FeeAccount. The example illustrates how interface encapsulation and the separation of class inheritance and subtyping facilitate
code reuse. Class FeeAccount reuses the implementation of PosAccount, but the type
of PosAccount is not supported by FeeAccount. Thus FeeAccount does not represent
a behavioral subtype of PosAccount.
A system of communicating components can be specified in terms of the observable
interaction between the different components [7, 17]. In an object-oriented setting with
interface encapsulation, the observable interaction of an object may be described by the
communication history, which is a sequence of invocation and completion messages of
the methods declared by the interface. At any point in time, the communication history
abstractly captures the system state. Previous work [12] illustrates how the observable
interaction and the internal implementation of an object can be connected. Expressing
pre- and postconditions to methods declared by an interface in terms of the communication history allows abstract specifications of objects supporting the interface. For this
purpose, we assume an auxiliary variable h of type Seq[Msg] (sometimes called a mythical program variable [11]), where Msg ranges over invocation and completion (return)
81
messages to the methods declared by the interface. However, for the example below it
suffices to consider only completion messages. Thus, a history h will be constructed as
a sequence of completion messages by the empty (ε) and right append (·) constructor.
We write completion messages on the form o, m(x, r) where m is a method completed
on object o, x is the actual parameter values for this method execution, and r is the return value. For reasoning purposes, such a completion message is implicitly appended
to the history at each method termination, as a side effect of the return statement.
5.1
Class PosAccount
Interface IPosAccount supports the three methods deposit, withdraw, and getBalance.
The current balance of the account is abstractly captured by the function Val(h) defined
below, and the three methods maintain Val(h) ≥ 0. Method deposit deposits an amount
as specified by the parameter value and returns the current balance after the deposit,
and method getBalance returns the current balance. Method withdraw returns true if
the withdrawal succeeded, and false otherwise. A withdrawal succeeds only if it leads
to a non-negative balance. In postconditions we let return denote the returned value.
interface IPosAccount {
int deposit(nat x) : (Val(h) ≥ 0, return = Val(h) ∧ return ≥ 0)
bool withdraw(nat x) : (Val(h) ≥ 0 ∧ h = h0 , return = Val(h0 ) ≥ x ∧ Val(h) ≥ 0)
int getBalance() : (Val(h) ≥ 0, return = Val(h) ∧ return ≥ 0)
}
where
Val(ε)
0
Val(h · o, deposit(x, r)) Val(h) + x
Val(h · o, withdraw(x, r)) if r then Val(h) − x else Val(h) fi
Val(h · others)
Val(h)
This interface is implemented by a class PosAccount, given below. The balance is
maintained by a variable bal , and the corresponding invariant expresses that the balance
equals Val(h) and remains non-negative. Notice that the invariant bal = Val(h) connects
the internal state of PosAccount objects to their observable behavior, and is needed in
order to ensure the postconditions declared in the interface.
class PosAccount implements IPosAccount {
int bal = 0;
int deposit(nat x) : (true, return = bal) {update(x); return bal}
bool withdraw(nat x) : (bal = b0 , return = b0 ≥ x) {
if (bal >= x) then update(-x);
return true else return false fi}
int getBalance() : (true, return = bal) {return bal}
void update(int v) : (bal = b0 ∧ h = h0 , bal = b0 + v ∧ h = h0 ) {
bal := bal + v}
inv bal = Val(h) ∧ bal ≥ 0 }
Notice that the method update is hidden by the interface. This means that the method
is not available to the environment, but only for internal use. The following simple definition of withdraw maintains the invariant of the class as it preserves bal = Val(h):
bool withdraw(int x) {return false}
82
However, this implementation does not meet the interface specification which requires
that the method must return true if the withdrawal can be performed without resulting
in a non-negative balance. Next we consider the verification of class PosAccount.
Pre- and postconditions. The pre- and postconditions in the definition of PosAccount
lead to the following extensions of the S mapping:
(true, return = bal) ∈ S(PosAccount, deposit)
(bal = b0 , return = b0 ≥ x) ∈ S(PosAccount, withdraw)
(true, return = bal) ∈ S(PosAccount, getBalance)
(bal = b0 ∧ h = h0 , bal = b0 + v ∧ h = h0 ) ∈ S(PosAccount, update)
(1)
(2)
(3)
(4)
These specifications are easily verified over their respective method bodies.
Invariant analysis. Rule (I NV ) of Fig.3 initiates the analysis of the class invariant wrt.
the methods deposit, withdraw, and getBalance. By (R EQ N OT D ER ), the invariant is treated
as a specification of these methods:
(bal = Val(h) ∧ bal ≥ 0, bal = Val(h) ∧ bal ≥ 0) ∈ S(PosAccount, m),
(5)
for m ∈ {deposit, withdraw, getBalance}. Methods deposit and withdraw perform self
calls to update, which result in the following two requirements:
R(PosAccount, update) =
{ (bal = Val(h) ∧ bal ≥ 0 ∧ v ≥ 0, bal = Val(h) + v ∧ bal ≥ 0),
(bal = Val(h) ∧ v ≤ 0 ∧ bal + v ≥ 0, bal = Val(h) + v ∧ bal ≥ 0) }
(6)
These requirements are proved by entailment from Equation 4.
Interface specifications. At last, we must verify that the implementation of each method
defined by interface IPosAccount satisfies the corresponding interface specification,
according to (I NT S PEC ). For getBalance, it can be proved that the method specification,
as given by Specifications 3 and 5, entails the interface specification
(Val(h) ≥ 0, return = Val(h) ∧ return ≥ 0)
Verification of the other two methods follows the same outline, and this concludes the
verification of class PosAccount.
5.2
Class FeeAccount
Interface IFeeAccount resembles IPosAccount, as the same methods are supported.
However, IFeeAccount takes an additional fee for each successful withdrawal, and the
balance is not guaranteed to be non-negative. For simplicity we take fee as a (read-only)
parameter of the interface and of the class (which means that it can be used directly in
the definition of Fval below).
83
interface IFeeAccount(nat fee) {
int deposit(nat x) : (N(h), return = Fval(h) ∧ N(h))
bool withdraw(nat x) : (N(h) ∧ h = h0 , return = Fval(h0 ) ≥ x ∧ N(h))
int getBalance() : (N(h), return = Fval(h) ∧ N(h)) }
where
N(h)
Fval(h) ≥ ¬fee
Fval(ε)
0
Fval(h · o, deposit(x, r)) Fval(h) + x
Fval(h · o, withdraw(x, r)) if r then Fval(h) − x − fee else Fval(h) fi
Fval(h · others)
Fval(h)
Note that IFeeAccount is not a behavioral subtype of IPosAccount: a class that implements IFeeAccount will not implement IPosAccount. Informally, this can be seen
from the postcondition of withdraw. For both interfaces, withdraw returns true if the
parameter value is less or equal to the current balance, but IFeeAccount takes an additional fee in this case, which possibly decreases the balance to ¬fee.
Given that the implementation provided by class PosAccount is available, it might
be feasible to reuse the code of this class when implementing IFeeAccount. In fact, only
withdraw needs reimplementation, which is illustrated by the class FeeAccount below.
This class implements IFeeAccount and extends the implementation of PosAccount,
which means that the interface supported by the superclass is not supported by the
subclass. Typing restrictions prohibit that methods on an instance of FeeAccount are
called through the superclass interface IPosAccount.
class FeeAccount(int fee)
extends PosAccount implements IFeeAccount {
bool withdraw(nat x) : (bal = b0 , return = b0 ≥ x) {
if (bal >= x) then update(-(x+fee));
return true else return false fi }
inv bal = Fval(h) ∧ bal ≥ −fee
}
Pre- and postconditions. As the methods deposit and getBalance are inherited without
redefinition, the specifications of these methods can be relied on in the context of the
subclass. Especially, Specifications 1, 3, and 4 above remain valid. For withdraw, the
declared specification can be proved:
(bal = b0 , return = b0 ≥ x) ∈ S(FeeAccount, withdraw)
(7)
Invariant verification. The subclass invariant can be proved over the inherited methods
deposit and getBalance in addition to the overridden method withdraw. For deposit,
the following requirement on update is included in the requirement mapping:
(bal = Fval(h) ∧ bal ≥ −fee ∧ v ≥ 0, bal = Fval(h) + v ∧ bal ≥ −fee)
∈ R(FeeAccount, update)
84
This requirement follows from Specification (4) of update. Analysis of withdraw gives
the following requirement, which also follows from Specification 4:
(bal = Fval(h) ∧ bal ≥ x ∧ x ≥ 0 ∧ v = −(x + fee),
bal = Fval(h) − (x + fee) ∧ bal ≥ −fee)
∈ R(FeeAccount, update)
Interface specification. Now reconsider getBalance. After analyzing the subclass invariant, the specification of getBalance is given by S↑(FeeAccount, getBalance), defined as follows:
S↑(FeeAccount, getBalance) =
{(bal = Val(h) ∧ bal ≥ 0, bal = Val(h) ∧ bal ≥ 0),
(true, return = bal),
(bal = Fval(h) ∧ bal ≥ −fee, bal = Fval(h) ∧ bal ≥ −fee)}
(8)
which is the specification set that can be assumed to prove the interface specification
(Fval(h) ≥ −fee, return = Fval(h) ∧ Fval(h) ≥ −fee)
(9)
Specification 9 can be proved by entailment from Specification 8 using (I NT S PEC ). Note
that the superclass invariant is not established by the precondition of Specification 9,
which means that the inherited invariant cannot be assumed when establishing the postcondition of Specification 9. The other inherited specification is however needed, expressing that return equals bal. Verification of the interface specifications for deposit
and withdraw then follows the same outline.
6
Discussion
The notion of behavioral subtyping, i.e., to require substitutability not just for static
object signatures but also for object behavior, goes back to America [2] and Liskov and
Wing [20]. Since then, it has both been adopted and developed further, and at the same
time criticised for being too restrictive to reflect the situation in actual class hierarchies.
For example, Wehrheim has studied variations of behavioral subtyping characterized
by different notions of testing in the context of CSP processes [29]. Recent advances in
program development platforms [5, 8] and in theorem proving technology for program
verification [6] make the development of more fine-grained systems for incremental
reasoning interesting, as a tool is able to collect and often automatically discharge proof
obligations during program development.
Related to the concept of behavioral subtyping is the notion of refinement. In an
object-oriented setting, Back, Mikhajlova, and von Wright propose class refinement
and use the refinement calculus to reason about substitutability for object-oriented programs [4]. Similarly, Utting [28] and Mikhajlova and Sekerinsky [22] deal with modular
reasoning for object-oriented programs using the refinement calculus.
Putting the emphasis not on how to avoid reverification on the client side of a
method call, but for the designer of a derived class, Soundarajan and Fridella [27] separate two specifications for each class, an abstract specification for the clients of the class
85
and a concrete specification for the derived subclasses. Like the current work, they aim
at relaxing behavioral subtyping and especially separating subclassing/inheritance from
behavioral subtyping to gain flexibility while maintaining proof reuse. Lately, incremental reasoning, both for single and multiple inheritance, has been considered in the
setting of separation logic [21, 9, 24]. These approaches support a distinction between
static specifications, given for each method implementation, and dynamic specifications
used to verify late bound calls. The dynamic specifications are given at the declaration
site, in contrast to our work where late bound calls are verified based on call-site requirements. Ideas from behavioral subtyping have also been used to support modular
reasoning for aspect-oriented programming [10] and for active objects [16].
We propose lazy behavioral subtyping to relax some of the restrictions for incremental development of classes imposed by behavioral subtyping, namely to require
preservation only for those properties actually needed for client side verification of
methods. The system is syntax-driven and should be possible to integrate in program
development platforms. In this paper, lazy behavioral subtyping has been combined
with interface encapsulation, allowing code reuse internally while relying on behavioral
interfaces for external method calls. This combination ensures not only that analysis is
incremental but also that analysis is modular; i.e., a class need only be considered once
during the program analysis. Revisiting a class for further analysis, which could happen
in previous work on lazy behavioral subtyping, is thereby avoided.
To use our system, the programmer is expected to provide specifications of interfaces and classes (by means of invariants or pre/post pairs), such that for each class the
specifications given entail the corresponding interface specifications. All other specifications and requirements are generated by the system. We have illustrated the approach
by a simple bank example where the subclass does not represent a behavioral subtype
of the superclass. Both the reuse of code and the reuse of proofs are demonstrated in
the example. At the same time, client-side reasoning may fully exploit the different
properties of the two classes, due to the presence of behavioral interfaces.
In future work we plan to investigate the possibilities of letting interfaces also influence the reasoning of self calls in a more fine-grained manner, with the aim of obtaining
even weaker requirements to redefinitions. Furthermore, the extension of the work presented in this paper to multiple inheritance could follow the approach of [14].
Acknowledgements. The authors are indebted to Bernd Krieg-Brückner, Ole-Johan
Dahl, and Neelam Soundarajan for cooperation and inspiration, the two latter for their
insight in object-orientation and formal methods, and Bernd Krieg-Brückner for his
insight in program specification and program verification, and for championing the importance of formal methods in computer science.
References
1. ACM. 37th Annual Symposium on Principles of Programming Languages (POPL), Jan.
2008.
2. P. America. Designing an object-oriented programming language with behavioural subtyping. In J. W. de Bakker, W.-P. de Roever, and G. Rozenberg, editors, Foundations of
Object-Oriented Languages, pages 60–90. Springer, 1991.
86
3. K. R. Apt. Ten years of Hoare’s logic: A survey — Part I. ACM Transactions on Programming Languages and Systems, 3(4):431–483, Oct. 1981.
4. R.-J. Back, A. Mikhajlova, and J. von Wright. Class refinement as semantics of correct object
substitutability. Formal Aspects of Computing, 12(1):18–40, 2000. Also as Turku Center of
Computer Science, TUCS Technical Report No. 333, March 2000.
5. M. Barnett, K. R. M. Leino, and W. Schulte. The Spec# programming system: An overview.
In G. Barthe, L. Burdy, M. Huisman, J.-L. Lanet, and T. Muntean, editors, Intl. Workshop on
Construction and Analysis of Safe, Secure, and Interoperable Smart Devices (CASSIS’04),
volume 3362 of LNCS, pages 49–69. Springer, 2005.
6. B. Beckert, R. Hähnle, and P. H. Schmitt, editors. Verification of Object-Oriented Software.
The KeY Approach, volume 4334 of LNAI. Springer, 2007.
7. M. Broy and K. Stølen. Specification and Development of Interactive Systems. Monographs
in Computer Science. Springer, 2001.
8. L. Burdy, Y. Cheon, D. R. Cok, M. D. Ernst, J. R. Kiniry, G. T. Leavens, K. R. M. Leino,
and E. Poll. An overview of JML tools and applications. International Journal on Software
Tools for Technology Transfer, 7(3):212–232, 2005.
9. W.-N. Chin, C. David, H.-H. Nguyen, and S. Qin. Enhancing modular OO verification with
separation logic. In POPL’08 [1], pages 87–99.
10. C. Clifton and G. T. Leavens. Obliviousness, modular reasoning, and the behavioral subtyping analogy. In SPLAT 2003: Software engineering Properties of Languages for Aspect
Technologies at AOSD 2003, Mar. 2003. Available as Computer Science Technical Report
TR03-01a from ftp//:ftp.cs.iastate.edu/pub/techreports/TR03-01/TR.pdf.
11. O.-J. Dahl. Verifiable Programming. International Series in Computer Science. Prentice
Hall, New York, N.Y., 1992.
12. J. Dovland, E. B. Johnsen, and O. Owe. Observable Behavior of Dynamic Systems: Component Reasoning for Concurrent Objects. Electronic Notes in Theoretical Computer Science,
203(3):19–34, 2008.
13. J. Dovland, E. B. Johnsen, O. Owe, and M. Steffen. Lazy behavioral subtyping. In J. Cuellar
and T. Maibaum, editors, Proc. 15th International Symposium on Formal Methods (FM’08),
volume 5014 of LNCS, pages 52–67. Springer, May 2008.
14. J. Dovland, E. B. Johnsen, O. Owe, and M. Steffen. Incremental reasoning for multiple
inheritance. In M. Leuschel and H. Wehrheim, editors, Proc. 7th International Conference
on Integrated Formal Methods (iFM’09), volume 5423 of LNCS, pages 215–230. Springer,
Feb. 2009.
15. E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable
Object-Oriented Software. Addison-Wesley, Reading, Mass., 1995.
16. N. Hameurlain. Behavioural subtyping and property preservation for active objects. In
B. Jacobs and A. Rensink, editors, Proceedings of the Fifth International Conference on
Formal Methods for Open Object-Based Distributed Systems (FMOODS 2002), volume 209,
pages 95–110. Kluwer, 2002.
17. C. A. R. Hoare. Communicating Sequential Processes. International Series in Computer
Science. Prentice Hall, 1985.
18. A. Igarashi, B. C. Pierce, and P. Wadler. Featherweight Java: a minimal core calculus for
Java and GJ. ACM Transactions on Programming Languages and Systems, 23(3):396–450,
2001.
19. G. T. Leavens and D. A. Naumann. Behavioral subtyping, specification inheritance, and
modular reasoning. Technical Report 06-20a, Department of Computer Science, Iowa State
University, Ames, Iowa, 2006.
20. B. H. Liskov and J. M. Wing. A behavioral notion of subtyping. ACM Transactions on
Programming Languages and Systems, 16(6):1811–1841, Nov. 1994.
87
21. C. Luo and S. Qin. Separation logic for multiple inheritance. ENTCS, 212:27–40, 2008.
22. A. Mikhajlova and E. Sekerinski. Class refinement and interface refinement in objectoriented programs. In J. Fitzgerald, C. B. Jones, and P. Lucas, editors, FME’97. Industrial
Benefits of Formal Methods, volume 1313 of LNCS, pages 82–101. Springer, 1997.
23. S. Owicki and D. Gries. An axiomatic proof technique for parallel programs I. Acta Informatica, 6(4):319–340, 1976.
24. M. J. Parkinson and G. M. Biermann. Separation logic, abstraction, and inheritance. In
POPL’08 [1].
25. C. Pierik and F. S. de Boer. A proof outline logic for object-oriented programming. Theoretical Computer Science, 343(3):413–442, 2005.
26. Z. Qian and B. Krieg-Brückner. Typed object-oriented functional programming with late
binding. In P. Cointe, editor, Proc. 10th European Conference on Object-Oriented Programming (ECOOP’96), volume 1098 of LNCS, pages 48–72. Springer, 1996.
27. N. Soundarajan and S. Fridella. Inheritance: From code reuse to reasoning reuse. In
P. Devanbu and J. Poulin, editors, Proc. Fifth International Conference on Software Reuse
(ICSR5), pages 206–215. IEEE Computer Society Press, 1998.
28. M. Utting. An Object-oriented Refinement Calculus with Modular Reasoning. PhD thesis,
University of New South Wales, Australia, 1992.
29. H. Wehrheim. Behavioral subtyping relations for active objects. Form. Methods Syst. Des.,
23(2):143–170, 2003.
Einar Broch Johnsen had the pleasure of spending a year as a Post.
Doc. in Bernt Krieg-Brückner’s group at the University of Bremen.
This year exposed him to many new and for him slightly surprising
research activities, reflecting the diversity of the group; for example, wheel-chair avoidance in the corridor, the coffee machines of
algebraic specification (i.e., natural numbers), and the laws of inconsistency and their illustruous proponent Erwin. It was indeed a
memorable year!
A Paradox in Estimating Uncertainty
Udo Frese1,2 and Oliver Birbach2
1
Fachbereich 3 - Mathematik und Informatik, Universität Bremen,
Postfach 330 440, 28334 Bremen, Germany
E-Mail: [email protected]
2
Sichere Kognitive Systeme, Enrique-Schmidt-Str. 5, 28359 Bremen, Germany
Abstract. This paper addresses the theoretical problems behind estimating the
measurement noise standard deviation σi of different measurement groups along
with the state in Gaussian least square estimation. We derive a solution in a Maximum Likelihood (ML) framework and present an iterative algorithm for computing the ML estimate. However, it turns out, that often ML gives meaningless,
paradoxical results. We analyze this phenomenon for the simple example of two
measurements. Paradoxically, the ML estimator blames one of the measurements
for all the error, pretending the other one was exact.
We then proof, that this happens, if the measurements associated with a single
σi are not over-constrained alone. This is the case for most interesting situations,
showing, that ML estimation is mostly useless here. Finally we derive a formula
for the residual covariance that allows to pin down the problems described above
and provides a starting point for a better uncertainty estimator.
1 Introduction
Least-square estimation is the task to obtain an estimate for an unknown state x based on
indirect measurements of that state corrupted by Gaussian noise z = f (x) + N (0, P ).
It has been invented by C.F. Gauss [1] for astronomy and surveying, and has found wide
spread application since then.
In robotics, (Nonlinear) Least Square (NLS) estimation is very widely used for calibration. Examples are: a camera, an inertial sensor, a laser-scanner, the kinematics
of a robot arm. Moreover, the whole areas of Simultaneous Localization and Mapping
(SLAM) [2], Multiple View Geometry [3] in computer vision, and tracking [4] are based
largely on least-square estimation.
One shortcoming of NLS is that the user has to specify the uncertainty of measurements by a covariance matrix. So in this paper, we address the problem of estimating
uncertainty parameters of the measurements along with the state.
1.1 Example Applications
Here are two applications that motivated our research and are used throughout the paper
for providing intuition.
89
2D feature based SLAM [2, §2] is concerned with building a map with a mobile
robot. A feature sensor provides the location of point features relative to the robot and
odometry provides the pose of the robot after moving a step relative to the pose before
moving. The goal would be to estimate two uncertainty parameters for the feature sensor
and for odometry.
In camera-inertial calibration internal camera parameters and the orientation of the
camera relative to the inertial sensor are to be estimated. The input are the image points
of a horizontal checkerboard pattern and gravity measured by the accelerometers in the
inertial sensor. Again, one wants to estimate the uncertainty in the image points and the
accelerometer.
How could this be achieved?
2
ML Estimation of Mean and Variance of a 1-D Gaussian
In fact, there is the well known textbook result on ML estimation of mean and variance [4, §2.5.3]. It assures that the mean and the variance of a 1-D Gaussian can be
estimated from samples z1 , . . . , zn by maximizing the likelihood
p(z• |μ, σ) =
n
p(zi |μ, σ) ∝
i=1
n 1
i=1
σ
exp
−(zi − μ)2
2σ 2
(1)
with respect to both μ and σ.
2.1 Optimal μ
There is a closed solution which we will derive in the following to illustrate the difference to classical least square estimation. The first step is to take the negative logarithm
χ2 (μ,σ)
− ln p(z• |μ, σ) = n ln σ +
= n ln σ +
n
1 (zi − μ)2
2
i=1
σ2
+ const
n
1 (zi − μ)2 + const
2σ 2 i=1
(2)
(3)
which is then to be minimized. In classical least-square estimation σ is fixed and only
the squared residual χ2 (μ; σ) remains. The optimal μ is the average of the samples
n
μmin =
being independent from σ.
1
zi .
n i=1
(4)
90
8
ln σ +
1
2σ 2
7
6
5
4
3
2
1
0
0
5
10
σ
15
20
Fig. 1. The function a ln σ + 2σb 2 plays an important role in estimating the standard deviation σ.
p
It converges to ∞ both for σ → 0 and σ → ∞ and has a minimum at σ = b/a. The plot
shows this function for a = b = 1.
2.2 Optimal σ
From the perspective of σ, (3) has the form a ln σ + 2σb 2 shown in Fig. 1. At this point
we can already catch a glimpse what happens when minimizing with respect to σ. With
σ → ∞ the χ2 error is scaled towards 0 but ln σ → ∞ . For σ → 0, ln σ → −∞, but
the χ2 error goes to +∞. The latter is stronger so the result will go to +∞. In between,
there is the minimum we are looking for. A notable exception is the situation where all
residuals are 0, hence the χ2 error is 0 and the minimum is −∞ at σ = 0. This is still
reasonable, since all samples are identical. This phenomenon will be important later,
where we will encounter paradoxical results.
The behavior discussed above is established by the following lemma (proof in the
appendix).
Lemma 1. If a, b > 0, then σ = b/a. is the minimum of
a ln σ +
b
,
2σ 2
(5)
which converges to +∞ both for σ → 0 and σ → ∞.
If b = 0, (5) converges to −∞ for σ → 0.
Combining this result with (3) we obtain
n
1 σ=
(zi − μ)2 .
n i=1
(6)
This is a well known formula for computing the standard deviation [5]. Many readers
may remember it mainly for the discussion, whether n or n − 1 should be used in the
denominator. Indeed, the ML estimate (6) would be okay, if μ was fixed. However, μ
is estimated by (4) as the average sample and hence is closer to the samples than the
actual mean of the distribution. This leads to a smaller χ2 error and an underestimated
91
σ. It can be shown [4, §2.6.3] that the corresponding sample standard deviation formula
with n − 1 in the denominator is unbiased and thus more desirable.
As a final remark, Bar-Shalom et al. [4] pointed out that many samples are needed
for a good σ estimate, for instance ≈ 800 samples for ≤ 10% error with 95% probability.
3
An ML View on Combined State and Covariance Estimation
3.1 Definition
Motivated by the successful estimator above, we will now derive a ML formulation
for NLS with estimation of covariance parameters. As for classical NLS, our goal is to
estimate a state x from vectors of stacked measurements z1 , . . . , zn . But unlike NLS
we also estimate a scalar uncertainty parameter σi for every such vector zi . Each vector
zi is build by stacking all measurements that have an uncertainty governed by the same
factor σi . So intuitively this corresponds to measurement groups rather than individual
measurements, e.g. all measurements from the same sensor.
Definition 1 (Probabilistic Model). The measurement group vector zi is assumed to
consist of a “true” measurement being a function fi (x) of the state vector x plus unknown noise ei . The noise ei is independently distributed as a Gaussian with 0 mean
and covariance matrix σi2 Pi .
zi = fi (x) + ei ,
ei ∼ N (0, σi2 Pi ),
i = 1, . . . , n
(7)
The measurement vectors zi , the functions fi and the covariance matrices Pi are known.
The state measurement errors ei , the state x, and the factors σi scaling the covariances
are unknown, the latter two shall be estimated.
3.2 Intuition
To understand the intuitive meaning of this definition, consider the 2D SLAM example
from the introduction. The state vector x would consist of all feature positions and
all robot poses stacked in a single vector. As Bar-Shalom pointed out, a lot of data
is needed to estimate an uncertainty parameter. So we can not hope to estimate an
individual uncertainty parameter for every such measurement.
As a first idea, one could assume that the noise in every component of all odometry
measurements has the same standard deviation σ1 and the noise in every component of
all feature measurements has the same standard deviation σ2 . The goal would then be to
estimate σ1 and σ2 along with the state vector x. According to Def. 1. all odometry measurements would be stacked into z1 and all feature measurements into z2 respectively.
So there are two measurement groups and P1 , P2 would be identity matrices.
92
3.3 Sensors with Varying Uncertainty
The assumption of having the same noise in all measurements of one sensor may be
too restrictive, because the noise may depend on a lot of factors. The noise of a feature
measurement depends for instance on distance, the feature itself or some signal to noise
ratio. The noise of an odometry measurement depends on the distance traveled and even
has correlations originating from the kinematic of wheeled motion. All these effects can
be incorporated into Pi , if they are known. The matrix Pi is derived as for usual NLS
assuming the sensor has some arbitrary reference uncertainty and the covariance of the
measurements group zi is then scaled by σi which is estimated by the algorithm.
There is a interesting class of sensors where raw sensor data is internally preprocessed. These sensors have a covariance which is known up to an unknown scale, so
are perfectly compatible with Def. 1. One example is odometry, where the rotation of
the wheels is integrated into a geometrical pose. Another example would be metrical
information from computer vision. In those cases one can assume σi to be the unknown
noise of the raw measurements r in each component, which then propagates through
the sensor preprocessing function zi = g(r) as
cov(zi ) = cov(g(r)) = J cov(r)J T
= J(σi I)J T = σi JJ T , with J =
(8)
∂g(r)
.
∂r
(9)
These kind of sensors can be readily incorporated into Def. 1 by setting Pi = JJ T .
4 A Practical ML Algorithm
4.1 The Likelihood function
We are now deriving an ML algorithm for the system in Def. 1. The likelihood function
p(z• |x, σ• ) =
=
n
i=1
n
p(zi |x, σi )
(10)
p(ei = zi − fi (x)|σi )
(11)
i=1
n
1 2
exp − χi (x, σ) ,
2
|σi2 Pi |
(12)
with χ2i (x, σi ) = (zi − fi (x))T (σi2 Pi )−1 (zi − fi (x))
(13)
∝
i=1
1
to be maximized is derived by using independence of the different zi , solving (7) for ei ,
and substituting the probability density function of a Gaussian [4].
Again, we take the negative logarithm
n 1
(14)
const + dim(zi ) ln σi + χ2i (x, σi ) ,
− ln p(z• |x, σ• ) =
2
i=1
93
C OMPUTE MLE STIMATE (f• , z• , P• , σ•initial )
σ• = σ•initial
repeat
compute x by NLS algorithm with fixed σ•
compute σi from (15) for all i
until convergence
return x, σ•
Fig. 2. Algorithm to compute the ML estimate of x and σ• for an input corresponding to Def. 1.
The subscript • means “for all i”.
2 dim(z )
i
using that |σi2 Pi | = σi
|Pi |. The result consists of the usual χ2 -error χ2 (x, σ) =
n
−2
2
χ
(x,
σ
)
where
the
σ
i
i
i scale the squared residuals and of a second term, namely
i=1
n
dim(z
)
ln
σ
that
favors
smaller σi . When σ• is fixed, the result is the minimum
i
i
i=1
of χ2 (x) as computed by NLS. All this is similar to the 1-D Gaussian case. The main
difference is, that there are now several σi , so the optimal x depends on σ• .
4.2 The Minimization Algorithm
One could simply use a general function minimization algorithm, such as downhillsimplex [6, §10.4] or Powell’s method [6, §10.5] to minimize (14). However, we propose
to use an NLS algorithm with fixed σi as a building block. We think of the problem
rather as an extension to NLS and try to design the algorithm as an extension too. The
advantage is that any problem specific NLS algorithm, for instance a SLAM algorithm,
could be used inside the overall ML algorithm then.
The proposed ML algorithm (Fig. 2) is iterative and related to expectation maximization (EM) [7]. It alternatingly minimizes over x with σ• fixed and over σ• with x
fixed. The essential observation for the second step is, that for a fixed x (14) decomposes into independent minimization problems for each σi . Each of them can be solved
by applying lemma 1 and using χ2i (x, σi ) = σi−2 χ2i (x, 1).
χ2i (x, 1)
χ2i (x, σiold )
= σiold
(15)
σi =
dim(zi )
dim(zi )
So, to compute an ML estimate for σi given x, one simply takes the residual of the last
NLS step (that used σiold ), computes the χ2 error, and applies (15).
4.3 Convergence
Two final remarks on the algorithm: First, each of the two steps in Fig. 2 reduces (14), so
the algorithm converges if (14) has a lower bound. When it converges, the gradient with
respect to x is 0 due to the convergence of the first step and the gradient with respect
to σ• is 0 due to the convergence of the second step. Hence, the overall gradient is 0
and the algorithm found a local minimum at least. Second, when the NLS algorithm is
94
iterative itself, for example Levenberg-Marquardt [6, §15.5], it is attractive to integrate
the σ• estimation step into the existing loop, because it does not make sense to iterate
x to convergence if σ• still is changing.
To summarize: A range of practically relevant problems involving estimation of state
and covariance parameters can be cast as an ML problem and there is a comparatively
simple algorithm for computing it. This sounds promising, but as we will analyze in the
following, in many practical cases the ML estimate is meaningless or even paradoxical.
5 An Example for a Paradoxical ML Estimate
When we had developed the algorithm above, we experienced that one of the σi always
converged to zero [8]. In words, the ML estimate blamed some of the sensors for all the
noise while pretending that the other sensor was perfect. Here is a simple example with
an analytical solution to obtain a deeper inside into this behavior.
5.1 Problem Definition
Imagine the same 1-D quantity measured by two sensors with different uncertainty as 0
and 1.
x ∈ R, f1 (x) = f2 (x) = x,
(16)
z1 = 0, z2 = 1, P1 = P2 = (1).
(17)
What estimate would you expect intuitively? It is hard to say, since two measurements
seem not enough for estimating one state and two uncertainty parameters. At least we
can say something about the sum of both uncertainties. We have one sample z2 −z1 = 1
from a Gaussian with 0 mean and variance σ12 + σ22 . So we can expect at least σ12 + σ22 to
have a well defined estimate. Apart from this, one could reasonably expect the minimum
to be in the middle (σ1 = σ2 = 21 , x = 12 ) for reasons of symmetry. Or, one could
equally reasonably expect the minimum to be indifferent with the same likelihood for
all σ1 , σ2 pairs that have the same σ12 + σ22 value.
That is what intuition says. But what is the true minimum?
5.2 Derivation of the Minimum
We plug (17) into (14), getting
ln σ1 +
(0 − x)2
(1 − x)2
+ ln σ2 +
2
2σ1
2σ22
(18)
We know from linear least squares that the optimal x is the average inversely weighted
by covariance [4]. So we substitute
x=
σ22 0 + σ12 1
σ12
=
σ12 + σ22
σ12 + σ22
(19)
95
Fig. 3. Likelihood of the example in Sec.5, (21) plotted over σ1 and σ2 . There is a saddle point at
σ1 = σ2 = 21 but the minimum is −∞ at either σ1 = 0 or σ2 = 0. The lines show the likelihood
on σ1 = σ2 (black), where the same shape as in Fig. 1 can be observed and on σ12 + σ22 = 21
(yellow) respectively.
96
into (18) getting
σ14
σ24
+
2(σ12 + σ22 )2 σ12
2(σ12 + σ22 )2 σ22
1
= ln σ1 + ln σ2 +
2(σ12 + σ22 )
= ln σ1 + ln σ2 +
(20)
(21)
At this point we can already see, that something strange is happening. If we stay on a
circle σ12 + σ22 = const the third term is constant and the overall function can be made
−∞ by either setting σ1 = 0 or σ2 = 0 (Fig. 3). Formally, we set the derivatives to 0.
1
σ1
− 2
σ1
(σ1 + σ22 )2
σ2
1
− 2
and 0 =
σ2
(σ1 + σ22 )2
0=
⇒
σ12 = σ22 = (σ12 + σ22 )2
1
⇒ σ1 = σ2 =
2
(22)
(23)
(24)
(25)
Indeed, we have a critical point at σ1 = σ2 = 12 , but it is a saddle point, not a minimum.
As Fig. 3 shows, it is a minimum in the direction of σ1 = σ2 , but a maximum in the
orthogonal direction of σ12 + σ22 = 12 . This shows, if we assume both measurements
to have the same standard deviation, the ML estimate of σ = 12 would be reasonable.
However, if we allow both measurements to have different standard deviations, ML has
a paradoxical estimate, claiming that one of the sensors is perfect and the other source
of all the error.
6 A Condition for Meaningful ML Covariance Estimation
One could criticize the above example for evaluating the ML estimate in a situation,
where even intuitively it is unclear what the result should be. It would therefor be interesting to know conditions when the ML estimate becomes paradoxical with one σi = 0
and when it is regular with all σi > 0. We can characterize this situation in the following, i.e. we give a necessary and a sufficient condition for one of the σi being 0.
6.1 Sufficient Condition
When one of the measurement groups alone can be realized without residual, the estimate will become paradoxical.
Theorem 1. If for some i, zi = fi (x0 ) for some x0 , a minimum of the likelihood function (14) is −∞ at x = x0 , σi = 0, σj > 0 for i = j.
Proof. Define a sequence of standard deviation vectors σ•k , with σik = k1 and σjk = 1
for all j = i. Then we claim, that (14) on x = x0 , σ• = σ•k converges to −∞:
97
We go through the terms in the sum in (14): χ2j (x, σjk ) as well as ln σjk is constant
for j = i. χ2 (x, σik ) is 0 by (13), since zi = fi (x0 ). Finally, ln σik = ln k1 = − ln k
converges to −∞ for k → ∞. So the whole negative log-likelihood (14), being the sum
of these terms converges to −∞ as σi approaches 0 with x = x0 and the other σj fixed.
6.2 Necessary Condition
We formulate the necessary condition in reversed form: If for all measurement groups
the residual error is lower bounded, the estimate will not be paradoxical.
Theorem 2. If for all measurement groups the residual error is lower bounded, i.e. ∃r ∈
k
converges
R : ∀x0 , i : |zi − fi (x0 )| ≥ r, then for any sequence (xk , σ•k ) where one σm
to 0 the whole negative log-likelihood (14) converges to +∞.
Proof. We first show that χ2i (x, 1) is bounded from below. As a symmetric positive
definite matrix, Pi can be decomposed as Pi = U T DU with U orthonormal and D
diagonal, consisting of the positive eigenvalues of Pi .
χ2i (x, 1) = (zi − fi (x))T (Pi )−1 (zi − fi (x))
T
T
(26)
−1
= (zi − fi (x)) U D U (zi − fi (x))
2
dim(zi )
U (zi − fi (x)) j
=
Djj
j=1
(27)
(28)
Replacing all Djj by the maximal eigenvalue Dmax of all Pi yields a lower bound
2
dim(zi )
U (zi − fi (x)) j
≥
(29)
Dmax
j=1
|U (zi − fi (x))|2
Dmax
|zi − fi (x)|2
=
Dmax
r2
≥
Dmax
=
(30)
(31)
(32)
We plug this result into a single term of (14).
1
dim(zi ) ln σi + χ2i (x, σi )
2
1
= dim(zi ) ln σi + 2 χ2i (x, 1)
2σi
1 r2
≥ dim(zi ) ln σi + 2
2σi Dmax
(33)
(34)
We apply lemma 1 to (14), setting a = dim(zi ), and b = Drmax . It follows that all
terms in the sum in (14) are bounded from below for all x and σ. For the particular
2
98
term i = m the lemma even implies convergence to +∞, because σm → 0. So overall,
(14) converges to +∞, being the sum of lower bounded terms and a term converging to
+∞.
6.3 The Cases between Necessary and Sufficient Condition
An ideal characterization would be an equivalent, i.e. a necessary and sufficient condition. So it is interesting to know, which cases fulfill the necessary but not the sufficient
condition, so we cannot tell whether they we will have a paradoxical σ = 0 estimate or
not.
In such a case, there would be no lower bound on the residual error |zi − fi (x0 )|
but still there would also be no x0 where residual error |zi − fi (x0 )| would actually
become 0. This cannot happen for a continuous measurements function in a compact
domain, where |zi − fi (x0 )| would also be continuous and hence achieve its minimum.
This can only happen, when there “is” a perfect, i.e. residual-free estimate from zi but it
lies at infinity or in a singularity. An example would be triangulation when the observed
bearings are parallel. Then we would argue, even classical NLS will fail.
So, for take-home message, we can focus on the necessary condition. For the covariance estimation to be non-paradoxical, each measurement group alone must not be
realizable by a state without leading to a residual.
6.4 Discussion
This result is very disappointing. It says, that from the perspective of whether it is
possible to estimate measurement uncertainty, sensor fusion does not make a difference.
A measurement can be expected to have a non-zero residual for all x0 , if it alone
already over-constrains the state. So, the characterization above means that for ML estimation of uncertainty to be possible, each group of measurements alone must already
be over-constrained. But if this holds, we could also estimate the measurement uncertainty much more easily. We would simply perform NLS on each measurement group
alone and apply the estimator (41) for a single σ.
This is disappointing, because by contrast the power of NLS is, that the result of
fusing several measurement groups is often dramatically better than a state obtained
from one of the measurement groups alone. Frequently, each group even does not contain enough information to estimate a state at all and only by fusing all measurement
groups a state estimate becomes available.
It is even more disappointing for robotics, because an important type of robotic sensors generally produces no over-constrained measurements. This holds for all sensors
that can be integrated over time, i.e. that can be used in the Kalman-filter’s [4] dynamic
equation. For every initial state there is one sequence of successive states in time that
perfectly corresponds to the measurements and is obtained by integrating the measurements over time. Examples for these sensors are odometry, inertial sensors, or dynamic
probabilistic models for target tracking that are mathematically treated as a sensor.
In the 2D SLAM example from the introduction, estimating the uncertainty of the
feature sensor and odometry is not possible, since measurements from a feature sensor
are usually over-constrained, but from odometry not.
99
7
An Analysis of the Inherent Difficulty
7.1 What should we expect?
Given that the ML approach to estimating measurement covariance did not succeed, an
interesting question is, whether this is due to the ML paradigm or whether the problem
itself is ill-posed. From our view, it is at least not always ill-posed. Consider again
the 2D-SLAM example. The measurement group of feature measurements is overconstrained. So one can estimate the uncertainty of feature measurements using the
single σ estimator (41). Now there are two extreme cases.
First, assume, odometry has very high uncertainty. Then, one could derive the relation between successive robot poses, i.e. what odometry measures, from the feature
result and use it more or less as ground truth to estimate the odometry uncertainty. In
that case is should indeed be possible to estimate both measurement uncertainties.
Now, assume, odometry has very low uncertainty. Then the discrepancy between
odometry and feature measurements could be completely explained by the uncertainty
in the feature measurements. Odometry alone is not over-constrained, has no inner discrepancy. So, there is no way, we could tell from this data, whether we have a very
precise, an extremely precise, or even exact odometry.
From this example we can conclude two things: First, there are cases, where ML
fails but estimation of measurement uncertainties should be possible. Second, if one of
the sensors is not over-constraint and much preciser than all others, then it is not possible rule to out that the sensor is exact. So it is not possible to estimate the measurement
uncertainty with some relative accuracy. All one can provide is an upper bound.
7.2 The Distribution of the Residual
We want to conclude the paper with a more fundamental view on estimation of measurement uncertainties.
The estimated state does not carry information on the uncertainties, because any
x could be estimated if measurements were exactly zi = fi (x). We have to estimate
the uncertainties from the residuals. So, in the following we will derive the covariance
matrix of the residuals assuming the measurements follow Def. 1 for some σ• . This
allows to pin down the core difficulty of the problem and is a starting point for the
future work of designing a better estimator.
From the perspective of the NLS algorithm the measurement function is f• , i.e. the
measurement functions from Def. 1 stacked. Let J be the corresponding Jacobian and
C = diag(σi2 Pi ) the measurement covariance used by the NLS algorithm. Then according to Frese [2, (17), (18)],
X = (J T C −1 J)−1 J T C −1
(35)
is the matrix version of least square estimation, mapping from measurement error e• to
state error x̃. So the overall matrix Y mapping from the measurement error e• to the
residual zi − f (x) is given by
Y = I − JX, with
(36)
100
The matrix Y is a projection matrix, i.e. Y Y = Y .
−1 T −1 T −1 −1 T −1
J C J J C J
J C
(JX)2 = J J T C −1 J
T −1 −1 T −1
=J J C J
J C = JX
Y = (I − JX)(I − JX) = I − 2JX + (JX) = I − JX = Y
2
2
(37)
(38)
(39)
It removes those degrees of freedom of the measurement noise that get absorbed into
the state estimate and passes the remaining degrees of freedom unmodified. If the measurement covariance is cov(e• ) = C, then the residual covariance is
cov (z• − f• (x)) = Y CY T
(40)
7.3 In a Nutshell
We are now in the position to put everything in a nutshell.
Our problem? We have obtained a sample of the residual distribution N (0; Y CY T )
and want to estimate the parameters σ• scaling the different blocks of the block-diagonal
matrix C.
ML’s fault? It treats Y as identity I.
The inherent difficulty? Y projects away some degrees of freedom which are diagonal to the subspaces corresponding to the different σi . Hence, the effects of the different
σi become coupled in a difficult way.
8 Related Work
NLS is covered in textbooks on statistical estimation [4] and numerical computation [6,
§15.5] for instance with the Levenberg-Marquardt algorithm. The first book also contains the ML estimator presented in Sec.2.
The second book presents a simple unbiased estimator for a single parameter σ
scaling the covariance C used in NLS. It is based on the observation that the χ2 error of
NLS approximately follows a χ2 distribution (hence the name) with dim(z) − dim(x)
degrees of freedom and expected value dim(z) − dim(x). This allows to estimate a σ
as
1
σ = σ old dim(z)−dim(x)
χ2 (x, σold )
(41)
This estimator is unbiased, because unlike (15) it takes the degrees of freedom into
account that are projected away by Y into the estimate. However, it works only for a
single σ, because for several σ it is unclear how these degrees of freedom are “divided”
among the different measurement groups.
The Analysis of Variance (ANOVA) [9] method introduced by Fisher is also related.
It addresses the problem of samples drawn from different classes. The method estimates
two parameters, the variance inside every class and the variance of the mean among the
classes. This has applications in psychology where the classes could for instance be
different cities.
101
9
Conclusion
In this paper we have analyzed a ML approach to estimating measurement uncertainty
along with the state as an extension to NLS. The main conclusion is, that the ML estimate becomes paradoxical, if a group of measurements governed by the same uncertainty factor σi does not over-constrain the state alone. Unfortunately this holds for
most interesting scenarios, so the ML estimate is mostly useless here.
One can also draw more general consequences from this result. Probabilistic inference is used in many branches of robotics, computer vision, and artificial intelligence.
Often, maximum-likelihood is viewed as a gold-standard there and the discussion focusses on how to compute it efficiently. This result suggests to also question the ML
solution itself, because it can sometimes be surprisingly ill-behaved.
Finally, we have analyzed the reason for this problem and provided a characterization of the residual covariance that could be a starting point for a better estimator.
References
1. Gauss, C.: Theoria combinationis observationum erroribus minimis obnoxiae. Commentationes societatis regiae scientiarum Gottingensis recentiores 5 (1821) 6–93
2. Frese, U.: A discussion of simultaneous localization and mapping. Autonomous Robots 20(1)
(2006) 25–42
3. Hartley, R., Zisserman, A.: Multiple View Geometry in Computer Vision. Cambridge University Press (2004)
4. Bar-Shalom, Y., Rong-Li, X., Kirubarajan, T.: Estimation with Applications to Tracking and
Navigation. John Wiley & Sons, Inc. (2001)
5. : Wikipedia: Standard deviation http://en.wikipedia.org/wiki/Standard_
deviation, accessed 14. January 2008.
6. Press, W., Teukolsky, S., Vetterling, W., Flannery, B.: Numerical Recipes, Second Edition.
Cambridge University Press, Cambridge (1992)
7. Dempster, A., Laird, A., Rubin, D.: Maximum likelihood from incomplete data via the EM
algorithm. Journal of the Royal Statistical Society 39 (1977) 1 – 38
8. Birbach, O.: Accuracy analysis of camera-inertial sensor based ball-trajectory prediction.
Master’s thesis, Universität Bremen, Fachbereich 3: Mathematik und Informatik (2008)
9. King, B., Edward, W.: Statistical Reasoning in Psychology and Education, Fourth Edition.
John Wiley & Sons, Inc. (2003)
102
Udo Frese received his Ph.D. from University of ErlangenNürnberg in 2004. From 2004 until 2008 he has been a postdoc researcher in Bernd Krieg-Brückners lab at University of
Bremen and in the German Research Center for Artificial Intelligence (DFKI). He is now assistant professor for real-time
computer vision at University of Bremen and further on affiliated with the DFKI. His research topics are real time computer vision, in particular simultaneous localization and mapping (SLAM) and computer vision for sport robotics.
Oliver Birbach received the diploma degree in computer science from University of Bremen in 2008. He is currently a junior researcher at the German Research Center for Artificial
Intelligence in Bremen. His main research areas are multitarget tracking, context-based computer vision and computer
vision in sports environments.
Appendix
Proof (Proof of Lemma 1). We start with the asymptotics. For σ → ∞, a ln σ → ∞
and 2σb 2 → 0. For σ → 0, it is more difficult, as a ln σ → −∞ and 2σb 2 → +∞. So we
apply L’Hospital’s rule to the fraction.
a ln σ
b
2σ2
L’Hospital
−−−−−→
b
b
a ln σ + 2 = 2
2σ
2σ
a
σ
− σb3
a ln σ
b
2σ2
aσ 2 σ→0
−−−→ 0
b
=−
+1
σ→0
−−−→ ∞1 = ∞
(42)
(43)
In the special case of b = 0, the function is simply ∝ ln σ which converges to −∞ for
σ → 0.
For a minimum, we set the derivative of (5) to 0:
0=
b
a
− 3 ⇒ σ = b/a.
σ σ
(44)
This is actually a minimum, because it is located in the interval [0, ∞) where the function goes to +∞ on both sides, so there must be at least one minimum in between.
(A) Vision for 2050
Context-Based Image Understanding for a
Human-Robot Soccer Match
Udo Frese1,2 , Tim Laue2 , Oliver Birbach2 ,
Jörg Kurlbaum1 , and Thomas Röfer2
1
Fachbereich 3 - Mathematik und Informatik, Universität Bremen,
E-Mail: {ufrese,jkur}@informatik.uni-bremen.de
2
E-Mail: {Tim.Laue,Oliver.Birbach,Thomas.Roefer}@dfki.de
Abstract. We believe it is possible to create the visual subsystem
needed for the RoboCup 2050 challenge – a soccer match between humans and robots – within the next decade. In this position paper, we
argue, that the basic techniques are available, but the main challenge
will be to achieve the necessary robustness. We propose to address this
challenge through the use of probabilistically modeled context, so for
instance a visually indistinct circle is accepted as the ball, if it fits well
with the ball’s motion model and vice versa.
Our vision is accompanied by a sequence of (partially already conducted)
experiments for its verification. In these experiments, a human soccer
player carries a helmet with a camera and an inertial sensor and the
vision system has to extract all information from that data, a humanoid
robot would need to take the human’s place.
1
Introduction
Soon after establishing the RoboCup competition in 1997, the RoboCup Federation proclaimed an ambitious long term goal (depicted in Fig. 1).
“By mid-21st century, a team of fully autonomous humanoid robot soccer
players shall win the soccer game, comply with the official rule of the
FIFA, against the winner of the most recent World Cup.”
Hiroaki Kitano, Minoru Asada [18]
Currently, RoboCup competitions take place every year. Within a defined set of
different sub-competitions and leagues, incremental steps towards this big goal
are made [28]. Although a rapid and remarkable progress has been observed
1
This paper is an extended version of [11] presented at the celebration of the 60th
birthday of Bernd Krieg-Brückner.
104
Fig. 1. Illustration of the RoboCup vision: An autonomous humanoid robot playing
soccer.
during the first decade of these robot competitions, it is not obvious, if and how
the final goal will be reached. There exist rough roadmaps, e.g. by [7], but in
many research areas, huge gaps must be bridged within the next 40 years.
While this is obvious for several areas, e.g. actuator design and control, we
claim that the situation is surprisingly positive for vision:
Within the next decade, it will be possible to develop a vision system that
is able to provide all environmental information necessary to play soccer
on a human level.
Annual RoboCup competitions are always bound to strict rule sets (defined for
the state of the art of the competing robots) and demand competitive robot
teams. Thus only incremental progress adapting to actual rule changes (which
continuously raise the level of complexity) is fostered. By developing the aforementioned vision system independently of these competitions, we hope to set a
new landmark which could guide the incremental development.
Because a real human level soccer robot will not be available for a long time,
our vision is accompanied by a (partially already conducted) set of experiments
that verify our claim without needing a robot.
This paper is organized as follows: Section 2 roughly identifies the challenges
for playing robot soccer and compares them to the state of the art in robotics. In
Sect. 3 we explain, why the basic techniques for the vision system are available.
We argue, why the remaining challenge is robustness, for which we present our
idea of a solution in Sect. 4. Finally, a sequence of experiments to verify our
claim is described in Sect. 5.
105
Fig. 2. The Sense-Think-Act cycle roughly depicting major tasks for playing soccer
with a humanoid robot.
2
Challenges for Playing Soccer
The global task of playing soccer consists of several different, interdepending
challenges. We roughly categorize them according to the Sense-Think-Act cycle
(see Fig.2). This should be considered as a possible architecture for illustration. In the following, the challenges are described in reverted order but with
decreasing degree of difficulty.
2.1
Challenges for Actuation
The hugest obvious gap may be observed in the field of actuation. Nowadays, the
probably most advanced humanoid robot, Honda’s ASIMO, is capable of running
at a top speed of six kilometers per hour [16]. This is an impressive result, but
still more than five times slower than the top speed of a human soccer player.
A similar gap regarding kicking velocity has been pointed out by [13, 14]. They
showed that a state-of-the-art robot arm (with a configuration comparable to
a human leg) is six times slower than required to accelerate a standard soccer
ball to an adequate velocity. It is still an open issue whether today’s motor
technology could be developed further on enough, or if more efficient actuators,
e.g. artificial muscles, will be needed. Since soccer is a contact sport leading to
physical human-robot interaction [13], not only direct position control but also
approaches for compliant motion, such as impedance control, need to be taken
into account. As pointed out by [14], joint elasticity appears to be a crucial
aspect for velocity as well as for safety.
Additionally, the problems of energy efficiency and power supply need to be
solved. The ASIMO robot for example is, according to [16], capable of walking
(with a speed of less than three kilometers per hour) for 40 minutes.
2.2
Challenges for Thinking
In this area, two different levels may be distinguished: motion planning and highlevel multi-agent coordination. The latter is a research topic in the RoboCup
106
Soccer Simulation League since a while and has reached a remarkable level.
Dealing with the offside rule as well as playing one-two passes are standard
behaviors, complex group tasks as playing keep-away soccer serve as a test bed
for learning algorithms [30]. This area could be considered to be already quite
close to human capabilities.
On the other hand, when playing with real humanoid robots, sophisticated
methods for motion planning are needed. The current research frontier on humanoid motion control is balancing and dynamic foot placement for walking
robots. Algorithms for full-body motion planning exist [19], but are subject to
restrictions that make them inapplicable to tasks as playing soccer.
Here is a big gap to human level soccer. As an example consider volleykicking. The player has to hit the ball exactly at the right time, position, and
velocity, with a motion compatible to the step pattern, allowing balancing, and
considering opponents. Last but not least, all this must happen in real-time.
2.3
Challenges for Sensing
According to [18], it is evident that the robots’ sensorial capabilities should resemble the human ones. Thus, we could assume to deal with data from cameras
and inertial sensors emulating the human eyes and vestibular system. The required information are estimates of the own position and the positions of the
ball and of other players. In case of tackles or dribbling, the latter will be needed
to be recognized in more detail (e.g. the positions of the feet and limbs).
Current solutions for these tasks and our idea how to bridge the remaining
gap are presented in the following section.
3
The Vision System
Our main thesis is that the “sense” part of the RoboCup 2050 challenge can be
realized within a decade starting from the current state of the art in computer
vision. This is remarkable, since the “act” and “think” parts are apparently lightyears away from reaching human level performance and for computer vision in
general, this is also true. The reason, why we believe such a vision system can
be realized, is that unlike a household robot for instance, a soccer robot faces a
rather structured environment.
3.1
State of the Art
The objects relevant in a soccer match are the ball, the goals, the line markings,
and, of course, the players as well as the referees. Ball, goal, and line markings are
geometrical features, i. e. circles and lines. There is a large number of algorithms
for detecting them in images, from the classical Hough transform [8] up to a
range of more elaborate methods [12].
Recognizing other players is more challenging. It is particularly difficult because we will probably need not only the general position but the detailed state
107
Fig. 3. Tracking sportsmen and their limbs: Three persons which are running and
passing a ball (left image), one person performing jumping jacks (right image). Both
images are results of [27] and are used with permission of Deva Ramanan.
of motion for close range tackling and to infer the player’s action for tactical
purposes. Fortunately, people tracking is an important topic in computer vision
with a large body of literature [25]. An approach which is capable of tracking the
body as well as the limbs of sportsmen (see Fig. 3) has been presented by [27].
Furthermore, soccer scenes are lightly colored with green lawn and the players
wearing colored clothes of high contrast. In the RoboCup competition, this idea
is taken to an extreme, where most teams rely on color segmentation on a pixelper-pixel basis as their primary vision engine (see Fig. 4). This will not be
possible for real-world soccer, mainly due to changing lighting conditions. Still,
color can provide a valuable additional cue, at least when looking below the
horizon, where objects are in front of green lawn.
The background above the horizon, including the stadium and the audience
is of course also visible and unfortunately rather undefined. However, if it is
relevant for the soccer robot at all, then not for recognition, but only in the
sense of a general landmark. For this purpose there are nowadays well working
techniques, such as the Scale Invariant Feature Transform (SIFT) [24].
Overall, understanding a soccer scene from the player’s perspective seems
much easier than for instance understanding an arbitrary household, traffic, or
outdoor scene. Indeed there are already half-automatic systems in the related
area of TV soccer scene analysis, for example the ASPOGAMO system by [4,
3], proofing that soccer scene understanding in general is on the edge of being
functional.
3.2
Open Problems
So, is a vision system for the RoboCup 2050 challenge an easy task? We believe
it is not. It is surprisingly a realistic task but well beyond the current state of
the art. The first problem is that the camera is moving along with the head
of the humanoid soccer robot. To predict a flying ball, the orientation of the
108
Fig. 4. Two images taken and processed by a humanoid soccer robot on a standard
RoboCup field [22]. The colored dots and lines indicate perceived parts of goals and
field lines; the recognized ball is bordered by an orange circle.
camera must be known very precisely. It seems unrealistic that the necessary
precision can be obtained from the robot’s forward kinematic, since unlike an
industrial robot, a humanoid robot is not fixed to the ground. So our solution
is to integrate an inertial sensor with the camera and fuse the complementary
measurements of both sensors in a probabilistic least-square framework.
The second problem is the player’s perspective. It is much more difficult than
the overview perspective used in TV soccer scene analysis. In the TV perspective
the scale of an object in the image varies by a factor of about 3 [4, Fig. 5] whereas
in the player’s perspective it can vary by a factor of 250 assuming the distance to
an object ranging from 0.5m to 125m. Hence, for instance the people detection
algorithm must handle both extreme cases, a person only the size of a few pixels,
where an arm or a leg maybe thinner than a single pixel and a person much larger
than the camera’s field of view, only partially visible. Furthermore, in an image
from the player’s perspective, other players will extend beyond the green lawn
of the field into the general background. Hence it is not possible to search for
non-green blobs as an easy first processing step. This can also happen for a flying
ball, which is then particularly difficult to detect.
However, the third and most severe problem is, that from our experience,
most of the academic computer vision systems perform on the level of lab demonstrators requiring nicely setup scenes and lighting conditions and usually considerable parameter tweaking. So, to summarize, for the vision part of the RoboCup
2050 challenge, we do not need a new level of functionality as for many other
grand challenges, but we need a new level of robustness.
4
Robustness Through Context
We propose to address the question of robustness by utilizing probabilistically
modeled context information, formulating the overall scene understanding and
prediction problem as a global likelihood optimization task. Using contextual
109
associations is not entirely new [31, 5] and recent progress has shown that exploiting context leads to promisingly robust results. Recent work worth noting
includes modeling of object to object relations as done by [26]. Here, the authors
improved the object categorization accuracy by integrating a post-processing
step that maximizes the object categorization agreement based on contextual
relevance. More generally, [20] proposed a hierarchical framework allowing interaction between objects and regions within the image plane.
Leaving the image plane and therefore 2D models behind, [15] propose a
mechanism for estimating rough 3D scene geometry from a single image which
is then used as an additional input to the object detection methods. Therefore,
detections which fail to fit into the estimated scene geometry at the detected
position are rejected from the global scene interpretation (e. g. pedestrians who
do not stand on the ground plane). This idea is taken one step further by [9]
and [23] where the relationships between objects and scene geometry is modeled,
allowing suitable recognition of objects for a mobile robot application.
These promising results show that exploiting context within the image and
the scene is particularly well suited to the task of creating a vision system for
RoboCup 2050 and also that this task is well suited to study this methodology.
4.1
Data-Driven Bottom-Up Processing
Most current vision systems use a data-driven bottom-up approach [10, 29, 3,
as examples]. Usually, low level features are extracted from the image and then
aggregated through several stages to high level information. Each stage may
incorporate background knowledge at its own level but does not take information
from higher levels into account. It simply takes some input from the previous
lower level and passes the result of the computation to the next higher level.
As an example, a classical Hough transform starts by classifying pixels as
edge or not by thresholding the result, for instance, of a Sobel filter. Similarly,
the system by [3] starts by classifying pixels as lawn or not on the basis of
their color. This is a hard decision taken on the lowest level without any higher
level knowledge, such as the fact that we are looking for a ball or the ball’s
motion model. Such a pixel-wise classification can be very ambiguous. Often we
could, for instance, classify a borderline pixel correctly as belonging to the ball,
although it looks rather greenish, if we considered the context of the ball or its
motion model. However, in conventional vision systems, on the low level this
knowledge does not exist and on the higher level, the fact, that this pixel was
borderline in the classification, is lost due to committing to a hard decision on
the lower level.
To make this idea more concrete, we will now describe a ball tracking system
in the conventional data-driven design (Fig. 5). We will later discuss how it
would look like in the context based design we propose in this paper.
In a data-driven approach, a ball finder algorithm is executed on every image
yielding the 2D image circle (position, radius) corresponding to the ball (or
several hypotheses thereof). These circles are passed to a probabilistic estimator,
such as Gaussian-Maximum-Likelihood that finds the mostly likely states, i. e.
110
Fig. 5. Information flow in a ball tracker based on the conventional data-driven
paradigm (see text). The ball finder is not part of the optimization loop (gray box).
ball positions and velocities. Such an estimator is based on model likelihoods,
i. e. functions with uncertainty, that specify the following:
1. A camera model defines when the ball was at a certain position, where it
would be in the image. This links 3D positions to 2D circles.
2. A ball motion model defines when the ball was at a certain position having
a certain velocity, where it would be and which velocity it would have after
one timestep. This links 3D positions and velocities over time.
The estimator then finds the most likely states by minimizing a sum of squared
differences, which indicates how likely an assumed sequence of states is. It consists of 1. the squared differences between where the ball has been observed by
the ball finder and where the ball model would expect it to be observed if the
assumed state sequence was true and 2. the squared difference between the states
predicted by the ball model and the assumed corresponding states.
The models 1. and 2. are Gaussian likelihoods, i. e. formulas with uncertainty,
so there is a wealth of algorithms for handling this kind of problems. In particular, figure 5 is a conceptual description. Most actual implementations do not
minimize over the whole state sequence in every step but instead use an incremental estimator, such as the Extended or Unscented Kalman Filter [32, 6, 21].
However, this changes only the computation not the result. The key point of this
111
approach is that the ball finder, more general the computer vision, is outside the
optimization loop and there is no information flow from the estimator back to
the ball finder. Hence the ball finder cannot take the high level context of the
ball’s motion into account when deciding on the low level, whether something is
accepted as a ball or not.
4.2
Global Likelihood Optimization
We believe that much of the brittleness of current vision systems originates from
this way of committing to hard decisions on an early level of processing. So our
approach for increased robustness is an overall likelihood optimization.
The problem is to understand an image sequence, i. e. estimating over time.
Indeed, successive images are linked by a motion model and this provides most of
the context we want to build upon. However, we propose not to use incremental
filters, such as EKF, but to look back into the raw images of the last few seconds
at least. This approach has surprising advantages. Imagine the ball is kicked, but
during the first 100ms there is too little contrast to the background so it is not
detected. Now when it is detected, there is new information on where the ball
has been before from the ball’s motion model. The old images are still in memory
and tracking the ball back in time is much less ambiguous than finding the ball
without context and will probably succeed. Paradoxically, once the system has
detected the ball, it has already observed it for 100ms. The first useful prediction
is not delayed at all, because prior to that the ball must have been observed for
some time anyway. In the example above, we would realize this (Fig. 6) by
replacing the ball finder by
3. a ball appearance model that indicates for a given circle in the image plane
how much it looks like a ball. This links the 2D image circle to the actual
image.
In the data-driven approach the ball finder determines where the ball is and the
camera model computes where the ball should be according to the state. Then
both are compared with the difference indicating the likelihood of the state. In
the global likelihood optimization approach, instead the camera model computes
where the ball should be and then the ball appearance model computes how
“ball-like” the image looks there. The difference is, that now the ball appearance
model, i. e. the computer vision, is inside the optimization loop. Now the lower
layer does not have to commit early to a single image circle, but instead it
gradually assesses different circles in the image as requested by the minimization
algorithm. In this approach, an indistinct ball would get a lower likelihood in 3.
but this could be compensated by 1. and 2. if it fits well to the context of a flying
ball. This mechanism allows the now implicit ball finder to utilize the context
provided by the ball motion and implement the behavior described above.
As a final remark, the provided functionality greatly resembles the priming
mechanism known from psychology [33]. This makes us even more believe that
the approach of a global likelihood optimization directly in the images is an
elegant way to greatly increase robustness of computer vision algorithms.
112
Fig. 6. Information flow in a ball tracker based on the global likelihood optimization
paradigm (see text). Here, computer vision, i.e. the ball finder, is part of the optimization loop (gray box).
4.3
Exploiting Semantic Context
Doubtless, if the goal is to track a flying ball, the ball’s motion model provides
the most valuable context. However, there is other, more semantic information
that could be incorporated to increase robustness. Figure 7 illustrates how a
broader context could help distinguishing the real ball from false responses of
the computer vision. We have constructed this example to illustrate what we
believe could happen. It is not based on real computation.
In a) only the first image I1 is considered (p(ball1 |I1 )). The computer vision gives varying responses for different image circles. After applying the necessary threshold needed to give a final result, there are five possible ball locations in the example, namely the true ball and the player’s head, hands,
and both feet together. The same happens in b), where in the example the
9th image I9 is considered alone (p(ball9 |I9 )). Now in c) all images I1...9 are
considered together (p(ball9 |I1...9 , ball model)). The link between the images
is provided by the ball motion model as described in the previous section. In
the example, the player’s head and feet could be ruled out, because their motion does not correspond to the ball motion model. However, in this example, the two hands remain valid hypotheses, because their side-swinging motion would actual correspond to a distant flying ball. In d), the additional con-
113
a) p(ball1 |I1 )
b) p(ball9 |I9 )
c) p(ball9 |I1...9 , ball model)
d) p(ball9 |I1...9 , ball model, field geometry)
e) p(ball9 |I1...9 , ball model, field geometry, f) p(ball1 |I1...9 , ball model, field geometry,
game semantics)
game semantics)
Fig. 7. An illustration, how different types of context information could help to distinguish the real ball from things that look like a ball to the computer vision (see
text).
114
text of the field geometry is added (p(ball9 |I1...9 , ball model, field geometry)).
This context makes the player’s right hand being a ball very unlikely, because from the image position and radius of the circle, the ball would be outside of the field. In e), additional information about game semantics is added
p(ball9 |I1...9 , ball model, field geometry, game semantics). From the game situation, the system expects the player to kick the ball towards the camera. A ball
flying sideward as the falsely detected left hand is implausible with this context and can be ruled out. Of course, as explained above, once the system has
found a unique ball in image 9, it already knows backwards, via the ball motion model, which was the correct ball in image 1. This situation is shown in
f) (p(ball1 |I1...9 , ball model, field geometry, game semantics)). So the system has
already observed the ball for 9 images and can immediately provide a prediction.
How could this example be realized? First of all, using game semantics requires to detect the players, lines and goals to have information about the game
situation. But how could the semantics of soccer be modeled? The classical AI
approach would be to use logic, for instance ontologies to describe a soccer
match. However, typical ontologies, such as OWL [2] express crisp knowledge in
some sort of logic and are difficult to combine with the probabilistic and vague
knowledge discussed in the previous section.
While in the long run modeling a rich and complex semantics, as ontologies
provide, is desirable, probably the first step would be to start with a shallow
semantics that is more easily integrated with probabilistic motion and perception
models. A candidate would be to run a Hidden Markov Model (HMM) [17] for
each player to model the different actions (kicking, running, tackling, etc.) a
player may take, maybe subdivided into different phases. Then one could define
how each phase would affect the players motion and the motion of the ball.
The advantage is that easy algorithms for inference in HMM exist and even
more important that HMM can be well combined with continuous probabilistic
estimation by the Interacting Multiple Model Filter (IMM) [1, §11.6.6].
Overall, it is obvious that modeling the player’s behavior is essential for
understanding a soccer match as a whole and is helpful even for tracking the
ball. However, it is still rather unclear how the required background knowledge
can be modeled in a way that can effectively help a computer vision system.
5
Proposed Experiments
For a vision to become reality, realistic intermediate steps are necessary. It would
not help, if we build a vision system now but then had to wait until a human
level soccer robot is available. So we propose a sequence of experiments that,
without a humanoid robot, ultimately allows to verify that the proposed system
is appropriate for human level soccer (Fig. 8).
115
Fig. 8. Our proposed experiment: Mount a camera and an inertial sensor on the head
of a human soccer player and use them to extract all the information, a humanoid
soccer robot would need to take the human’s place.
5.1
Helmet Camera with Inertial Sensor
The basic idea is to let a human soccer player wear a helmet with a camera and
an inertial sensor and verify, that the information extracted by the vision system
from the sensor data, would allow a humanoid robot to take the human’s place.
As a first experiment, we propose to record data from a soccer match and
run the vision system on that data offline. Since it is hard to obtain groundtruth data, we would use our expert’s judgment to assess, whether the result
would be enough for a humanoid robot to play soccer. It is very advantageous to
work on recorded data allowing to reproduce results for debugging and analysis
and to run the system even if it is still not real-time. Overall, it allows to first
concentrate on functionality and robustness instead of computation time and
integration.
We have already conducted a very first experiment [21, 6], where the ball
and the field lines are manually extracted from the recorded images (available
on request). The ball’s trajectory is predicted by least-square estimation using
the likelihood functions 1. and 2., as well as corresponding equations for how
the inertial sensor observes the free motion of the camera (Fig.9). The results
indicate that if the ball can be detected in the image with about one pixel
precision, the prediction would be precise enough. We believe that these kinds
of studies which deliberately discard essential aspects, such as integration, realtime computation, or autonomy are undervalued by the community who favors
full system approaches. But even from a full system perspective, it is much more
valuable to obtain an extensive result on a subsystem which then can guide the
full system design than to do another increment on a full system.
116
2.0
UKF
Distance (m)
1.5
1.0
0.5
0.0
0
200
400
600
Time (ms)
800
1000
1200
Fig. 9. Predicting the trajectory of a flying ball from a moving camera-inertial system.
As an initial study, the ball, the lines, and the goal corners have been manually extracted from the images. From this data, the trajectory of the ball is predicted (left).
The right plot shows the error of the predicted touchdown point varying over time. It
shows, even though the camera is moving, the prediction is roughly precise enough for
interception.
5.2
Motion Capture Suit
Departing from the experiment above, one might ask whether more sensors are
needed than just camera and inertial. Both human and humanoid robot can
derive their motion from the joint angles. This provides the horizontal motion
(odometry) and the height over ground. The horizontal motion facilitates localization and the height derived from vision is much less precise. Indeed, we
experienced that the uncertain height is a major part of the error in Fig. 9.
An intriguing idea is to equip the human player with a tracker-less motion
capture suit [34] measuring joint angles. Apart from providing the kinematic
information discussed above, it also provides the trajectory of both feet. If the
player hits the ball, one can compare the predicted ball trajectory with the real
foot trajectory and evaluate the precision. This is important since in such an
experiment, ground truth is not available.
5.3
Virtual Reality Display
The experiments above have the drawback that they are evaluated by an expert
looking at the vision system’s output. The most direct proof that this is all you
need for playing soccer would be to give a human just that output via a head
mounted display and see whether s/he can play.
The approach is of course fascinating and direct, but we have some concerns
regarding safety. Anyway, this experiment becomes relevant only after we are
convinced in principle, that the system is feasible. So this is something to worry
about later.
117
6
Conclusion
In this position paper, we have outlined the road to a vision system for a humanrobot soccer match. We claim that, since soccer is a structured environment, the
basic techniques are available and the goal could be reached within a decade. The
main challenge will be robustness, which we propose to address by optimizing a
global likelihood function working on a history of raw images. We have outlined
a sequence of experiments to evaluate such a vision system with data from a
camera-inertial system mounted on the head of a human soccer player.
The reason for being confident such a system can be realized within a decade
is the insight that it does not need general common-sense-reasoning AI. This is
good news for the RoboCup 2050 challenge. But it suggests that, even when we
meet that challenge, it does not imply we have realized the dream of a thinking
machine, the whole challenge had started with.
That would not be the first time.
References
1. Y. Bar-Shalom, X. Li, and T. Kirubarajan. Estimation with Applications to Tracking and Navigation. John Wiley & Sons, Inc., 2001.
2. S. Bechhofer, F. van Harmelen, J. Hendler, I. Horrocks, D. McGuinness, P. PatelSchneider, and L. Stein. OWL web ontology language reference. Technical Report
REC-owl-ref-20040210/, W3C, 2004.
3. M. Beetz, S. Gedikli, J. Bandouch, B. Kirchlechner, N. v. Hoyningen-Huene, and
A. Perzylo. Visually tracking football games based on tv broadcasts. IJCAI 2007,
Proceedings of the 20th International Joint Conference on Artificial Intelligence,
Hyderabad, India, 2007.
4. M. Beetz, N. v. Hoyningen-Huene, J. Bandouch, B. Kirchlechner, S. Gedikli, and
A. Maldonado. Camerabased observation of football games for analyzing multiagent activities. In International Conference on Autonomous Agents, 2006.
5. G. Binnig. Cellenger automated high content analysis of biomedical imagery, 2004.
6. O. Birbach. Accuracy analysis of camera-inertial sensor based ball trajectory prediction. Master’s thesis, Universität Bremen, 2008.
7. H.-D. Burkhard, D. Duhaut, M. Fujita, P. Lima, R. Murphy, and R. Rojas. The
Road to RoboCup 2050. IEEE Robotics and Automation Magazine, 9(2):31–38,
2002.
8. E. R. Davies. Machine Vision. Theory, Algorithms, Practicalities. Morgan Kauffmann, 2004.
9. A. Ess, B. Leibe, and L. V. Gool. Depth and Appearance for Mobile Scene Analysis.
In Proceedings of the IEEE International Conference on Computer Vision, 2007.
10. U. Frese, B. Bäuml, S. Haidacher, G. Schreiber, I. Schaefer, M. Hähnle, and
G. Hirzinger. Off-the-shelf vision for a robotic ball catcher. In Proceedings of
the IEEE/RSJ International Conference on Intelligent Robots and Systems, Maui,
pages 1623 – 1629, 2001.
11. U. Frese and T. Laue. (A) vision for 2050: The road towards image understanding
for a human-robot soccer match. In Proceedings of the 5th International Conference
on Informatics in Control, Automation and Robotics, 2008.
118
12. D. Guru and B. Shekar. A simple and robust line detection algorithm based on
small eigenvalue analysis. Pattern Recognition Letters, 25(1):1–13, 2004.
13. S. Haddadin, T. Laue, U. Frese, and G. Hirzinger. Foul 2050: Thoughts on Physical
Interaction in Human-Robot Soccer. In Proceedings of the IEEE/RSJ International
Conference on Intelligent Robots and Systems, 2007.
14. S. Haddadin, T. Laue, U. Frese, S.Wolf, A. Albu-Schäffer, and G. Hirzinger. Kick
it with elasticity: Safety and performance in human-robot soccer. Robotics and
Autonomous System - Special Issue on Humanoid Soccer Robots, 2009. to appear.
15. D. Hoiem, A. A. Efros, and M. Hebert. Putting Objects in Perspective. In Proceedings of the IEEE Computer Society Conference on Computer Vision and Pattern
Recognition, 2006.
16. Honda Worldwide Site. Honda World Wide — Asimo, 2008. http://world.honda.
com/ASIMO/.
17. W. Hu, T. Tan, L. Wang, and S. Maybank. A survey on visual surveillance of object
motion and behaviors. IEEE Transactions on Systems, Man and Cybernetics, Part
C, 34(3):334–352, 2004.
18. H. Kitano and M. Asada. RoboCup Humanoid Challenge: That’s One Small Step
for A Robot, One Giant Leap for Mankind. In International Conference on Intelligent Robots and Systems, Victoria, pages 419–424, 1998.
19. J. J. Kuffner, S. Kagami, K. Nishiwaki, M. Inaba, and H. Inoue. Dynamically-stable
Motion Planning for Humanoid Robots. Auton. Robots, 12(1):105–118, 2002.
20. S. Kumar and M. Hebert. A Hierarchical Field Framework for Unified ContextBased Classification. In Proceedings of the IEEE International Conference on Computer Vision, 2005.
21. J. Kurlbaum. Verfolgung von ballflugbahnen mit einem frei beweglichen kamerainertialsensor. Master’s thesis, Universität Bremen, 2007.
22. T. Laue and T. Röfer. Particle filter-based state estimation in a competitive and
uncertain environment. In Proceedings of the 6th International Workshop on Embedded Systems. VAMK, University of Applied Sciences; Vaasa, Finland, 2007.
23. B. Leibe, K. Schindler, N. Cornelis, and L. V. Gool. Coupled Object Detection
and Tracking from Static Cameras and Moving Vehicles. IEEE Transactions on
Pattern Analysis and Machine Intelligence, 30(10):1683–1698, 2008.
24. D. Lowe. Distinctive image features from scale-invariant keypoints. International
Journal of Computer Vision, 60(2):91 – 110, 2004.
25. K. Price. The annotated computer vision bibliography, 2008. http://www.
visionbib.com/.
26. A. Rabinovich, A. Vedaldi, C. Galleguillos, E. Wiewiora, and S. Belongie. Objects
in Context. In Proceedings of the IEEE International Conference on Computer
Vision, 2007.
27. D. Ramanan and D. Forsyth. Finding and tracking people from the bottom up.
In IEEE Conference on Computer Vision and Pattern Recognition, 2003.
28. RoboCup Federation. RoboCup Official Site, 2008. http://www.robocup.org.
29. T. Röfer et al. GermanTeam RoboCup 2005, 2005. http://www.germanteam.org/
GT2005.pdf.
30. P. Stone, R. S. Sutton, and G. Kuhlmann. Reinforcement Learning for RoboCupSoccer Keepaway. Adaptive Behavior, 13(3):165–188, 2005.
31. S. Ullman. Sequence seeking and counter streams: A computational model for
bidirectional information flow in the visual cortex. Cerebral Cortex, 5(1), 1995.
32. G. Welch and G. Bishop. An introduction to the kalman filter. Technical Report
TR 95-041, University of North Carolina, 1997.
119
33. Wikipedia. Priming (psychology) — wikipedia, the free encyclopedia, 2008. [Online; accessed 10-December-2008].
34. Xsens Technologies B.V. Moven, Inertial Motion Capture, Product Leaflet, 2007.
120
Udo Frese received his Ph.D. from University of
Erlangen-Nürnberg in 2004. From 2004 until 2008
he has been a post-doc researcher in Bernd KriegBrückner’s lab at University of Bremen and in the
German Research Center for Artificial Intelligence
(DFKI). He is now assistant professor for real-time
computer vision at University of Bremen and further
on affiliated with the DFKI. His research topics are
real time computer vision, in particular simultaneous
localization and mapping (SLAM) and computer vision for sport robotics.
Tim Laue received his diploma in computer science
from the University of Bremen, Germany, in 2004.
Until 2008 he has been a researcher in Bernd KriegBrückner’s working group at the University of Bremen
Currently, he is with the German Research Center for
Artificial Intelligence at the research group for Safe
and Secure Cognitive Systems, Bremen, Germany. His
research and development fields are simulation and localization for autonomous robots, i. e. for wheelchairs
as well as for different soccer robots participating in
RoboCup competitions.
Oliver Birbach received the diploma degree in computer science from University of Bremen in 2008. He is
currently a junior researcher at the German Research
Center for Artificial Intelligence in Bremen. His main
research areas are multi-target tracking, context-based
computer vision and computer vision in sports environments.
Jörg Kurlbaum studied computer science at the University of Bremen with personal preference in robotics.
After he received the diploma in 2007, he started to
work in the SFB/TR8 Spatial Cognition group on map
building and representation for real-time operator applications. Jörg is affiliated with Udo Frese in his realtime vision group.
Thomas Röfer received his diploma in computer science and his Dr.ing. degree from Universität Bremen,
Germany, in 1993 and 1998, respectively. He is in the
Executive Committee of the RoboCup Federation, and
he is member of the Transregional Collaborative Research Center SFB/TR 8 “Spatial Cognition” at Bremen. He is currently with the German Research Center
for Artificial Intelligence at the research group for Safe
and Secure Cognitive Systems, Bremen, Germany. His
research interests include rehabilitation robotics, robot
soccer, real-time computer vision, world modeling, and
humanoid robots.
On the whereabouts of CSP-CASL – A Survey
The Processes & Data Gang
∗
Andy Gimblett, Temesghen Kahsai, Liam O’Reilly, Markus Roggenbach
Swansea University, United Kingdom
Abstract. Csp-Casl is but one of the many languages, Bernd KriegBrückner (BKB) was influential to: From the initial idea of working towards an integration of the process algebra Csp with the algebraic specification language Casl, over the concrete design of the language’s syntax,
to the tool’s side where the theorem prover Isabelle should provide the
common platform, BKB provided inspiration and guidance, funding, and
also a helping hand when needed.
This paper provides a survey on the technology developed so far for CspCasl, covering results of theoretical nature, an industrial case study, tool
support as well as a testing approach. In honour of BKB’s 60th birthday,
this survey documents what has become out of one of BKB’s visions.
1
Introduction
“Deep is the fountain of the past. Shouldn’t it be called unfathomable?”1 So,
where to start, when it comes to the formal specification language Csp-Casl
[23, 2]? Back in Munich, in the early 1970s, when Bernd Krieg-Brückner (BKB)
met Mila Majster, who later became Markus Roggenbach’s (MR) PhD supervisor? Or, jumping forward in time, at the NWPT 1996 in Oslo, when MR met
Christoph Lüth from BKB’s group? Or at the CoFI meeting in Paris-Cachan
in 1998, where various ideas on reactive Casl extensions were discussed? Even
geography is far from being stable when it comes to Csp-Casl — the language
originated in Bremen, and has now come into bloom at Berlin and Swansea.
What is clear is that BKB was – very much to MR’s dislike – a fan of Csp, and
so we truly can call BKB the matchmaker. The marriage of Csp and Casl was
finally announced at AMiLP 2003, where else but in the town of Romeo and
Juliet, Verona.
As unfathomable as Csp-Casl’s past might appear, Csp-Casl’s reason is
clear: Distributed computer applications like flight booking systems, web services, and electronic payment systems such as the EP2 standard [1] involve
the parallel processing of data. Consequently, these systems exhibit concurrent
aspects (e.g. deadlock-freedom) as well as data aspects (e.g. functional correctness). Often, these aspects depend on each other. Casl alone can deal with data
∗
1
This work was supported by EPSRC under the grant EP/D037212/1.
T. Mann: Joseph and his Brothers, S. Fischer, Berlin, 1933.
122
aspect, Csp is quite capable of modelling concurrent systems. The mutual dependencies between processes and data, however, require a new type of language:
e.g., Csp-Casl.
Previous approaches to integrate processes and data, such as LOTOS [6],
E-LOTOS [9], or CSPM [24] restrict data to initial or concrete data types. This
has the shortcoming that data needs to be fixed the moment the modelling is
done. A step forward in this respect is the specification language μCRL [4].
Here, data types have loose semantics and are specified in equational logic with
total functions. Casl, and thus Csp-Casl, offers a more expressive logic for the
specification of data, namely many-sorted first order logic with sort-generation
constraints, partiality, and sub-sorting. On the process side, μCRL employs a
branching time semantics based on bisimulation. Csp-Casl offers the choice
between the various trace semantics defined in the context of Csp, i.e. CspCasl provides a linear time view on systems. For Casl, various reactive extensions have been defined. They include CCS-CASL [25] and CASL-Charts [22],
which combine Casl with reactive systems of a particular kind, the semantics
of which are defined in terms of set theory. Casl extensions such as CoCASL
[15] (being much simpler than full set theory) and CASL-Ltl [21] provide more
of what one might call a meta-framework: for example, the process algebra CCS
has been formalized in both these languages.
Based on previous publications, this paper provides a survey on the technology available for Csp-Casl. It is organized as follows: Section 2 presents the
language and the basic ideas underlying its semantics, [23]. We then review a
major industrial case study, namely, how to model the electronic payment system EP2 in Csp-Casl, [3]. Section 4 reports on parsing and statically analyzing
Csp-Casl, [2]. Csp-Casl refinement [11] is the topic of Section 5: Besides its
obvious use for system development, refinement is the fundamental means to analyze systems within the Csp-Casl context, e.g. in order to check a specification
for deadlock-freedom. Section 6 documents the construction of Csp-Casl-Prover
[19, 20], which offers theorem proving support for checking Csp-Casl refinement.
With this technology around, we mechanically verify parts of the EP2 system in
Section 7: we prove that the formal specifications representing the different layers of the EP2 system are related via refinement, and demonstrate how to prove
deadlock freedom of typical EP2 dialogues. Modelling and formally analyzing
a system improves the quality of the design process, however, there still is no
direct link between specification and implementation. Section 8, finally, presents
a framework for black-box testing from Csp-Casl specifications, [12, 13].
2
The design of CSP-CASL
Csp-Casl [23, 2] is a comprehensive language which combines processes written
in Csp [5, 24] with the specification of data types in Casl [17]. The general idea
is to describe reactive systems in the form of processes based on Csp operators,
where the communications of these processes are the values of data types, which
are loosely specified in Casl. All standard Csp operators are available, such as
123
multiple prefix, the various parallel operators, operators for non-deterministic
choice, communication over channels. Concerning Casl features, the full language is avaliable to specify data types, namely many-sorted first order logic
with sort-generation constraints, partiality, and sub-sorting. Furthermore, the
various Casl structuring constructs are included, where the structured free
construct adds the possibility to specify data types with initial semantics.
Syntactically, a Csp-Casl specification with name N consists of a data part
Sp, which is a structured Casl specification, an (optional) channel part Ch to
declare channels, which are typed according to the data part, and a process
part P written in Csp, within which Casl terms are used as communications,
Casl sorts denote sets of communications, relational renaming is described by a
binary Casl predicate, and the Csp conditional construct uses Casl formulae
as conditions:
ccspec N = data Sp channel Ch process P end
See the below for concrete instances of this scheme. In choosing the loose semantics of Casl, semantically, such a Csp-Casl specification is a family of process
denotations for a Csp process, where each model of the data part Sp gives rise
to one process denotation.
The definition of the language Csp-Casl is generic in the choice of a specific
Csp semantics. Whether a Csp-semantics can be used within our construction
depends on the semantics’ requirements concerning what we call here the data
type of communications. This data type takes as values the alphabet of communications, but additionally provides certain test functions. In this respect, our
construction provides as operations
– test on equality for arbitrary Casl terms (can two communications synchronise?),
– test on membership for a Casl term concerning a Casl sort (does a communication belong to a certain subset of the alphabet of communications?),
– test whether a binary predicate holds between two Casl terms (are the terms
in a renaming relation?), and
– satisfaction of a Casl first order formula (is the formula of the conditional
construct true?).
These test functions can solely be formulated in Casl. Fig. 1 illustrates this setting. The above listed, seemingly small set of test operations allows for all denotational semantics described in [24], namely trace-semantics, failure-divergencesemantics and stable-failure-semantics.
The data types specified by algebraic specification consist of many-sorted
algebras. The data type of communications required by the process algebraic
semantics is a one-sorted algebra. Thus, in order to integrate data into processes,
we need to turn a many-sorted algebra into one set of values such that the above
described tests are closely connected with the original data type. We illustrate
our construction here for the example of many-sorted total algebras:
There are two natural ways to define the alphabet of communications in terms
of the carrier sets of a Casl model: union and disjoint union of all carrier sets.
124
Casl specification Sp
?
has as semantics
Subsorted signature (S , TF , PF , P , ≤)
Class of Σ-models M ; (Ms )s∈S family of carrier sets
Interface: Alphabet construction Set of communications A
?
is parameter for
Csp process P
?
denotes
j
Tests over A :
a = b?, a ∈ X ?, aRb?, ϕ?
Set of traces over A
Fig. 1. Translating data into an alphabet of communication
To illustrate the effect of both possibilities, consider the following Csp-Casl
specification:
data
sorts S , T
ops c : S ; d : T
process c → SKIP || d → SKIP
Its data part, written in Casl, provides two constants c and d of type S and
T , respectively. The process part, written in Csp with Casl terms denoting
communications, combines two processes by the synchronous parallel operator,
i.e. they have to agree on all actions.
The question is, may c and d synchronise or not? In all the various Csp
semantics, c and d synchronise iff they are equal. Now consider two isomorphic
Casl models A and B of the data part:
A(S ) = {∗}, A(T ) = {+}, A(c) = ∗, A(d ) = +
B(S ) = B(T ) = {}, B(c) = B(d ) = Choosing the union of all carrier sets as alphabet has the effect, that c and d
do not synchronise for algebra A while they synchronise for algebra B. Thus,
isomorphic algebras give rise to different behaviour. Therefore, we define the
alphabet to be the disjoint union — with the consequence that c and d do not
synchronise.
Similar ‘experiments’ for partiality, subsorting, and the combination of both
– see [23] – finally lead to an alphabet construction
Ms ∪ {⊥})/∼ .
A(M) := (
s∈S
Here M is a Casl model and S is the set of all sorts declared in the data part.
The special element ⊥ encodes partiality, while ∼ is an equivalence relation
which – on the alphabet level – deals with subsorting.
125
3
The first challenge: Modelling EP2
In [3] we describe the formal specification of a banking system using Csp-Casl.
The system in question is called EP2, which stands for EFT/POS 2000 , short for
‘Electronic Fund Transfer/Point Of Service 2000’; it is a joint project established
by a consortium of (mainly Swiss) financial institutes and companies in order to
define EFT/POS infrastructure for credit, debit, and electronic purse terminals
in Switzerland2 .
Formalising
Specifications
Informal
Design Process
Formal Design
Process
..
.
Architectural
Level
Abstract
Component
Level
Concrete
Component
Level
...
...
Formalisation
Csp-Casl Spec
SP0
...
Formalisation
Csp-Casl Spec
SP1
Formalisation
Csp-Casl Spec
SP2
..
.
...
Intuitive Refinement
Fig. 2. Formalising specifications at various levels of abstraction.
At the architectural level, the system consists of seven autonomous entities
centred around the EP2 Terminal (see Figure 2, which shows several of these
entities), a hardware device concerned with processing card details and authorising financial transactions. The other entities are the Cardholder (i.e. customer),
Point of Service/POS (i.e. cash register), Attendant, POS Management System/PMS , Acquirer , Service Center , and Card . These entities communicate with
the Terminal, and to a certain extent one another, mostly via XML messages
over TCP/IP; the messages contain information about authorisation, financial
transactions, and initialisation and status data. Each component is thus a reactive system, and there are both reactive parts and data parts which need to be
modelled, with these parts heavily intertwined.
2
www.eftpos2000.ch
126
The EP2 specification, a typical informal specification as used in industry,
consists of twelve documents, each of which either considers some particular component of the system in detail, or considers some aspect common to many or all
components. The major components have specification documents setting out
general , functional , and supplementary requirements, where the functional requirements carry the most detail, and consist mainly of use cases discussing how
that particular component behaves in various situations. Additionally, there is a
Security Specification, an Interface Specification and a Data Dictionary. The Security Specification discusses the various security mechanisms used within EP2,
many of which are inherited from EMV and other related specifications. The
Interface Specification describes every interface between components in terms of
the messages allowed on the interface, and in what order they may flow. The
Data Dictionary describes in more detail the data elements found in messages
and, in some cases, in the state of some component. It includes brief discussion
of every data element occurring in the system. The documents are written using
a number of different specification notations: plain English; UML-like graphics
(use cases, activity diagrams, message sequence charts, class models, etc.); pictures; tables; lists; file descriptions; encoding rules. In these regards it is entirely
typical of a modern industrial strength system specification.
With such a document structure, the information required to understand a
particular aspect of the system is contained in several different documents, each
of which has its own things to say about the situation in question. For example,
the SI-Init interface between Terminal and Acquirer is documented in the
Terminal Specification, the Acquirer Specification, the Interface Specification,
and the Data Dictionary. In general, as we found, this results in a specification
which is difficult to understand, and which easily leads to inconsistencies and
ambiguities.
As such, this is exactly the kind of system we would like to specify formally,
with all the associated benefits of tool support that this brings. When [3] was
written, such tool support for Csp-Casl was unavailable; nonetheless, we were
able to specify in Csp-Casl a number of aspects of the system at varying levels
of abstraction, as indicated in Figure 2, and corresponding to different views used
in the informal specification documents. In particular, we wrote an architectural
specification providing the system overview, and abstract component specifications of several elements including the SI-Init interface between Terminal and
Acquirer. In doing so, we identified a number of ambiguities and even contradictions in the EP2 specification. For example, the order of communications over
the SI-Init interface was specified in two contradictory ways in two different
documents. Thus, the very act of writing specifications in a formal language
required a level of rigour at which such problems were forced into the light.
With our specifications we were then able to perform (relatively simple)
proofs on paper — for example of the deadlock-freedom of part of our SI-Init
specification. It quickly became clear, however, that in order to deal with the
full complexity of a specification of this sort, tool support would be absolutely
essential.
127
4
From blackboard langugage to tool support
For quite a while, Csp-Casl existed only as a ‘blackboard language’: while the
subject of several papers, its syntax and semantics remained malleable, allowing
experimentation and discussion. In order to achieve its full promise, however, it
was clear that tool support would be required. The first step towards such tool
support was to fix Csp-Casl’s syntax and static semantics, and to implement
them within an appropriate tool. This work is described fully in [2].
Element
Machine readable
Named process
P (t1 ,...,tn )
Skip
SKIP
Stop
STOP
Div
DIV
Run
RUN(es)
Chaos
CHAOS(es)
Term prefix
t->p
Internal prefix choice
|~|x ::s->p
External prefix choice
[]x ::s->p
Channel send
c!t->p
Channel nondeterministic send c!x ::s->p
Channel receive
c?x ::s->p
Sequential composition
p;q
Internal choice
p|~|q
External choice
p[]q
Interleaving
p|||q
Synchronous
p||q
Generalised parallel
p[|es|]q
Alphabetised parallel
p[es1 ||es2 ]q
Hiding
p\es
Renaming
p[[R]]
Conditional
if ϕ then p else q
Pretty printed Precedence
P (t1 , . . . , tn )
0
SKIP
0
STOP
0
DIV
0
RUN (es)
0
CHAOS (es)
0
t →p
1
x :: s → p
1
2 x :: s → p
1
c!t → p
1
c!x :: s → p
1
c?x :: s → p
1
p;q
2
pq
3
p2q
3
p ||| q
4
p q
4
p|[es]|q
4
p|[es1||es2 ]|q
4
p \ es
5
p[R]
5
if ϕ then p else q
6
Fig. 3. Summary of Csp-Casl process terms.
Csp-Casl is presented as a Casl extension language; its syntax and static
semantics extend, and refer to, those of Casl; as such, they are formalised in a
style matching that of Casl found in [17]. The abstract and concrete syntaxes
are written in the normal BNF-like style (see figure 3 for an informal overview
of the concrete syntax of process terms), whereas the static semantics is in the
style of natural semantics [10]. As a representative example, here is the static
semantics rule for a conditional process term:
Σ, Λ, G, L P1 p, αp
Σ, Λ, G, L P2 q, αq
(Σ, G ∪ L) F ϕ
Σ, Λ, G, L condition-proc F P1 P2 if ϕ then p else q, αp ∪ αq ∪ sorts(ϕ)
128
The rule shows how to devolve the static check on an abstract syntax element for a conditional process term (condition-proc F P1 P2 ), into checks on
the condition (a Casl formaula F) and processes (P1 and P2 ) involved. It operates within some context (a Casl signature Σ; a so-called Csp-Casl signature
Λ, containing process and channel declarations; and global and local variable
bindings G and L), elements of which then provide context for the devolved
rules. Note that the FORMULA rule is found in the Casl static semantics. If the
devolved checks succeed, they yield semantic objects representing the formula
(ϕ), process terms (p, q) and terms’ constituent alphabets (αp , αq ), which are
combined into the semantic objects yielded as the overall product of the rule: an
object representing the entire conditional term, and an object representing its
constituent alphabet, itself the subject of later checks, at the process equation
level.
The syntax and static checks are implemented within the framework of the
heterogeneous toolset, Hets [16]. Casl sits at the centre of a family of related
specification languages – its extensions and sublanguages – and the language
HetCasl[14] then provides a framework for heterogeneous specification over
this family.3 That is, it enables specification using a mix of languages, rather
than requiring all aspects of a system to be specificied using the same formalism.
Hets then provides tool support for heterogeneous specification in this setting.
It consists of a general framework for working with specifications across multiple
logics, with facilities for parsing, static analysis, error reporting, translation between logics, and integration with proof tools; logics for the various Casl-family
languages (including Csp-Casl) are implemented within this framework.
5
Refinement and property verfication in CSP-CASL
Our notions of refinement for Csp-Casl [11, 23] are based on refinements developed in the context of the single languages Csp and Casl. For a denotational
Csp model with domain D, the semantic domain of Csp-Casl consists of families of process denotations dM ∈ D over some index set I ,
(dM )M ∈I
where I is a class of Casl models over the same signature. Intuitively, a refinement step, which we write here as ‘;’, reduces the number of possible implementations. Concerning data, this means a reduced model class, concerning
processes this mean less non-deterministic choice:
Definition 1 (Model class inclusion). Let (dM )M ∈I and (dM
)M ∈I be families of process denotations.
(dM )M ∈I ;D (dM
)M ∈I ⇔ I ⊆ I ∧ ∀ M ∈ I : dM %D dM .
3
In fact, HetCasl is generic in its language family, and could be used as a heteregenous specification framework in an entirely different setting.
129
Here, I ⊆ I denotes inclusion of model classes over the same signature, and
%D is the refinement notion in the chosen Csp model D. In the traces model
T we have for instance P %T P :⇔ traces(P ) ⊆ traces(P ), where traces(P )
and traces(P ) are prefixed closed sets of traces. Given Csp-Casl specifications
Sp = (D, P ) and Sp = (D , P ), by abuse of notation we also write
(D, P ) ;D (D , P )
if the above refinement notion holds for the denotations of Sp and Sp , respectively. On the syntactic level of specification text, we additionally define the
notions of data refinement and process refinement in order to characterize situations, where one specification part remains constant: In a data refinement, only
the data part changes:
(D, P ) ; (D , P )
data
if
Σ(D) = Σ(D ) and Mod(D ) ⊆ Mod(D)
In a process refinement, the data part is constant:
proc
(D, P ) ;D (D, P )
if
for all M ∈ Mod(D) : den([[P ]]M ) %D den([[P ]]M )
Here, den([[P ]]M ) is the denotation of the process P over the model M in the
chosen Csp denotational model. Clearly, both these refinements are special forms
of Csp-Casl refinement in general, for which the following holds:
Theorem 1. Let Sp = (D, P ) and Sp = (D , P ) be Csp-Casl specifications,
where D and D are data specifications over the same signature. Let (D , P ) be
a new Csp-Casl specification that consists of the process part P of Sp and the
data part D of Sp . For these three specifications holds:
(D, P ) ;D (D , P )
⇐⇒
proc
data
(D, P ) ; (D , P ) and (D , P ) ;D (D , P )
This result forms the basis for the Csp-Casl tool support, see Section 6. In
order to prove that a Csp-Casl refinement (D, P ) ;D (D , P ) holds, first one
uses proof support for Casl alone, see [16], in order to establish Mod(D ) ⊆
Mod(D). Independent of this, one has then to check the process refinement
P %D P .
A similar result can be obtained if the signature of D is embedded into
the signature of D , where σ denotes the signature morphism induced by the
embedding, see [11] for the technical details:
Theorem 2. Let Sp = (D, P ) and Sp = (D , P ) be Csp-Casl specifications, such that the signature of D is embedded into the signature of D . Then
proc
data
(D, P ) ;σ (D , P ) and (D , P ) ;D (D , P ) imply (D, P ) ;σD (D , P ).
For system development one often is interested in liberal notions of refinements, which allow for substantial changes in the design. For system verification,
however, it is important that refinement steps preserve properties. This allows to
130
verify properties on abstract specifications which in general are less complex than
the more concrete ones. Here, we show how to perform deadlock free analysis
using refinement.
In Csp, deadlock is represented by the process STOP . In the Csp context,
the stable failures model F is best suited for deadlock analysis. The model F
records two observations on processes: the first observation is the set of traces a
process can perform, this observation is given by the semantic function traces;
the second observation are the so-called stable failures, given by the semantic
function failures. A failure is a pair (s, X ), where s represents a trace that the
process can perform, after which the process can refuse to engage in all events
of the set X .
A Csp-Casl specification is deadlock-free, if it enforces all its possible implementations to be deadlock-free. On the semantical level, we capture this idea
as follows:
Definition 2. Let (dM )M ∈I be a family of process denotations over the stable
failures model, i.e., dM = (TM , FM ) ∈ F(A(M )) for all M ∈ I , where A(M ) is
the alphabet induced by the model M , see Section 2.
– A denotation dM is deadlock free if (s, X ) ∈ FM implies that X = A(M ) .
– (dM )M ∈I is deadlock-free if for all M ∈ I it holds that dM is deadlock-free.
Deadlock can be analyzed through refinement checking: The most abstract deadlock free Csp-Casl specification over a Casl signature Σ with a set of sort
symbols S = {s1 , . . . , sn } is defined as:
ccspec DFS =
data . . . declaration of Σ . . .
process DF = (!x : s → DF ) Skip
s:S
end
We observe that DFS is deadlock-free. This result on DFS extends to a complete
proof method for Csp-Casl deadlock analysis:
Theorem 3. A Csp-Casl specification (D, P ) is deadlock free iff DFS ;F
(D, P ). Here S is the set of sorts of the signature of D.
Similar ideas allow to employ the notion of refinement to check for divergencefreedom, see [11].
6
CSP-CASL-Prover
Csp-Casl-Prover [19, 20] exploits the fact that Csp-Casl refinement can be
decomposed into first a refinement step on data only and then a refinement
step on processes, see the previous section. The basic idea is to re-use existing
tools for the languages Casl and Csp, namely for Casl the tool Hets [16]
and for Csp the tool Csp-Prover [7, 8], both of which are based on the theorem
prover Isabelle/HOL [18]. The main issue in integrating the tools Hets and CspProver into a Csp-Casl-Prover is to implement – in Isabelle/HOL – Csp-Casl’s
131
construction of an alphabet of communications out of an algebraic specification
of data written in Casl. In Csp-Casl-Prover, we choose to prove the relation ∼ –
see Section 2 – to be an equivalence for each Csp-Casl specification individually.
This adds an additional layer of trust: complementing the algorithmic check of
a static property, we provide a proof in Isabelle/HOL that the construction is
valid. The alphabet construction, the formulation of the justification theorems
(establishing the equivalence relation), and their proofs can all be automatically
generated.
CSP-CASL Prover
Hets +
Process & Data
Refinement
(Sp’,P) <= (Sp’,P’)
Hets
Translator
CSP-Prover
Translated
Process & Data
Refinement
([Sp’],[P]) <= ([Sp’],[P’])
Theory Files
+
Isabelle
Theorem
Prover
Refinement
Holds /
Doesn’t Hold
Interactive
Theorem
Proving
Fig. 4. Diagram of the basic architecture of Csp-Casl-Prover.
The architecture of Csp-Casl-Prover is shown in Figure 4. Csp-Casl-Prover
takes a Csp-Casl process refinement statement as its input. The Csp-Casl
specifications involved are parsed and transformed by Csp-Casl-Prover into a
new file suitable for use in Csp-Prover. This file can then be directly used within
Csp-Prover to interactively prove if the Csp-Casl process refinement holds.
The alphabet construction discussed in Section 2 depends on the signature
of the data part of a Csp-Casl specification, e.g., on the set of sorts S , see
Section 2. Hets, however, produces a shallow encoding of Casl only, i.e., there
is no type available that captures the set of all sorts of the data part of a
Csp-Casl specification. Consequently, it is impossible to give a single alphabet
definition within Isabelle/HOL which is generic in the data part of a Csp-Casl
specification. Instead, we produce an encoding individually crafted for the data
part of any Csp-Casl specification.
7
Towards a verification of EP2
We consider two levels of the EP2 specification, namely: the architectural level
(Arch) and the abstract component level (ACL). We choose a dialogue between
132
Informal Design
Process
Formal Design
Process
..
.
Architectural
Level
...
...
Formalisation
Arch Init
=T
Csp-Casl
Csp-Casl
Abstract
Component
Level
..
.
...
σ T
...
Formalisation
RUN Arch
σ T
F
ACL Init
=F
F
Seq Init
Fig. 5. Refinement in EP2
the Terminal and the Acquirer. In this dialogue, the terminal and the acquirer
are supposed to exchange initialization information. For presentation purposes,
we study here only a nucleus of the full dialogue, which, however, exhibits all
technicalities present in the full version.
Our notion of Csp-Casl refinement mimics the informal refinement step
present in the EP2 documents: There, the first system design sets up the interface between the components (architectural level), then these components are
developed further (abstract component level). Here, we demonstrate how we can
capture such an informal development in a formal way, see Fig. 5.
We first specify the data involved using Casl only. The data specification
of the architectural level (D Arch GetInit) requires only the existence of
sets of values: spec D Arch GetInit = sort D SI Init end. In the EP2
system, these values are communicated over channels; data of sort D SI Init
is interchanged on a channel C SI Init linking the terminal and the acquirer.
On the architectural level, both these processes just ‘run’, i.e., they are always
prepared to communicate an event from D SI Init or to terminate. We formalize
this in Csp-Casl:
ccspec Arch Init =
data D Arch GetInit
channel C SI Init : D SI Init
process
let Acquirer = EP2Run
T erminal = EP2Run
in T erminal |[ C SI Init ]| Acquirer
end
where EP 2Run = (C SI Init ? x : D SI Init → EP 2Run) 2 SKIP . On the
abstract component level (D ACL GetInit), data is refined by introducing a
type system on messages. In Casl, this is realised by introducing subsorts of
D SI Init. For our nucleus, we restrict ourselves to four subsorts, the original
dialogue involves about twelve of them.
spec D ACL GetInit =
sorts SesStart, SesEnd, DataRequest, DataResponse < D SI Init
ops r : DataRequest; e : SesEnd
133
axioms ∀ x : DataRequest; y : SesEnd.¬(x = y)
∀ x : DataRequest; y : SesStart.¬(x = y)
∀ x : DataResponse; y : SesEnd.¬(x = y)
∀ x : DataResponse; y : SesStart.¬(x = y)
end
In the above specification, the axioms prevent confusion between the different
sorts. Using this data, we can specify the EP2 system in Csp-Casl. In the
process part the terminal (TerInit) initiates the dialogue by sending a message
of type SesStart; on the other side the acquirer (AcqInit) receives this message.
In AcqConf , the acquirer takes the internal decision either to end the dialogue by
sending the message e of type SesEnd or to send another type of message. The
terminal (TerConf ), waits for a message from the acquirer, and depending on
the type of this message, the terminal engages in a data exchange. The system
as a whole consists of the parallel composition of terminal and acquirer:
ccspec ACL Init =
data D ACL GetInit
channels C ACL Init : D SI Init
process
let AcqInit = C ACL Init ? session : SesStart → AcqConf
AcqConf =C ACL Init ! e → Skip
C ACL Init ! r
→ C ACL Init ? resp : DataResponse → AcqConf
T erInit = C ACL Init ! session : SesStart → T erConf
T erConf =C ACL Init ? conf M ess →
(if (conf M ess : DataRequest)
then C ACL Init ! resp : DataResponse → T erConf
else if (conf M ess : SesEnd) then SKIP else ST OP )
in T erInit |[ C ACL Init ]| AcqInit
end
Theorem 4. Arch Init ;σT ACL Init
Proof. Using tool support, we establish this refinement by introducing two intermediate specifications RUN Arch and Seq Init:
ccspec RUN Arch =
data D Arch GetInit
channel C SI Init : D SI Init
process EP2Run
end
ccspec Seq Init =
data D ACL GetInit
channels C ACL Init : D SI Init
process
let SeqStart =C ACL Init ! session : SesStart → SeqConf
SeqConf =C ACL Init ! e → Skip
C ACL Init ! r
→ C ACL Init ! resp : DataResponse → SeqConf
in SeqStart
end
134
With Csp-Casl-Prover we proved: Arch Init =T RUN Arch. Now we want
to prove that RUN Arch ;σT Seq Init. Using HETS we showed:
data
D Arch GetInit ;σ D ACL GetInit. Now, we formed the specification (D ACL GetInit, PSeq Init ) and showed in Csp-Casl-Prover that, over
the traces model T , this specification refines to Seq Init. Here, PSeq Init denotes the process part of Seq Init. [20] proves ACL Init =F Seq Init. As
stable failure equivalence implies trace equivalence, we obtain ACL Init =T
Seq Init. Fig. 5 summarizes this proof structure.
As ACL Init involves parallel composition, it is possible for this system
to deadlock. Furthermore, the process TerConf includes the Csp process STOP
within one branch of its conditional. Should this branch of TerConf be reached,
the whole system will be in deadlock. The dialogue between the terminal and
the acquirer for the exchange of initialization messages have been proven to
be deadlock free in [20]. Specifically, it has been proven that the following reproc
finement holds: Seq Init ;F ACL Init, where Seq Init is a sequential
system. Sequential system are regarded to be deadlock-free. With our proof
method from Section 5, we can strengthen this result by actually proving that
Seq Init is deadlock free. To this end, we proved with Csp-Casl-Prover that
proc
DF ;F Seq Init where DF is the least refined deadlock-free process.
8
Specification based testing
The fundamental question when dealing with testing based on formal specifications is the following: which are the intentions or properties formulated in the
specification text? In the end, each test case reflects some intentions described
in the specification.
In order to study the above question for Csp-Casl, in [12] we undertake a
specification exercise in modelling a one-bit calculator. It has two input buttons and can compute the addition function only. Whenever one of the buttons
is pressed on the calculator, the integrated control circuit displays the corresponding digit in the display. After pressing a second button, the corresponding
addition result is displayed and the calculator returns to its initial state. In a
first high-level specification we might want to abstract from the control flow and
just specify the interfaces of the system:
ccspec BCalc0 =
data sort N umber
ops 0, 1 : N umber;
+ : N umber × N umber →? N umber
channel Button, Display : Number
process P0 = (?x : Button → P0 ) (!y : Display → P0 )
end
Relatively to BCalc0, the process
T0 = Button!0 → Button!0 → STOP
135
encodes ‘left open’ behaviour: The specification says that the process P0 internally decides if it will engage in an event of type Button or in an event of type
Display. Thus, if the environement offers to press the zero button twice, a legal implementation of BCalc0 can in one experiment refuse to engage in this
behaviour (by deciding internally that initially it engages in an event of type
Display), while in a second run it engages in it.
A more refined version requires that the first displayed digit is echoing the
input, and the second displays the result of the computation:
ccspec BCalc1 =
data sort N umber
ops 0, 1 : N umber;
process P1 =?x : Button → Display!x → ?y : ButtonDisplay!(x +y) → P1
end
Relatively to BCalc1, now the process T0 encodes ‘forbidden’ behaviour as it
does not alternate between pressing buttons and display of digits. The process
T1 = Button!0 → Display!0 → Button!1 → Display!1 → STOP
however, again represents ‘left open’ behaviour: We haven’t yet specified the
arithmetic properties of addition, i.e. it is undecided yet if 0 + 1 = 1 or 0 + 1 = 0.
This underspecification can be resolved by adding suitable axioms:
ccspec BCalc2 =
data sort
N umber
ops
0, 1 : N umber;
axioms 0 + 0 = 0; 0 + 1 = 1; 1 + 0 = 1
process P2 =?x : Button → Display!x → ?y : ButtonDisplay!(x +y) → P2
end
Relatively to BCalc2, T1 represents ‘required’ behaviour.
We encode the intention of a test case with respect to a specification by
a colouring scheme. Intuitively, green test cases reflect required behaviour of
the specification. Red test cases reflect forbidden behaviour of the specification.
A test is coloured yellow if it depends on an open design decision, i.e., if the
specification does neither require nor disallow the respective behaviour. Internal
non-determinism and underspecification are the sources of yellow tests.
Formally, a test case is just a Csp-Casl process in the same signature as
the specification, which may additionally use first-order variables ranging over
communications. The colour of a test case T with respect to a Csp-Casl specification (Sp, P ) is a value c ∈ {red , yellow , green}. [12] provides, besides a mathematical definition of test colouring, also a syntactic characterization of test
colouring in terms of refinement. This enables the use of Csp-Casl-Prover in
order to check the colour of a test case.
136
We call a Csp-Casl refinement ‘;’ well-behaved, if, given specifications
(D, P ) ; (D , P ) with consistent data parts D and D , the following holds
for any test process T over (D, P ):
1. colour (T ) = green with respect to (D, P ) implies
colour (T ) = green with respect to (D , P ), and
2. colour (T ) = red with respect to (D, P ) implies
colour (T ) = red with respect to (D , P ).
This means: If a test case T reflects a desired behavioural property in (D, P ),
i.e. colour (T ) = green, after a well-behaved development step from (D, P ) to
(D , P ) this property remains a desired one and the colour of T is green. If a test
case reflects a forbidden behavioural property in (D, P ), i.e. colour (T ) = red ,
after a well-behaved development step from (D, P ) to (D , P ) this property remains a forbidden one and the colour of T is red. A well-behaved development
step can change only the colour of a test case T involving an open design decision, i.e. colour (T ) = yellow . For the various Csp-Casl refinements holds:
Csp-Casl data refinement is well-behaved; Csp-Casl process refinement based
on the Csp models T is not well-behaved; Csp-Casl process refinement based
on Csp models N and F is well-behaved, provided the processes involved are
divergence-free. [13] studies preservation of test colourings under enhancement.
In terms of refinement, for the above specifications holds: BCalc0 ;F
BCalc1 ;F BCalc2. The first step is a process refinement based on F, the
last one is a data refinement, i.e. both refinement steps are well behaved.
In [12, 13], we develop these ideas towards a testing framework: Given a test
and its colour, its execution on a system under test (SUT) is defined algorithmically. The test result is obtained by comparing intended and actual behaviour of
a SUT, where the test verdict is either pass, fail or inconclusive. Intuitively, the
verdict pass means that the test execution increases our confidence that the SUT
is correct with respect to the specification. The verdict fail means that the test
case exhibits a fault in the SUT, i.e., a violation of the intentions described in
the specification. The verdict inconclusive means that the test execution neither
increases nor destroyes our confidence in the correctness of the SUT.
In an industrial cooperation with Rolls-Royce, Derby, UK, our testing approach has successfully been applied to the contol software of air plane engines.
9
Summary and future work
Fig. 6 provides an overview of the Csp-Casl technology discussed: Given an
informal system description such as the EP2 documents, we mirror informal
specifications by formal ones written in Csp-Casl. In this process, the static
analysis of Csp-Casl specifications provides valuable feedback and helps to
avoid modelling errors. Then, we analyze if a Csp-Casl specification exhibits
desired properties, e.g. deadlock freedom. On the theoretical side, we showed
that – for some fundamental system properties – such an analysis can be carried out by studying an equivalent refinement problem. Thus, on the practical
137
side, Csp-Casl-Prover offers mechanized proof support for the analysis. Additionally, we mirror the informal development steps present in such a system
description by Csp-Casl refinement relations. Using Csp-Casl-Prover, we can
verify if these refinement relations actually hold. Properties are guaranteed to be
preserved within a development step provided a suitable Csp-Casl refinement
holds, e.g. deadlock-freedom is preserved under Csp-Casl-stable-failures refinement. Finally, using testing [12, 13], we link the formal specifications with actual
implementations. Csp-Casl refinement relations ensure that test cases which
are designed at an early stage can be used without modification for the test of
a later development stage. Hence, test suites can be developed in parallel with
the implementation. Also testing has tool support in terms of Csp-Casl-Prover,
e.g. in order to colour test cases.
Fig. 6. The Csp-Casl verification approach
Future research will include the integration of the Casl institution independent structuring mechanisms into Csp-Casl, the development of compositional
proof methods in Csp-Casl-Prover, as well as a semantically sound connection
to distributed Java programs.
138
Acknowledgment The authors wish to thank B. Krieg-Brückner for inspiring
Csp-Casl in the first place, Y. Isobe for his pioneering work on Csp-Prover,
B.-H. Schlingloff for being the driving force in applying Csp-Casl to real world
examples, and Erwin R. Catesbeiana (Jr) for being the mastermind of our gang.
References
1. eft/pos 2000 Specification, version 1.0.1. EP2 Consortium, 2002.
2. A. Gimblett. Tool Support for CSP-CASL, 2008. Swansea University, MPhil thesis.
3. A. Gimblett, M. Roggenbach, and B.-H. Schlingloff. Towards a formal specification
of an electronic payment system in CSP-CASL. In WADT 2004, LNCS 3423.
Springer, 2005.
4. J. Groote and A. Ponse. The syntax and semantics of μCRL. In Algebra of
Communicating Processes ’94, Workshops in Computing Series. Springer, 1995.
5. C. A. R. Hoare. Communicating Sequential Processes. Prentice Hall, 1985.
6. ISO 8807. LOTOS - a formal description technique based on the temporal ordering
of observational behaviour. Geneva, 1989.
7. Y. Isobe and M. Roggenbach. A generic theorem prover of CSP refinement. In
TACAS 2005, LNCS 3440, pages 108–123. Springer, 2005.
8. Y. Isobe and M. Roggenbach. CSP-Prover - a proof tool for the verification of
scalable concurrent systems. JSSST Computer Software, 25, 2008.
9. ISO/IEC. E-LOTOS, 2001.
10. G. Kahn. Natural Semantics. In STACS, LNCS 247, pages 22–39. Springer, 1987.
11. T. Kahsai and M. Roggenbach. Refinement notions for CSP-CASL. In WADT
2008. Springer, to be published.
12. T. Kahsai, M. Roggenbach, and B.-H. Schlingloff. Specification-based testing for
refinement. In SEFM 2007, pages 237–247. IEEE Computer Society, 2007.
13. T. Kahsai, M. Roggenbach, and B.-H. Schlingloff. Specification-based testing for
software product lines. In SEFM 2008. IEEE Computer Society, 2008.
14. T. Mossakowski. Heterogeneous specification and the heterogeneous tool set. Habilitation thesis, Universitaet Bremen, 2005.
15. T. Mossakowski, L.Schröder, M. Roggenbach, and H. Reichel.
Algebraiccoalgebraic specification in CoCASL. JALP, 2006.
16. T. Mossakowski, C. Maeder, and K. Lüttich. The Heterogeneous Tool Set, HETS.
In TACAS 2007, LNCS 4424, pages 519–522. Springer, 2007.
17. P. D. Mosses, editor. CASL Reference Manual. LNCS 2960. Springer, 2004.
18. T. Nipkow, L. Paulon, and M. Wenzel. Isabelle/HOL. LNCS 2283. Springer, 2002.
19. L. O’Reilly. Integrating Theorem Proving for Processes and Data, 2008. Swansea
University, MPhil thesis.
20. L. O’Reilly, Y. Isobe, and M. Roggenbach. CSP-CASL-Prover – a generic tool for
process and data refinement. In AVOCS’08, ENTCS, to appear.
21. G. Reggio, E. Astesiano, and C. Choppy. CASL-LTL — a Casl extension for
dynamic reactive systems. Technical Report TR-99-34, Università di Genova, 2000.
22. G. Reggio and L. Repetto. CASL-Charts. In AMAST’00, LNCS 1816, pages
243–257. Springer, 2000.
23. M. Roggenbach. CSP-CASL: A new integration of process algebra and algebraic
specification. Theoretical Computer Science, 354(1):42–71, 2006.
24. A. Roscoe. The theory and practice of concurrency. Prentice Hall, 1998.
139
25. G. Salaün, M. Allemand, and C. Attiogbé. A formalism combining CCS and Casl.
Technical Report 00.14, University of Nantes, 2001.
Andy Gimblett studied in Cardiff and received an
MPhil at Swansea University for research on tool support for CSP-CASL undertaken under the supervision
of Markus Roggenbach in the Processes and Data research group. Currently he is working in the Future
Interaction Technology Lab at Swansea University on
the project “Formally-based tools for user interface
analysis and design”.
Temesghen Kahsai joined the ’Processes and Data’
project in October 2006 as a PhD student. He is researching in the area of refinement and testing for
CSP-CASL. Before coming to Swansea, he was a student at Udine University (Italy).
Liam O’Reilly completed his BSc and masters studies at Swansea University in Wales. He is currently
studying a PhD under the supervision of Markus
Roggenbach at Swansea University. He is a member
of the ’Processes and Data Group’ currently specialising in the development and implementation of tool
support for CSP-CASL.
Markus Roggenbach joined BKB’s group in November 1998, worked on all the things around CASL, especially the real ones, and was also playing around
within the MMISS project. He is famous for promoting the ‘CoFI’ time and is a special friend of Erwin
R. Catesbeiana. He left Bremen in May 2003 to become a lecturer in Swansea, Wales. There he founded
his research group ‘Processes & Data Gang’.
Enhanced Formal Verification Flow for Circuits
Integrating Debugging and Coverage Analysis
Daniel Große, Görschwin Fey, and Rolf Drechsler
Institute of Computer Science, University of Bremen,
28359 Bremen, Germany
{grosse,fey,drechsle}@informatik.uni-bremen.de
Abstract. In this paper we present the state-of-the-art in formal hardware verification with the focus on automatic proof techniques. On top
of necessary fundamentals we describe the well accepted and widely used
industrial technique of Bounded Model Checking (BMC). Thereafter, two
major methodological improvements are proposed which significantly
improve the quality of BMC-based verification:debugging and coverage
analysis. The verification engineer can locate the source of a failure with
an automatic debugging approach. Components are identified which explain the discrepancy between the property and the circuit behavior. This
method is complemented by an approach to analyze functional coverage
of the proven BMC properties. The approach automatically determines
whether the property set is complete or not. In the latter case coverage
gaps are returned. Both techniques are integrated in an enhanced verification flow. A running example demonstrates the resulting advantages.
1
Introduction
For economic reasons the number of components in integrated circuits grows at
an exponential pace according to Moore’s law. This growth is expected to continue for another decade. Resulting is the so-called design gap, the productivity
in circuit design does not increase as fast as the technical capabilities. Thus,
more components can be integrated on a physical device than can be assembled
in a meaningful way during circuit design. The verification gap is even wider,
i.e. how to ensure the correctness of a design. This is of particular importance
in safety critical areas like traffic or security-related systems storing confidential
information. Thus, techniques and tools for the verification of circuits received
a lot of attention in the area of Computer Aided Design (CAD).
Simulation has always been in use as a fast method to validate the expected
functionality of circuits. Once the circuit is described in a Hardware Description
Language (HDL) like Verilog or VHDL, a testbench is used to excite the circuit
under stimuli expected during in-field operation. But the full space of potential
assignments and states of a circuit is exponential in the number of inputs and
state elements. Therefore the search space cannot be exhausted by simulation.
Even emulation using prototypical hardware is not sufficient to completely cover
the full state space.
141
Edit/add property
Property checker
fails
Analyze candidates
Autom. debugger
holds
Coverage analyzer
Analyze scenario
<100%
100%
DONE
Fig. 1. Enhanced flow
Thus, more powerful techniques for formal verification have been developed.
In particular, to prove the correctness of a hardware design with respect to a
given textual specification property checking has been developed. Formal properties are derived from the textual specification. The properties are proven fully
automatically to hold on the design. The underlying Boolean reasoning engines
are quite effective. Even for very large designs meaningful properties are handled
effectively. Still the verification gap remains due to low productivity, and intensive training of verification engineers is required to apply property checking in
practice. Therefore besides powerful reasoning engines, tool support is necessary
for several tasks during formal verification.
Here we propose an enhanced verification flow enriched by techniques to
ease the verification task. The flow is based on previous results by the authors.
Figure 1 illustrates this flow. Dark boxes denote automatic tools while light
boxes require manual interaction.
Typically only a property checker is available that returns a counterexample if
a property fails. The subsequent debugging task is only supported by standard
simulators. But techniques automating debugging in the context of property
checking have been presented [FSBD08] to speed up the work flow. The debugger
uses multiple counterexamples to determine candidate sites for the bug location
and thus decreases the amount of manual interaction.
Another major problem in property checking is to decide when a property
set is complete. This is usually done by manual inspection of all properties –
a threat to correctness for any larger design. The work in [GKD08] automates
this step. The coverage analyzer determines whether the properties describe the
behavior of the design under all possible input stimuli. If some input sequences
are not covered, this scenario is returned to the verification engineer for manual
inspection. Additional properties may be required or existing properties have to
be modified.
This work is structured as follows: The next section provides preliminaries
on Boolean reasoning engines. Section 3 explains property checking as consid-
142
ered here. The automatic debugging approach is briefly discussed in Section 4.
Section 5 explains the approach to automatically analyze functional coverage.
An embedded example is used to illustrate the techniques. Section 6 concludes.
2
Boolean Reasoning
Since the introduction of model checking there has been large interest in robust
and scalable approaches for formal verification. Symbolic model checking based
on Binary Decision Diagrams [McM93] has greatly improved scalability in comparison to explicit state enumeration techniques. However, these methods are
impractical for industrial designs.
Due to dramatic advances of the algorithms for solving Boolean Satisfiability
(SAT) many SAT-based verification approaches have emerged. Today, SAT is
the workhorse for Boolean reasoning and is very successful in industrial practice
[GG07]. Hence, in the following a brief introduction to SAT is provided as SAT
is also the basis for BMC.
The SAT problem is defined as follows: Let h be a Boolean function in Conjunctive Normal Form (CNF), i.e. a product-of-sums representation. Then, the
SAT problem is to decide whether an assignment for the variables of h exists
such that h evaluates to 1 or to prove that no such assignment exists.
The CNF consists of a conjunction of clauses. A clause is a disjunction of
literals and each literal is a propositional variable or its negation. SAT is one of
the central N P-complete problems. In fact, it was the first known N P-complete
problem that was proven by Cook in 1971 [Coo71]. Despite this proven complexity today there are SAT algorithms which solve many practical problem
instances, i.e. a SAT instance can consist of hundreds of thousands of variables,
millions of clauses, and tens of millions of literals.
For SAT solving several (backtracking) algorithms have been proposed
[DP60,DLL62,MS99,MMZ+ 01,ES04]. The basic search procedure to find a satisfying assignment is shown in Fig. 2 and follows the structure of the DPLL
algorithm [DP60,DLL62]. Instead of simply traversing the complete space of assignments, intelligent decision heuristics [GN02], conflict based learning [MS99],
and sophisticated engineering of the implication algorithm by Boolean Constraint
Propagation (BCP) [MMZ+ 01] lead to an effective search procedure. The description follows the implementation of the procedure in modern SAT solvers. While
there are free variables left (a), a decision is made (c) to assign a value to one
of these variables. Then, implications are determined due to the last assignment
by BCP (d). This may cause a conflict (e) that is analyzed. If the conflict can be
resolved by undoing assignments from previous decisions, backtracking is done
(f). Otherwise, the instance is unsatisfiable (g). If no further decision can be
done, i.e. a value is assigned to all variables and this assignment did not cause
a conflict, the CNF is satisfied (b).
To apply SAT for solving CAD problems an efficient translation of a circuit
into CNF is necessary. The principle transformation in the context of Boolean
formulas has been proposed by Tseitin [Tse68]. The Tseitin transformation can
143
(a) free var. left?
yes
no
(b) SAT
(c) decision
(d) propagation
no
(e) conflict ?
yes
ok
(f) resolve conflict
failed
(g) UNSAT
Fig. 2. DPLL algorithm in modern SAT solvers
i0
...
i1
ic
...
s0
o0
o1
oc
p
Fig. 3. Unrolled circuit and property
be done in linear time. This is achieved by introducing a new variable for each
sub-formula and constraining that this new variable is equivalent to the subformula. For circuits the respective transformation has been presented in [Lar92].
3
Formal Hardware Verification using Bounded Model
Checking
In the following the basic principles of Bounded Model Checking (BMC) are
provided.
We use BMC [BCCZ99] in the form of interval property checking as described
e.g. in [WTSF04,NTW+ 08]. Thus, a property is only defined over a finite time
interval. For a circuit with its transition relation Tδ , a BMC instance for a
144
property p over the finite interval [0, c] is given by:
c−1
Tδ (si , si+1 ) ∧ ¬ p ,
i=0
where p may depend on the inputs, states and outputs of the circuit in the time
interval [0, c]. This verification problem can be formulated as a SAT problem
by unrolling the circuit for c time frames and generating logic for the property.
The transformation is illustrated in Figure 3. As the property is negated in the
formulation, a satisfying assignment corresponds to a case where the property
fails – a counterexample.
In contrast to the original BMC as proposed in [BCCZ99] interval property
checking does not restrict the state s0 in the first time frame during the proof.
This may lead to false negatives, i.e. counter-examples that start from an unreachable state. In such a case these states are excluded by adding additional
assumptions to the property. But, for BMC as used here, it is not necessary to
determine the diameter of the underlying sequential circuit. Thus, if the SAT
instance is unsatisfiable, the property holds.
In the following we assume that each property is an implication of the form
always(A → C). A is the antecedent and C is the consequent of the property
and both consist of a timed expression. A timed expression is formulated on
top of variables that are evaluated at different points in time within the time
interval [0, c] of the property. The operators in a timed expression are the typical
HDL operators like logic, arithmetic and relational operators. The timing is
expressed using the operators next and prev. An example circuit given in Verilog
and properties specified in the Property Specification Language (PSL) [Acc] are
given in the following.
Example 1. Figure 4 describes the circuit sreg with the reset input and a clock
signal, the data input in and the control input ctrl. The input data from input
in is stored in the internal register s0 at each clock tick (lines 7–9). The control
input ctrl decides whether output out returns the Boolean AND or the Boolean
OR of the current value of in and the previously stored value s0 (lines 11-19).
The simple PSL property pReset in Figure 5 describes the behavior of this
circuit immediately after a reset has been triggered. The property is defined over
the interval [0, 1]. The antecedent consists of a single assumption saying that the
reset is triggered at time step 0. The consequent specifies that the output is 0
in the next time step under this condition.
4
Debugging
As explained above debugging is a manual task in the standard design flow. Tool
automation helps to improve the productivity. An automatic approach for debugging in the context of equivalence checking has been proposed in [SVFAA05]
and extended to property checking in [FSBD08].
145
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
module s r e g ;
input c l k , r s t
input in , c t r l ;
output out ;
reg s0 , out ;
always @( posedge c l k )
i f ( r s t ) s 0 <= 0 ;
else
s 0 <= i n ;
always @( posedge c l k )
i f ( r s t ) out <= 0 ;
else
// i n c o r r e c t l i n e :
// i f ( ! c t r l )
if ( ctrl )
out <= s 0 | | i n ;
else
out <= s 0 && i n ;
endmodule
1
2
3
4
5
property pReset = always (
r s t == 1
) −> (
next [ 1 ] ( out ) == 0
);
Fig. 5. Reset property
1
2
3
4
5
6
7
8
9
property pOperation = always (
next a [ 0 . . 1 ] ( r s t == 0 )
) −> (
next [ 1 ] ( c t r l ==0) ?
next [ 2 ] ( out )==
( i n && next [ 1 ] ( i n ) )
: next [ 2 ] ( out )==
( i n | | next [ 1 ] ( i n ) )
);
Fig. 6. Property for normal operation
Fig. 4. Example circuit
Essentially, the same model is created as for BMC shown in Figure 3. Additionally, for the failing property one or more counterexamples are given. The
primary inputs of the circuit are restricted to this counterexample. While the
property is restricted to hold. This forms a contradictory problem instance: when
a counterexample is applied to the circuit, the property does not hold. Finding
a cause for this contradiction yields a potential bug location, a so called fault
candidate.
A fault candidate is a component in the circuit that can be replaced to fulfill
the property. Here, a component may be a gate, a module in the hierarchical
description, or an expression in the source code.
To determine such fault candidates, each component of the circuit is replaced
by the logic shown in Figure 7. In the circuit component c implements the
function fc . This signal line is modified to calculate fc =!rc → fc , where rc is a
new primary input to the model. This allows to change the output value of c.
When rc is zero, c simply calculates the original output as given by the circuit
description. When rc is one, the circuit can be repaired by injecting a new output
value for c.
A trivial solution at this stage would modify all components of the circuit
at the same time and by this easily fulfill the attached property. Therefore an
additional constraint limits the number of modifications. First a solution with
only one modification is searched, if no such solution exists more modifications
are iteratively allowed until a first solution has been found. For example, if more
146
C
Rdd
R
rc
C
fc
f’c
Fig. 7. Repairing a component
than one bug is present, often multiple modifications are required to fix the
circuit. Then, all modifications that allow to fulfill the property are determined to
retrieve all fault candidates. Finding the ”real” bug among the fault candidates
is left to the verification engineer.
Some improvements have been proposed to improve accuracy or efficiency of
this simple approach [FSBD08]. Improving the accuracy can be achieved by using multiple counterexamples. The same construction as described above is done
for all counterexamples. The same variables rc are reused with respect to all
counterexamples. Thus, the same components are modified to correct all counterexamples at the same time. Alternatively, the specification may be strengthened to improve the accuracy. By using multiple properties to specify correct
behavior, the acceptable behavior is described more accurately. Therefore, false
repairs are excluded. Finally, so called Ackermann constraints force all modifications to be realizable by combinational circuitry. The approach considered so far
allows components to behave non-deterministic for repair, which is not feasible
in practice. Ackermann constraints can be used to remove these infeasible fault
candidates.
Efficiency can be improved, by incrementally using more and more counterexamples or more and more properties. Simulation-based preprocessing can
help to remove some fault candidates in case of single faults.
Further works show how to improve the efficiency [SLM+ 07,SFBD08], exploit hierarchical knowledge [FASV+ 05], apply abstraction [SV07], fully correct
a circuit with respect to a given specification [CMB07] or generate better counterexamples [SFB+ 09].
Example 2. Assume that the control signal ctrl of the Verilog circuit was interpreted wrongly. Instead of the correct line 16 in Figure 4, line 15 was used.
In this case property pOperation in Figure 6 does not hold on the circuit. One
counterexample may set ctrl to zero, so the then-branch of the if-statement is
executed erroneously. The resulting output may be corrected by changing either
line 17, where the operation is carried out, or line 16, the faulty condition. These
two locations are returned as fault candidates by the approach. When adding
another counterexample that sets ctrl to one, the else-branch is erroneously executed. Lines 16 or 19 are fault locations. Thus, only line 16 remains as a common
147
fault candidate when both of the counterexamples are applied during automatic
debugging.
5
Coverage Analysis
After debugging and finally proving a set of properties, the verification engineer
wants to know if the property set describes the complete functional behavior of
the circuit. Thus, in the standard design flow the properties are manually reviewed and the verification engineer checks whether properties have been specified for each output (and important internal signals) which prove the expected
behavior in all possible scenarios. The coverage analysis approach introduced in
[GKD07,GKD08] automatically detects scenarios – assignments to inputs and
states – where none of the properties specify the value of the considered output.
The general idea of the coverage approach is based on the generation of a
coverage property for each output. If this coverage property holds, the value of
the output o is specified by at least one property in any scenario. Essentially, the
method shows that the union of all properties that involve the output o does not
admit behavior else than the one defined by the circuit. For this task a multiplexor construct is inserted into the circuit for the actual output o, the properties
describing the behavior of o are aligned and finally the coverage property for o is
generated. Figure 8 depicts the final result of the multiplexor insertion which is
carried out before unrolling. As can be seen for each bit of the n-bit output o a
multiplexor is inserted. Each multiplexor is driven by the respective output bit
and the inverted output bit. Then, in a renaming step the output of each multiplexor becomes oi and the input o origi , respectively. Moreover, the predicate
sel computes the conjunction of all the select inputs of the multiplexers. Based
on this construction, the coverage check can be performed by proving that the
multiplexor is forced to select the original value of o (i.e. o orig) at the maximum
time point, assuming all properties involved. This is expressed in the generated
coverage property of the considered output:
⎛
⎞
|Po |
tmax
−1
⎝
p̂j ∧
Xt sel = 1⎠ → Xtmax sel = 1,
j=1
t=0
where |Po | is the set of properties which involve o in the consequent, tmax is the
maximum time point of time intervals defined by the properties in |Po |, p̂j are
the adjusted properties over time, and Xk denotes the application of the next
operator for k times. By this, the coverage problem is transformed into a BMC
problem.
Complete coverage in terms of the approach is achieved by considering all
outputs of a circuit. If all outputs are successfully proven to be covered by the
properties, then the functional behavior of the circuit is fully specified.
Further works consider to aid the verification engineer while formulating
properties with the goal to achieve full coverage. In [GWKD08] an approach to
understand the reasons for contradictions in the antecedent of a property has
148
sel0
0
1
0
o0
...
o_orig
sel
sel1
o_orig
1
1
0
o1
...
Fig. 8. Insertion of the multiplexor
1
2
3
4
5
6
p r o p e r t y pNew = always (
( r s t == 1 ) && next [ 1 ] ( r s t == 0 )
) −> (
next [ 1 ] ( c t r l ==0) ? next [ 2 ] ( out ) == 0
: next [ 2 ] ( out ) == next [ 1 ] ( i n )
);
Fig. 9. Property required for full coverage
been proposed. The technique of [KGD09] removes redundant assumptions in
a property and generates valid properties for a given specified behavior. Both
techniques can be combined with the coverage analysis to reduce the number of
iterations to obtain full coverage.
Example 3. Again consider the example circuit and the properties pReset and
pOperation. Property pReset covers the behavior after the reset while property
pOperation describes the normal operation of the circuit. Thus, full coverage
should be reached and both properties are passed to the coverage analyzer.
The algorithm unexpectedly returns the uncovered scenario where rst is one
in the first time step and zero in the next. Indeed none of the properties covers
this case, because pOperation assumes rst to be zero in two consecutive time
steps. Thus, a new property pNew to cover the remaining scenario is formulated
as shown in Figure 9. Applying the coverage analysis to the three properties
yields 100% coverage.
6
Conclusions
In this paper we have presented an enhanced formal verification flow. For formal
verification the flow uses bounded model checking. The two major improvements
in the new flow are the integration of debugging and coverage analysis. Both techniques automate manual tasks and hence the productivity improves significantly
in comparison to a traditional flow.
149
References
[Acc]
Accellera Property Specification Language Reference Manual, version 1.1.
http://www.pslsugar.org, 2005.
[BCCZ99] A. Biere, A. Cimatti, E. Clarke, and Y. Zhu. Symbolic model checking
without BDDs. In Tools and Algorithms for the Construction and Analysis
of Systems, volume 1579 of LNCS, pages 193–207. Springer Verlag, 1999.
[CMB07] K. Chang, I.L. Markov, and V. Bertacco. Fixing design errors with counterexamples and resynthesis. In ASP Design Automation Conf., pages 944–
949, 2007.
[Coo71]
S.A. Cook. The complexity of theorem proving procedures. In 3. ACM
Symposium on Theory of Computing, pages 151–158, 1971.
[DLL62]
M. Davis, G. Logeman, and D. Loveland. A machine program for theorem
proving. Comm. of the ACM, 5:394–397, 1962.
[DP60]
M. Davis and H. Putnam. A computing procedure for quantification theory.
Journal of the ACM, 7:506–521, 1960.
[ES04]
N. Eén and N. Sörensson. An extensible SAT solver. In SAT 2003, volume
2919 of LNCS, pages 502–518, 2004.
[FASV+ 05] M. Fahim Ali, S. Safarpour, A. Veneris, M.S. Abadir, and R. Drechsler.
Post-verification debugging of hierarchical designs. In Int’l Conf. on CAD,
pages 871–876, 2005.
[FSBD08] G. Fey, S. Staber, R. Bloem, and R. Drechsler. Automatic fault localization
for property checking. IEEE Trans. on CAD, 27(6):1138–1149, 2008.
[GG07]
M. Ganai and A. Gupta. SAT-Based Scalable Formal Verification Solutions
(Series on Integrated Circuits and Systems). Springer, 2007.
[GKD07] D. Große, U. Kühne, and R. Drechsler. Estimating functional coverage in
bounded model checking. In Design, Automation and Test in Europe, pages
1176–1181, 2007.
[GKD08] D. Große, U. Kühne, and R. Drechsler. Analyzing functional coverage in
bounded model checking. IEEE Trans. on CAD, 27(7):1305–1314, 2008.
[GN02]
E. Goldberg and Y. Novikov. BerkMin: a fast and robust SAT-solver. In
Design, Automation and Test in Europe, pages 142–149, 2002.
[GWKD08] D. Große, R. Wille, U. Kühne, and R. Drechsler. Using contradiction analysis for antecedent debugging in bounded model checking. In
ITG/GI/GMM-Workshop “Methoden und Beschreibungssprachen zur Modellierung und Verifikation von Schaltungen und Systemen”, pages 169–178,
2008.
[KGD09] U. Kühne, D. Große, and R. Drechsler. Property analysis and design understanding in a quality-driven bounded model checking flow. In Design,
Automation and Test in Europe, 2009.
[Lar92]
T. Larrabee. Test pattern generation using Boolean satisfiability. IEEE
Trans. on CAD, 11:4–15, 1992.
[McM93] K.L. McMillan. Symbolic Model Checking. Kluwer Academic Publisher,
1993.
[MMZ+ 01] M.W. Moskewicz, C.F. Madigan, Y. Zhao, L. Zhang, and S. Malik. Chaff:
Engineering an efficient SAT solver. In Design Automation Conf., pages
530–535, 2001.
[MS99]
J.P. Marques-Silva and K.A. Sakallah. GRASP: A search algorithm for
propositional satisfiability. IEEE Trans. on Comp., 48(5):506–521, 1999.
150
[NTW+ 08] M. D. Nguyen, M. Thalmaier, M. Wedler, J. Bormann, D. Stoffel, and
W. Kunz. Unbounded protocol compliance verification using interval property checking with invariants. IEEE Trans. on CAD, 27(11):2068–2082,
2008.
[SFB+ 09] A. Sülflow, G. Fey, C. Braunstein, Ulrich Kühne, and R. Drechsler. Increasing the accuracy of sat-based debugging. In Design, Automation and
Test in Europe, 2009. to appear.
[SFBD08] A. Sülflow, G. Fey, R. Bloem, and R. Drechsler. Using unsatisfiable cores
to debug multiple design errors. In Great Lakes Symp. VLSI, pages 77–82,
2008.
[SLM+ 07] S. Safarpour, M. Liffton, H. Mangassarian, A. Veneris, and K. A. Sakallah.
Improved design debugging using maximum satisfiability. In Int’l Conf. on
Formal Methods in CAD, pages 13–19, 2007.
[SV07]
S. Safarpour and A. Veneris. Abstraction and refinement techniques in
automated design debugging. In Design, Automation and Test in Europe,
pages 1182–1187, 2007.
[SVFAA05] A. Smith, A. Veneris, M. Fahim Ali, and A.Viglas. Fault diagnosis
and logic debugging using boolean satisfiability. IEEE Trans. on CAD,
24(10):1606–1621, 2005.
[Tse68]
G. Tseitin. On the complexity of derivation in propositional calculus. In
Studies in Constructive Mathematics and Mathematical Logic, Part 2, pages
115–125, 1968. (Reprinted in: J. Siekmann, G. Wrightson (Ed.), Automation of Reasoning, Vol. 2, Springer, Berlin, 1983, pp. 466-483.).
[WTSF04] K. Winkelmann, H.-J. Trylus, D. Stoffel, and G. Fey. Cost-efficient block
verification for a UMTS up-link chip-rate coprocessor. In Design, Automation and Test in Europe, volume 1, pages 162–167, 2004.
Daniel Große received the Diploma degree in computer science from the Albert-Ludwigs-University,
Freiburg im Breisgau, Germany in 2002 and the Dr.
degree from the University of Bremen, Bremen, Germany, in 2008. He is currently with the research group
of computer architecture at the University of Bremen.
His research interests include verification, logic synthesis, and high-level languages like SystemC.
Görschwin Fey received his Diploma degree in computer science from the Martin-Luther Universität,
Halle-Wittenberg, Germany in 2001. Since then he has
been with the research group of computer architecture
at the University of Bremen, where he received the Dr.
degree in 2006. He was a guest associate professor at
the University of Tokyo from Dec. 2007 to June 2008.
Currently, he is a postdoctoral researcher at the University of Bremen. His research interests are in testing
and formal verification of circuits and systems. In particular he focuses on debugging and reliability.
151
Rolf Drechsler received the Diploma and Dr. Phil.
Nat. degrees in computer science from the J.W.
Goethe-University, Frankfurt am Main, Germany, in
1992 and 1995, respectively. He was with the Institute of Computer Science at the Albert-LudwigsUniversity, Freiburg im Breisgau, Germany, from 1995
to 2000. He joined the Corporate Technology Department of Siemens AG, Munich, in 2000, where he
worked as a Senior Engineer in the Formal Verification Group. Since October 2001, he has been with
the University of Bremen, Bremen, Germany, where
he is now a Full Professor for Computer Architecture.
He has authored more than 10 books in the area of
VLSI CAD and he published more than 250 papers in
archival journals and refereed conference proceedings.
He was the recipient of Best Paper Awards at the 2006
Haifa Verification Conference and the 2007 Forum on
Specification and Design Languages. He served on the
program committee of major conferences in Electronic
Design Automation (EDA), including Design Automation Conference (DAC), Asia and South Pacific Design
Automation Conference (ASP-DAC), and Design Automation and Test Europe (DATE). His research interests include verification, testing and synthesis.
Program Graph Transformation
Berthold Hoffmann
Universität Bremen
[email protected]
Abstract. Graph transformation, a branch of theoretical computer science, is about the definition of graph languages by grammars, and the
study of computations on graphs by rewrite rules. In this paper, we sketch
a software engineering problem – the refactoring of object-oriented software – and indicate how graph grammars and graph rewrite rules can
be extended for specifying and implementing refactoring operations on
a high level of abstraction.
1
Introduction
Graph transformation generalizes two areas of theoretical computer science.
Chomsky grammars and Lindenmeyer systems [28, chap. 4, 5] generate sets,
or formal languages, of words. Graph grammars allow more general languages
to be generated: data structures like double-linked lists, the admissible states
of some system, or the growth and habitus of plants [26]. Term rewriting and
narrowing define rule-based computational models on terms, or trees [1]. With
graph rewriting, it is possible to study rule-based computations on more general
structures: term graph rewriting [25], or petri nets [12], to mention just a few.
Graphs are often drawn as diagrams, and diagrams are abstractly represented
as graphs. This makes graph transformation a natural choice for specifying and
implementing systems that generate and modify diagrams. Diagram languages
like Uml are now widely used for the model-driven design of object-oriented software. Graph transformation has a high potential for specifying and implementing
visual software models and their transformation, witnessed by a series of international workshops on graph transformation and visual modeling techniques [16]. In
this paper, we use a particular scenario from this area to illustrate the potential
of graph transformation.
Refactoring of Object-Oriented Code. Refactoring aims at improving the
structure of object-oriented software for maintenence and adaptation, without
changing its behavior. Martin Fowler’s book [15] gives a catalog of basic refactoring operations, which, skillfully combined, shall attain these goals. A typical
operation in this catalog, Pull-up Method, is summarized as follows:
– All subclasses of a class c contain equivalent implementations of a method m.
– Pull one of these implementations up to c, and remove all other implementations of m in the subclasses of c.
153
An informal description of the “mechanics” then prescribes a series of steps by
which a programmer should interactively change the code, compile, and test it,
in order to make sure that the consistency of the code, and the behavior of
the program is preserved. Nowadays, many case tools do support refactoring.
However, these implementation have no formal basis so that is remains unclear
whether the application of a refactoring will always preserves code consistency,
let alone program behavior.
The extensive case study [20, 21] by D. Janssens, T. Mens et al. has shown
that graph transformation has a high potential for formalizing refactoring operations. Many advantages are equally true for software models and model transformation in general.
Graph grammars allow languages of graphs and diagrams to be described
in a general way. In Section 2 we show how the shape of program graphs, a
language-independent representation of object-oriented code, can be be defined
with adaptive star grammars. Refactoring operations can be defined by graph
rewriting rules. In Section 3, the Pull-up Method refactoring is specified by a
single generic graph rewrite rule. These rules allow to specify expressive patterns,
including sub-patterns of variable number and shape. In Section 4, we study
how it can be checked whether rewriting steps preserve the shape of graphs. In
particular, we discuss under which conditions generic rules do preserve shape
automatically. Only if all these concepts are supported by an efficient tool, they
can be used for developing refactoring tools. In Section 5 we outline how such a
tool could be developed. We conclude with some remarks on related and future
work in Section 6.
2
Models and Graph Grammars
We describe program graphs informally, discuss why their properties cannot be
captured easily by meta-models like class diagrams, and define them precisely,
by adaptive star grammars with application conditions.
Program Graphs. The case study [20] has proposed a language-independent
representation of object-oriented programs as program graphs, which can be used
for refactoring code written in many languages. In a program graph, nodes represent syntactic entities, and edges establish relations between entities. Relations
represent a hierarchical structure representing abstract syntax, and context links
between uses and definitions of variables and methods that result from the analysis of declarations. Thus the names of variables or methods are not relevant in
this representation.
Fig. 1 below shows two program graphs G and H. (We prefer the classical
way to draw graphs. A denotation as Uml object diagrams would be less concise.) In G, the subgraph P (underlaid in light grey) represents a class with a
method signature and two sub-classes (the nodes labeled C and M). Every subclass contains bodies for the method (the subgraphs underlaid in darker grey),
containing body, expression, and variable nodes, which are labeled B, E, and V.
154
Berthold Hoffmann
1
G
2
3
4
C
M
B
V
1
H
C
C
2
C
3
C
4
M
P
5
C
R
5
=⇒
B
V
B
pum
E
6
V
E
E
E
E
M
E
E
6
V
7
E
M
7
Fig. 1. Two program graphs
In H, one of the method bodies in P has been deleted, and the other one pulled
up to the superclass (by altering the source of the red edge). Actually, this is
what a Pull-up Method refactoring should do to any pattern P of a program
graph G.
In model-driven design, the shape of models is usually specified by metamodeling. In Uml, for instance, a class diagram specifies the shape of the object
diagrams that can be generated by a system. A class diagram usually specifies
subclass relations on nodes, incidence constraints for edges (i.e., which type of
node may be the source or target of some type of edge), and cardinality constraints (i.e., how many edges of some type may be the source or target of a
certain type of node). More involved constraints concerning, e.g., the existence
of paths in a graph, can be specified by logical formulas, as in the Uml’s sublanguage Ocl.
Program graphs are trees representing the nesting of the abstract syntax (by
solid arrows), with contextual links from the uses of names to their declaration
(by dashed arrows). A class diagram can capture the syntactic structure by
subclasses. But, the definition-to-use links of program trees can only be specified
by Ocl formulas.
Therefore we propose to use graph grammars for specifying program graphs,
rather than meta-models. A graph grammar generates a language of graphs (the
valid models) by inductive rules.
Star Grammars. We start from a class G of graphs that are labeled and
directed, and may have loops and parallel edges (with the same label, connecting
the same nodes).
Star grammars are based on variable substitution. In a graph, a variable is a
star-like subgraph X with a center node that is labeled with a variable symbol,
and has edges connecting the center node to border nodes that are labeled with
terminal symbols. The graph in Figure 7 is a star.
A star rule is written Y ::= S, where Y is a variable and S a graph so that
Y and S share the border nodes of Y . Figure 2 shows a star rule for the body of
a method. The box annotated e that surrounds the variable named Exp (with
155
center node x and border node v) indicates a multiple subgraph: this box may
have n > 0 clones, where each of them is connected to the rest of the graph in
the same way (by an edge from the B-node to each clone of the node v in this
case). Multiple subgraphs transfer the notations for repetitions in the EBNF of
context-free grammars to graphs.
We draw star rules by “blowing up” the center node of Y and drawing the
inserted nodes and edges of S inside, as can be seen in Figure 4. (The second
rule in the lower row of is that of Figure 2.).
A variable X in a graph G can be substituted with a star rule Y ::= S
if there is an isomorphism m : Y → X. Then a variable substitution yields the
graph denoted as G[X/m S], which is constructed from the disjoint union of G and
S by identifying the border nodes of X and Y according to m and removing their
edges and center nodes. Let Σ be a finite set of star rules. Then we write G ⇒Σ H
if H = G[X/m S] for some y ::= S ∈ Σ, and denote the reflexive-transitive closure
of this relation by ⇒∗Σ . Let Y be the set of all variables occurring in Σ. We call
them syntactic variables, like in Chomsky grammars, and denote the graphs with
syntactical variables by G(Y). Then Γ = G(Y), Y, Σ, Z is a star grammar with
a start variable Z ∈ Y. The language of Γ is obtained by exhaustive substitution
of its rules to the start variable:
L(Γ ) = {G ∈ G | Z ⇒∗Σ G}
Figure 4 shows the star rules generating the program trees that underlie program
graphs, and Figure 3 shows the generation of a method body tree.
Adaptive Star Grammars. The dashed edges in the rules use, assign, and call
point to new nodes generated by these rules. In program graphs, dashed edges
are contextual links that shall point to a visible declaration of an attribute,
a variable, or a method, respectively. The contextual links of program graphs
cannot be generated with star grammars. Because, in a finite star grammar, the
number of border nodes in stars is bounded. For the insertion of a contextual
link, say to a method in a call rule, all potential targets of the link had to be
border nodes of the left-hand side of the call rule. Since the number of visible
B
Bdy
B
B
B
B
B
Bdy
E
⇓
v
E
Exp
⇒
B
e
Exp
x
E
E
Exp
Exp
E
E
E
Exp
⇒
Exp
E
⇒
E
E
E
E
⇒
E
E
E
E
V
V
Exp
bdy
Fig. 2. A star rule
V
V
V
V
V
V
M
V
Fig. 3. Variable substitutions generating a method body
M
156
Berthold Hoffmann
C
C
Prg
A
C
Hy
Fea
Cls
C
start
M
Sig
B
Hy
hy
Sig
Bdy
Fea
Fea
att
cls
method
E
E
B
E
Exp
Exp
Bdy
B
F
Cls
Hy
M
Exp
E
E
E
A
Exp
sig
Exp
V
A
use
bdy
M
assign
Exp
call
Fig. 4. Star rules generating program trees
methods in a program graph is not bounded, but grows with the size of the
graph, this is not possible.
This observation, however, gives a clue how this limitation can be overcome.
We make stars, star rules, and variable substitutions adaptive wrt. the numbers
of border nodes in stars, as proposed in [7]. In Figure 5, the star rule bdy on the
left is adaptive: The node d is a multiple node (which is drawn with a shade, like
the multiple subgraph in Figure 2), representing a set of clone nodes. The clones
of d are the declarations visible in the body1 A clone of a graph X is denoted
as X vk , where v is a multiple node or subgraph, and k the number of its clones.
On the right, a schematic view of the clones bdy ke nd of the adaptive star rule bdy
is given, for k > 0, n 0. When all multiple nodes and subgraphs in a rule are
cloned, the result is an ordinary star rule, but every adaptive rule may have an
infinite number of clones.
B
B
Bdy
Bdy
e
E
Exp
v
x
bdy
v1
x1
bdy ke
D
d
E
E
···
Exp · · · Exp
··· ···
d
n
d1
···
D
···
···
D
vk
xk
dn
Fig. 5. An adaptive star rule for bodies with clones
1
The type D has subtypes K, V, and M representing declarations of constants, variables, and methods. We silently assume that types in rules may be replaced by
subtypes.
157
Let Σ̈ denote the sets of all possible clones a set Σ of adaptive star rules.
Then, an adaptive star grammar Γ = G(Y), Y, Σ, Z has the same components
as a star grammar, where the syntactic variables in Y and the rules in Σ are
adaptive, but the start variable Z is not. The adaptive star grammar Γ generates
the language
L̈(Γ ) = {G ∈ G | Z ⇒∗Σ̈ G}
The set of cloned star rules Σ̈ is infinite. It has been shown in [7] that this
gives adaptive star grammars greater generative power than grammars based on
hyperedge [17] or node replacement [13], but are still parseable. The adaptive
C
C
A
g
p
D
A
e
e
Hy
i
C
g
F
e
Hy
Prg
C
D
M
p
h
Cls
M
A
p
d
Cls
Sig
p
e
B
Hy
A
Fea
i
sig
hy
cls
D
D
D
start
B
A
M
A
B
B
Bdy
p
Fea
Fea
Fea
E
i
Sig
Bdy
Bdy
h
att
method
override
D
D
h
M
A
Exp
i
p
A
bdy
D
D
E
E
E
Exp
Exp
Exp
E
E
Exp
use
d
A D
assign
d
V
Exp
call
D
p
A
M
A
D
Fig. 6. The set PG of adaptive star rules generating program graphs
rules in Figure 6 generate all program graphs. Since space does not permit to
explain all rules, we refer the reader to [8] for a thorough explanation. Roughly,
the rules start, hy. and cls generate the class hierarchy of a program, collecting
the declarations contained in the classes, and distributing them according to the
visibility rules: If a declaration is global, it is visible in the entire hierarchy; if
it is heritable, it is visible in the class and all its subclasses, if it is internal, it
158
Berthold Hoffmann
is only visible inside the class itself. The features of a class are either attributes
(variables or constants), or new methods, or bodies overriding some inherited
method. Expressions just represent data flow: the use of some visible attribute, or
the assignment of the value of an expression to a variable, or the call of a method
with expressions as actual parameters. The full grammar for program graphs,
with control flow in method bodies, typing, and more sophisticated visibility
rules, appeared in Niels Van Eetvelde’s PhD thesis [31].
Application Conditions. Adaptive star rules do not suffice to capture all
properties of program graphs. In a call, e.g., the number of actual parameters
must match the formal parameters of the method being called. If a program contained m 0 methods, this would require to collect m different sets F1 , . . . , Fm
of formal parameters in distinct multiple border nodes of a variable like Exp.
However, the number m is not bounded, whereas there are only finitely many
edge types. So adaptive stars do not suffice to distinguish all parameter sets
F1 , . . . , Fm .
Our solution is to extend adaptive star rules with positive and negative application conditions as in [11]. A conditional adaptive star rule has the form
A, N → Y ::= S where the graphs A, N ∈ G may share nodes with Y . For
some clone Ä, N̈ → Ÿ ::= S̈ of this rule, a variable substitution G[X/m S̈] is
only defined if the isomorphism m : Ÿ → X can be extended to the positive
application condition Ä, and cannot be extended to the negative application
condition N̈ .
In PG, application conditions are used as follows: The syntactic variables are
attached, not only to all visible declarations, but also to all formal parameters
of all methods. In rule call, the edge from M to A underlaid in green is a positive
condition, collecting formal parameters of M, and the edge from M to the other Anode underlaid in red is a negative condition, forbidding the existence of further
formal parameters of M. Then the multiple subgraph makes sure that an actual
parameter will be generated for every formal parameter of the method being
called.2
The adaptive star grammar in Figure 6 is harder, both to develop, and to
understand, than a class diagram for program graph.
However, the definition of a graph language by adaptive star grammars is
inductive. For instance, the rule bdy ke nd in Figure 5 expresses the following inductive property: If E1 , . . . , Ek are expression graphs, where every graph Ei has
a root vi , and uses the same set {d1 , . . . , dn } of declarations, adding a B-node
as a root, with edges to all nodes v1 , . . . , vk yields a body graph using the same
declarations. This allows to prove properties of adaptive star languages by induction over the rules, and to define operations on these languages by structural
recursion over the rules.
Adaptive star rules have further properties that will be useful in the next
section.
2
In rule override, a similar application condition makes sure that all formal parameters
of a method are visible as variables within its body.
159
Lemma 1 (Commutativity and Substitutivity [7]). Consider two consecutive variable substitutions G[X/m S][X /m S ]. Then the following holds:
1. Commutativity: If X is in G, then G[X/m S][X /m S ] = G[X /m S ][X/m S].
2. Substitutivity: If X is in R, then G[X/m S][X /m S ] = G[X/mS[X /m S ]].
Commutativity and substitutivity are typical for context-free grammars on words
or graphs, as discussed by B. Courcelle in [5]. However, adaptive star grammars
are not context-free, because they fail to be universal : this would mean that
every variable X in a graph may be substituted by every rule Y ::= S if the
variable symbols at their center nodes are the same. Obviously, this is not always
the case for adaptive star rules. For instance, consider a variable X with center
labeled Exp and a single E-labeled border node, i.e., no declaration node is
“visible” to X. Then X (like all graphs containing X) is a blind alley. None of
the rules use, assign, call applies to X, because each of these rules requires that
an attribute, a variable, or a method is visible to X.
3
Generic Graph Rewriting
When applying a graph rewrite rule to a host graph G, a match m(P ) of a graph
pattern P in G shall be identified in order to insert a replacement graph R for
it. The connection between G and R is established by letting P and R share an
interface at which the match m(P ) and R shall be glued.
Gluing Rules. A gluing rule consists of a pair of star rules Y ::= P , Y ::= R
using the same variable Y as their interface; it is denoted as t = P R : Y ,
and applies to a graph G if there exists a context graph C containing a star X
with an isomorphism m : Y → X so that G = C[X/m P ]. Then, the application
of t yields the graph H = C[X/m R]; such a transformation step is denoted as
G ⇒t H.3
In Figure 1, the grey parts of graphs G and H form pattern and replacement
of a gluing rule pum = P R : Y ; the interface Y is shown in Figure 7. When
drawing rules, we omit the interface, and indicate common border nodes of Y
in P and R by attaching the same numbers to them, as done in Figure 1. The
figure thus shows a rewrite step G ⇒pum H, for a schematic context as shown
in Figure 8.
Rule pum captures just some of the situations where the Pull-up Method
refactoring shall be performed. A general rule for Pull-up Method should apply
to a class with any number of subclasses (not just two), to methods with any
number of parameters (not just one), and to bodies of arbitrary shape. Therefore
we extend gluing rules with sub-patterns of arbitrary number or shape.
3
Rewriting with gluing rules corresponds to double pushout graph transformation [10]
with discrete interfaces and injective occurrences.
160
Berthold Hoffmann
Y
C
C
C
M
C
V
H1
2
C
4
V
C
M
C
V
H1
V
M
Fig. 7. An interface star
M
Fig. 8. A context graph
Cloning and Expansion. Adaptive star rules do already provide multiple
nodes and subgraphs that may have a variable number of clones. It is easy
to allow them in gluing rules as well. According to the other requirement, rule
pum should apply to method bodies of arbitrary shape, not just to the particular
bodies in the example (which are underlaid in dark grey).
We therefore allow that in a generic rewrite rule t : P R : Y , the graphs
P and R may not only contain multiple nodes and multiple subgraphs, but also
graph variables from a set X . Graph variable are expanded to varying subgraphs
before applying a rule.
1
1
C
2
pum =
C
3
4
C
M
C
B
V
B
5
c
B1
2
c
3
C
4
M
C
V
B
5
B2
6
D
B2
6
D
Fig. 9. The generic Pull-up Method rule
Figure 9 shows a generic rule pum for Pull-up Method. The rule contains
a multiple subgraph c, two multiple nodes 5 and 6, and two graph variables
B1 and B2 . In order to apply a generic rule, its multiple nodes and subgraphs
must be cloned, and its variables must be expanded by graphs. For simplicity, we
assume that cloning is done before expansion. (In practice, cloning and expansion
should be incremental, and interleaved. This is useful for implementing matching
of generic rules.)
1
1
C
2
¨ =
pum
C
3
4
C
M
C
B
V
B
2
B1
B2
V
M
3
C
5
6
161
4
M
C
V
B
5
B2
7
V
6
M
7
Fig. 10. A clone of the generic Pull-up Method rule
¨ in Figure 10 is the clone pum 1c 15 26 of the generic rule pum in
The rule pum
Figure 9.
A substitution σ is a set of star rules with mutually distinct graph variables
on their left-hand sides. Since σ actually defines a partial function from variables
to graphs, we write Dom(σ) for the set of the left-hand sides in σ, and σ(Y ) = S
for every Y ∈ Dom(σ) if Y ::= S is a star rule in σ. The expansion of a graph G
applies σ to each graph variable in G, and is denoted by Gσ . Due to Lemma 1.1,
variables can be expanded in any order, even in parallel.4
β=
8
>
>
>
>
>
>
>
B1
>
>
>
>
>
>
E
>
<
>
>
E
>
>
>
>
>
>
>
>
> b1
>
>
>
: V
B
9
>
>
>
>
>
>
>
>
>
>
>
>
>
>
=
B
B2
E
E
,
E
E
b2
V
M
V
V
V
M
V
>
>
>
>
>
>
>
>
>
>
>
>
>
>
;
Fig. 11. A shaped substitution for method bodies
¨ β of the clone
The gluing rule pum applied in Figure 1 is the expansion pum
¨ in Figure 10, where β is the substitution defined in Figure 11.
pum
A generic rule t : P R : Y applies to a host graph G = C[X/m P̈ σ ], where
ẗ : P̈ R̈ : Ÿ is a clone of t and σ is a substitution. The application of t yields
the graph H = C[X/m R̈σ ], and we write G =⇒ H.
t,σ
4
In this notation, we omit the morphisms from the variables of σ to those of G by
which the expansion becomes unique.
162
Berthold Hoffmann
Shaped Expansion. Expansions insert arbitrary graphs into a generic rule.
This is not only hard to implement, because the substitution has to be found
while applying the generic rule, but it is also too general. In our example, rule
pum shall be applied to program graphs. Then the graph variables B1 and B2
are placeholders for method bodies. So we require that substitutions are shaped
according to adaptive star rules.
Let Γ = G(Y), Y, Σ, Z be an adaptive star grammar with application conditions. We assume that every graph variable X ∈ X refers to a syntactic variable
X ∈ Y, which is called the shape of X. For some graph G ∈ G(X ), replacing
graph variables by the corresponding syntactic variables yields the shape graph
G ∈ G(Y). A graph G ∈ G(X ) is shaped according to Σ if Y ⇒∗Σ G for some
Y ∈ Y; this is written as Σ G : Y .
A substitution σ is shaped (according to Σ) if Σ σ(Y ) : Y for every graph
variable Y ∈ Dom(σ).
¨ have the shape Bdy. Then
Let the graph variables B1 and B2 in rule pum
the substitution β is shaped.
4
Shape Preservation
For our example, it is relevant to ask whether the refactoring of a program graph
will always yield a valid program graph again. A simple solution to this problem
would be to check this property after every rewrite step. Since the parsing for
adaptive star grammar is decidable, this can be done automatically, but is not
efficient. It would be better if the rules and the way they are applied could be
restricted so that shapes are preserved in any case.
A generic rule t = P R : Y is called shaped if Σ P : Y and Σ R :
Y. A shaped generic rule t = P R : Y applies to a graph G if there exists a
shaped context graph C containing a star X with an isomorphism m : Y → X so
that G = C[X/m P σ ], for some substitution σ. Then, the application of t yields
Σ
the graph H = C[X/m Rσ ]; a shaped rewrite step is denoted as G =⇒
t H.
Theorem 1 (Shape-Correctness). For any graph G and any shaped generic
rule t:
Σ
Σ G : Z ∧ G =⇒
T H =⇒ Σ H : Z
Proof Sketch. Assume w.l.o.g. that t = P R : Y and H = C[X/m R̈σ ],
for some clone ẗ = P̈ R̈ : Ÿ of t, some shaped substitution σ and some
isomorphism m : Ÿ → X.
The following fact is easily shown by induction over the number of star rule
applications, using Lemma 1.2. (*) If Y ⇒∗Σ S and Y ⇒∗Σ S with an isomorphism m : Y → X for some syntactic variable X in S, then Y ⇒∗Σ S[X /m S ].
Since t is shaped, we have Y ⇒∗Σ R. This carries over to the clone, so
Y ⇒∗Σ R̈. Consider those variables X1 , . . . , Xn in R̈ where every Xi has a
Yi ∈ Dom(σ) with an isomorphism mi : Yi → Xi , for 1 i n. Then fact
(*) yields that Y ⇒∗Σ R̈[X1 /m1 σ(Y1 )] · · · [Xn /mn σ(Yn )] and hence Y ⇒∗Σ
R̈σ by Theorem 1.1.
163
Again by fact (*), Z ⇒∗Σ C and Y ⇒∗Σ R̈σ with the isomorphism
m : Y → X for some variable X in C implies Z ⇒Σ C[X/m R̈σ ]. Hence
Z ⇒∗Σ H, and H is shaped.
Let pumPG be the shaped generic rule obtained from rule pum in Figure 9
by removing nodes 2 and 4 from the interface. This rule is shaped according to
the syntactic variable with center Hy as it appears in the adaptive star rule hy
in Figure 6.
Note however that pumPG applies only to (shaped) graphs where the superclass 1 has no further features, and the subclasses 2 and 4 have no other features
or subclasses either. In other words, the rule is still not general enough if its
applied in a shape-preserving fashion.
We can extend rule pumPG by further graph variables that are placeholders
for further features and subclasses to change this. Unfortunately, the resulting
rule is rather complicated.
5
Towards an Implementation
The concepts for shapes and rules outlined in Sections 2 to 4 shall be incorporated into a diagram programming language, diaplan. The structure for an
implementation of this language is outlined in Figure 12. The basic layer of the
diaplan system shall be obtained by extending two kernel components of the
Graph rewrite generator GrGen developed at Universität Karlsruhe [4]. The
GrGen rule compiler translates sets of rewrite rules into abstract machine code
of a rewrite engine, using highly sophisticated optimization techniques, making
GrGen the fastest graph rewriting tool available.5 Since the system already
5
Admittedly, Fujaba [24] is close in efficiency, and even better on some benchmarks,
due to a simpler specification language.
program
diagram
user
interface
diaplan
editor
diagram
editor
structure
layer
diaplan
compiler
diaplan
interpreter
GrGen
system
rule
compiler
rewrite
engine
Fig. 12. Outline of the diaplan programming system
164
Berthold Hoffmann
supports shaped graph variables discussed in Section 4, in form of recursively
defined sub-patterns and sub-rules [18], it has “just” to be extended to handle multiple nodes, multiple subgraphs, cloning, and shapes defined by adaptive
rather than plain star grammars.
The structure layer of the system shall consist of a compiler that translates classes with shape and predicate definitions into rewrite units. The diaplan
interpreter shall link these units, call rewrite code recursively, and initiate backtracking for nondeterministic predicates if necessary.
The user interface consists of a diagram editors for diaplan programs, and
a diagram editor for constructing input graphs, invoking the interpreter, and
displaying its results. The editors can be generated with the generator DiaGen
for diagram editors developed M. Minas [22, 23].
6
Conclusions
Refactoring shows that graph transformation can be useful for specifying software models and model transformations. Graph grammars, in particular adaptive star grammars with application conditions, can capture the shape of models
precisely. Thanks to multiple nodes, multiple subgraphs, and graph variables,
generic graph rewrite rules allow to specify refactorings like Pull-up Method
refactoring by a single rule. It is even possible to define criteria under which
applications of a generic rule will always stay within the language of the host
graph, even if these rules may become quite complicated.
Some work related to the concepts shown in this paper shall be mentioned
here. Shape analysis is about specification and verification of invariants for
pointer structures in imperative programming languages, e.g., whether a data
structure is a leaf-connected tree. Often, logical formalisms are used for this
purpose [29]. When specifying models by meta-models, e.g., in Uml, object constraint logic (ocl) is used for properties that are beyond the descriptive power
of class diagrams. Plump et al. have proposed graph reduction grammars for
shape specification [2]. There is a close relationship between graph languages
and (monadic second-order) logic [6], which has not yet been studied for reduction graph grammars or adaptive star grammars, however. The concept of
multiple nodes in graph rewrite rules dates back to Progres [30], and is used
in several other systems. We have extended it to multiple subgraphs. Graph
variables have been implemented, under the name of recursive sub-patterns and
sub-rules, in the extension [18] of the GrGen system [4]. Viatra2 [3] seems to
be the only other system implementing recursive sub-patterns.
Several questions and challenges remain for future research. Fundamental
properties of generic and shaped generic rewrite rules have still to be investigated, such as parallel and sequential independence of rewrite steps, and critical
pairs of rewrite rules, which are prerequisites to study confluence of (shaped)
generic graph rewrite. Another topic is termination.6 For our example, analy6
Generic graph transformation could be defined as an instance of adhesive high-level
replacement, a categorical axiomatization of graph transformation [9]. Then criteria
165
sis of these properties would allow to indicate which refactorings could become
applicable after a particular refactoring has been performed. And—last but not
least—the system outlined in Section 5 has to be implemented.
Acknowledgment. This paper describes the outcome of my research while I
am working with Bernd Krieg-Brückner at Universität Bremen. This work was
only possible since Bernd allowed my to continue my original line of research –
next to my “daily work”, the management of an esprit project [19], teaching
(programming languages and compiler construction), and administration of his
group at Universität Bremen. I have been lucky – and are still happy – to get
this freedom and generous support. Danke schön, Bernd!
References
1. F. Baader and T. Nipkow. Term Rewriting and All That. Cambridge University
Press, Cambridge, UK, 1998.
2. A. Bakewell, D. Plump, and C. Runciman. Specifying pointer structures by graph
reduction. Mathematical Structures in Computer Science, 2009. Accespted for
publication.
3. A. Balogh and D. Varró. Pattern composition in graph transformation rules. In
European Workshop on Composition of Model Transformations, Bilbao, Spain, July
2006. See also http://viatra.inf.mit.bme.hu/update/R2.
4. J. Blomer and R. Geiß. GrGen.net: A generative system for graph-rewriting,
user manual. www.grgen.net, 2008.
5. B. Courcelle. An axiomatic definition of context-free rewriting and its application
to NLC rewriting. Theoretical Computer Science, 55:141–181, 1987.
6. B. Courcelle. The expression of graph properties and graph transformations in
monadic second order logic. In Rozenberg [27], chapter 5, pages 313–400.
7. F. Drewes, B. Hoffmann, D. Janssens, and M. Minas. Adaptive star grammars and
their languages. Technical Report 2008-01, Departement Wiskunde-Informatica,
Universiteit Antwerpen, 2008.
8. F. Drewes, B. Hoffmann, and M. Minas. Adaptive star grammars for graph models.
In H. Ehrig, R. Heckel, G. Rozenberg, and G. Taentzer, editors, 4th International
Conference on Graph Transformation (ICGT’08), number 5214 in Lecture Notes
in Computer Science, pages 201–216. Springer, 2008.
9. H. Ehrig and K. Ehrig. An overview of formal concepts for model transformations
based on typed attributes graph transformation. Electronic Notes in Theoretical
Computer Science, 152(4), 2006. Proc. Graph and Model Transformation Workshop (GraMoT’05).
10. H. Ehrig, K. Ehrig, U. Prange, and G. Taentzer. Fundamentals of Algebraic Graph
Transformation. EATCS Monographs on Theoretical Computer Science. Springer,
2006.
11. H. Ehrig and A. Habel. Graph grammars with application conditions. In G. Rozenberg and A. Salomaa, editors, The Book of L, pages 87–100. Springer, Berlin, 1986.
for these properties come “for free”. However, such an instance would be too “coarse”
to provide good results for confluence.
166
Berthold Hoffmann
12. H. Ehrig and J. Padberg. Graph grammars and petri net transformations. In
J. Desel, W. Reisig, and G. Rozenberg, editors, Lectures on Concurrency and Petri
Nets, volume 3098 of Lecture Notes in Computer Science, pages 496–536. Springer,
2003.
13. J. Engelfriet and G. Rozenberg. Node replacement graph grammars. In Rozenberg
[27], chapter 1, pages 1–94.
14. G. Engels, H. Ehrig, H.-J. Kreowski, and G. Rozenberg, editors. Handbook of
Graph Grammars and Computing by Graph Transformation, Vol. II: Applications,
Languages, and Tools. World Scientific, Singapore, 1999.
15. M. Fowler. Refactoring—Improving the Design of Existing Code. Object Technology Series. Addison-Wesley, Reading, MA, 1999.
16. gt-vmt: International workshops on Graph Transformation and Visual Modelling
Techniques. http://www.cs.le.ac.uk/events/gtvmt09/, 2000–2009.
17. A. Habel. Hyperedge Replacement: Grammars and Languages. Number 643 in
Lecture Notes in Computer Science. Springer, 1992.
18. B. Hoffmann, E. Jakumeit, and R. Geiß. Graph rewrite rules with structural
recursion. In M. Mosbah and A. Habel, editors, 2nd Intl. Workshop on Graph
Computational Models (GCM 2008), pages 5–16, 2008.
19. B. Hoffmann and B. Krieg-Brückner, editors. Program Development by Specification and Transformation, number 680 in Lecture Notes in Computer Science.
Springer, 1993.
20. T. Mens, S. Demeyer, and D. Janssens. Formalising behaviour-preserving transformation. In A. Corradini, H. Ehrig, H.-J. Kreowski, and G. Rozenberg, editors,
First International Conference on Graph Transformation (ICGT’02), number 2505
in Lecture Notes in Computer Science, pages 286–301. Springer, 2002.
21. T. Mens, N. Van Eetvelde, S. Demeyer, and D. Janssens. Formalizing refactorings
with graph transformations. Journal on Software Maintenance and Evolution:
Research and Practice, 17(4):247–276, 2005.
22. M. Minas. Specifying and Generating Diagram Editors. Habilitationsschrift, Universität Erlangen, 2001. [In German].
23. M.
Minas.
DiaGen/DiaMeta:
A
diagram
editor
generator.
www.unibw.de/inf2/DiaGen, 2008.
24. J. Niere and A. Zündorf. Using Fujaba for the development of production control systems. In M. Nagl, A. Schürr, and M. Münch, editors, Int’l Workshop on
Applications of Graph Transformations with Industrial Relevance (Agtive’99), Selected Papers, number 1779 in Lecture Notes in Computer Science, pages 181–191.
Springer, 2000.
25. D. Plump. Term graph rewriting. In Engels et al. [14], chapter 1, pages 3–102.
26. P. Prusinkiewicz, M. Hammel, J. Hanan, and R. Měch. Visual models of plant
development. In G. Rozenberg and A. Salomaa, editors, Handbook of Formal Languages, volume 3: Beyond Words, chapter 9, pages 535–597. Springer, 1999.
27. G. Rozenberg, editor. Handbook of Graph Grammars and Computing by Graph
Transformation, Vol. I: Foundations. World Scientific, Singapore, 1997.
28. G. Rozenberg and A. Salomaa, editors. Handbook of Formal Languages, volume 1:
Word, Language, Grammar. Springer, 1997.
29. M. Sagiv, T. Reps, and R. Wilhelm. Solving shape-analysis problems in languages
with destructive updating. ACM Transactions on Programming Languages and
Systems, 20(1):1–50, 1998.
30. A. Schürr, A. Winter, and A. Zündorf. The Progres approach: Language and
environment. In Engels et al. [14], chapter 13, pages 487–550.
167
31. N. Van Eetvelde. A Graph Transformation Approach to Refactoring. Doctoral
thesis, Universiteit Antwerpen, May 2007.
Berthold Hoffmann received his Diplom and PhD
(Dr.-Ing.) from TU Berlin. He works in Bernd KriegBrüchner’s group since 1982.
Type-Safe Red-Black Trees with Java Generics
Stefan Kahrs
University of Kent at Canterbury
Department of computer Science
[email protected]
Abstract. Java Generics[1] are a powerful extension of Java’s class system, allowing the static type checker to ensure (as their most typical
application) the type-safe usage of homogeneous collections.
The paper shows that the expressiveness of generics goes a very long
way, by using them to enforce the tree balancing in a red-black tree
implementation. The idea originates from Functional Programming [2, 3],
though Java Generics are too different to allow a one-to-one adaptation.
Based on experiences with this application, a number of suggestions are
made for the improvement of Java Generics.
1
Introduction
Java Generics came about as a response to a long-standing problem in Java:
the need for dynamic type casts used to make many Java programs potentially
unsafe, with the possibility of class cast exceptions at run-time. In the late 1990s
Phil Wadler et al. [4, 5] showed how the Java language could be extended to
provided for a richer static analysis that would allow to eliminate dynamic casts
almost entirely. Since Java 5 these ideas have entered the language standard [6].
Red-black trees provide a well-known way of implementing balanced 2-3-4
trees as binary trees. They were originally introduced (under a different name)
in [7] and are nowadays extensively discussed in the standard literature on algorithms [8, 9]. The basic operations for search-trees (search, insertion, deletion)
are realised in O(log(n)) time, for tree size n.
Red-black trees are binary search trees with an additional “colour” field
which is either red or black. The root of the tree will always be black. In a redblack tree each red node is required to have black subtrees and is regarded as
an intermediate auxiliary node. All binary nodes are required to be of the same
black height, which is the nesting depth of binary black nodes. Therefore, every
binary black node has a black height of n + 1, where n is the black height of its
subtrees. Moreover, viewing red nodes only as auxiliary nodes, a black binary
node of height n + 1 has between 2 and 4 black subtrees of height n, depending
on whether 0, 1 or 2 of its direct subtrees have red roots. This is the reason why
red-black trees can be seen as an implementation of 2-3-4 trees.
Since the mid 1990s it has been known in the Functional Programming community that invariances such as tree-balance can be enforced through a sufficiently rich type system [2], using the feature of “nested” datatypes. Characteristic for these types is that the unfolding of their recursion (see [10]) results in
169
non-regular infinite trees; this causes problems for type inference [11] and indeed
Standard ML’s type-inference based type system fails to cope with nested types
[12]. However, this does not affect the type-checking of type-annotated code, as
in Java Generics.
It would be fairly straightforward to “ape” the FP implementation of redblack trees in an object-oriented setting. However, this would require to move
fields into the implementing concrete classes, and consequently operations on
fields higher up the class hierarchy would have to be expressed in terms of
abstract methods instead. This paper uses a more object-oriented approach that
permits directly operating with fields at abstract classes. However, this requires
to abstract the types of the fields and as a consequence the generic parameter
lists for the classes become more complex.
2
Inheriting Generic Fields
All our red-black trees (even the empty ones) are special cases of binary search
trees. Moreover, the abstract class of binary search trees also contains the only
fields for all of our various tree types. This inheritance of the fields is what makes
the implementation overall rather different from its FP cousin.
public abstract class Bin<T extends Comparable<? super T>,
F extends Find<T>>
implements Find<T>
{
public T co;
public F le,ri;
public T find(T x) {
int res=co.compareTo(x);
if (res==0) return co;
if(res<0) return le.find(x);
return ri.find(x);
}
}
The fields for the left and right branches of a tree node (le and ri) are of
the generic type F, which at this stage just suffices to implement binary search.
Subclasses of Bin will restrict the type for F further, to trees of a particular
height and (possibly) a particular colour.
Consequently, other classes in the hierarchy of tree types will need a matching
type parameter for F — it can only be removed from the class interface once it
no longer changes. In a context in which these fields are both read and written
to this concrete type needs to be made available as a generic parameter.
3
Typing Red-Black Trees
Figure 1 shows the raw type hierarchy used for the red-black tree implementation; it is “raw” in the sense that it does not include the type parameters, most
170
Bin
Black
NeBlack
DeepBlack
Red
EmptyTree
Singleton
DeepRed
ShallowBlack
Fig. 1. Raw Type Hierarchy
notably the ones responsible for the GADT effect, though the node colouring
is already modelled. Also not included are the interfaces which guide how these
types are used, and the types modelling tree underflow.
Clients for this implementation would use the trees through the interface
PureTree which hides the information about black heights: the trees need to
know how high they are, the clients do not. Providing a similar abstraction in
Functional Programming is comparatively awkward, as it would typically involve
the relatively advanced feature (it is not part of the Haskell-98 standard [13],
though all Haskell compilers support it) of existential types, as used in [3]. Java
Generics have a form of existential type abstraction of their own: wildcards.
To provide a tree type for clients the use of wildcards would have been less
appropriate, as PureTree<T> would have been replaced by the rather bewildering
Black<T,?,?,?>.
Generally, the class hierarchy regards all red-black trees as cases of binary
search trees. The tree-manipulation methods for red and black trees share common interfaces, but their implementation is considerably different, so that they
are given different classes. Within colours, classes are distinguished by height:
Singleton is the class of red-topped trees of black height 0, DeepRed the class of
red-topped trees of black height n + 1; black-topped trees have an even finer distinction, with DeepBlack having black height n + 2. Why this particular height
distinction is appropriate will be discussed later.
Notice that such a hierarchy has already considerable implications for the
classes: as trees can shrink through deletion and grow through insertion, trees
need to have some knowledge of the types that would be attached to the neighbouring levels.
There is an immediate price to pay for this design: we can neither change
the colour, nor the height of an existing tree node, because either change requires a change of type. Thus, where the standard imperative implementation of
red-black trees freely rewires (and recolours) tree nodes to realise tree rotations
to compensate for insertion overflow or deletion underflow, a type-safe implementation will have to frequently discard existing nodes and create fresh ones
instead.
171
4
Tree Heights
Red-black trees are a form of balanced trees. Left and right branch of any node
are required to have the same black height. This is enforced in this implementation through the type system, as follows:
– As already seen, left and right branch of any tree node have the same generic
type F; thus, if the branch types of the implementing classes encode height
information the tree is necessarily balanced.
– Empty trees have (by definition) black height 0, as have singleton red trees.
– Non-empty black trees have type NeBlack<T,B,O>, and their black height is
1 plus the black height of O, which is the type of their branches.
– Red trees have type Red<T,B,O> where B is the type of their (black) branches.
Their black height is the same as the black height of type B.
– Red-black trees appear as branches of non-empty black trees. They are instances of the interface RBTree<T,B,O>. The only implementing classes of
this interface, i.e. red trees and black trees, set the B parameter to a black
tree class of black height n which is equal to their own black height.
Therefore the black height of a red-black tree can be read off its type. The reason
this is unambiguous is that the type of the branches occurs as a subexpression
in the whole type expression.
The security this gives to the implementation is relative: tree height is maintained as an invariant. In itself this does not stop end users from writing further
subclasses which could break the invariant — such as ordinary binary search
trees, without any balancing whatsoever.
5
Black Trees
The code that sits at abstract class Black looks mostly rather peculiar and
mysterious. The reason is that most code that can be placed at that abstract
class is code that deals with tree operations relative to some context, such as
a tree rotation w.r.t. a parent and grandparent node. Without knowing where
that context is coming from these operations make very little sense. However,
the type interface for class Black is less obscure:
abstract public class Black<
T extends Comparable<? super T>,
F extends Find<T>,
O extends RBTree<T,B,O>,
B extends Black<T,F,O,B>
> extends Bin<T,F>
implements PureTree<T>, RBTree<T,B,O>,Embed<T,B,O>
The type T is the type of search values; type F is some type which has a method
find for searching T values, and type F is used as the types for the left and right
172
children of the tree. The type O is a red-black tree of the same black height, and
it is the type of insertion results.
Based on this, class Black can already provide the implementation for the
insertion and deletion methods when used as a pure tree:
public PureTree<T> insert(T x) { return ins(x).makePure(); }
public PureTree<T> delete(T x) { return del(x).makePure(); }
abstract public O ins(T x);
abstract public MakePure<T> del(T x);
Subclasses of this will need to constrain the result type of the del method further
— but this is possible in Java since version 5, using covariant overriding. Without
that language feature, class Black would need an additional parameter.
The final parameter of the class B is a standard trick in Java Generics (see
e.g. [6]) to refer to an implementing subclass. The value expressed by this is of
type Black<T,F,O,B>, but this can be too general to be of good use, as it forgets
too much information. Instead, the class Black leaves its concrete subclasses an
abstract method B self() to implement; inside the class Black calls to self()
will therefore lose less information than the constant this does.
The class implements (promises to implement) three interfaces: all black trees
are pure trees, all black trees are red-black trees, and furthermore black trees of
height n can be embedded into the red-black trees of height n. The last of these
three promises (the interface Embed) may appear rather peculiar, and is worth a
further look, as it also reveals a weakness in the expressiveness of Java Generics.
The problem is this: all red-black trees implement the RBTree interface; however, for height 0 (and height > 0) the interface is extended with methods specific
to zero heights and non-zero heights. What we need is that our specialised subclass B needs to implement that associated more specialised interface, e.g. be a
subclass of O. However, Java Generics do not allow subclassing constraints between variables, only between variables and classes. Therefore, within the class
Black we cannot even make the promise that B will be a subclass of O.
public interface Embed<
A extends Embed<T,A,B>,
B extends RBTree<T,A,B>
> extends Find<T> {
public B embed();
public B ins(T x);
public B mkPair(T x,A sibling);
public NeBlack<T,A,B> mkBpair(T x,A sibling);
}
The way around this problem is to require instead a method embed which coerces a black tree of whatever height into its associated red-black variety. As all
implementing black classes do maintain the property that they subclass their
respective red-black variety, the method always has a trivial implementation.
173
Thus this works but it is not particularly nice and calls for a slight overhaul
of Java Generics, e.g. supporting something like this as a replacement for the
specification of B:
B extends Black<T,F,O,B> & O
This should express that B not only subclasses Black in this way, but that it
also will maintain a subtype relationship with O. This is legal Java syntax for
class/interface names, but not for type variables.
The other methods in that class are needed for forming larger trees, e.g. the
method mkBpair is applied to a value of type T and another black tree of the
same height n to form a non-empty black tree of height n + 1; this particular
method is used for buffering deletion underflow.
As a final remark, it may appear a little bit peculiar that type O is part of the
generic parameter list at all. After all, height information is already recoverable
from the F parameter. It is indeed necessary, because the results of various
operations of the Embed interface will be stored in fields of a node and thus
have to match their type exactly (at this abstract level), and thus when the
class Black promises to implement Embed this type needs to be mentioned itself.
There is also a pragmatic reason to keep generic parameters at class level: even
if we could remove type O from the class interface we would then have to move
that abstraction to the level of individual methods, turning them into generic
methods — generic methods with rather complex type interfaces.
6
Generalised Algebraic Data Types
Algebraic Data Types in Haskell introduce a fresh type, plus constructors that
can be used to create values of this type. In particular, if that new type is
a parametric type A t then all constructors of the type will be polymorphic
functions with return type A t. Generalised Algebraic Data Types weaken this
condition slightly by allowing that constructors can have return type A u, where
u is a substitution instance of t. This generalisation can be used to define, for
example, length-aware lists (vectors) as follows:
data Vector a n
where
Nil :: Vector a ()
Cons :: a -> Vector a k -> Vector a (S k)
In (GHC) Haskell, this defines a fresh type Vector, with two type parameters
a and n. The first parameter is the component type of the vector, the second
the length of the vector, though this length is encoded as a type. This second
parameter has no bearance on the contents of the vectors, it is a phantom type
whose sole purpose is to make the use of vectors more rigid. With this definition,
vectors of different lengths have different types, e.g. Cons 4(Cons 7 Nil) has
type Vector Int (S(S())). A motivation for defining length-aware lists is that
174
they allows us to express indexing operations that are guaranteed to stay within
bounds.
When translating ADTs to Java, the type as a whole becomes an abstract
class, and each data constructor becomes a new subclass. This works without
change in the generalised setting, because when we are subclassing a generic
class in Java we can specialise its type parameters. For example, the subclass
corresponding to the above Cons would commence like this:
class Cons<A,K> extends Vector<A,S<K>> {
A val;
Vector<A,K> tail;
Here, the parameters of Haskell’s data constructor become fields of the new class.
Going back to our case study, the subclasses for Black and Red also use
this technique, though as explained earlier the subclasses have a rigid structure
anyway and thus there is no need to use phantom types (this would be different
for red-black trees without deletion). For example, EmptyTree extends Black
but it specialises the type parameters, as its class header shows:
final public class EmptyTree<
T extends Comparable<? super T>>
extends Black<T,Find<T>,FlatTree<T>,EmptyTree<T>>
Explanation: an empty tree has left and right branches of type Find<T> (which
will always be null), insertion into an empty tree gives a flat tree (red-black
tree of black height 0), and the EmptyTree<T> in the final argument position is
the reflection type of empty trees, which is used e.g. as result type of the self()
method.
Although empty trees already make use of GADT-style subclassing, the exploitation of the expressive power of the feature is perhaps better understood in
connection with the class NeBlack of non-empty black trees:
abstract public class NeBlack<
B extends Embed<T,B,O>,
O extends RBTree<T,B,O>>
extends Black<T,O,DeepTree<T,B,O>,NeBlack<T,B,O>>
Explanation: non-empty-black trees (of height n+1) store red-black trees of some
description (type O) as their left and right children. Type B is really the type of
black trees of height n, but NeBlack only needs to know that it implements the
Embed interface — and using the weaker constraint helps to keep the parameter
list of NeBlack short, because Embed mentions fewer type parameters than Black.
The result type of insertions into non-empty black trees is DeepTree<T,B,O>,
the type of red-black trees of height n + 1 (which has a richer interface than
RBTree). Finally, the reflection type is NeBlack<T,B,O>; this suggests that no
subclasses of NeBlack are needed, as they would reflect into their superclass —
175
thus, the subclasses ShallowBlack and DeepBlack are created more for convenience than necessity, as issue that will be discussed later.
Because the class header ensures that the left and right subtree of an NeBlack
object are themselves red-black trees, it can implement the ins method which
is required for all black trees:
public DeepTree<T,B,O> ins(T x) {
int res=co.compareTo(x);
if (res==0) return this;
if (res<0) return le.insL(x,this);
return ri.insR(x,this);
}
The methods insL and insR are required in the RBTree interface which the
fields le and ri must implement since their type O extends that interface. The
purpose of these methods is to insert into a subtree, but to provide the parent
as a context, in case there is an insertion overflow.
7
Iterative vs. Recursive Insertion
A consequence of the type structure for red-black trees is that insertion and
deletion cannot be implemented iteratively (i.e. through loops), the implementation has to be recursive. The reason is that the loop state would not have a
proper type: as the algorithms traverse through the tree, the visited nodes have
different types. However, a recursive implementation should not need to be less
efficient than the iterative implementation: the standard imperative realisation
of red-black trees [8] represents every edge in the tree through two pointers going
in opposite directions. For the recursive version one pointer per edge suffices, as
all required references to parent nodes sit on the run-time stack; in other words,
the method-call overhead in the recursive version is quite similar to the doublepointer overhead in iterative implementations.
During insertion and deletion a sufficient amount of parent context is provided to realise the invariant promised in the types of these operations. Moreover,
if the root of a subtree changes (because a tree rotation is required) this is signalled to the calling context simply through its return value — the iterative
version would instead update the parent through its parent pointer.
Consequently, empty trees are easier to deal with. In particular, the ins
operation of class EmptyTree is the following:
public Singleton<T> ins(T x) {
return new Singleton<T>(x,this);
}
Because the ins methods return the new root, insertion into an empty tree
can be realised by creating and returning a new node. When a tree grows to n
internal nodes it will have n + 1 occurrences of empty trees; however, instead of
176
doubling the memory requirements for a tree all these empty trees are the same
object, which is achieved by passing this to the Singleton constructor.
The need for doing this reveals again a slight weakness of Java generics.
Because the class EmptyTree is generic in T, the Singleton class cannot keep
a static copy of an empty tree, and thus it is passed to it at construction time.
This is correct and proper, but why has EmptyTree to be generic in T? The
answer is this: EmptyTree “could” implement Black without being given the type
parameter T. However, this would make its implementing methods themselves
generic, e.g. for the ins method we would get this signature:
public <T extends Comparable<? super T>> FlatTree<T> ins(T x);
The actual problem with this is that Java does not recognise a generic method as
an implementation of a less generic abstract one, and therefore a type-unaware
empty tree cannot be used to implement type-aware tree interfaces.
g
p
p
t
c
t
a
d
b
a
g
b
c
d
Fig. 2. Insertion with required right rotation
If insertions return new roots so should tree rotations. While this is possible
in a recursive and imperative realisation of red-black trees, tree rotations (as
methods) do not fit terribly well in this typed setting, because they are not
universally applicable with universally meaningful types. Instead they occur in
certain contexts, and these contexts need to be provided so that the same effect
can be achieved.
An example is shown in figure 2; here, the circular nodes indicate red colour,
the square ones black colour. In the example, an insertion into a tree has proceeded in the left child of the red node p and returned another red tree rooted
at t. Because of the colour clash this node cannot be placed as the new left child
of p — this is indicated by the dashed line. Instead, the attempt to place t as
the left child of p is informed by the context, nodes p and g. This is sufficient
to be able to form the desired (legal) tree fragment on the right. This tree fragment cannot entirely be created through pointer rewiring either: although node
t only changes colour this is now a change of class which consequently requires
the creation of a new object; the node p would be re-used as indicated in the
177
picture, but the height of p on the left and right differs, which again requires
a fresh object. Only node g retains colour and height and can be updated as
indicated.
Tree rotations of this kind sit fairly high up in the class hierarchy at classes
Black and Red themselves. The object responsible for performing this tree rotation is t; as t is red, the corresponding method sits in the class Red:
public DeepTree<T,B,O>
goLL(Red<T,B,O> pa, NeBlack<T,B,O> gpa) {
gpa.le=pa.ri.embed();
return blacken().mkPair(pa.co,gpa);
}
The method goLL generally attempts to place this object (if possible) as the left
child of (red) parent pa who is itself left child of (black) grandparent gpa; there
are four such methods for the four possible left/right combinations. The type
parameters to Red and NeBlack indicate that these have indeed types that fit
this scenario. The result type of the rotation is a red-black tree of height n + 1
and will thus implement the corresponding DeepTree interface.
Class Black has also four goXY methods which in its case (when t is black)
will not require tree rotations.
The reason for the call of embed is the earlier mentioned problem that Java
does not allow us to specify that B is a subtype of O; to avoid this call the method
definition could have been duplicated to the more specific classes Singleton and
DeepRed where this subtype relationship is established.
In class Red this method creates two fresh nodes of height n+1 (one black, one
red), and abandons two red nodes of height n. An implementation of red-black
trees in which these nodes have the same types could reclaim the abandoned
ones instead of allocating new memory.
These four goXY methods deal with (potential) insertion overflow, i.e. when
an insertion into a black tree might not result in another black tree, in a context
where a black tree is required. The classes also have methods that deal with
deletion underflow, i.e. when the deletion from a black tree results in a black
tree of lower height. These are more complex, because the trees involved in the
required rotation are of different heights.
8
Deletion
When the root node of a subtree is earmarked for deletion, the deletion process
attempts to replenish that node with the nearest node to it from one of its
subtrees (in the actual code it is always the left child, but this is not important),
in order to keep the effect of deletion local. This attempt can go wrong in one
of two different ways:
– the subtree in question could be empty
– otherwise, the removal of that nearest element might make the subtree underflow, i.e. reduce its height
178
The first of these problems goes away if the strategy is only applied to red trees
of height n + 1, and black trees of height n + 2; the second problem goes away
for trees lower in height. This case distinction is the reason for the chosen class
hierarchy.
In its most elementary form a tree underflow arises when the only node of a
black tree of height 1 is removed. Deletion underflow is propagated up the tree,
until either a red node is encountered which can absorb the underflow, or the
root is reached — in which case the overall tree shrinks in height.
Generally, the methods for underflow propagation/absorption are more complex than the methods that deal with insertion overflow, because at absorption
point tree nodes from three different height levels are involved. An example for
g
r
g
u
z
r
b
x
b
u
x
y
z
y
Fig. 3. Absorption of deletion underflow
the absorption process is in figure 3: a deletion has taken place in the left branch
of black tree g (of height n + 2). The returned result is b, a black tree of height
n — the deletion in this branch has underflown. An attempt to absorb the underflow is made by calling a method absorbL on u, the right child of g. As it is
black, it cannot itself absorb the underflow, but it makes a 2nd-level absorption
attempt, by calling absorbL2 on its left child r.
In this case r is red, and can therefore absorb the deletion underflow by
creating the tree fragment on the right, which is a tree of the same height as the
original tree. The corresponding code for r sits in class Red:
public Grey<T,NeBlack<T,B,I>,DeepTree<T,B,I>>
absorbL2(B un,DeepBlack<T,B,I> gpa,NeBlack<T,B,I> pa){
pa.le=ri.embed();
T aux=gpa.co; gpa.co=co;
gpa.le=un.mkBpair(aux,le);
return gpa;
}
179
One could slightly improve the efficiency of this, as it is not really necessary to
create a fresh black node: an abandoned black node of the right height still sits
at gpa.le, though the types do not tell us that it does.
Notice that the result type of absorbL2 is an instance of Grey, an interface
that allows for potential deletion underflow. In this case, there was no further
underflow, but all non-empty black trees of height n + 1 implement the Grey
interface at height n, so returning gpa is well-typed.
However, the type indicates that a further deletion underflow would have
been possible. Had r been black then the absorption attempt would have failed,
with the situation as in figure 4: In this case, the node r is paired with b, creating
g
u
u
b
r
z
g
z
b
r
Fig. 4. Propagation of deletion underflow
a new red node as the left child of u. The overall result would have been u, a
black tree of height n + 1 — and therefore the overall result in this section of the
tree is another underflow. However, even underflow has a height attached to it,
as is apparent in the absorbL2 method of class Black which produces this tree
fragment:
public Grey<T,NeBlack<T,B,O>,DeepTree<T,B,O>>
absorbL2(B un,DeepBlack<T,B,O> gpa,NeBlack<T,B,O> pa) {
pa.le=un.mkPair(gpa.co,self());
return new Underflow<T,NeBlack<T,B,O>,
DeepTree<T,B,O>>(pa);
}
As pa (the u in figure 4) is a non-empty black tree, it does implement the
Grey interface; however, it implements it at height n, and the signature of the
absorbL2 method requires a grey of height n + 1. Therefore a new underflow
object is created. The class Underflow is just a wrapper for black trees that are
“too low” in height. It implements the Grey interface, which solely consists of
methods for attempting to place a deletion result back into a parent context.
The method that triggered the absorption attempts in figures 3 and 4 is the
method putL, implemented by Underflow as follows:
180
public Grey<T,NeBlack<T,B,O>,DeepTree<T,B,O>>
putL(DeepBlack<T,B,O> pa) {
return pa.ri.absorbL(body,pa);
}
The tree body is a field of Underflow; it is that mentioned “too low” black tree.
The reason this wrapper class is needed is that method selection is not informed
by the type parameters of generic classes. Thus we could not make a black tree
class implement two different type instances of the Grey interface, i.e. one where
the heights match and the parent node can be updated, and one where they are
one level out of step and the absorption methods are called.
9
Java Language Issues
In the process of developing this application a number of problematic issues
about various details in Java Generics were encountered. Only some of them
remain nuisances for the final version of the red-black tree implementation, but
the other issues remain worth discussing anyway.
Beside language issues, there were also problems with the compiler, e.g. certain type dependencies made it crash, and some complex class/interface relations
were unjustly rejected, but this section focuses on language design issues only.
Already mentioned earlier were the problems that it is impossible to specify
subtype relationships between type variables, and that generic methods cannot
implement non-generic ones. It is not easy to see how the second of these ideas
can be sensibly incorporated into Java, but the first one should be possible and
worthwhile to do.
A number of further issues are dedicated a subsection each:
9.1
Type Abbreviations
Java has no feature to abbreviate type expressions. Before generics there was
very little need for that, although import clauses also have a name-abbreviating
effect and purpose.
Within generics, type expressions can grow to rather unmanageable levels.
Earlier we have seen the return type of absorbL2 barely fitting onto a single line,
and this is a return type quite a few methods share. It is possible to introduce
a shorter name by simply subclassing a type expression. This is indeed one of
the reasons for providing the (not strictly necessary) class DeepBlack; without
this subclass, all methods mentioning DeepBlack<T,B,O> in their parameter list
would have to replace each occurrence of this type by the rather unwieldy:
NeBlack<T,NeBlack<T,B,O>,DeepTree<T,B,O>>
However, abbreviating a type expression through subclassing still introduces a
proper subclass instead of an alias, and this can create problems — which is
why the same technique has not been used for example for the return type of
methods such as absorbL2.
181
Thus, the author proposes the following Java extension: permit inner class
declarations like the following:
private class DG =
Grey<T,NeBlack<T,B,O>,DeepTree<T,B,O>>;
This should introduce DG as an alias for the type expression on the right-hand
side, i.e. it should be freely exchangeable with that type expression. Of course,
this would not be necessary if Java had a macro language.
9.2
GADTs with closed world assumptions
The issue of not always being able to use subclassing for type abbreviations also
points to a subtle distinction between GADTs Haskell-style and their realisation
in Java: GADTs come with a closed-world assumption, in that the values formed
with their constructors are the only values of their defined type.
Going back to the vector example from section 6, values of type Vector a
(S k) can only be formed using the constructor Cons. In the Java realisation of
this type, nothing would stop us from defining a third subclass of vectors which
also extends Vector<A,S<K>>. This distinction can be rather irksome. We may
have code that produces a Vector<A,S<K>>, and we have written Cons as the
only instance of that class, and yet they are only assignment-compatible in one
direction (unless we resort to casts).
Looking at it differently: in Java we can only place code at a generic class
when all its generic parameters are uninstantiated. In order to place code at a
class like Vector<A,S<K>> we have to subclass Vector with its second parameter instantiated to S<K> and place the code at that subclass. This leaves the
possibility of other subclasses of Vector<A,S<K>> that may not provide such
code. Potential discrepancies of this ilk have complicated the red-black tree implementation tremendously, as precise type information needs to be threaded
through various class interfaces to make types fit.
There is not an obvious Java language extension that fits into the Java system
and permits such behaviour, which is unfortunate as in practice this is probably
the biggest obstacle in the usability of this approach.
10
Conclusions
On the example of red-black trees this paper has shown how properties such
as tree-balancing can be expressed within Java Generics, to the extent that
the type-checker will guarantee the data invariants. The ideas are known from
functional programming but have been adapted for a better fit to Java’s features.
In contrast to functional programming, the inability to place code at an instantiated class (without introducing a fresh subclass) is extremely inconvenient
in this setting: the resulting potential type incompatibilities have to be counteracted by extending generic parameter lists throughout the implementation.
182
Some of the implementation comes with a performance penalty: each object
has a fixed invariant in this setting. Therefore, object reuse is restricted to situations with the same invariant; instead of changing the invariant of an object
a fresh object with different invariants would have to be created that takes its
place. In particular, this applies to some of the objects involved in tree rotations.
One can use the height-verified code as the basis for a more efficient (but
still recursive) implementation of red-black trees that eliminates this overhead.
This involves mostly fine-tuning tree-rotation methods by reclaiming memory
we know will become free. While this can be seen as a program transformation,
it is one informed by global assumptions about the memory such as single use
of tree pointers, and thus goes beyond mere refactoring.
Expressing red-black tree balancing tests Java Generics a fairly long way,
and so this journey discovered a few deficiencies of Java Generics, which leads
the paper to make several suggestions for improvements.
References
1. Bracha, G.: Add Generic Types to the Java Programming Language. Technical
Report JSR-000014, Sun Microsystems (2004)
2. Hinze, R.: Constructing red-black trees. In: Workshop on Algorithmic Aspects of
Advanced Programming Languages, Paris (1999) 89–99
3. Kahrs, S.: Red-black trees with types. Journal of Functional Programming 11(4)
(2001) 425–432
4. Bracha, G., Odersky, M., Stoutamire, D., Wadler, P.: Making the future safe for
the past: Adding genericity to the Java programming language. In Chambers, C.,
ed.: ACM Symposium on Object Oriented Programming: Systems, Languages, and
Applications (OOPSLA), Vancouver, BC (1998) 183–200
5. Bruce, K.B., Odersky, M., Wadler, P.: A statically safe alternative to virtual types.
In: ECOOP ’98: Proceedings of the 12th European Conference on Object-Oriented
Programming, London, UK, Springer-Verlag (1998) 523–549
6. Naftalin, M., Wadler, P.: Java Generics. O’Reilly (2007)
7. Bayer, R.: Symmetric binary b-trees: Data structure and maintenance algorithms.
Acta Informatica 1 (1972) 290–306
8. Cormen, T.H., Leiserson, C.E., Rivett, R.L.: Introduction to Algorithms. MIT
Press (1990)
9. Sedgewick, R.: Algorithms. Addison-Wesley (1988)
10. Cardone, F., Coppo, M.: Two extensions of Curry’s type inference system. In
Odifreddi, P., ed.: Logic and Computer Science. Academic Press (1990) 19–76
11. Kfoury, A.J., Tiuryn, J., Urzyczyn, P.: Type reconstruction in the presence of polymorphic recursion. ACM Transactions on Programming Languages and Systems
15(2) (1993) 290–311
12. Kahrs, S.: Limits of ML-definability. In: Proceedings of PLILP’96. (1996) 17–31
LNCS 1140.
13. Jones, S.P., ed.: Haskell 98, Languages and Libraries, The Revised Report. Cambridge University Press (2003)
183
Stefan Kahrs I was in my third semester of Computer Science when BKB joined Uni Bremen, which if my memory is right - was in 1983. I first encountered him when he taught our programming module.
After the Vordiplom I picked a project that was supervised by him, and after graduation in 1986 I became
a Wissenschaftlicher Mitarbeiter of his group - which
amongst other things attached me to the Prospectra
project. Finally I finished my PhD early in 1991, and
in May 1991 I left Bremen. I am now lecturer at the
University of Kent.
Compensating the Computational Bias of
Spreadsheets
Andrea Kohlhase and Michael Kohlhase
German Center for Artificial Intelligence (DFKI)
{Andrea,Michael}[email protected]
Abstract. Spreadsheets are heavily employed in administration, financial forecasting, education, and science because of their intuitive, flexible,
and direct approach to computation. They represent examples for “active documents” which are considered very worthwhile in the field of
Knowledge Management. But these activity traits also lead to usability
and maintenance problems, as spreadsheet-based applications grow evermore complex and long-lived. We argue that these difficulties come from
a fundamental bias of spreadsheets towards computational aspects of the
conceptual models underlying the applications, i.e., a computational bias.
Concretely, we present the software architecture of the SACHS project
geared towards a semantic enhancement of MS Excel spreadsheets that
aims at compensating this computational bias.
This paper contains our view on the foundations of the SACHS project which aims
to extend semantic document modeling to spreadsheets. Bernd Krieg Brückner has
been proposing for years to do this. He always maintained that spreadsheets would
ideal targets for semantic preloading. Indeed our research shows that spreadsheets
are semantically much more interesting than anticipated. Therefore we dedicate this
paper to him as a tribute to his intuitions.
1
Introduction
In 1979 Dan Bricklin and Bob Frankston co-authored the famous first
spreadsheet program: “VisiCalc” [BF79]. Terry Winograd considers the key
innovation of spreadsheet programs to be that they virtualize ledger sheets.
In particular, “spreadsheet virtuality combines the regular structure of the familiar ledger sheet with an underlying structure of interlinked formula” [Win06,
p. 230]. Ledger sheets have been well used in financial accounting scenarios and
as spreadsheets they obtain the additional quality of being computational: the
spreadsheet user can manipulate data directly or via the abstract level of formulas in order to appropriate the data setting, to forecast developments, and to
test financial scenarios.
The management qualities led to wide spread use and reuse of spreadsheets
(see [AE06] and its references for a discussion). But unfortunately, the intensity
with which they were used yielded more and more complex documents intended
185
to be shared among people who needed to understand the same (or similar) data
sets. In turn, this very complexity now often results in errors on the data level
and misinterpretation or misapprehension of the underlying model.
The work reported here originates in the SACHS project (Semantic Annotation
for a Controlling Help System) at the German Center for Artificial Intelligence
(DFKI), Bremen. It addresses the usability problem that even though MS Excel
spreadsheets have the potential to serve well as an interface for a financial controlling system, DFKI employees experience them as too complex in practice —
even longtime users cannot interpret all data and are not certain about their origins. A controlling system is a means for the organization to control finances, i.e.,
to understand profits and losses and draw conclusions, thus a lack of overview
hampers the process: if users are not sufficiently informed they cannot optimize
the next data to be gathered.
A key observation in our approach to solving these usability problems is that
spreadsheets are active documents, we take this to mean that they are documents
whose surface structure can adapt to the environment and user input. “Activeness” in documents can only be realized by making some of the relations between
the underlying objects explicit to the software layer presenting the document. In
the case of spreadsheets these relations are given as the spreadsheet formulae. In
this paper we take a foundational stance and analyze spreadsheets as “semantic
documents”, where the formula representation is only the computational part of
the semantic relations about how values were obtained. In this sense the focus on
the computational aspects constitutes a bias towards computational aspects in
spreadsheets. In particular, spreadsheets disregard other semantic relations that
are important for understanding and relegate them to informal treatment, which
we claim accounts for a good part of the usability problems lamented above.
To compensate the diagnosed computational bias we propose to augment the
two existing semantic layers of a spreadsheet — the surface structure and the
formulae by one that makes the intention of the spreadsheet author explicit. In
the SACHS project we encode the intention as an accompanying OMDoc [Koh06]
document and can thereby provide multi-layered, semantic help services.
2
Semantic Layers in Spreadsheets
Instead of developing the general theory, we will expose the salient parts of our
approach using Winograd’s example spreadsheet from [Win06] (re-represented
in MS Excel in Figure 1) as a running example. We will differentiate the three
semantic layers in turn and draw conclusions viewing this spreadsheet as both
an active and a semantic document.
2.1
Active and Semantic Documents
We call a document semantic, iff it contains an infrastructure that distinguishes
between content and form. Note that such an infrastructure can range from superficial styling information in PowerPoint slide masters or LATEX document
186
Fig. 1. A Simple Spreadsheet after [Win06]
classes, over RDFa [W3C08] annotations in web pages to formal logic specifications of program behaviors. The idea is that this infrastructure makes relations
between the objects described in the document explicit, so that they can be
acted upon by machines. In particular, semantic documents can be interpreted
by “presentation engines” that operationalize the semantic relations by allowing
the reader to interact with various aspects of the semantic properties. We call the
combination of a semantic document with a presentation engine that can adapt
the surface structure of the document to the environment and user input an active document. Our definition is between the concept of embedding semantic
networks into hyper-documents employed by Gaines and Shaw in [GS99] and
the rather visionary notion of documents that can answer arbitrary questions
about their content proposed by Heinrich and Maurer [HM00]. Crucially both
presuppose some kind of content representation in or near the document and a
suitable “presentation engine”.
For the purposes of this paper, we will neglect the fact that most presentation engines also incorporate editing facilities and concentrate on the interaction with active documents for reading and exploration. This view is similar to
what [UCI+ 06] call “intelligent documents”.
A paradigmatic example of an active document is a Mathematica notebook [Wol02], where equations and mathematical objects can be inspected, visualized, and manipulated by the user. Here, the semantic document is written in
the Mathematica markup language which includes a content markup scheme
for mathematical formulae and a high-level programming language. The presentation engine is the Mathematica front-end which presents interactive documents to the user and calls the Mathematica kernel for evaluation of program
fragments and computation of mathematical properties.
Spreadsheets are another paradigmatic class of active documents. Here the
semantic document contains representations of the cell values or formulae together with display information such as cell color, font information, and current
viewport. The presentation engine is a spreadsheet program like MS Excel, which
187
presents the semantic document to the user by giving it a grid layout and recalculates values from formulae after each update. But what is the underlying
semantic model, i.e. what is the “activeness” of spreadsheets based on?
2.2
The Surface/Data Layer
If we look at the example in Figure 1, we see that the grid of cells can be
roughly divided into three areas. The darker, ochre area in the center contains
values of actual and past expenses and revenues; the lighter, yellow box on the
right contains values projected from these. The white region that surrounds
both boxes supplies explanatory text or header information that helps users to
interpret these numbers. Generally, non-empty cells that do not contain input or
computed values usually contain text strings that give auxiliary information on
the cells that do; we call these cells collectively the legend of the spreadsheet,
since they serve the same purpose as the legend of a map.
Observe that row 17 displays the central values of the spreadsheet: the
profit/loss situation over time (i.e., in the years 1984-1988 as indicated by the
values in row 4). Moreover note that the meaning of the values in row 17 is that
they represent profits and losses as a function π of time: recall that a function is
a right-unique relation — i.e., a set of pairs of input values and output values.
In our example the pair 1984, 1.662 of values of the cells [B4] and [B17] is one
of the pairs of π. We will call such a grid region a functional block, and the
function it corresponds to its intended function. Empirically, all non-legend ,
semantically relevant cells of a spreadsheet can be assigned to a functional block,
so we will speak of the functional block and the intended function of a cell.
In the general case a functional block consists of multiple rows and columns:
if it represents a binary (i.e., two-argument) function, then its values depend on
two (main) parameters which are usually in the cells of the column on the left
and the row on top of the block. We will call the cell ranges of arguments of the
function of a block its input row/column. In our example the block with cells
[B9:D13] ranges over expense categories (given in [A9:A13]) and years (given in
[B4:D4]) and therefore represents a binary function.
Of course the actual values can also depend on more parameters, but these are
given lower salience by the restriction to a two-dimensional grid. Alternatively, an
n-ary function is split up into a sequence of binary functions and the spreadsheet
grid contains blocks for all of these. If a functional block has only one row or
column, then it represents a unary (i.e. one-argument) function, and in the case
where it only consists of a single cell, it represents a constant (i.e., a function
without arguments).
Our notion of a functional block is related to, but different from Abraham
and Erwig’s of a “table” [AE04,AE06], which also contains row and column
header and footer blocks. Our functional blocks roughly correspond to their
“table core”, whereas we would consider their header blocks as input blocks or
legend cells (but there may be non-header input blocks in our model) and their
footer blocks which contain aggregation cells as separate functional blocks.
188
2.3
The Formula Layer
A spreadsheet cell c may not only be associated with a simple data item (or
value) [[c]], it may also be connected with a formula [[[c]]], i.e., an expression built
up from constants, an extended set of numeric and logic operators, and references
to other cells, which evaluates to the cell value. Without loss of generality we
assume that cells with a constant value given by the spreadsheet author carry
the pseudo-formula input.
In our example, the value of π can be computed from the yearly revenues in
R: = [B6:F 6] and the total expenses in E: = [B15:F 15] by a simple subtraction,
the total expenses can in turn be computed by summing up the various particular
expense categories listed in cells [A9:A13].
Note that the formulae of cells in a functional block have to be “cp-similar ”
[BSRR02], i.e., they can be transformed/copied into each other by adjusting the
respective rows and columns. We call a functional block computed if all of its
formulae are cp-similar. In our example, the functional block P: = [B17:F 17] is
computed: let γ range over the columns B to F in P. Note that the formulae
[[[γ17]]] = γ6 − γ15 in cells [γ17] are indeed cp-similar. Together, they make up
the function
F(P): = {[[γ6]], [[γ15]], [[γ17]]|γ ∈ {B, . . . , F }}
We call F(P) the function induced by the (formulae in) block P. But we also
observe that not all functional blocks in a spreadsheet are computed, for instance
the block [B9:D13] only has the pseudo-formula input, since all the values are
provided by the spreadsheet author. We call such blocks data blocks and note
that the property of being a functional block only depends on a functional correspondence (a conceptual aspect of the data) and not on the existence of formulae
(a property of the spreadsheet).
With spreadsheet formulae, users can express data dependencies on a generic
level, so that the spreadsheet program can do much computational work in the
background. By this virtualization of the traditional ledger sheet (see above),
the user’s role is lifted to a layman programmer and offers according potential.
But Abraham and Erwig report an error rate of up to 90% (!) in spreadsheets [AE06], which shows that this potential comes with a substantial risk.
They analyze the source of many of these errors to be in a mismatch between
what the spreadsheet author wants to express and the formulae he writes. They
try to address this situation by static analysis techniques (type checking) of the
formulae and supplying the author with “spreadsheet templates”. To understand
this mismatch better, let us now turn to the model the author intends to convey.
2.4
The Intention Layer
Note that even though F(P) and π compute the same values, they are completely
different functions. π is defined via the actual or projected profits or losses of
an organization, while F(P) is a finite, partial binary arithmetic function. Even
when we compose F(P) with F(R) and F(E) and restrict them to the years
189
1984-86 yielding F: = F(P) ◦ F(R), F(E)[[B4:D4]] , the functions F and π are
only extensionally equal (they are equal as input/output relations) and still differ
intensionally.
Surprisingly, only F is explicitly represented in the spreadsheet of Figure 1,
moreover, this explicit representation is invisible to the user if she doesn’t look
at the formula boxes — thus, leaving the user to figure out the ‘intention’ (the
function π) from the implicit information given in the white part by herself. This
is why we speak of a computational bias of spreadsheet programs, as some
layers of the semantics are explicated but others are not.
Generally, we can assume that spreadsheet program authors use spreadsheets
to express and compute (measurable) properties of situations; if we look a little
closer then we see that these are not properties of the world as such, but of a
high-level, abstract, or mental model of the world, which we subsume under the
term intention of the spreadsheet. In our example, the function π could be
seen as a concept from the intention, whereas the function F can be seen as its
implementation. In our simple example the intention is easy to deduce from the
text in the legend and basic financial accounting knowledge.
But even here, some parts of the spreadsheet’s intention remain unclear: e.g.
for what company or department are the profits and losses computed or what are
the methods of projection for the years 1987/8. Let us now take stock of what
the cells in the spreadsheet mean and what information we need to infer from
this. As we already remarked above, the values of cells [B17:D17] are (the scalar
parts of) the actual profits/losses in the years 1984-1986. We need information
from cell [A3] for the unit of measurement, from cells [B3:D3] that they are
actual, and from [A17] for the interpretation as a ‘profit/loss’. To understand
the full meaning of these cells, we also need to know about profits and losses of
companies — e.g. that high profits of a company I am employed by or that I
own stock in are good for me, the fact that the company is based in the USA
and therefore calculates finances in US$, and that values that are actual are
computed from measured values. Finally, we need to know that the profit/loss
of an organization over a time interval is defined as the difference between its
revenues and expenses over this interval. This knowledge allows to compute the
values of cells in P with the respective formulae from the values of cells in R ∪ E
(i.e., using the function F). The values of the cells in E can be similarly computed
from the values of the cells [B9:D13]. Note that while the definition of profits
and losses above is general accounting knowledge, this definition is particular to
the respective company, as the applicable expenses vary with the organization.
A similar account can be given for the projected profits/losses in cells [E17:F 17],
only that the interpretation of the cells wrt. the intention is even more difficult — even though the situation is simple if taken at face value. Cell [[E17]]
is the projected profit in the year 1987, which is computed from the revenue
and expenses in column E. But in contrast to the values in the actual block
[B6:D6] ∪ [B9:D13], the values in the projected block [E6:F 6] ∪ [E9:F 13] are
not measured, but projected from the actual values by some financial forecasting
method that is reflected in the respective formulae. Note that the correspondence
190
of the formula need not be as direct as in the case of the total expenses above.
It might be that the forecasting method is defined abstractly, and the concrete
formula is derived from it making some simplifying assumptions. Furthermore,
we need to know what assumptions the forecasting method makes, what parameter values are employed and why, how reliable it is, etc. to fully understand the
values. All of these concerns are not addressed at all in the spreadsheet as an
active document. Abraham and Erwig describe this as follows:
There is a high level of ambiguity associated with spreadsheet template
inference since spreadsheets are the result of a mapping of higher-level abstract models in the user’s mind to a simple two-dimensional grid structure. Moreover, spreadsheets do not impose any restrictions on how the
users map their mental models to the two-dimensional grid (flexibility is
one of the main reasons for the popularity of spreadsheets). Therefore the
relationship between the model and the spreadsheet is essentially manyto-many [...].
[AE06,
p. 5]
3
Compensating the Computational Bias
Our analysis of the example above has shown us that large parts of the intention
of a spreadsheet is left implicit, even though it is crucial for a user’s comprehension. In particular, a user needs to know the following for a spreadsheet:
– The ontology1 , i.e., background information about relations between concepts and objects of the intention. The objects in the intention include the
functions represented in the spreadsheets e.g. π, their properties, e.g. the
units of their arguments and values, and thus of the values in the cells.
– The provenance of data in a cell, i.e., how the value of this data point was
obtained, e.g. by direct measurement, by computation from other values via
a spreadsheet formula, or by import from another source; see [MGM+ 08] for
a general discussion of provenance.
– The interpretation, i.e., a correspondence between functional blocks and
concepts or objects of the intention. We distinguish three parts here
• The functional interpretation, that specifies the intended function of
the functional block.
• The value interpretation, i.e. a bijective function that specifies how
to interpret the values of the block cells as ontology objects.
• The formula interpretation that links the formulae of a block to an
object in the ontology. This mapping must be a refinement in the sense
that the interpretations of proper formulae compute the same value as
the formulae itself and the pseudo-formulae input is mapped to a provenance object.
1
In this paper we use the word “ontology” in its general, philosophical meaning as
the study of the existence of objects, their categories and relations amongst each
other, and not in the Semantic Web usage, where it is restricted to formal systems
with tractable inference properties (description logics).
191
In some spreadsheets that are the digital equivalent to “back-of-the-envelope
calculations”, the interpretation, provenance, and ontology information is simple
to infer, so that the un-documented situation is quite tolerable. Indeed this shows
the cognitive strength of the table metaphor, in our example it is no problem for
the human reader to interpret the legend item “(in Millions)” as a specification of
the value interpretation of the cells [B6:F 17] (but not of the years Y: = [B4:D4]).
In many cases spreadsheets have developed into mission-critical tools that
are shared amongst whole departments, because they encapsulate important,
non-trivial, institutional knowledge. The intention of such spreadsheets is much
harder to infer, a fact that is witnessed by the fact that companies spend considerable energy to train employees in the usage (and intention) of such spreadsheets.
In this situation, it would be natural to extend the activity of spreadsheets
to support the user’s comprehension of the spreadsheet intention. Thus, in light
of the discussion of Section 2.1, we suggest to compensate for the computational bias diagnosed above by extending the underlying semantic document of
a spreadsheet. Concretely, we propose to represent the intention (as the provenance and ontology) and to tie the cells in the spreadsheets to concepts in the
intention (via an interpretation function).
3.1
Fixing the Ontology
We have (at least) two possibilities to extend spreadsheets with an ontology
and provenance component: we can either extend spreadsheets by ontology and
provenance facilities or we can extend them by interpretation facilities that reference external representations of the intention. As we have seen above, the
intention contains quite a lot of information, and making it explicit in a software
framework means a large investment. Therefore we contend that an external
representation of the intention is more sensible, since it can leverage pre-existing
tools and profit from interoperability.
We use the OMDoc format (Open Mathematical Documents, see [Koh06]) to
represent the intention model. OMDoc is an XML-based format for representing
semi-formal, semantically structured document collections. It allows to factorize knowledge into “content dictionaries” that serve as constitutive contexts for
knowledge elements. OMDoc provides a mathematically inspired infrastructure
for knowledge representation: document fragments are classified by their epistemic role as e.g. axioms, definitions, assertions, and proofs and mathematical
formulae are represented in the OpenMath [BCC+ 04] or MathML [ABC+ 03]
formats. Furthermore, OMDoc provides a strong, logically sound module system based on structured “theories” (content dictionaries extended by concept
inheritance and views) [RK08]. Finally, the language has been extended to deal
with units and measurable quantities [HKS06] as a prerequisite for interacting
with the physical world. We make use of all of these features for modeling the
intentions of spreadsheets. In contrast to other ontology modeling languages like
OWL [MvH04], the OMDoc format does not commit to a formal logical language, and therefore lacks a native concept of inference but also does not force
192
the author to fully formalize the spreadsheet intention and to work around the
expressivity limitations of the underlying logical system. Instead, OMDoc allows
to locally formalize elements — and thus provide partial inference — with whatever formal system is most suitable; in our application, we mainly use an formal
system for arithmetics as a counterpart for spreadsheet formulae.
For the intention model in our example we divide the background knowledge
into theories that inherit functionalities from each other via the imports relation.
At the very basis we would have a content dictionary Revenues that defines the
concept of the revenue of an organization over a time interval. This theory defines
the concept of a binary revenue function ρ, such that given an organization o and
a natural number n the value ρ(o, n) is the revenue (as a monetary quantity) of
o over the span of the year n (AD) in the Gregorian calendar. Note that we use
this very naive notion of revenues for didactic purposes only. For instance ρ was
chosen as a binary function to highlight that there is no automatic agreement
between functional correspondences in the table and objects of the intention.
We would be perfectly free to analyze the concepts more thoroughly, embarking
into representing monetary systems, theories of time, etc. For the purposes of
this paper, we assume that we can either appeal to the intuition of the user or
inherit these representations from a suitable foundational ontology.
In the same way we proceed with a content dictionary Expenses, which imports from a content dictionary Salaries. Finally, we build a content dictionary
Profits that imports from both. In the OMDoc document pictured in Figure 2
we have summarized some of the relevant content dictionaries and the concepts
they introduce.
3.2
Fixing the Provenance
We enrich our ontology with provenance information: As we have required the
formula interpretation to be a refinement, we need to represent an abstract
notion of spreadsheet computation in the ontology. This can be readily done
making use of e.g. the CASL libraries [CoF04]. For modeling the provenance of
user inputs in spreadsheets, we can be extremely minimalistic, just establishing
a stub content dictionary that lifts the concept of “user input” to the ontology
level. But in our example we can already see what a more elaborate provenance
model could give us: We could specify that the salary values in [B9:F 9] are not
only user inputs, but really manually copied over from another spreadsheet —
the top spreadsheet “Salaries” in Figure 2. To take advantage of this (see details
in the next section) we have to develop content dictionaries for provenance,
adapting and extending first formalizations reported on in [MGM+ 08]. As this
goes beyond the scope of this paper, we leave this to future work.
3.3
Fixing the Interpretation
To interpret the cells in P for example, we need to
193
– fix the functional interpretation: Identify that P and R form functional
blocks with input row Y.
In Section 2.2 we have already discussed the functional interpretation of P:
it is just the intended function π. Similarly, we link the revenues block R
with a unary function ρ(c, ·), where c is the representation of our example
company. Then we have to express the semantic counterpart of the spreadsheet formulae. In our OMDoc format we can simply represent this function
as λy.ρ(c, y) in OpenMath or MathML.
– fix the value interpretation: In our example we observe that the values in
P are actually only the scalar parts of measurable quantities, in this case
measured “in millions” (of US$ presumably) according to the spreadsheet
legend. Similarly, the (string) values Salaries, Utilities, . . . in [A9:A13]
have to be interpreted as objects in the ontology. Thus in our example,
we choose i: = {y "→ y(AD)} as the value interpretation of block Y and
j: = {x "→ 106 xUS$} for block P; obviously both are bijective.
– fix the formula interpretation: our example the formulae γ6 − γ15 in the
functional block P would be linked to the formula π(year) = ρ(year) −
(year) in the FMP element of the Profit/Year definition. Furthermore, we
would link R to a semantic provenance object “imported from Salaries.xsl”.
In Figure 2 we show the functional interpretation mappings as red, dotted arrows and the formula interpretation as purple, dot-dash-arrows. The totality
of cell interpretations induces a set of content dictionaries that is associated
with a spreadsheet, we call these content dictionary the intention model. Note
that we can see the intention model as a representation of the intention of this
spreadsheet.
We can think of the value interpretations as parser/generator pairs that mediate between the scalar function represented by the formulae in the spreadsheet and the intended function in the intention — which is usually a function between measurable quantities. In particular the functions F and π are
related via the commutative diagram, where the function F is induced by the
spreadsheet formulae as discussed in Section 2.4 above. We see that the three
components of the interpretation fully
F
specify the correspondence between
spreadsheet
Y
P
functional blocks in the spreadsheet and
−1
j
i
objects induced by the intention model.
year π
profit
To see the strength of this construction
intention
let us return to our example and look
at the import of salaries from Salaries.xsl. There we have a different value
interpretation for the functional block [F 6:F 6]: this spreadsheet does not calculate in millions, so we chose k: = {x "→ xUS$} and get the import functions
k ◦ j −1 = {xUS$ "→ 10−6 xUS$} in the intention and j −1 ◦ k = {x "→ 10−6 x} in
the spreadsheet.
In conclusion we observe that setting the ontology, provenance, and the interpretation of a cell gives us a full and explicit account of its intention, and we
can relegate all further semantic services to the intention model. For instance we
194
Fig. 2. The SACHS Information Architecture and Control/Search Panel
can verify (using inference in the intention model) this part of the spreadsheet
by establishing the equality of j −1 ◦ F ◦ j and ρ(c).
The SACHS system is a work-in-progress add-in for MS Excel (written in Visual Basic for Applications) that aims at providing semantic help facilities for
spreadsheets. Though it has been developed for the DFKI controlling system, it
works for any spreadsheet whose intention has been encoded as an OMDoc document, e.g. our running example, and mash-up information has been provided2 .
We have designed SACHS as invasive technology that extends well-used (and
therefore well-known) software systems from within to overcome usage hurdles —
see [Koh05b] for a discussion. We designed the semantic services in SACHS to allow the user to explore the intention of a spreadsheet from her micro-perspective,
i.e., from her here-and-now. In particular, all semantic help facilities start from
the cell level. Moreover, we tried to implement a processual interaction design,
i.e., a design where the semantic help evolves in a user-steered process.
For services that visualize the intention, the cells in the spreadsheet must
be interpreted, i.e., linked to elements of the accompanying OMDoc document
as e.g. shown in Figure 2. Generally, all cells in a functional block are linked
to an OMDoc definition — the definition of its intended function, while OMDoc assertions justify their formulae. Concretely, for instance, the Dublin Core
metadata element dc:subject of an OMDoc definition can be used as a SACHS
2
We will spare the reader the technical details of this mash-up for lack of space.
195
label for the cell it interprets. MS Excel’s comment functionality is hijacked to
create SACHS comments that draw on the respective dc:description element,
which contains a concise description of the object in question. In contrast, the
CMP element of the OMDoc definition contains a detailed explanation using semantically marked up representations of objects from the intention model. These
can be mathematical formulae encoded as OpenMath objects like the revenue
function ρ or technical terms like “difference” which we have decorated in angle
brackets in Figure 2.
A formula underlying a cell is mirrored in the formula element FMP of the
respective definition in the semantic document (see Figure 2) in the OpenMath
5
format, this allows us to present it to the user in math notation: i=1 i (1984)
is more readable than “=SUM(B9:B13)”.
Fig. 3. Navigating the Spreadsheet Intention
3.4
Semantic Services in SACHS
In Figure 2 we have already shown the main control panel of the SACHS system
in the right bottom hand corner. This allows the user to enable various semantic
enhancements in the spreadsheet and also search the intention semantically.
From a semantic point of view, contextual views of the spreadsheet intention as
the one in Figure 3 are probably most interesting and helpful. Such views allow
a user to understand the connections between spreadsheet cells and background
information. This view aggregates information about
196
– the intention of a cell in terms of the intended function of its functional
block, and the intended arguments.
– how the cell value is computed from the values of its arguments.
– and the intentions of the arguments.
All information points in the pop-up are hyperlinked to their respective sources
in the OMDoc document or in the spreadsheet so that the graph view can also
serve as a meaning-driven navigation tool. In a future version of SACHS, these
hyperlinks could pre-instantiate the intention model with the argument values
and allow an exploration from the view of the current cell — in our example in
Figure 3 the intention specialized to the year 1984. Note that our example here
only shows the situation for a formula-computed cell. For other provenances,
the pop-up would visualize the provenance object given by the formula interpretation. For instance, for cell [B9] the provenance object is “imported from
Salaries.xls[B5]”, so we can visualize the data from that cell using the existing
SACHS pop-up.
As OMDoc is organized by theories, the provision of multi-level theory graphs
as in the CPoint system [Koh05a] are nice-to-have services one can think of.
4
Conclusion and Outlook
We have analyzed the reasons for users’ difficulties in understanding and appropriating complex spreadsheets, as they are found e.g. in financial controlling
systems. We claim that the ultimate cause is that spreadsheets are weak as active
documents, because their underlying semantic documents are biased to computational aspects and fail to model the provenance, interpretation, and ontological
relations of the objects and concepts operationalized by the system. To remedy
the situation we propose to explicitly model the intention of a spreadsheet as
an intention model in a collection of OMDoc content dictionaries which serve as
an explicit knowledge base for the spreadsheet. Finally, we present the work-inprogress SACHS system that draws on such an intention model to offer various
semantic services that aid the user in understanding and interacting with the
spreadsheets.
In essence, our approach makes double use of the following duality identified
by Fensel in [Fen08]
– Ontologies define formal semantics for information, consequently allowing information processing by a computer.
– Ontologies define real-world semantics, which makes it possible to
link machine processable content with meaning for humans based on
consensual terminologies.
In the analysis we look at the formal semantics of spreadsheets and find a computational bias that hampers understanding since it fails to model consensual terminologies and therefore leads to real-world usability problems. In our proposed
solution we extend the formal semantics of spreadsheets to draw on explicitly
represented consensual terminologies.
197
While a semantic help system for a spreadsheet-based controlling system was
the original motivation for our analysis, we feel that an explicit representation
of the intention model of a spreadsheet has many more applications: it can be
used for verification of the formulae, for change management along the lines
of [MW07], and automated generation of user-adapted spreadsheets.
Our approach seems to be related to “Class Sheets” [EE05] introduced by
Engels and Erwig. Their class descriptions can also be counted as an external,
structured intention model, which is referenced by an interpretation mapping.
We will have to study the relation to our work more closely, but it seems that
their work suffers the same computational bias as the spreadsheets themselves.
But classes with extensive documentation or UML diagrams might go some ways
towards generating a help system like SACHS.
In the future we plan to extend the repertoire of semantic services of the
SACHS system. For instance, we envision a dual service to the one in Figure 3
which could visualize where the value of a cell is used to get an intuition for the
relevance of a cell value.
At the moment, our approach presupposes that the spreadsheet author documents the spreadsheet intention as an OMDoc document and also annotates the
spreadsheet with interpretation information. Both tasks place a heavy burden on
the author and currently restrict our approach to mission-critical or extremely
complex spreadsheets. But we expect the burden of specifying the ontology to
decrease as more and more OMDoc content dictionaries for common models
(e.g. standard accounting techniques) appear. For the interpretations, we plan
to adapt techniques of header, unit, and template inference [AE04,AE06] to
partially automate the annotation process via suggestions.
But future extensions are not limited to spreadsheets. Note that the semantic analysis in Section 2 is largely independent of the computational information
that is at the heart of spreadsheets. The semantic information we are after only
pertains to the use of data grids as a user interface to complex functions. In
the future we plan to generalize the intention model architecture presented in
Section 3 to the case of data grids — e.g. tables of experimental results or raster
data from satellite images. Moreover, we want to develop a native infrastructure
for representing “data grids” as a user interaction feature in OMDoc: In accordance with the format, the provenance and interpretation functionality would
allow to link grid presentations to their intention without leaving the language.
OMDoc-based systems could then pick up the semantics and offer complex interactions based on them. This would lead to much more general active documents.
We could even turn the approach presented in this paper around and generate
SACHS spreadsheets from OMDoc documents as active documents.
As a theoretical extension, we conjecture that the interpretation mappings
can actually be seen as logic morphisms [RK08], which would allow us to re-use
much of the higher-level OMDoc functionalities based on these.
Finally, we admit that we are still at the very beginning of understanding
the repercussions of viewing spreadsheets as active and semantic documents. We
198
were quite surprised at the depth of meaning in even our very simple example
and are looking forward to further spelunking.
References
ABC+ 03.
AE04.
AE06.
ASK+ 04.
BCC+ 04.
BF79.
BSRR02.
Cla92.
CoF04.
EE05.
Fen08.
GS99.
HKS06.
David Carlisle, Patrick Ion, Robert Miner, et al Mathematical Markup
Language (MathML) version 2.0 (second edition). W3C recommendation,
World Wide Web Consortium, 2003. http://www.w3.org/TR/MathML2.
Robin Abraham and Martin Erwig. Header and unit inference for spreadsheets through spatial analysis. In IEEE International Symposium on Visual Languages and Human-Centric Computing, pages 165–172, 2004.
Robin Abraham and Martin Erwig. Inferring templates from spreadsheets.
In ICSE ’06: Proceedings of the 28th international conference on Software
engineering, pages 182–191, New York, NY, USA, 2006. ACM. doi:http:
//doi.acm.org/10.1145/1134285.1134312.
T. Antoniu, P.A. Steckler, S. Krischnamurthi, E. Neuwirth, and
M. Felleisen. Validating the unit correctness of spreasheet programs. In
26th IEEE International Conference on Software Engineering, pages 439–
448, 2004.
Stephen Buswell, Olga Caprotti, David P. Carlisle, Michael C. Dewar, Marc
Gaetano, and Michael Kohlhase. The Open Math standard, version 2.0.
Technical report, The Open Math Society, 2004. Available from: http:
//www.openmath.org/standard/om20.
Dan Bricklin and Bob Frankston. VisiCalc: Information from its creators,
Dan Bricklin and Bob Frankston. http://www.bricklin.com/visicalc.
htm, 1979.
M. M. Burnett, A. Sheretov, B. Ren, and G. Rothermel. Testing homogenous spreadsheet grids with the “what you see is what you test” methodology. IEEE Transactions on Software Engineering, 29(6):576–594, 2002.
J. Claerbout. Electronic documents give reproducible research a new meaning. pages 601–604, 1992.
CoFI (The Common Framework Initiative). Casl Reference Manual. LNCS
2960 (IFIP Series). Springer, 2004.
Gregor Engels and Martin Erwig. ClassSheets: Automatic generation
of spreadsheet applications from object oriented specifications. In 20th
IEEE/ACM International Conference on Automated Seofware Engineering, pages 124–155. IEEE Computer Society, 2005.
Dieter Fensel. Foreword. In Martin Hepp, Pieter De Leenheer, Aldo
de Moor, and York Sure, editors, Ontology Management: Semantic Web,
Semantic Web Services, and Business Applications, Semantic Web and beyond: Computing for Human Experience, pages 9–11. Springer Verlag, 2008.
Brian R. Gaines and Mildred L. G. Shaw. Enbedding formal knowledge
models in active documents; creating problem-solving documents. Communications of the ACM, 42(1):57–63, 1999.
Eberhard Hilf, Michael Kohlhase, and Heinrich Stamerjohanns. Capturing the content of physics: Systems, observables, and experiments. In
Jon Borwein and William M. Farmer, editors, Mathematical Knowledge
Management, MKM’06, number 4108 in LNAI, pages 165–178. Springer
Verlag, 2006. Available from: http://kwarc.info/kohlhase/papers/
mkm06physml.pdf.
199
HM00.
E. Heinrich and H. Maurer. Active documents: Concept, implementation,
and applications. Journal of Universal Computer Science, 6(12):1197–1202,
2000.
Koh05a.
Andrea Kohlhase. Cpoint, 2005. http://kwarc.info/projects/CPoint/.
Koh05b.
Andrea Kohlhase. Overcoming Proprietary Hurdles: CPoint as Invasive
Editor. In Fred de Vries, Graham Attwell, Raymond Elferink, and Alexandra Tödt, editors, Open Source for Education in Europe: Research and
Practise, pages 51–56, Heerlen, The Netherlands, November 2005. Open
Universiteit Nederland, Open Universiteit Nederland. Proceedings at
http://hdl.handle.net/1820/483.
Koh06.
Michael Kohlhase. OMDoc – An open markup format for mathematical
documents [Version 1.2]. Number 4180 in LNAI. Springer Verlag, 2006.
Available from: http://omdoc.org/omdoc1.2.pdf.
MGM+ 08. Luc Moreau, Paul Groth, Simon Miles, Javier Vazquez, John Ibbotson,
Sheng Jiang, Steve Munroe, Omer Rana, Andreas Schreiber, Victor Tan,
and Laszlo Varga. The provenance of electronic data. Communications of
the ACM, 51(4):52–58, 2008. doi:http://doi.acm.org/10.1145/1330311.
1330323.
MvH04.
Deborah L. McGuinness and Frank van Harmelen. OWL web ontology
language overview. W3C recommendation, W3C, February 2004. Available
from: http://www.w3.org/TR/2004/REC-owl-features-20040210/.
MW07.
Normen Müller and Marc Wagner. Towards Improving Interactive Mathematical Authoring by Ontology-driven Management of Change. In Alexander Hinneburg, editor, Wissens- und Erfahrungsmanagement LWA (Lernen, Wissensentdeckung und Adaptivität) conference proceedings, pages
289–295, 2007.
RK08.
Florian Rabe and Michael Kohlhase. A web-scalable module system for
mathematical theories. Manuscript, to be submitted to the Journal of
Symbolic Computation, 2008. Available from: https://svn.kwarc.info/
repos/kwarc/rabe/Papers/omdoc-spec/paper.pdf.
UCI+ 06.
Victoria Uren, Philipp Cimiano, José Iria, Siegfried Handschuh, Maria
Vargas-Vera, Enrico Motta, and Fabio Ciravegna. Semantic annotation for
knowledge management: Requirements and a state of the art. Web Semantics: Science, Services, and Agents on the World Wide Web, 4(1):14–28,
Jan. 2006.
W3C08.
Rdfa primer. http://www.w3.org/TR/xhtml-rdfa-primer/, 2008. Available from: http://www.w3.org/TR/xhtml-rdfa-primer/.
Win06.
Terry Winograd. The spreadsheet. In Terry Winograd, John Bennett,
Laura de Young, and Bradley Hartfield, editors, Bringing Design to Software, pages 228–231. Addison-Wesley, 1996 (2006).
Wol02.
Stephen Wolfram. The Mathematica Book. Cambridge University Press,
2002.
200
Andrea Kohlhase holds a diploma in Mathematics
from the Technical University Berlin. After graduation she spent ten years in the software industry, but
came back to academia via a research programmership at Carnegie Mellon University, Pittsburgh. She
has finished her PhD at University Bremen in 2008
with Bernd Krieg-Brückner as one of her advisors.
Currently she works as a research associate at the
Bremen Lab “Safe and Secure Cognitive Systems” of
the German Center for Artificial Intelligence (DFKI)
in Bremen, Germany. Her research interest lies in the
field of Human-Computer Interaction, especially Interaction Design with a focus on applications using semantic data. She has developed several software packages offering invasive, semantic applications for MS
Office products, e.g., “CPoint” for PowerPoint or the
semantic help system “SACHS” for Excel.
Michael Kohlhase Michael Kohlhase is Professor
for Computer Science at Jacobs University, Bremen
and Vice Director at the German Research Centre
for Artificial Intelligence (DFKI), Bremen. His current research interests include Automated Theorem
Proving and Knowledge Representation for Mathematics, inference-based techniques for Natural Language Processing, and computer-supported Education.
He has pursued these interests during extended visits to Carnegie Mellon University, SRI International,
Rice University, and the Universities of Amsterdam
and Edinburgh. Michael Kohlhase is recipient of the
dissertation award of the Association of German Artificial Intelligence Institutes (1995) and of a Heisenberg stipend of the German Research Council (DFG
2000-2003). He was a member of the Special Research
Action 378 (Resource-Adaptive Cognitive Processes),
leading projects on both Automated Theorem Proving and Computational Linguistics. Michael Kohlhase
is trustee of the Interest Group Mathematical Knowledge Management, a member of the W3C Math working group and the president of the OpenMath Society
(since 2007).
Formal Management of CAD/CAM Processes
Michael Kohlhase, Johannes Lemburg, Lutz Schröder, and Ewaryst Schulz
DFKI Bremen, Germany
<firstname>.<lastname>@dfki.de
Abstract. Systematic engineering design processes have many commonalities with software engineering, with CAx objects taking the place
of program code. They are, however, currently considerably less formal.
We propose to draw on the mentioned similarities and transfer methods
from software engineering to engineering design in order to enhance in
particular the reliability and reusability of engineering processes. Concretely, we formulate a document-oriented design process that integrates
CAx documents with requirement specifications, and show how to interface a CAD system with program verification workflows, thus allowing for completely formalised development strands within a semi-formal
methodology.
1
Introduction
The engineering design process guides the development of products by describing
methods for solving problems on different levels of abstraction. The product
that comes into being will be described by the requirements list, the function
structure, the priciple solution, and its embodiment design. Within these steps
the degree of concreteness of the solution and the amount of detail increases. The
elements of these forms of representation stand for system elements, which are
linked by dependencies within and across their different levels of abstraction. The
present state of the art regarding CAx object representations does not support
this crosslinking of dependencies. Therefore, e.g. non-embodied priciple solution
knowledge is often shared and stored in the form of hand-made sketches and
oral explanations. In other words, large parts of the engineering process are not
completely representable by embodiment focused CAx systems.
Contrastingly, software engineers have long acknowledged the need for a formal representation of the entire software development process. In particular,
formal specification and verification of software and hardware systems is without alternative in safety-critical or security areas where one cannot take the risk
of failure. Formal method success stories include the verification of the Pentium
IV arithmetic, the Traffic Collision Avoidance System TCAS, and various security protocols. In many cases, only the use of logic-based techniques has been
able to reveal serious bugs in software and hardware systems; in other cases,
spectacular and costly failures such as the loss of the Mars Climate Orbiter
could have been avoided by formal techniques. Norms such as IEC 61508 make
the use of formal methods mandatory for software of the highest safety integrity
intro.tex
432
2009-01-05
16:04:14Z
lutz
202
level (SIL 3). Thus, formal methods will form an integral part of any systematic
methodology for safe system design. The main goal of the present work is to outline how formal methods, hitherto used predominantly in areas such as software
development and circuit design that are inherently dominated by logic-oriented
thinking anyway, can be transferred to the domain of computer-aided design
and manufacture of industrial artifacts (CAx), which is more closely tied to the
physical world1 . Potential benefits for the CAx process include
–
–
–
–
formal verification of physical properties of the objects designed
tracing of (formalised) requirements across the development process
improved control over the coherence of designs
semantically founded change management.
Concretely we want to associate the CAD documents with specifications of their
goals, constraints, manufacturing information, etc. The envisioned extended design process is very similar to the semi-formal software engineering process, where
the software artifact under development is accompanied with and cross-linked to
a series of specification documents that describe its intended purpose and meaning with respect to a background theory that is also provided in the collection
of specification documents.
It is crucial to keep the agile spirit of the robotics component design process,
therefore we need to embed the specification processes into the CAD system
using “invasive technology” [5]. On the other hand, we need to create a formal background theory for the geometric CAD objects in the form of CASL
theories [1].
2
A Document-oriented Process for CAx
The best practices for designing technical artifacts are typically standardized
by the professional societies of engineers to ensure quality. In our exposition
here, we will follow the German VDI 2221 [12], which postulates that the design
process proceeds in well-defined phases, refining an initial idea to a fully specified
product documentation in steps.
We observe that the process is similar to the software engineering process and
that the stages in the design process result in specification documents, as they
are e.g. found in the V-model. In contrast to software engineering approaches
like the V-model, the VDI 2221 (and current practices in engineering design) do
not specify processes to ensure consistency between the design stages or methods
to verify that products actually meet requirements from earlier specifications.
1
caddocs.tex
432
2009-01-05
16:04:14Z
We primarily concern ourselves with constructive aspects of the design process — as
opposed to the aesthetic aspects. The English language does not supply an obvious
label for this aspect of the design process as the term “construction” is already taken
and refers to constructing buildings. We will use the term “systematic engineering
design” to be synonymous to the German field of “Konstruktionslehre” which studies
constructive aspects of design processing in mechanical engineering. The details of
the process are described in [12], we build on [8] for intuitions.
lutz
203
In fact, the VDI 2221 process corresponds only to the left shank of the process
depicted in Figure 1, the quality control process (the right shank in Figure 1 and
the main contribution of the V-model) is left unspecified.
Even in software-engineering methods like the V-model, the quality control
processes are only insufficiently supported by machines, leading to high levels of
personnel costs and human errors. Therefore we propose a process where the design documents are semantically annotated, making relations explicit that were
only implicit before and using this information for extended machine support.
Fig. 1. The V-model of Software Engineering
2.1
The Engineering Design Process
Let us now take a more concrete look into the CAx-based design process. To
make the correspondence between VDI 2221 and the V-model explicit we review
the six2 stages and relate them to the V-model before we illustrate them with a
simple example.
S1 Purpose/Problem: a concise formulation of the purpose of the product to
be designed.
S2 Requirements List: a list of explicit named properties of the envisioned
product. It is developed in cooperation between designer and client and
corresponds to the “User Specification” document in the V-model.
S3 Functional Structure: A document that identifies the functional components of the envisioned product and puts them into relation with each other.
S4 Solution in Principle: a specification of the most salient aspects of the
design. It can either be a CAD design like the one in Figure 4 below or a
hand drawing [8].
S5 Embodiment Design/“Gestalt”: a CAD design which specifies the exact
shape of the finished product.
2
caddocs.tex
432
2009-01-05
In fact, [12] specifies separate stages for determining modular structures and developing their embodiments, which we will subsume in steps S3 and S5
16:04:14Z
lutz
204
S6 Documentation: accompanies all steps of the design process.
Note that most of these design steps result in informal text documents, with
step S5 being the notable exception. In the document-oriented engineering design process we will concentrate on the documents, enhance them with semantic
annotations and link them to background specifications to enable machine support: e.g. requirements tracing, management of change, or verification of physical
properties. Before we do this let us set up our example by considering a rational
reconstruction of the design process of a machinists’ hammer according to DIN
1041.
2.2
The Design of a Hammer
We will now exemplify the stages of the design process of a machinists’ hammer,
as this is a tool familiar to most readers. As the standardization process for hammers is at a very advanced stage, so that most product features are completely
determined by industrial standards, we will present a rational reconstruction of
the design process.
Ideally, the list of requirements of a product should be unambiguous, clear
and complete. This ideal goal is seldom fulfilled in a real life design process. This
is due e.g. to implicit customer wishes, which in fact often are more important
to the market-success of a product than the well-known and explicitly named
requirements.
Explicit Hammer Requirements
E1 The hammer has to fulfill the standard DIN 1041 and all related subsequent
standards, namely: DIN 1193, DIN 1195, DIN 5111, DIN 68340 and DIN
ISO 2786-1.
E2 The handle has to be painted with a clear lacquer over all and with colour
RAL 7011 (iron grey) at 10 cm from the lower end.
E3 Two company logos of 20mm length are to be placed on both sides of the
handle.
Implicit Hammer Requirements In our example this could be:
I1
I2
I3
I4
The
The
The
The
hammer
hammer
hammer
hammer
must be usable for right-handed and left-handed persons.
should be ergonomic.
must fit into a standard tool chest.
shall look strong and matter-of-fact.
The Purpose of a Hammer The first and most important step in setting up a
requirements list is the specification of the purpose of the product. The purpose
describes the intended use of the product solution-neutrally. This is the highest
level of abstraction used within the design process. In the case of a hammering
tool the purpose can be in the form of a very simple definition:
caddocs.tex
432
2009-01-05
16:04:14Z
lutz
205
Fig. 2. Engineering standards affecting machinists’ hammers
A hammer is an apparatus for transmitting an impulse to an object.
Within the scope of a hand-tool in contrast to e.g. a hammer mill the purpose
can be narrowed to:
A hammer is an apparatus for the manual generation and transmission
a defined impulse to an object.
Functional Specification of a Hammer Within the design process, the functional specification is done by setting up the function structure that breaks down
the complex problem into managable smaller subfunctions and represents the
logical interrelationships of the given tasks. As in the design step of naming the
purpose, the function structure is still solution neutral. The aim is to open up a
caddocs.tex
432
2009-01-05
16:04:14Z
lutz
206
preferably broad solution field, which will be narrowed by explicit named criteria
within further steps of the design process.
The function structure as a tool to develop new technical solutions is able
to explain interrelationships within the future embodied product; therefore the
connection between function structure and the given product has to be clear.
Every subfunction can be found within the product, or the product is not a
suitable solution. On the other hand, function structures are not appropriate
as a tool for reverse engineering, because the relation between the embodied
product and the underlying functions is ambiguous.
One possible function structure for the hammer as an apparatus for the
manual generation and transmission of a defined impulse to an object can look
as in Figure 3.
Fig. 3. function structure of a hammer
Fig. 4. A principle solution for a Hammer
The Hammer Principle From the functional specification, we develop a principle solution, which can be found in Figure 4. This solution abstracts from the
caddocs.tex
432
2009-01-05
16:04:14Z
lutz
207
physical traits of the eventual product and identifies the functional parts. For
a hammer, one of these is the handle, here a cylindrical part of the hammer
shaft used for gripping. The fact that it is symmetric/cylindrical is a response
to the requirement E1. The handle is connected to an inert mass (depicted by a
solid ball in Figure 4) which is again connected to an active surface that delivers
the impact on the object. The size and form of the active surface will be determined by the requirement E2. In fact, the principle solution reveals that there
is a second possible active area of the hammer, opposite to the primary one;
Figure 4 shows three variants of the principle solution with differing secondary
active surfaces.
The Embodiment of a Hammer Note that the principle solution is not
a finished design yet, since it abstracts from most of the physical traits of a
hammer, e.g. the dimensions of the shaft and the form of the head, which will be
specified in the embodiment design step. Here, the ultimate three-dimensional
shape and the materials of the product are derived, taking into account material
properties, manufacturability constraints, and aesthetic factors. These can lead
to widely differing final designs (see 5 for examples).
Fig. 5. Embodiments of the Hammer Principle
2.3
A Document-Oriented Design Process
We propose an engineering design process which concentrates on the design documents, semantically enhancing them and linking them to semi-formal specifications, so that quality control can be machine supported. It is crucial to note that
the various design documents necessarily have differing levels of rigour, ranging
from informal and hard-to-quantify requirements like E2 to mathematical proofs
of security-relevant properties e.g. in aerospace applications. Additionally, different product parts and aspects underly differing economic and security-related
caddocs.tex
432
2009-01-05
16:04:14Z
lutz
208
constraints, so that design quality control3 must be supported at various levels of formality. As a consequence we need to encode the design documents in
document formats that support flexible degrees of formality. Therefore we chose
OMDoc (Open Mathematical Documents [6]) as the basis of our work. The
format concentrates on structural aspects of the knowledge embedded in documents and provides a markup infrastructure to make it explicit by annotation.
Crucially for our project, the format supports a fine-granular mixture of formal
and informal elements and thus supports the stepwise migration e.g. from informal user requirements to specifications expressed in formal logics that can be
exported to program verification environments like our HeTS system.
We postulate that most of the design documents only need to be semi-formal
for our design method to be effective. Practical semiformalization in OMDoc is
scaffolded by establishing “content dictionaries” (CDs), i.e. semi-formal, but
explicitly structured documents that specify the meaning of the terms used
in design documents. Incidentally, CDs are also convenient for structuring the
background knowledge involved in engineering design. We call a document semiformal if the relevant meaning-giving concepts are annotated by references to
their CDs, and all defined concepts, model assumptions, and postulates are
marked up as such using an OMDoc-compatible vocabulary.
The OMDoc format provides a strong, web-scalable infrastructure for inheritance and modularization of CD-based knowledge [10] and supports practical
knowledge management processes with a rich tool set [4,7,3,9]. In software engineering and mathematics, the additional effort involved in upgrading design
documents to the semi-formal level is significantly lower than the initial effort
of creating these documents once a basic set of CDs has been established for a
domain. In any case, the semiformalization effort is an order of magnitude lower
than fully formalizing them. We anticipate that this relation will not change by
the generalization of the OMDoc to design documents.
Semi-formal design documents already allow machine support for many common quality control tasks like requirements tracing and management of change
which are based on an explicitly given dependency relation (see [2] for details).
3
Invading SolidWorks
In this chapter we illustrate our formal/semi-formal methodology in design processes by means of an integration of formal methods tools into the widely used
CAD system SolidWorks [11]. The latter serves mainly as a demonstration
platform; our overall approach is sufficiently general to apply equally well to any
other CAD system that provides suitable interfaces.
To obtain a formal representation of CAD documents, we provide a SolidWorks plugin that extracts the constructed objects in the shape of the design
3
solidworks.tex
430
2009-01-05
In our deliberations it is important to distinguish the concept of “quality of design”
from the quality assurance in the production process. We are only concerned with
the former in this paper: our methods are inspired by the software design process,
where production quality problems can largely be ignored.
12:25:12Z
lutz
209
tree, which consists of a tree of objects and constraints relating these objects.
These data are obtained using the SolidWorks API, and are output as an
OMDoc file. This file consists of constants, defined by terms, each representing
a design tree, and of axioms stating the given constraints. Formally, a design tree
is a labeled tree where each node represents a SolidWorks object stemming
from an action or base constructor, recorded as the label of this node, applied
to the SolidWorks objects which are represented by the children of the node.
The representation format of design trees is defined in a content dictionary
containing all actions and base constructors of SolidWorks as constants and
function symbols accessing abstract data types (see Listing 1.1 for a code snippet of this content dictionary in OMDoc format). We base the SolidWorks
content dictionary on the theory of real numbers. The main datatype is then the
type SWObject of objects; these may e.g. be points with 3 real coordinates, arcs,
i.e. sectors of circles given by a start and an end point, a center point, and an
orientation (in the shape of a normal vector), or planes, i.e. 2-dimensional affine
subspaces defined by their normal vector and a point. The type of objects is a
recursive data type — e.g. an extrusion (see Listing 1.1) represents the figure
which results as the space covered by an oriented base object when moved along
or against its orientation (as specified by a direction parameter ±1) for a given
distance.
Listing 1.1. The SolidWorks content dictionary
1
6
11
16
21
<theory xml:id=”solidworks”>
<imports from=”Logic/casl.omdoc” type=”global”/>
...
<adt xml:id=”solidworks−object−adt”>
...
<sortdef name=”SWObject” type=”free”>
<constructor name=”Extrusion”>
<argument>
<type><OMOBJ><OMS cd=’solidworks’ name=”SWObject”/></OMOBJ></type>
<selector name=”From” total=”yes”/>
</argument>
<argument>
<type><OMOBJ><OMS cd=’Reals’ name=”Real”/></OMOBJ></type>
<selector name=”Length” total=”yes”/>
</argument>
<argument>
<type><OMOBJ><OMS cd=’Reals’ name=”Real”/></OMOBJ></type>
<selector name=”ExDirection” total=”yes”/>
</argument>
</constructor>
</sortdef>
</adt>
...
</theory>
In the case study of the next section we will show a concrete example which
illustrates the use of the plugin and how this integrates into the whole development process. The case study is mainly concerned with the verification of
solidworks.tex
430
2009-01-05
12:25:12Z
lutz
210
designs against abstract requirements. Further potential uses of the invasive approach include semantic preloading, i.e. automated rapid prototyping of designs
from abstract specifications, as well as requirements tracing and a closer general integration of specifications and designs e.g. by user-accessible links between
specifications and parts in the SolidWorks design.
4
Case Study: Simple Geometric Objects
One would naively imagine that there is really nothing to verify about a geometric object: a cylinder is a cylinder is a cylinder. But as soon as one starts
using a real CAD system, it becomes clear that the situation is actually more
complex. The mathematical concept of a three-dimensional geometric object is
a set of points in three-dimensional euclidean space, typically described by a
general formation principle and a number of parameters. E.g. in the case of a
(solid) cylinder, the parameters are
–
–
–
–
the
the
the
the
coordinates of some anchor point, say the centre of the cylinder,
spatial direction of the axis,
height h and
radius r,
and the formation principle for cylinders prescribes that these parameters describe the set of points p such that
– p has distance at most r from the axis (regarded as an infinite straight line)
and
– the orthogonal projection of p onto the axis has distance at most h/2 from
the centre point.
On the other hand, the description of a geometric object than can be extracted
from a CAD document will in general take a totally different form: instead of
a point set or the above-mentioned parameters, a CAD system will store the
process involved in drawing an object as a set of so-called features, which are
moreover subject to dependencies (these correspond to what a computer scientist
would call constraints, a term that however is used differently in the context
of CAD). Here, a feature is a very basic, typically one- or two-dimensional,
geometric component which may refer in various ways to other components.
E.g. the process of drawing a cylinder would typically look as follows.
– Create a two-dimensional plane.
– Insert a circle into the plane, described as a circular arc with coincident start
and end points and marked as filled.
– Extrude the circle orthogonally to the plane.
The cylinder is thus anchored in one feature, the plane, and itself consists of
two features, the circle and the extrusion that refers to it. Note that a number
of variants are possible, e.g. one might choose to draw an empty circle, extrude
casestudy.tex
432
2009-01-05
16:04:14Z
lutz
211
spec Vectors3DBase =
RealBase
then free type Vector ::= V (C1 : Real ; C2 : Real ; C3 : Real )
ops 0 : Vector = V (0, 0, 0);
..
.
end
spec Vectors3D = . . .
then ops
∗ (x, y : Vector ) : Real =
C1 x ∗ C1 y + C2 x ∗ C2 y + C3 x ∗ C3 y;
%(scalar product)%
# (x, y : Vector ) : Vector = . . . ;
%(vector product)%
| |(x : Vector ) : Real = sqrt (x ∗ x );
..
.
end
Fig. 6. Specification of the basic geometry
it, and then fill the resulting tube. We shall generally refer to a combination of
features as described above as a concrete design, while a definition via mathematical point sets will be called an abstract design. While in the above case it is
easy to see intuitively that the concrete design matches the abstract design, i.e.
that extruding a circle really yields a cylinder, the formalisation of this intuition
is by no means an entirely trivial enterprise, and more complex objects quickly
lead to quite challenging verification tasks – imagine e.g. having to check that
two given circular extrusions of two circles yield two interlocking chain links.
Additional complexity arises from the above-mentioned dependencies – e.g. one
may initially leave the height of the cylinder open, cut part of the cylinder off
using a skewed plane placed at a defined angle to the base plane and touching
the perimeter of the bottom circle, and then impose that the height of the short
side of the arising cut cylinder is half that of the long side, thus completely
determining the height.
It is therefore desirable to have machine support for checking that an abstract
design is actually implemented by a given concrete design. Besides the mere fact
that one can verify geometric shapes, added benefits include
– Easy proofs of physical and geometric properties of the objects involved –
e.g. once one has matched the abstract cylinder to the concrete cylinder, one
can now prove on the abstract side (much more easily than on the concrete
side) that the cylinder adheres to a prescribed surface area, volume, or mass
(if the density is known).
– Better control over the cohesion and consistency of the design – e.g. if it
turns out that the design fails to match the abstract object, this may mean
that the designer has accidentally left extraneous degrees of freedom. Such
casestudy.tex
432
2009-01-05
16:04:14Z
lutz
212
spec BaseObjects =
AffineRealSpace3DWithSets
then ops Cylinder (offset : Point; r : Real ; axis : Vector )
: PointSet =
{ (λ x : Point
• ∃ l : Real
• ∃ y : Vector
• l isIn [ 0 ... 1 ] ∧ orth (y, axis) ∧ | y | ≤ r
∧ x = offset + l ∗ axis + y)
};
end
Fig. 7. The abstract specification of a cylinder
errors may later lead to blocked designs that cannot be completed due to
unsatisfiability of their dependencies, a notorious problem in computer-aided
construction; verification against abstract designs may help detecting such
errors at an early stage of the development process.
– The abstract design may in fact properly abstract from the concrete shape of
the final object, e.g. by leaving less relevant dimensions open (within certain
ranges) or omitting features that do not play a central role in the present
stage of the design process, thus providing for a property-centered approach
to evolutionary design.
The paradigm proposed in FormalSafe for machine-supported verification of designs within the Bremen heterogeneous tool set HeTS is, in the simplest case,
as follows.
– Specify the abstract design in HasCasl, using a library of three dimensional
space and standard geometric objects.
– Export a concrete design from the CAD system and import the resulting
OMDOC document as a HasCasl specification.
– Set up a refinement view in HasCasl that matches the components of the
abstract design to those of the concrete design.
– Discharge the proof obligations arising from the refinement in an automatic
or semi-automatic theorem prover connected to HasCasl via HeTS, typically in Isabelle/HOL.
Further semantic services provided by the connection between abstract and concrete designs within HeTS include semantic annotation and requirements tracing as discussed in Section 2. A more visionary potential application of abstract
designs is the automated derivation of concrete designs, i.e. rapid prototyping
by compilation of abstract designs into preliminary formally verified CAD documents.
casestudy.tex
432
2009-01-05
16:04:14Z
lutz
213
Fig. 8. A cylinder in SolidWorks
The above-mentioned basic libraries are designed as follows4 . The abstract
specification of three dimensional basic geometry is contained in a HasCasl
library which provides the fundamental types and objects such as the datatypes
Point and Vector for points and vectors in R3 , types for point sets and vector
sets and operations on these types (See Figure 6 for some selected specifications
of this library). We will use PointSet as type of geometric objects, and we understand as standard geometric object the set of point sets which is implicitly given
by the image of an operation with result type PointSet, the constructor of the
standard geometric object in question. To give an example, consider Figure 7:
We define here an operation Cylinder , the constructor for cylinders, and thus
obtain the set of cylinders as image of this operation where the arguments vary
over the domain Point × Real × Vector. On the other side we specify the concrete
SolidWorks objects as described in Section 3. As our abstract type for geometric objects is PointSet, we define the semantics of the SolidWorks objects
in terms of points and point sets: objects of type SWPoint are interpreted as
Point or Vector and objects of type SWObject as PointSet. A concrete specification exported from the SolidWorks project shown in Figure 8 can be seen
in Figure 9. As already mentioned we can observe the straight-forward encoding
of the design tree of the cylinder as a HasCasl term. Furthermore we see that
we linked the exported specification to a theory called SolidWorksCylByArcExtrusion. This and similar theories are collected in a common patterns HasCasl
library for SolidWorks and provide the “heart” of the future semi-formal de4
casestudy.tex
432
2009-01-05
All mentioned HasCasl specifications can be obtained over the web from:
https://svn-agbkb.informatik.uni-bremen.de/Hets-lib/trunk/HasCASL/Real3D/
16:04:14Z
lutz
214
spec Project1 = . . .
then ops arc1 : SWArc =
SWArc
(E1, SWPoint (0, 0, 0), SWPoint (1, 0, 0),
SWPoint (1, 0, 0));
cylinder1 : SWObject = Extrusion (Arc arc1, 3, 1);
end
view cylinder1IsCylinder :
SolidWorksCylByArcExtrusion to
{Project1
then ops direction : Direction = 1;
center : SWPoint = SWPoint (0, 0, 0);
boundarypoint : SWPoint = SWPoint (1, 0, 0);
height : Real = 3;
plane : SWPlane = E1 ;
arc : SWArc = arc1 ;
cylinder : SWObject = cylinder1 ;
}
end
Fig. 9. The concrete specification of a cylinder
sign framework presented in this work, as they link the formal output of the
CAD program to the abstract specification of geometry. The main task will be
to develop this library and to provide proof support to close semi-automatically
the asserted links.
5
Conclusion and Further Work
We have shown that systematic engineering design processes (as laid down e.g.
in VDI 2221) have many commonalities with software engineering. To transfer
methods from software engineering to engineering design we have to deal with the
fact that engineering design processes are considerably less formal and are geared
towards producing CAx objects instead of program code. We have formulated a
semi-formal, document-oriented design process that integrates CAx documents
and extended a commonly used CAD system with an interface for exporting
CAD objects to the HeTS system. Moreover, we have illustrated the kind of
proof obligations that may arise in completely formal parts of the development.
The work reported here is just a first step in an ambitious endeavor where we
want to rethink the systematic engineering design process as a whole.
Acknowledgements
The work reported here was supported by the FormalSafe project conducted by
DFKI Bremen and funded by the German Federal Ministry of Education and
concl.tex
432
2009-01-05
16:04:14Z
lutz
215
Research (FKZ 01IW07002). We gratefully acknowledge discussions with Bernd
Krieg-Brückner, Dieter Hutter , Christoph Lüth, and Till Mossakowski. Erwin
R. Catesbeiana has contributed his known opinions on fundamental matters of
logic.
References
1. E. Astesiano, M. Bidoit, B. Krieg-Brückner, H. Kirchner, P. D. Mosses, D. Sannella,
and A. Tarlecki. CASL – the common algebraic specification language. Theoretical
Computer Science, 286:153–196, 2002.
2. S. Autexier, D. Hutter, T. Mossakowski, and A. Schairer. Maya: Maintaining
structured documents. In OMDoc – An open markup format for mathematical
documents [Version 1.2] [6], chapter 26.12.
3. A. Ioniţă. Developing a rest interface to a database for omdoc. http://kwarc.
info/projects/ombase/pubs/report2.pdf, 2007.
4. JOMDoc Project.
5. A. Kohlhase and M. Kohlhase. CPoint: Dissolving the author’s dilemma. In A. Asperti, G. Bancerek, and A. Trybulec, eds., Mathematical Knowledge Management,
MKM’04, number 3119 in LNAI, pp. 175–189. Springer Verlag, 2004.
6. M. Kohlhase. OMDoc – An open markup format for mathematical documents
[Version 1.2]. Number 4180 in LNAI. Springer Verlag, 2006.
7. C. Lange. SWiM – a semantic wiki for mathematical knowledge management. In
S. Bechhofer, M. Hauswirth, J. Hoffmann, and M. Koubarakis, eds., ESWC, vol.
5021 of Lecture Notes in Computer Science, pp. 832–837. Springer, 2008.
8. J. P. Lemburg. Methodik der schrittweisen Gestaltsynthese. PhD thesis, Fakultät
für Maschinenwesen, RWTH Aachen, 2008.
9. Math WebSearch – a semantic search engine. http://betasearch.mathweb.org.
10. F. Rabe and M. Kohlhase. An exchange format for modular knowledge. In P. Rudnicki and G. Sutcliffe, eds., Knowledge Exchange: Automated Provers and Proof
Assistants (KEAPPA), Nov. 2008.
11. Introducing SolidWorks. SolidWorks Corporation, Concord, MA, 2002.
12. VDI-Gesellschaft Entwicklung Konstruktion Vertrieb. Methodik zum Entwickeln
und Konstruieren technischer Systeme und Produkte, 1995. English title: Systematic approach to the development and design of technical systems and products.
concl.tex
432
2009-01-05
16:04:14Z
lutz
216
Michael Kohlhase Michael Kohlhase is Professor
for Computer Science at Jacobs University, Bremen
and Vice Director at the German Research Centre
for Artificial Intelligence (DFKI), Bremen. His current research interests include Automated Theorem
Proving and Knowledge Representation for Mathematics, inference-based techniques for Natural Language Processing, and computer-supported Education.
He has pursued these interests during extended visits to Carnegie Mellon University, SRI International,
Rice University, and the Universities of Amsterdam
and Edinburgh. Michael Kohlhase is recipient of the
dissertation award of the Association of German Artificial Intelligence Institutes (1995) and of a Heisenberg stipend of the German Research Council (DFG
2000-2003). He was a member of the Special Research
Action 378 (Resource-Adaptive Cognitive Processes),
leading projects on both Automated Theorem Proving and Computational Linguistics. Michael Kohlhase
is trustee of the Interest Group Mathematical Knowledge Management, a member of the W3C Math working group and the president of the OpenMath Society
(since 2007).
Johannes Lemburg received his Dipl.-Ing. from the
RWTH Aachen University, Germany, in 2002. Up to
2008 he stayed at this university as a research assistant for the Chair and Institute for Engineering Design
led by Univ.-Prof. Dr.-Ing. J. Feldhusen. He joined the
DFKI Robotics Research Group in 2008 as a senior researcher to strengthen the mechanical design group.
Lutz Schröder received his Dipl.-Math. from the University of Bremen in 1996, his PhD in mathematics
from the University of Bremen in 1999, and his habilitation in computer science from the university of
Bremen in 2005. He held a substitute associate professorship in theoretical computer science from 2003
to 2006. He joined the DFKI safe and secure cognitive systems group in 2006 as a senior researcher.
His research interests include algebraic, higher order,
and reactive specification and verification, in particular coalgebraic modal logic. He received the EATCS
best paper award at ETAPS 2006 for a paper that laid
the ground for the algorithmic theory of coalgebraic
modal logic. He presently holds two DFG grants on
coalgebraic modal logic and, with Christoph Lüth, on
monad-based program logics, respectively.
Ewaryst Schulz received his M.Sc. degree in mathematical logic from University Jussieu (Paris VII),
France, in 2006, after having worked for several years
in internet industry where he developed the content management system ePilot. He joined the Omega
group in Saarbrücken at the end of 2006. Since June
2008 he works as a junior researcher in the FormalSafe
project with the German Research Center for Articial
Intelligence at the research group for Safe and Secure
Cognitive Systems, Bremen, Germany.
concl.tex
432
2009-01-05
16:04:14Z
lutz
Graph Transformation Units
to Model Model Transformation –
First Ideas
Hans-Jörg Kreowski
University of Bremen
[email protected]
No Institute Given
Abstract. In this paper, graph transformation units are temptatively
proposed as a core concept to model model transformations in a compositional framework. The very first ideas are sketched concerning the
sequential and parallel compositions of model transformations, their input and output types, and the possible notions of correctness.
1
Introduction
Computers are devices that can be used to solve all kinds of data-processing problems – at least in principle. The problems to be solved come from economy, production, administration, military, science, education, entertainment, and many
other areas. There is quite a gap between the problems as one has to face them
in reality and the solutions one has to provide so that they run on a computer.
Therefore, computerization is concerned with bridging this gap by transforming a
problem into a solution. Many efforts in computer science contribute to this need
of transformation. First of all, compilers are devices that transform programs in
a high-level language into programs in a low-level language where the latter are
nearer and more adapted to the computer than the former. The possibility and
success of compilers have fed the dream of transforming descriptions of dataprocessing problems automatically or at least systematically into solutions that
are given by smoothly running programs. This includes the request for corectness meaning that a resulting program solves the original problem completely
and precisely (and does not do anything else in addition). In, e.g., Basin and
Krieg-Brückner [BKB99], this key idea is discussed and investigated under the
heading of program development and program transformation. In recent years,
the term model transformation has become more popular.
In this paper, it is sketched how the concepts of graph transformation units
(cf., e.g., [KKS97,KK99,KKR08]) can be employed to model model transformation. Following the ideas of model-driven architecture (MDA)(cf., e.g., Frankel
[Fra03]), the aim of model transformation is to transform platform-independent
models (PIMs), which allow to describe problems adequately, into platformspecific models (PSMs), which run properly and smoothly on a computer. As
218
a typical description of the PIMs, one may use UML diagrams while PSMs are
often just JAVA programs. In addition, there is another source of inspiration:
model transformation in theoretical computer science – in formal language theory as well as in automata theory in particular. These areas provide a wealth
of transformations between various types of grammars and automata like, for
example, the transformation of nondeterministic finite automata into deterministic ones or of pushdown automata into context-free grammars (or the other
way round) or of arbitrary Chomsky grammars into the Pentonen normal form
(to give a less known example). While the models in the MDA context are often
diagrammatic or textual, the examples of theoretical computer science show that
models may also be tuples with components being sets of something.
Accordingly, graphs, tuples of models, and sets of models are introduced as
models in Section 3. In Section 2, graph transformation units are recalled as
devices to transform initial graphs into terminal graphs by means of regulated
rule application. They can be considered as model transformations if the initial
and terminal graphs represent models. Such units are used as building blocks
of the sequential and parallel compositions of model transformations in Section
4 while some variants of the notion of correctness of model transformations are
considered in Section 5.
2
Graph Transformation Units
Graph transformation units are rule-based devices to transform initial graphs
into terminal graphs by iterated rule applications which obey control conditions. The basic components are taken from an underlying graph transformation
approach as introduced in [KK99] . There are always a class of graphs and a class
of rules that can be applied to these graphs. In many cases, rule application is
highly nondeterministic – a property that is not desirable in any case. Hence, a
graph transformation approach can also provide a class of control conditions so
that the degree of nondeterminism of rule application can be reduced. Moreover,
graph class expressions can be used in order to specify sets of initial and terminal
graphs.
Formally, a graph transformation approach is a system A = (G, R, X , C) the
components of which are defined as follows.
– G is a class of graphs.
– R is a class of rules such that every r ∈ R specifies a binary relation on
graphs SEM (r) ⊆ G × G.
– X is a class of graph class expressions such that each x ∈ X specifies a set
of graphs SEM (x) ⊆ G.
– C is a class of control conditions such that each c ∈ C specifies a set of
sequences SEM (c) ⊆ G × G.
219
A well-known instance for the class G is the class of all directed edge-labeled
graphs. Other classes of graphs are trees, Petri nets, undirected graphs, hypergraphs, etc.
One encounters quite a variety of notions of rules and rule applications in the
literature (see, e.g., [Roz97] for the most typical examples). In all cases, a rule
r provides a left-hand side L and a right-hand side R, and its application to a
graph G involves a match of L in G (usually given by a graph morphism often
subject to further conditions). Then certain parts of the match are removed,
and R is added in some way. Let H be the resulting graph, then such a direct
derivation is denoted by G =⇒ H.
r
Every finite subset M ⊆ G is a graph class expression that specifies itself, i.e.
SEM (M ) = M . Moreover, every set L of labels specifies the class of all graphs
in G the labels of which are elements of L. Every set P ⊆ R of rules can also be
used as a graph class expression specifying the set of all graphs that are reduced
w.r.t. P where a graph is said to be reduced w.r.t. P if no rules of P can be
applied to the graph.
The least restrictive control condition is the term free that allows all graph
transformations, i.e. SEM (free) = G × G. Other typical examples are regular
expressions or priorities specified over a given rule set.
More about graph class expressions and control conditions can be found in
[Kus00a,Kus00b].
Now all the ingredients are ready to introduce graph transformation units.
A simple graph transformation unit is a system tu = (I, P, C, T ), where I and
T are graph class expressions to specify the initial and the terminal graphs
respectively, P is a set of rules, and C is a control condition.
Such a transformation unit tu specifies a binary relation SEM (tu) ⊆ SEM (I) ×
SEM (T ) that contains a pair (G, H) of graphs if and only if there is a derivation
∗
G =⇒ H permitted by C, i.e. (G, H) ∈ SEM (C).
P
It is worth noting that in general transformation units have an import component
that allows to use the semantic relations specified by other units as transformation steps [KK99]. But for the purpose of this paper, simple units are enough.
A unit tu = (I, P, C, T ) may be depicted by
I
P, C
T
A graph transformation can be considered as a model transformation if SEM (I)
and SEM (T ) specify classes of graph models. Typical examples of graph transformation units that model model transformations are the transformation of
220
well-structured flow diagrams into while-programs in [KHK06] and of UML sequence diagrams into collaboration diagrams in [CHK04]
Graph transformation units are used as basic building blocks to construct more
complex model transformations by sequential and parallel compositions in Section 4 while, in the following section, the classes of graph models to be transformed are specified accordingly.
3
Graph-based Models and Model Types
The starting point is the observation that many models used in Computer Science are of a graphical, diagrammatic, and visual nature and that they can be
represented as graphs in an adequate way in most cases. But models may not
occur only as singular items, but also as tuples or as some other collections of
models. To cover this, we define the class M of graph-based models in a recursive
way:
1. G ⊆ M,
2. (M1 , . . . , Mk ) ∈ M if M1 , . . . , Mk ∈ M for all k ≥ 2,
3. M ∈ M if M ⊆ M.
Point 1 makes sure that all graphs and – in this way – all diagrams with graph
representations are models. Point 2 allows one to consider a k−tuple of models
as a model and makes k models simultaneously available in this way. Point 3 also
makes many models available at the same time. But now they are not ordered.
The sets may be infinite so that they may serve as semantic models.
Usually, model transformations do not transform all models, but initial models
of a particular type into terminal models of another type. The models of a type
form a set of models. The following type-building operators are considered in
this paper:
1. a graph class expression X ∈ X with SEM (X) ⊆ G yields a type,
2. if L1 , . . . , Lk are types then L1 × . . . × Lk is a type.
As SEM (X) ⊆ G and G ⊆ M, one gets SEM (X) ⊆ M. As L1 ×. . .×Lk contains
tuples as elements, one gets L1 × . . . × Lk ⊆ M. Therefore, the constructions in
Points 1 and 2 are yielding types.
In addition we assume some standard types including BOOL• , N• , Σ • , and
(Σ ∗ )• . The dot means that Boolean values T and F , the natural numbers, the
symbols of the alphabet Σ, and the strings over Σ are represented as special
graphs:
221
T
a
F
,
,
0
+1
n
begin
a1
...
. . . +1
times
ak
end
for n ∈ N,
for a ∈ Σ,
for a1 . . . ak ∈ Σ ∗ , ai ∈ Σ.
It is easy to see, that types can be described by type expressions. The set of type
expressions T is recursively defined:
1. X ⊆ T ,
2. t1 , . . . , tk ∈ T implies t1 × . . . × tk ∈ T
with the obvious semantics
1. SEM (X) for X ∈ X as before,
2. SEM (t1 × . . . × tk ) = SEM (t1 ) × . . . × SEM (tk ).
A typical example of a graph model is the state graph of a finite state automaton. A tuple of such graphs represents the parallel composition of finite state
automata. A pair of a finite state automaton and a string graph represents a
configuration of an acception process. It is an initial configuration if the current
state is the initial one, it is a terminal configuration if the current state is a final
one and the string is empty. A context-free grammar is a model of a quite different form than a state graph. It is a 4-tuple of two finite sets of nonterminal and
terminal symbols respectively, a finite set of production each being a pair of a
nonterminal symbol and a string, and a nonterminal start symbol. Therefore, it
is a model due to the definition above using mainly tupling and set enumeration.
The introduced model types and type expressions are suitable to provide proper
input and output types to the compositional model transformations of the following section.
4
Sequential and Parallel Composition
As pointed out in Section 2, one may consider graph transformation unit as basic
model transformations that transform initial models into terminal ones. To get
a more general notion, one can close the basic transformations under sequential
and parallel compositions. This allows a nice separation between the syntactic
level of expressions and the semantic level of model transformation.
The set MT E of model transformation expressions is defined recursively:
1. graph transformation units are in MT E,
222
2. mte 1 , . . . , mte k ∈ MT E implies mte 1 ; . . . ; mte k ∈ MT E
(sequential composition),
3. mte 1 , . . . , mte k ∈ MT E implies mte 1 . . . mte k ∈ MT E
(parallel composition).
The relational input-output semantics of graph transformation units can be extended to model transformation expressions using the sequential composition of
relations and the product types:
1. SEM (tu) as defined in Section 2,
2. SEM (mte 1 ; . . . ; mte k ) = SEM (mte 1 ) ◦ . . . ◦ SEM (mte k ),
3. ((M1 , . . . , Mk ), (N1 , . . . , Nk )) ∈ SEM (mte 1 . . . mte k ) if and only if
(Mi , Ni ) ∈ SEM (mte i ).
To make this more transparent, one may assign an input type and an output
type to each model transformation expression. Then the relational semantics of
an expression turns out to be a binary relation between input and output types.
The input type in and the output type out are recursively defined on MT E:
1. in(tu) = SEM (I), out(tu) = SEM (T ),
2. in(mte 1 ; . . . ; mte k ) = in(mte 1 ), out(mte 1 ; . . . ; mte k ) = out(mte k ),
3. in(mte 1 . . . mte k ) = in(mte1 ) × . . . × in(mte k ) and out(mte 1 . . . mte k ) = out(mte1 ) × . . . × out(mte k ).
Due to these definitions, it is easy to see that the following observation holds:
SEM (mte) ⊆ in(mte) × out(mte).
The compositions can be quite intuitively depicted:
tr1 ; tr2
I1
T1
tr1
I2
tr2
T2
tr1 tr2
I1
tr1
T1
I1 × I2
T1 × T2
I2
tr2
T2
223
The formal language theory offers many examples of sequential compositions of
model transformations like the transformation of right-linear grammars into finite state automata followed by their transformation into deterministic automata
followed by the transformation of the latter into minimal automata.
A typical example of a parallel composition is given by the acception processes
of two finite state automata that run simultaneously. If they try to accept the
same input strings, this parallel composition simulates the product automaton
that accepts the intersection of the two accepted regular languages.
5
Correctness
The idea of correctness is that a model transformation is assumed to preserve
or reflect the meaning of the transformed model such that the meaning of an
input model and the meaning of a related output model coincide or correlate in
a meaningful way at least. If the meaning of the input models and of the output
models are given by model transformations into suitable semantic models, then
we have the following situation
I
sem I
tr
T
sem T
The ideal result would be that the meaning of the semantics of the input models
equals the meaning of the sequential composition of the model transformation
tr followed by the semantic construction of the output models:
SEM (sem I ) = SEM (tr; sem T ) = SEM (tr) ◦ SEM (sem T ).
But this is not realistic to expect if the semantic constructions are given independently from each other. Usually, the semantic models differ and need some
adaptation before they can coincide. There are principally four cases of adaptations:
1. The semantic models of the input side are adapted to the semantic models
of the output side.
2. The other way round.
3. The semantic models of the input and the output side are both adapted to
certain common reference models.
4. Or such reference models are adapted to the input and output sides.
224
If the adaptations are transformations between semantic models, we get the
following pictorial versions:
1.
adaptIT
2.
adaptT I
3.
adaptI
adaptT
4.
adaptI
adaptT
In all four cases, one can define the correctness of the original transformation
relative to the adaptations. The model transformation tr is a correct model
transformation with respect to sem I and sem T if
1.
2.
3.
4.
SEM (sem I ) ◦ SEM (adaptIT ) = SEM (tr) ◦ SEM (sem T ),
SEM (sem I ) = SEM (tr) ◦ SEM (sem T ) ◦ SEM (adaptT I ),
SEM (sem I ) ◦ SEM (adaptI ) = SEM (tr) ◦ SEM (sem T ) ◦ SEM (adaptT ),
if (M, N ) ∈ SEM (sem I ) and (M, N ) ∈ SEM (tr) ◦ SEM (sem T ), then there
is N̄ with (N̄ , N ) ∈ SEM (adapt I ) and (N̄ , N ) ∈ SEM (adapt T ).
All four notions of correctness can be depicted as follows.
225
tr
1.
sem I
sem T
=
adaptIT
tr
2.
sem I
sem T
=
adaptT I
tr
sem I
=
sem T
3.
adaptI
adaptT
226
tr
sem I
=
sem T
4.
adaptI
adaptT
If all adaptations are the identity, all four notions yield the ideal case of correctness.
6
Conclusion
In this paper, some first ideas for the modeling of model transformations are
sketched. Models are recursively defined as tuples and sets of models starting
with graphs (including some graph-represented standard types). Models of this
kind cover graphical models like UML diagrams as well as set-theoretic models
like grammars and automata. The transformations of such models are recursively
given by the sequential and parallel compositions of model transformations starting with graph transformation units.
To shed more light on the significance of this temptative novel approach, more
work is needed including the following topics.
1. The parallel composition combines model transformations in such a way
that they run independently of each other on their respective components
of the tuples of models. But this is not always desirable as one may like
to interrelate transformation steps. Therefore, one may like to employ control conditions on the level of parallel compositions as they are available
on the basic level of graph transformation units. In [KKK05], the parallel
composition of units is studied as a step in this direction.
2. The variants of the notion of correctness are introduced for a single model
transformation. One interesting question is whether and how these correctness notions are compatible with the sequential and parallel compositions
so that the correctness of the components yields the correctness of the composed model transformation. Another question is how a proof theory for
model transformations may look like.
227
3. Explicit and detailed examples are needed to illustrate all introduced concepts properly.
References
[BKB99] David Basin and Bernd Krieg-Brückner. Formalization of the development process. In Egidio Astesiano, Hans-Jörg Kreowski, and Bernd KriegBrückner, editors, Algebraic Foundations of Systems Specification, chapter 14,
pages 521–562. Springer, 1999.
[CHK04] Björn Cordes, Karsten Hölscher, and Hans-Jörg Kreowski. UML interaction diagrams: Correct translation of sequence diagrams into collaboration
diagrams. In John l. Pfaltz, Manfred Nagl, and Boris Böhlen, editors, Applications of Graph Transformations with Industrial Relevance (AGTIVE 2003),
volume 3062 of Lecture Notes in Computer Science, pages 275–291, 2004.
[Fra03]
David S. Frankel. Model Driven Architecture. Applying MDA to Enterprise
Computing. Wiley, Indianapolis, Indiana, 2003.
[KHK06] Hans-Jörg Kreowski, Karsten Hölscher, and Peter Knirsch. Semantics of
visual models in a rule-based setting. In R. Heckel, editor, Proceedings of
the School of SegraVis Research Training Network on Foundations of Visual
Modelling Techniques (FoVMT 2004), volume 148 of Electronic Notes in Theoretical Computer Science, pages 75–88. Elsevier Science, 2006.
[KK99]
Hans-Jörg Kreowski and Sabine Kuske. Graph transformation units with
interleaving semantics. Formal Aspects of Computing, 11(6):690–723, 1999.
[KKK05] Renate Klempien-Hinrichs, Hans-Jörg Kreowski, and Sabine Kuske. Rulebased transformation of graphs and the product type. In Patrick van Bommel,
editor, Transformation of Knowledge, Information, and Data: Theory and
Applications, pages 29–51. Idea Group Publishing, Hershey, Pennsylvania,
USA, 2005.
[KKR08] Hans-Jörg Kreowski, Sabine Kuske, and Grzegorz Rozenberg. Graph transformation units – an overview. In P. Degano, R. De Nicola, and J. Meseguer,
editors, Concurrency, Graphs and Models, volume 5065 of Lecture Notes in
Computer Science, pages 57–75. Springer, 2008.
[KKS97] Hans-Jörg Kreowski, Sabine Kuske, and Andy Schürr. Nested graph transformation units. International Journal on Software Engineering and Knowledge
Engineering, 7(4):479–502, 1997.
[Kus00a] Sabine Kuske. More about control conditions for transformation units. In
Hartmut Ehrig, Gregor Engels, Hans-Jörg Kreowski, and Grzegorz Rozenberg, editors, Proc. Theory and Application of Graph Transformations, volume 1764 of Lecture Notes in Computer Science, pages 323–337, 2000.
[Kus00b] Sabine Kuske. Transformation Units—A Structuring Principle for Graph
Transformation Systems. PhD thesis, University of Bremen, 2000.
[Roz97] Grzegorz Rozenberg, editor. Handbook of Graph Grammars and Computing
by Graph Transformation, Vol. 1: Foundations. World Scientific, Singapore,
1997.
228
Hans-Jörg Kreowski is professor for theoretical computer science at the University of Bremen
since October 1982 while his colleague Bernd KriegBrückner was appointed even a month earlier. In all
the years until today, they have worked together and
undertaken many efforts at a prosperous development
of the computer science department although their
views of the right track were not always identical.
Concerning research, they share a common interest in
formal methods that led to various close cooperations
in national and international research projects and in
the IFIP Working Group 1.3 (Foundations of System
Specification). Hans-Jörg Kreowski enjoyed particularly the co-edition of the IFIP State-of-the-Art Report Algebraic Foundations of Systems Specification
with Egidio Astesiano and Bernd Krieg-Brückner.
Test Automation Problems and Their Reduction
to Bounded Model Checking
Jan Peleska
Department of Mathematics and Computer Science
University of Bremen
Germany
[email protected]
Abstract. In this paper we analyse a collection of test automation problems and describe the core concepts to their solution. It turns out that
all of them may be regarded as reachability problems of a finite nature.
This means that a finite number of applications of some sort of transition
relation in conjunction with a test-specific predicate completely characterises the solution set of test data to be constructed for the test objective
under consideration. This characterisation coincides with the notion of
a BMC instance which is the bounded model checking equivalent to the
SAT instances of Boolean model checking. All testing problems described
originate from the field of safety-critical systems verification and validation, where rigorous standards specify the amount of testing required in
order to achieve system certification.
1
Introduction
Objectives. The standards for avionic and railway control systems [16, 5] are quite
explicit with respect to dynamic testing of safety-critical systems in these domains: The whole testing process should be driven by requirements-based tests,
that is, tests establishing that a required system feature really has been implemented and works properly – at least for the situations covered by these
tests. Given formal requirements models of untimed or timed automata nature,
requirements-based tests can be made exhaustive in theory; this means that it is
possible to generate a comprehensive test suite from the model which is capable
to uncover every possible discrepancy between implementation and specification model [3, 18, 9]. The amount of test cases to be executed, however, would
exceed any acceptable time limit for the duration of the test suite execution,
even for systems of only moderate size and complexity. As a consequence it is
necessary to find reasonably well-founded heuristics how to decide when a test
suite may be regarded as “sufficiently effective”, though not exhaustive. To this
end, requirements-based testing is refined and complemented by the following
techniques:
1. Structural testing aims at covering all code portions, interfaces and synchronisation aspects of the implementation, while checking that the requirements
230
are still met. These tests are helpful if seemingly atomic requirements had
to be implemented by different components, such that it is impossible to
guess the different test cases required to cover all implementation aspects by
means of requirements analysis alone.
2. Equivalence class testing tries to structure the input data to the system under
test into different classes, such that it can be reasonably expected that the
implementation handles each member of the same class in a uniform manner.
As a consequence, only one or a very small number of test cases from the
same class have to be exercised on the system.
3. Boundary value testing helps to determine how many members of an equivalence class should be exercised on the system under test: At least the test
cases whose input data is located at the boundaries of each class have to be
executed.
4. Mutation testing gives a further answer to the question if a sufficient number
of test cases has been generated: The model is tainted with one or more errors
(this process is called error seeding) and then it is checked whether the test
suite is capable of uncovering the error. If not, additional test cases have to
be constructed.
Our objective in this paper is to provide a uniform formal approach to the
automated model-based construction of requirements-based, equivalence class,
boundary value and mutation test cases which can be practically applied for
the construction of the associated test data. It turns out that every test case
can be formulated as a reachability problem within the given model: We have
to reach a certain pre-state in the model from where the system feature under
investigation can be checked. Then a specific timed sequence of input vectors
has to be constructed which stimulates exactly the system reaction associated
with this feature. The system reaction can be automatically checked against the
model; therefore we only focus on the input data generation problem for the
rest of this paper. Each of the reachability problems associated with the kinds
of tests described above may be brought into a “format” that coincides with the
problem instances of bounded model checking (BMC).
Structural tests are outside the scope of this paper, because the reachability
problems associated with structural test case generation cannot be based on the
model, but have to be derived from the implementation code structure. The
reader is referred to [2] for further details.
Overview. Section 2 introduces the notion of BMC instances and discusses their
application is a timed automata context. In Section 3 a case study is presented
which is used to illustrate the main results about test case and test data generation and the associated reachability problems. These main results are described
in Section 4. Section 5 gives the conclusion and refers to related work and practical applications, as well as future work.
231
2
Bounded Model Checking
Given a model with transition relation Φ, bounded model checking (BMC) tries
to construct solutions of BMC instances, that is, predicates of the form
b=
c−1
j=0
Φ(i(k0 + j), s(k0 + j), s(k0 + j + 1))
(1)
∧ P (i(k0 ), s(k0 ), o(k0 ), . . . , i(k0 + c), s(k0 + c), o(k0 + c))
with
i(k) = (x1 (k), . . . , xm (k)) input vector at execution step t,
s(k) = (s1 (k), . . . , sn (k)) state vector at execution step t,
o(k) = λ(i(k), s(k)) output vector at execution step t,
Φ the transition relation relating pre-states s(k) and inputs i(k) at execution
step k to post states s(k + 1), and
– P a property about inputs, outputs and internal state to be fulfilled during
these c execution steps.
–
–
–
–
In classical BMC the input, output and state vectors consist of boolean components only. While this is appropriate for many problems related to the verification of electronic circuits, the application of BMC for general embedded systems
requires more general data types, such as integral numbers with large data ranges
and floating point data with their associated operations. While, in theory, these
data types and their operations could be re-coded as boolean vectors and operations, resulting again in classical BMC instances, it is often more efficient to
construct the solution space with methods (“theories”) optimised for the nonboolean data types. The tools for solving these mixed data type problems are
called Satisfiability Modulo Theories (SMT) solvers [15].
For discrete time models the execution steps are obviously induced by discrete
time ticks, as, for example, the clock cycles in electronic circuits. For dense-time
models, however, a further abstraction step is required, because the existence
of real-valued clocks induces an uncountable state space. As a consequence, the
meaning of “unfolding the transition relation for c execution steps” is not as
obvious as in untimed or discrete-time models. For models based on the semantics
of timed automata a suitable abstraction is given by the region or zone graphs [1,
p. 70]. Intuitively speaking, the zone graph abstracts timed states conforming to
the same constraints into a single node of the graph. Transitions between nodes
can either be triggered by inputs to the system or by the passage of time, when
boundaries given by clock conditions are reached. Suppose that the system will
reside in a node n of the zone graph in the time interval [t0 , t1 ] if no further
inputs are supplied, but leave n if some input x is provided during that interval.
Then placing x at time t0 +δ, 0 ≤ δ ≤ t1 −t0 will lead to the same system outputs
and state changes, regardless of the value of δ within the specified bounds. These
considerations lead to a specific structure of an abstracted transition relation:
– Timed transitions shift the time forward, but never beyond the next boundary induced by a clock condition in the zone graph. As a consequence, the
232
system never switches nodes during a timed transition. At the end of a timed
transition new inputs to the system may be placed.
– Zero-time transitions perform switches between nodes in the zone graph,
possibly changing state variables and outputs. They occur while inputs and
time remain fixed.
– Timed transitions can only occur if no zero-time transition is enabled. This
obviously requires some well-formedness conditions on the models, in order to avoid divergence (unbounded number of consecutive zero-time steps)
and Zeno sequences (unbounded number of timed transitions with strictly
decreasing time intervals between transitions).
3
Case Study
As an example illustrating the different types of test cases and their associated
representation as BMC instances the model of a fictive automotive controller is
presented in Figures 1 — 3. This controller manages the interplay between turn
indication and emergency flashing: Inputs to the controller are (1) the command
to switch on/off turn indications left or right, TurnIndLeft = 1/TurnIndLeft = 0 or
TurnIndRight = 1/TurnIndRight = 0, (2) the command to turn on/off emergency
flashing, EmerFlash = 1/EmerFlash = 0 and (3) the electrical current status in
percent, Current ∈ {0, . . . , 100}. Controller outputs act on the interfaces to the
left-hand side and right-hand side indication lights: FlashLeft = 1 and FlashRight
= 1 switch these lights on and they are switched off by setting the respective
outputs to zero.
Fig. 1. Components of the flash control unit.
The system requirements to be reflected in the model are given as follows:
R1 Indication lights are only active if the electrical current status is > 80%.
233
R2 If any lights are flashing, this is done synchronously with a 340ms ON –
220ms OFF period.
R3 An input change from (TurnIndLeft,TurnIndRight) ∈ {(0, 0), (0, 1)} to
(TurnIndLeft,TurnIndRight) = (1,0) switches indication lights left into flashing
mode and switches indication lights right off.
R4 An input change from (TurnIndLeft,TurnIndRight) ∈ {(0, 0), (1, 0)} to
(TurnIndLeft,TurnIndRight) = (0,1) switches indication lights right into flashing mode and switches indication lights left off.
R5 An input change from EmerFlash = 0 to EmerFlash = 1 switches indication
lights left and right into flashing mode, regardless of any previously activated
turn indication.
R6 Activation of the turn indication left or right overrides emergency flashing,
if this has been activated before.
R7 If turn indication left or right is switched of and emergency flashing is still
active, emergency flashing is continued or resumed, respectively.
R8 If emergency flashing is turned off and turn indication left or right is still
active, the turn indication is continued or resumed, respectively.
Fig. 2. Control component FLASH CTRL for the decisions “flash left” and “flash right”.
The controller model consists of two sub-components (Fig. 1): The “flash left”
and/or “flash right” decisions are managed by FLASH CTRL whose behaviour is
depicted in the statechart in Fig. 2. Its control decisions are passed to the second
component via internal interfaces Left, Right ∈ {0, 1}. The output interface control together with the timing control for flashing lights is handled by the second
234
component denoted OUTPUT CTRL (Fig. 3). The behavour of OUTPUT CTRL
is modelled by a timed Statechart with clock variable t: Setting t = 0 resets
the clock to 0. Conditions t ≥ c are interpreted as “after c milliseconds have
elapsed”.
A model state vector s(k) evaluated at execution step k can be structured
into s(k) = (t, (loc(k), v(k), tim(k))), where
–
–
–
–
t ≥ 0 is the relative time stamp of the execution,
loc(k) is the sub-vector of Statechart locations,
v(k) is the sub-vector of variable valuations and
tim(k) is the sub-vector of clock valuations.
A state formula ϕ(k) evaluated at execution step k admits atoms C.(k) where
C is a component and a location. Its interpretation is “At execution step k
component C is in location ”. Atoms on clock variables are of the form t(k) ◦ c,
where t(k) is the valuation of a clock variable t at step k, ◦ ∈ {=, ≤, ≥, <, >}
and c is a constant1 . For example, state formula
OUTPUT CTRL.FLASHING.ON(k) ∧ Left(k) ∧ Current(k) = 100 ∧ t(k) < 340
states: “At execution step k, component OUTPUT CTRL is in location FLASHING.ON, variable Left has value 1, variable Current has value 100 and clock t has
not yet reached deadline 340”.
The Transition relation is structured into timed and zero-time transitions as
described in Section 2.
4
Test Types and Their Associated Reachability
Problems
4.1
Requirements-Based Testing
Provided that our model completely reflects the requirements, every property is
represented by one or more paths through the model, together with a suitable
trace of inputs to be passed from the environment to the system under test
at certain points in time. The specific paths to be covered with the associated
specification of admissible inputs is encoded in the P -component of the BMC
c−1
Φ(i(k0 + j), s(k0 + j), s(k0 + j + 1))-conjunct ensures that
instance, while the
j=0
only legal paths through the model are taken.
If a test case is constructed from scratch, unrolling the transition relation
starts at k0 = 0. In many cases, however, test data previously constructed can
be used to drive the system into a suitable pre-state from where the requirement
can be directly checked. This corresponds to the situation where k0 > 0 and
s(k0 ) is this pre-state reached by means of the test data already available.
1
We do not need the full expressiveness of formulae involving clocks which is possible
for timed automata.
235
Fig. 3. Output control component OUTPUT CTRL managing indications lights and
associated flash cycles.
236
Example 1. For testing requirement R1 defined in Section 3 we need two types
of test cases: The first type starts in a system state where indications are off and
the current is ≤ 80%. Then it is tried to switch indications on and checked that
the controller does not give activation signals on outputs FlashLeft, FlashRight.
These test cases are characterised by the condition
c−1
P1 (loc(k0 ), . . . , loc(k0 + c)) ≡ ( k=0 Current(k0 + k) ≤ 80)∧
c−1
k=0 (FlashLeft(k0 + k) = 0 ∧ FlashRight(k0 + k) = 0 ∧
((TurnIndLeft(k0 + k) = 0 ∧ TurnIndLeft(k0 + k) = 1) ∨
(TurnIndRight(k0 + k) = 0 ∧ TurnIndRight(k0 + k + 1) = 1) ∨
(EmerFlash(k0 + k) = 0 ∧ EmerFlash(k0 + k + 1) = 1)))
The second type of test cases starts in a system state where indication lights
are on and then decreases the current to ≤ 80%, expecting the indication lights
to be switched off. These test cases are characterised by the condition
P2 (i(k0 ), loc(k0 ), . . . , i(k0 + c), loc(k0 + c)) ≡
c−1
k=0 (OUTPUT CTRL.FLASHING.ON(k0 + k) ∧
Current(k0 + k) ≤ 80 ∧ OUTPUT CTRL.IDLE(k0 + k + 1))
4.2
Equivalence Class Testing
The test case characterisations P1 , P2 from Example 1 give rise to an infinite
number of test cases, since we are dealing with a non-terminating system and we
have an infinite number of choices with respect to the points in time when inputs
could be placed. In theory, it would be possible to construct a grid automaton
from the model’s zone graph which can be covered by a finite number of test
cases which would uncover every possible deviation of the implementation from
the model [18]. The number of these test cases, however, would be far too large
to be executed in acceptable time. As a consequence it is desirable to apply a
reasonably justified heuristics allowing to reduce the number of test cases without
omitting the examination of important situations. One of the most important
heuristics is called equivalence testing. This approach tries to structure the input
domain into a finite number of so-called equivalence classes, so that each two
members of a class are equally suitable to check a certain aspect of a given
requirement (requirements-based equivalence class construction). Equivalence
classes can be further justified if it can be shown that these members stimulate
the same execution paths in the system under test (structure-based equivalence
class construction). After construction of the classes, only one or a few members
of each class have to be tested.
The construction of equivalence classes for testing reactive real-time systems
is more complicated than equivalence class construction for the test of sequential
terminating modules because the elements of each class are timed sequences of
input vectors. The availability of a model, however, facilitates the justification
237
and construction of requirements-based equivalence classes: Every cycle-free path
through the zone graph satisfying P gives rise to an equivalence class, and two
timed input traces are equivalent if they stimulate the same cycle-free path. This
notion of equivalence is justified as follows:
– We only have to consider cycle-free paths since returning to a previous node
on the path would mean that a previous model state has been reached again.
– Two timed input traces stimulating the same path through the zone graph
are regarded as equivalent, because they result in the same sequence of operations being applied to state variables, clocks and output variables and
to the application of the same deadlines. Of course, these equivalent traces
may use different input values and result in different outputs occurring at
different times, but since they are processed by the same operations and
are subject to the same deadlines, it can be reasonably expected that a few
equivalent traces suffice to uncover every error in this operational sequence.
– Conversely, two different paths through the zone graph induce different
equivalence classes since they lead to different operations exercised on the
state, clock and output variables and to the application of different deadlines.
Example 2. For the test cases characterised in Example 1 by predicate P2 different paths through the zone graph lead to the required pre-state
OUTPUT CTRL.FLASHING.ON(k0 + k) ∧ Current(k0 + k) ≤ 80
Condition Q1 below specifies a path for some suitable 0 ∈ {1, . . . , k0 −1} leading
through locations
(FLASH CTRL.EMER OFF, OUTPUT CTRL.IDLE) →
(FLASH CTRL.EMER OFF, OUTPUT CTRL.ON) →
(FLASH CTRL.EMER OFF, OUTPUT CTRL.IDLE)
where indication lights are switched on via the turn indication lever, while the
emergency flash switch remains in state off (otherwise the model would not
remain in state FLASH CTRL.EMER OFF). The electric current drops below the
acceptable threshold at execution step k0 , and this already happens during the
very first ON-phase of the flash cycle:
Q1 (i(0), loc(0), . . . , i(k0 − 1), loc(k0 − 1)) ≡
k0 −1
( =0
Current() > 80 ∧ FLASH CTRL.EMER OFF()) ∧
0 −1
OUTPUT CTRL.IDLE()) ∧
( =0
k0 −1
( =
OUTPUT CTRL.FLASHING.ON())
0
Now any solution to the BMC instance
b1 =
k0 +c−1
j=0
Φ(i(j), s(j), s(j + 1)) ∧
Q1 (i(0), loc(0), . . . , i(k0 − 1), loc(k0 − 1)) ∧
P2 (i(k0 ), loc(k0 ), . . . , i(k0 + c), loc(k0 + c))
238
with P2 as defined in Example 1 results in a representative for this equivalence
class. For example, b1 can be solved with the timed input trace2
w1 (0, (TurnIndLeft = 0, TurnIndRight = 0, Current = 100),
(100, (1, 0, 90)), (435, (1, 0, 70))
as well as with the equivalent trace
(200, (1, 0, 98)), (210, (1, 0, 10))
Another path through the zone graph passes through locations
(FLASH CTRL.EMER OFF, OUTPUT CTRL.OFF) →
and can be characterised by
Q2 (i(0), loc(0), . . . , i(k0 − 1), loc(k0 − 1)) ≡
k0 −1
( =0
Current() > 80 ∧ FLASH CTRL.EMER OFF()) ∧
0 −1
( =0
OUTPUT CTRL.IDLE()) ∧
1 −1
( =
OUTPUT CTRL.FLASHING.ON()) ∧
0
k0 −1
( =1 OUTPUT CTRL.FLASHING.OFF())
with suitable 0 < 0 < 1 < k0 . This equivalence class is determined by BMC
instance
k0 +c−1
Φ(i(j), s(j), s(j + 1)) ∧
b2 =
j=0
Q2 (i(0), loc(0), . . . , i(k0 − 1), loc(k0 − 1)) ∧
P2 (i(k0 ), loc(k0 ), . . . , i(k0 + c), loc(k0 + c))
and b2 could be solved, for example, with the input trace
w3 = (0, (TurnIndLeft = 0, TurnIndRight = 0, Current = 100),
(200, (1, 0, 98)), (550, (1, 0, 10))
Since the size of region graphs is known to grow exponentially with the number of clocks (see [1, p. 70]), the zone graphs – though representing further
abstractions of the region graphs – may still become quite large for real-world
problems, so that the number of cycle-free paths may induce too many equivalence classes to be exercised on the system under test during a test campaign
of acceptable duration. In such a situation a uniform distribution of the paths
should be enforced. Techniques for statistic path selection have been suggested
in [4].
2
Trace elements are pairs (τ, x) with time stamp τ and input vector x.
239
4.3
Boundary Value Testing
It is a well-known fact that many critical implementation errors are revealed by
choosing inputs at the boundary between different types of behaviours, such as
– the boundary between legal and illegal data ranges,
– the time boundary when a clock reaches a given threshold, or
– the boundary between equivalence classes.
Normal behaviour boundary value testing selects inputs which are always on the
admissible side of the specified bounds, robustness boundary value testing selects
the inputs from the illegal side of the bounds.
In analogy to equivalence testing for timed reactive systems we first have to
clarify when a timed input trace should be regarded as a boundary input to the
system under test. To this end, to input traces are defined to be close to each
other if
1. they have the same length,
2. each pair of corresponding trace elements (ti , xi ), (ui , xi ) is close in the
canonic metric induced by the data types.
For integral numbers and enumeration types “close” means a numeric distance
of 0 or 1. For time stamps ti , ui closeness depends on the latency of the system
under test, that is, if |ti − ui | is less or equal to the smallest time interval
where consecutive inputs can still be captured and lead to the system responses
required. For floating point data types closeness depends on the resolution of
the data type: If the floating point number precision available is much finer
than the resolution ε > 0 required for the control task under consideration,
x1 , x2 ∈ floatingpoint type are considered close if |x1 −x2 | < ε. Alternatively,
if the control task really exhausts the resolution offered by the data type, close
values should only differ by a number of ulp (units in the last place), that is, the
distance measured in the number of least significant bits in the floating point
format considered [7, p. 289]. For strings, the closeness notion may be based on
the Hamming distance [6].
With this concept of closeness at hand, we can define an input trace w1 to
represent a boundary value test case if there exists an input trace w2 which is
close to a prefix of w1 and is contained in another equivalence class (or stimulates
another path through the zone graph) than w1 .
The automated construction of boundary test cases is best performed in
combination with the elaboration of equivalence classes: Recall from the sections
above that a representative of an equivalence class is constructed by finding a
solution
z = (t(k), (i(k), loc(k), v(k), tim(k), o(k))) | k ∈ {0, . . . , c}
of a suitable BMC instance b as given in Equation 1. The input trace w is
extracted from z by restriction to the points in time where the input vector
changes, say
w = (t(i ), i(i )) | ∈ {0, . . . , m}, 0 ≤ i ≤ c, 0 ≤ t(i0 ) < . . . < t(i )
240
for some suitable m ≤ c (recall that some time has to pass between changing
input vectors). Now we can perform variations on the input trace w by applying
zero, one or more changes of the following kind to each element (t(i ), i(i )) in
w:
1. For 0 < , time point t(i ) is varied in the interval [t(i−1 ), t(i+1 )]; the
variation value is denoted by ti ∈ [t(i−1 ), t(i+1 )].
2. In analogy, time point t(i0 ) of w is varied in the interval [0, t(i1 )], and time
point t(im ) is varied as [t(m), ∞).
3. Each input component of xn (i ) of i(i ) = (x1 (i ), . . . , xm (i )) can be varied
within its admissible bounds (since we are dealing with normal behaviour
boundary tests), leading to variation value xn (i ) and associated vector i (i ).
For a given input variation
w = (t (i ), i (i )) | ∈ {0, . . . , m}, 0 ≤ i ≤ c, 0 ≤ t(i0 ) < . . . < t(i )
it is checked whether it still solves the BMC instance without changing the locations, that is, we can find suitable v (k), tim (k), o(k) such that
z = (t (k), (i (k), loc(k), v (k), tim (k), o (k))) | k ∈ {0, . . . , c}
is still a solution of b. The variation process is performed until a pair of traces
z , z with the given locations loc(k) is found such that
– z solves b,
– z does not solve b,
– A prefix of the input trace w associated with z is close to a prefix of the
input trace w associated with z .
Example 3. Consider input trace w1 defined in Example 2 and its associated
equivalence class. Assuming that the system under test can capture inputs with
a precision of 1ms, the following input trace represents a boundary value of the
same equivalence class.
(100, (1, 0, 81)), (439, (1, 0, 80))
Obviously w1 is still a solution of P2 which traverses the same locations as w1 .
The traces
w1 (0, (TurnIndLeft = 0, TurnIndRight = 0, Current = 100), (100, (1, 0, 80))
(100, (1, 0, 81)), (440, (1, 0, 81))
however, are close to prefixes of w1 and are associated with other equivalence
classes: Trace w1 forces the system to remain in location
241
and w1 induces a path through locations
(FLASH CTRL.EMER OFF, OUTPUT CTRL.OFF) →
The process of identifying boundary input traces is considerably sped up by
application of the following techniques:
1. For a given input trace element (t(i ), i(i )) only those symbols that are
referenced in the constraints of their associated zone graph nodes need to
undergo a variation: In Example 3 above it was not necessary to perform
variations of the time points t(0) = 0, t(1) = 100 because the initial zone
(FLASH CTRL.EMER OFF, OUTPUT CTRL.OFF, Current > 80)
did not depend on any clocks.
2. Time boundaries are always given by the clock whose deadline is closest to
the current time, but which has not yet elapsed.
3. Zones specified by linear constraints about inputs and state variables can
be solved by specialised algorithms such as the Simplex algorithm for linear
constraint systems of real values or by Fourier Motzkin elimination [17] for
linear inequations involving integral numbers.
4. In the general case involving non-linear zone constraints with transcendent
mathematical functions bi-partitioning can be applied as described in [7]:
(a) The interval vector consisting of initial intervals for each relevant input
variable from i(i ) is partitioned into a collection of sub-vectors Vj , 0 <
j ≤ m such that each function occurring in the constraint is monotonic
when restricted to a vector Vj .
(b) A sub-vector Vj is identified such that the BMC instance b can be solved
without changing the sequence of locations, when some vertex v1 of Vj is
used as input vector, and such that b can not be solved without changing
the sequence of locations, when some other vertex v2 of Vj is used as
input.
(c) By bi-partitioning the edges of Vj two vertexes v1 , v2 with the same
properties as v1 , v2 can be found such that v1 , v2 are sufficiently close to
each other.
(d) Using v1 for the relevant components of i (i ) and keeping the other
components as given in i(i ) result in a boundary input trace.
4.4
Error Seeding and Mutation Testing
After having generated test cases and test data guaranteeing full requirements
coverage, adequate consideration of equivalence classes and boundary values, the
242
resulting test suite will still not be exhaustive in general. This means that some
errors of the system under test will not be uncovered by the test suite. Therefore
error seeding and mutation testing are applied as the preferred technique to measure the strength of a test suite with respect to its error detection capabilities.
In model-based testing this technique is used as follows:
1. Error seeding: The model is changed according to a suitable random distribution by modifying expressions and state transitions. This results in a
mutation of the original model.
2. An executable mutant simulation is generated from the corrupted model.
3. Mutation testing: The mutant is tested against the original test suite which
had been generated before using the original model.
4. If the test suite uncovers an error in the mutant this bug is fixed and a
regression test is performed by re-running the complete test suite.
5. If repetitive application of bug-fixing and regression testing uncovers all errors originally implanted in the mutant the test suite is considered as sufficiently effective for error detection.
6. For each uncovered bug a new test case and test data are constructed so
that this error will be detected by the new test which is then added to the
test suite. In order to make this process as efficient as possible it is desirable
to automate this test generation process.
For the generation of test data uncovering a mutation we consider the system
consisting of original model (transition relation Φ) and mutant (transition relation Φ ), both receiving the same inputs but managing their own state variables
and clocks s and s and writing to their own output vectors o and o , respectively. The mutant is tainted with a single error, this is the one for which the
new test has to be constructed. Our objective is now to generate a timed input
trace such that original model and mutant produce different timed output traces
(back-to-back test principle). This results in a BMC instance (“MT” standing for
“Mutation Testing”)
bM T ≡
c−1
(Φ(i(j), s(j), s(j + 1)) ∧ Φ (i(j), s (j), s (j + 1)))
j=0
∧ P (o(0), o (0), . . . , o(c), o (c))
with
s(0) = s (0)
P (o(0), o (0), . . . , o(c), o (c)) ≡
c
(o(j) = o (j))
j=0
While this BMC instance captures the task of mutation test construction, it
may be too time-consuming to be solved in general; in particular, because the
dimension of the state space has been doubled. In practice it is more efficient to
construct the test by re-using information from the already existing test suite:
243
1. Since the existing test suite already provides requirements coverage, there
exists a test driving the system into the pre-state (s(k), s (k)) which has
been tainted with the error seed, that is, s(k) = s (k).
2. Using the techniques described in [18] we can construct an input trace w
which, when exercised on the pre-state (s(k), s (k)) distinguishes s(k) and
s (k) by producing different timed output traces.
5
Conclusion
In this paper a formal basis for automated requirements-based, equivalence,
boundary value and mutation testing has been presented. For each of these
methods the problem of automated test case and test data generation could
be reduced to the solution of reachability problems typically encountered in
bounded model checking.
The solution of the reachability problems induced by test automation require
extensive support of SMT solvers. Solution techniques based on interval analysis
have been described in [2]. For code-based testing, more powerful interpretation
techniques are needed than in model-based testing in order to cope with pointers,
arrays, union data types and bit vectors; solutions to these problems are given
in [13, 12, 11]. These publications also provide detailed references to the work of
other research groups in the field of test automation.
While this paper investigated the theoretical foundations of automated modelbased testing, the results are currently applied in practice in the fields of avionics, railway and automotive control systems. Aspects related to testing in these
application domains have been described in [10, 8, 14].
Most of the test generation features described in this paper have already
been implemented or are currently integrated into the test automation tool RTTester [19] developed by Verified Systems International GmbH together with the
author’s research team at the University of Bremen. This tool provides the core
components for an integrated testing and verification environment, where codebased and model-based formal verification, abstract interpretation and testing
can be performed in an integrated manner and in compliance with the requirements of applicable standards for safety-critical systems development.
Acknowledgements. I would like to express my gratitude to Bernd Krieg-Bückner
for his invaluable support of both my academic and industrial career and for his
competence and resourcefulness as a project partner, co-author and colleague.
References
1. B. Bérard et. al. Systems and Software Verification. Springer, 2001.
2. Bahareh Badban, Martin Fränzle, Jan Peleska, and Tino Teige. Test automation for hybrid systems. In Proceedings of the Third International Workshop on
SOFTWARE QUALITY ASSURANCE (SOQUA 2006), Portland Oregon, USA,
November 2006.
244
3. Tsun S. Chow. Testing software design modeled by finite-state machines. IEEE
Transactions on Software Engineering, SE-4(3):178–186, March 1978.
4. A. Denise, M.-C. Gaudel, and S.-D. Gouraud. A generic method for statistical
testing. In Proceedings of the 15th International Symposium on Software Reliability
Engineering (ISSRE’04), pages 25–34, 2004.
5. European Committee for Electrotechnical Standardization. EN 50128 – Railway
applications – Communications, signalling and processing systems – Software for
railway control and protection systems. CENELEC, Brussels, 2001.
6. Richard W. Hamming. Error detecting and error correcting codes. Bell System
Technical Journal, 26(2):147–160, 1950.
7. Luc Jaulin, Michel Kieffer, Olivier Didrit, and Éric Walter. Applied Interval Analysis. Springer-Verlag, London, 2001.
8. J. Peleska and A. Tsiolakis. Automated Integration Testing for Avionics Systems.
In Proceedings of the 3rd ICSTEST – International Conference on Software Testing, April 2002.
9. Jan Peleska. Formal Methods and the Development of Dependable Systems. Number
9612. Christian-Albrechts-Universität Kiel, Institut fr Informatik und Praktische
Mathematik, December 1996. Habilitationsschrift.
10. Jan Peleska. Formal methods for test automation - hard real-time testing of controllers for the airbus aircraft family. In Proc. of the Sixth Biennial World Conference on Integrated Design & Process Technology (IDPT2002), Pasadena, California, June 23-28, 2002. Society for Design and Process Science, June 2002. ISSN
1090-9389.
11. Jan Peleska. A unified approach to abstract interpretation, formal verification and
testing of c/c++ modules. In John S. Fitzgerald, Anne E. Haxthausen, and Husnu
Yenigun, editors, Theoretical Aspects of Computing - ICTAC 2008, 5th International Colloquium, volume 5160 of Lecture Notes in Computer Science, pages 3–22.
Springer, 2008.
12. Jan Peleska and Helge Löding. Symbolic and abstract interpretation for c/c++
programs. In Proceedings of the 3rd intl Workshop on Systems Software Verification
(SSV08), Electronic Notes in Theoretical Computer Science. Elsevier, February
2008.
13. Jan Peleska, Helge Löding, and Tatiana Kotas. Test automation meets static analysis. In Rainer Koschke, Karl-Heinz Rödiger Otthein Herzog, and Marc Ronthaler,
editors, Proceedings of the INFORMATIK 2007, Band 2, 24. - 27. September, Bremen (Germany), pages 280–286.
14. Jan Peleska, Oliver Möller, and Helge Löding. Model-based testing for modeldriven development with uml/dsl. In Proceedings of the Software & Systems Quality
Conference 2008 (SQC 2008).
15. S. Ranise and C. Tinelli.
Satisfiability modulo theories.
TRENDS and
CONTROVERSIES–IEEE Magazine on Intelligent Systems, 21(6):71–81, 2006.
16. SC-167. Software Considerations in Airborne Systems and Equipment Certification. RTCA, 1992.
17. Alexander Schrijver. Theory of Linear and Integer Programming. John Wiley &
sons, 1998.
18. J.G. Springintveld, F.W. Vaandrager, and P.R. D’Argenio. Testing timed automata. Theoretical Computer Science, 254(1-2):225–257, March 2001.
19. Verified Systems International GmbH, Bremen. RT-Tester 6.2 – User Manual,
2007.
245
Jan Peleska is professor for computer science at the
University of Bremen, where he teaches operating systems and distributed systems. His research focus is
on verification, validation and testing of safety-critical
embedded real-time Systems. He is co-founder of the
company Verified Systems International GmbH, where
the results of his research work are applied to avionic
software, space mission systems and railway and automotive control systems. His first contacts to the University of Bremen were made through Bernd KriegBrückner, and they were partners in the UNIFORM
research project on the integration of different formal methods and associated tools. Bernd considerably
helped paving the way for the foundation of Verified
Systems by introducing Jan to new industrial project
partners in the field of space transportation systems.
Regularity based on categorical algebra
(dedicated to the 60th birthday of Bernd Krieg–Brückner)
Horst Reichel
Institut für Theoretische Informatik
Technische Universität Dresden
D–01062 Dresden, Germany
[email protected]
Abstract. In [6] the author has sketched an approach to regular subsets
for arbitrary inductively defined data types. This development is motivated by the increasing interest in unranked trees as a foundation for
XML (see [5], [1]) and in semi–structured date.
The aim of this paper is a precise formalization of the ideas developed in
the previous paper. The formalization is based on initial algebras such
that the fundamental operations may have rich structured domains. The
most liberal approach with respect to algebraic operations with structured domains is the categorical notion of T –algebras in the sense of
[2]. Therefore we will use categorical universal algebra as basis of the
formalization. Regular T –algebras are introduced as generalizations of
bottom–up automata for unranked trees [8]. It is shown that the category of regular T –algebras is closed with respect to finite colimits which
provides a useful basis to compose regular T –algebras that represent
accepting automata of generalized regular data sets.
1
Basic notions of categorical algebra
The reader is assumed to have some basic knowledge in category theory as
presented in [2].
Let T : Set → Set be any endofunctor of the category of sets. A T –algebra is
a pair A = (A, α : T (A) → A) consisting of the carrier set A and the structure
map α : T (A) → A of A.
A homomorphism f : A → B, where A = (A, α : T (A) → A) and B = (B, β :
T (B) → B) are given T –algebras, is a morphism f : A → B in Set commuting
with the structure maps, i.e. f ; β = α; T (f ). TAlg denotes the category of all
T –algebras and UT : TAlg → Set denotes the forgetful functor which assigns to
each T –algebra the carrier set. A type functor T : Set → Set is called a varietor
[2] if the forgetful functor UT : TAlg → Set has a left adjoint FT : Set → TAlg .
The endofunctor FT ; UT : Set → Set is called the monad freely generated by
T : Set → Set.
In case of classical algebras the type functor is a finite sum of finite products
of the identity functor.
247
An example outside of classical algebra are list algebras. List algebras are
given by the type functor TList : Set → Set with TList (M ) = M ∗ . In case of list
algebras the structure map assigns to each finite sequence (or list) of elements
of the carrier set another element of the carrier set. It is well known that the
category of list algebras (TList )Alg has an initial algebra which represents finitely
branching unranked trees.
Let L be a given set of labels and TL list : Set → Set be the endofunctor with
TL list (M ) = L × M for each set M and TL list (f ) = IdL × f for each morphism
f : A → B in Set. This type functor is again a varietor and the initial algebra
represents labeled unranked trees where the labels on the nodes are elements of
the given set L.
If one takes the varietor Tf ineSet : Set → Set which assigns to each set M
the set Tf ineSet (M ) of all finite subsets of M then the associated initial algebra
represents unranked, repetition free, unordered trees. By the same construction
as above one could generated also the labeled version of this kind of unranked
trees.
This few examples should be enough to demonstrate the greater expressive
power of categorical algebra.
For a better understanding of the following we will recall from [2] the construction of free T –algebras. We define a chain of objects and morphisms in Set
indexed by all ordinals:
f0,1
f1,2
fω,ω+1
fn,n+1
F0 → F1 → . . . → Fω −→ Fω+1 → . . . → Fn −→ Fn+1 → . . .
where
– F0 = ∅, F1 = T (F0 ), Fn+1 = T (Fn ),
f0,1
f1,2
f0,1
– → is the embedding of the empty set, −→= T (−→) and
fn,n+1
fn−1,n
−→ = T ( −→ )
F0,1
F1,2
– Fω is the colimit of the preceding chain, i.e., the colimit of F0 → f1 →
. . . →, which is also the construction for each limit ordinal. The morphism
fω,ω+1
Fω −→ Fω+1 = T (Fω ) is induced by the universal property of the colimit
construction of Fω .
The varietor T : Set → Set is called constructive if the transfinite construction reaches a fixed point and it is called finitary if Fω is a fixed point, i.e.
T (Fω ) = Fω .
This is the construction of the initial T –algebra, i.e. of the T –algebra freely
generated by the empty set. The construction of a T –algebra freely generated
by the set X can be reduced to the construction of the initial (T + X)–algebra.
If T : Set → Set is a finitary varietor then is the monad freely generated
by T : Set → Set again a finitary varietor. This property of finitary varietors is
basic for the following generalization of regularity from strings and ranked trees
to arbitrary inductively defined data types.
248
2
Generalization of Regularity
In the following we will introduce the concept of regular subsets of initial T –
algebras in an inductive way.
The basic case is given by any finitary varietor Tf ineSet : Set → Set which
preserves finite sets. Any functor which is a finite sum of finite products of the
identity functor is a finitary varietor and preserves finite sets. This implies that
the basic case comprises classical algebras.
If we consider finite T –algebras with a distinguished subset of accepting
states as button up automata then in the basic case a subset of an initial T –
algebra is regular if it is the inverse homomorphic image of the set of accepting
states of a finite T –algebra A with respect to the unique homomorphism from
the initial T –algebra to the finite T –algebra.
Definition 2.1.(base case) Let T : Set → Set be a varietor preserving finite
sets. A subset X ⊆ F of the initial T –algebra F is called regular, if there is a finite
−1
(A0 ),
T –algebra A = (A, α) and a distinguished subset A0 ⊆ A with X = fA
where fA : F → A is the unique morphism from the initial T –algebra F to the
finite algebra A.
Let Σ = {a1 , . . . , an } be a finite alphabet. The set Σ ∗ of all finite words
over the alphabet Σ can be seen as the carrier set of an initial Tstring –algebra,
where the varietor Tstring : Set → Set corresponds to a signature consisting of
a constant and a unary operation for each element of Σ. Finite Tstring –algebras
with a distinguished subset correspond to finite deterministic automata and the
previous definition redefines the concept of regular sets of strings over a finite
alphabet directly.
We see that the notion introduced by the basic case extends the well known
notion of regularity for strings and ranked trees following the line of Thatcher
and Wright from 1968 [7].
But, the previous definition yields also the concept of regular sets for finitely
branching, repetition–free , unordered trees, since the varietor Tf inset : Set →
Set, which assigns to each set the set of all finite subsets, this functor preserves
finite sets.
The more interesting generalization is given by the following induction step,
but this needs some preparations.
Let T : Set → Set be a finitary varietor, UT : TAlg → Set the forgetful
functor and LT : Set → TAlg the unique left–adjoint functor to the forgetful
functor.
The composed functor LT ; UT : Set → Set is called the monad freely generated by T : Set → Set [3].
Definition 2.2. (inductive definition of regularity)
Each finitary varietor T : Set → Set which preserves finite sets is called a type
functor with a regularity concept.
Each monad freely generated by a type functor with a regularity concept is again
a type functor with a regularity concept.
Let LT ; UT : Set → Set be a type functor freely generated by a type functor
T : Set → Set with a regularity concept.
249
Let Y be a finite set. A subset X ⊆ UT (LT (Y )) is called regular if there is a
finite LT ; UT –algebra A = (A, α) with a distinguished subset A0 ⊆ A and a
mapping c : Y → A such that
– for each a ∈ A the set α−1 (X) ⊆ UT (LT (A)) is a regular.
−1
– and X = fA,c
(A0 ), where fA,c denotes the unique homomorphism induced
by the the mapping c : Y → A and the LT ; UT –algebra A.
For a type functor T : Set → Set a finite T –algebra A will be called regular
if for each element a ∈ A the inverse image α−1 ({a}) ⊆ T (A) is a regular subset.
Evidently, if T : Set → Set preserves finite sets, then every finite T –algebra is
regular.
The type functor TList : Set → Set is a type functor with a regularity concept
according to the inductive definition above. The resulting notion of regular sets
for the data type of unranked ordered trees coincides with the recent definitions
in literature.
2.1
Example
Let us consider the type functor T1 : Set → Set with T1 (X) = {a, b, A, B}∗ ×
X ∗ . A T1 –algebra E is then given by a carrier set E and an operation α :
{a, b, A, B}∗ × E ∗ → E. The initial T1 –algebra represents finite unranked unordered trees where each node is decorated with an attribute being a string over
the alphabet {a, b, A, B}.
– Let be E = {s0 , s1 , s2 , s3 , sd }
– and for (w, l) ∈ {a, b, A, B}∗ × E ∗ let be
–
⎧
s0 if w ∈ L(a∗ )
l ∈ {nil}
⎪
⎪
⎪
⎪
l ∈ {s0 s0 , s0 s0 s0 }
⎨ s1 if w ∈ L(b∗ )
α(w, l) = s2 if w ∈ L((A + B)a∗ ) l ∈ {s1 s1 , s0 s1 }
⎪
⎪
s3 if w ∈ L((A + B)b∗ ) l ∈ {s2 s2 s2 , s1 s2 s3 }
⎪
⎪
⎩
else
sd else
– and let {s3 } ⊆ E be a distinguished subset (of accepting states).
Then we have four interesting classes of attributed trees, defined by the
inverse homomorphic images of s0 , s1 , s2 , s3 respectively, and the complement of
the union of this classes, represented by sd .
– s0 represents the class of all trees with exactly one node labeled with a string
w ∈ L(a∗ ).
– s1 represents the class of trees with two or three sons, classified by s0 and
the root is labeled with a string w ∈ L(b∗ ).
– s2 represents the class of trees with two sons such that the first is classified
by s1 or s0 and the second son is classified by s1 . Finally the root is labeled
with a string L((A + B)a∗ ).
250
– Finally, the accepting state s3 represents the class of trees with exactly three
sons, where either all of them are classified by s2 or the first son is classified
by s1 , the second by s2 and the third again by s3 . The root is labeled by a
string w ∈ L((A + B)b∗ ).
The example is basically a partial T1 –algebra with a one–point completion
given by the state sd . In terms of automata this completion point is a trap. If
the computation once reaches the trap it can never leave it.
Motivated by this example we will use in the following finite partial T –
algebras as a model for bottom–up automata wich recognize generalized regular
sets.
Definition 2.3. (one–point completion)
Let A = (A, α : T (A) →?A) be a partial T –algebra. The one–point completion A∗ = (A + 1, α∗ : T (1 + A) → 1 + A) is a total T –algebra such that
α∗ ((T (iA ))(x)) = iA (x) if x ∈ dom(α) and α+ (y) = i1 (∅) else, where 1 = {∅}
and i1 : 1 → 1 + A, iA : A → 1 + A are the canonical injections.
The set accepted by a regular partial T –algebra A is then the set accepted
by the one–point completion A∗ as defined above.
3
Regular Expressions based on Limits and Colimits
In the following we will reduce operations on regular subsets in the initial T –
algebra, where T : Set → Set is a type functor with a regularity concept, to
finite limits and colimits in the category of partial regular T –algebras with week
homomorphisms.
Let T : Set → Set be a varietor with a regularity concept. A partial regular
T –algebra A = (A, α : T (A) →?A) is given by a finite set A together with a
partial mapping α : T (A) →?A such that for each a ∈ A the set α−1 ({a}) ⊆
T (A) is regular.
For partial regular T –algebras A = (A, α), B = (B, β) a total mapping
f : A → B is a weak homomorphism if x ∈ dom(α) implies f (x) ∈ dom(β)
and f (α(x)) = β((T (f ))(x)). TprAlg denotes the category of partial regular T –
algebras with week homomorphism.
First we show that the category TprAlg is closed with respect to finite colimits.
Theorem 3.1. TprAlg is closed with respect to finite colimits.
Proof: The empty T –algebra with empty domain of the structure mapping
is the colimit of the empty diagram.
For finite coproducts it is sufficient to show the existence of the coproduct
A + B for any A = (A, α : T (A) →?A), B = (B, β : T (B) →?B) from TprAlg .
On the set A + B with the injections iA : A → A + B, iB : B → A + B we define
the relation ρ ⊆ (A + B) × (A + B) as the smallest equivalence relation which
satisfies the following two conditions:
(1) ρ ⊇ {(iA (α(jA (x))), iB (β(jB (x)))) | x ∈ T (∅) ∧ jA (x) ∈ dom(α) ∧ jB (x) ∈
dom(β)}
(2) If (wA ∈ dom(α) ∧ wB ∈ dom(β) ∧ (T (iA ; natρ )(wA ) = (T (iB ; natρ )(wB ))
then (((iA (α(wA )), iB (β(wB ))) ∈ ρ.
251
This relations allows to define on the quotient set (A + B)/ρ a T –algebra
Q = ((A + B)/ρ, δ : T ((A + B)/ρ) →?(A + B)/ρ)
with dom(δ) = [T (iA ; natρ )](dom(α)) ∪ [T (iB ; natρ )](dom(β)).
If [x]ρ ∈ [T (iA ; natρ )](dom(α)) then δ([x]ρ ) = natρ (iA (α(x))) and δ([x]ρ ) =
natρ (iB (β(x))) if [x]ρ ∈ [T (iB ; natρ )](dom(β)).
If [x]ρ ∈ [T (iA ; natρ )](dom(α))∩[T (iB ; natρ )](dom(β)) then due to condition (2)
it does not matter if we set δ([x]ρ ) = natρ (iB (β(x))) or δ([x]ρ ) = natρ (iA (α(x)))
the results are equal.
By this definition one gets homomorphisms iA ; natρ : A → Q, iB ; natρ : B →
Q and one can show that with these homomorphisms Q is a coproduct of A and
B in the category of partial T –algebras with weak homomorphisms. Evidently
Q is finite and later we will prove that Q is regular.
Let f : A → C, g : B → C be given weak homomorphisms, let [f, g] : A+B →
C be the canonical mapping induced by f and g and let natker[f,g] ; q = f be the
corresponding factorization. Since homomorphisms preserve existing constants
ker[f, g] ⊇ {(iA (α(jA (x))), iB (β(jB (x)))) | x ∈ T (∅) ∧ jA (x) ∈ dom(α) ∧ jB (x) ∈
dom(β)}
To show that ker[f, g] satisfies also condition (2) we assume wA ∈ dom(α),
wB ∈ dom(β) and T (iA ; natker[f,g] )(wA ) = T (iB ; natker[f,g] )(wB ) This implies
T (q)(T (iA ; natker[f,g] )(wA )) = T (iA ; natker[f,g] ; q)(wA ) = T (f )(wA ) = . . . =
T (g)(wB ) so that γ(T (f )(wA )) = γ(T (g)(wB ). Since f and g are homomorphisms and wA ∈ dom(α), wB ∈ dom(β) we obtain f (α(wA )) = g(β(wB )) or in
other words [f, g](ia (wA )) = [f, g](iB (wB )) what we have to prove.
The next step is the existence of coequalizers. The construction is based on
the notion of a T –congruence. Let A = (A, α : T (A) →?A) be a partial T –
algebra. An equivalence relation ρ ⊆ A × A is called a T –congruence, if x ∈
dom(α), y ∈ dom(α) and T (natρ )(x) = T (natρ )(y) implies (α(x), α(y)) ∈ ρ.
The quotient algebra A/ρ = (A/ρ, δ : T (A/ρ) →?A/ρ) is defined by dom(δ) =
T (natρ )(dom(α)) and δ(T (natρ )(x)) = natρ (α(x)).
Let f : A → B, g : A → B be homomorphisms and ρ(f, g) the smallest
T –congruence in B which contains {(f (x), g(x)) | x ∈ A}. The natural mapping
natρ(f,g) : B → B/ρ(f, g) defines a homomorphism natρ(f,g) : B → B/ρ(f, g)
which is a coequalizer of the given homomorphisms.
Finally we prove inductively that the coproduct of two objects in the category
TprAlg is again in TprAlg and that the coequalizer of f : A → B, g : A → B is in
TprAlg if B is in TprAlg . This will complete the proof.
In the base case a type functor T 0 : Set → Set preserves finite sets, so that
any finite partial T0 –algebra is regular. This means, in the the case the theorem
holds.
0
0
Let UT0 : TAlg
→ Set be the forgetful functor and L0T : Set → TAlg
a left
0
0
adjoint. The LT ; UT : Set → Set is a type functor with regularity concept on
the next inductive level.
We show, that the union of finitely many regular sets in L0T (Y ) is regular
again. It is sufficient, to show this for two regular subsets X1 , X2 ⊆ L0T (Y ).
252
By definition there are regular T 0 –algebras A1 , A2 , distinguished subsets Z1 ⊆
A1 , Z2 ⊆ A2 and mappings c1 : Y → A1 , c2 : Y → A2 such that X1 =
−1
−1
(Z1 ), X2 = fA
(Z2 ).
fA
1 ,c1
2 ,c2
Then the pushout for fA1 ,c1 : L0T (Y ) → A1 , fA2 ,c2 : L0T (Y ) → A2 with the
canonic injection h1 : A1 → Q, h2 : A2 → Q exists. Together with A1 , A2 the
T 0 –algebra Q is regular and it holds
X1 ∪ X2 = (fA1 ,c1 ; h1 )−1 (h1 (Z1 ) ∪ h2 (Z2 )),
i.e., X1 ∪ X2 is regular. Since for both the coproduct and the coequalizer, which
are quotients of finite sets, for each element x the inverse image δ −1 (x) is the
union of finitely many regular set and therefor regular as just proved, the coproduct and the coequalizer are also regular. This means that the category of
regular L0T ; UT0 –algebras is closed with respect to finite colimits. The preceding
construction describes also the induction step.
As next we will show that homomorphisms reflect regular sets.
Theorem 3.2. Let h : A → B be a T –homomorphism, B a partial regular
T –algebra and X ⊆ T (B) a regular set. Then (T (h))−1 (X) ⊆ T (A) is again
regular.
Proof: By definition there is a partial regular T –algebra C, a mapping c : B →
C and a distinguished subset C0 ⊆ C such that (fC,c )−1 (C= ) = X. This implies
the existence of a mapping h; c : A → C so that (fC,h;c )−1 (C0 ) = (T (h))−1 (X)
is regular.
This result helps us to see that TprAlg is also closed with respect to finite
limits.
Theorem 3.3. TprAlg is closed with respect to finite limits.
Proof: Let f, g : A → B be homomorphisms in TprAlg . Then we define the
finite partial T –algebra E = (E, δ : T (E) →?E) with E = {x ∈ A | f (x) =
g(x), x ∈ A}, δ(y) = α(T (iE )(y)) for y ∈ dom(δ) = (T (iE ))−1 (dom(α)), where
iE : E → A is the embedding of the subset E. Since δ −1 (e) = (T (iE ))−1 (α−1 (e))
this subset is regular due to Theorem 3.2. This means, E is regular and evidently
the equalizer of the two homomorphisms.
For any two objects A, B of TprAlg we construct the finite partial T –algebra
A × B = (A × B, (T (pA ); α, T (pB ); β) : T (A × B) →?A × B). Then pA : A × B →
A, pB : A × B → B are homomorphisms and dom((T (pA ); α, T (pB ); β)) =
T (pA )−1 (dom(α)) ∩ T (pB )−1 (dom(β)) is the intersection of two regular subsets.
In the same way as we proved above that a finite union of regular subsets is
is regular we can show that a finite intersection of regular subsets ist regular.
This means TprAlg is closed with respect to finite products. Again by induction
on type functors with a regularity concept one can see that the one–element
T –algebra 1tT with total domain is a final object in TprAlg .
As a direct consequence of the preceding theorems we obtain
Theorem 3.4. For any type functor T with a regularity concept and any
finite set X the regular subsets in T (X) are closed with respect to boolean
operations.
253
In [6] the composition of regular algebras corresponding to sequential composition and the ∗–operation in regular expressions is discussed in a very special
case. This compositions are based on the coproduct and on fusing two elements
of a regular algebra. The fusing of elements is a special case of a pushout construction.
may
Let T : Set → Set be any type functor with regularity concept and 1par
T
denote the one–element regular T –algebra with empty domain of the structure
→ A, b : 1par
→B
mapping. For T –algebras A, B the homomorphisms a : 1par
T
T
select elements and the pushout of these selecting homomorphisms fuses the
selected elements.
For the minimization of automate accepting regular sets of unranked trees
in [8] two different kinds of concatenations for unranked trees are used. This
illustrates, that the syntax of regular expressions can not be simply extended
from strings to more general data types. In [1] the section 10 Hedge and tree
regular expression is empty since 2001. This observation suggests the assumption
that the generalizations of the sequential composition and the ∗–operation on
generalized regular sets depends on the used data type an can not be done in a
uniform way.
We hope that finite colimits of regular T –algebras, understood as accepting
bottom–up automata for regular sets of complex structured data, will be a useful
basis for a future study of the different kinds of regular expression.
In [4] another generalization of regular and context free sets of strings to finite
objects like trees or graphs is presented. This approach is based on universal
algebra of many–sorted algebras and defines the sets in terms of systems of
equations. In the introduction the author claims that automata cannot be used
ar general level since automata have no meaning for abstract algebraic objects.
We hope that we could show that at least to some extend bottom–up automate
can usefully be applied to to abstract algebraic objects.
References
1. M. Murata A. Brüggemann-Klein and D. Wood. Regular tree and regular hedge
languages over unranked alphabets: Version 1. Technical Report HKUST-TCSC2001-0, The Hongkong University of Science and Technology, April 2001.
2. J. Adamek and V. Trnkova. Automata and Algebras in Categories. Kluwer Academic
Publisheres, 1990.
3. M. Barr. Coequalizers and freee triples. Math. Z., (166):307–322, 1970.
4. B. Courcelle. Basic notions of universal algebra for language theory and graph
grammars. Theoretical Computer Science, 163:1–54, 1996.
5. F. Neven. Automata, logic, and XML. In Proceedings CSL 2002, volume 2471 of
LNCS, pages 2–26. Springer, 2002.
6. Horst Reichel. An algebraic approach to regular sets. In Algebra, Meaning, and
Computation, volume 4060 of LNCS, pages 449–458. Springer, 2006.
7. J.W. Thatcher and J.B. Wright. Generlized finite automata theory with an application to a decision problem of second–order logic. Mathematical Systems Theory,
2(1):57–81, 1968.
254
8. Wolfgang Thomas, Julien Christau, and Christof Löding. Deterministic automata
on unranked trees. In Proceedings of the 15th Symposium on Fundamentals of Computation Theory, FCT 2005, number 3623 in Lecture Notes in Computer Science.
Springer, 2005.
Horst Reichel is a professor emeritus at the Technische Universität Dresden. He is obliged to deepest
thanks since in the 80th he has been invited by Bernd
to become a member of the COMPASS Working Group
and to participate in the WADT workshop series. This
was the perfect community to discuss the ideas on algebraic specifications, a topic of low interest and support
in east Germany. Later the author got the possibility
to cooperate with the research group of Bernd in Bremen. One result of this cooperation is the specification
language COCASL. The author is deeply impressed of
the broad field of scientific activities and of Bernd’s
abilities to bring together people.
15 Years of Rolland
Thomas Röfer1 , Christian Mandel2 , Axel Lankenau3 ,
Bernd Gersdorf1 , and Udo Frese2
3
1
E-Mail: {Thomas.Roefer,Bernd.Gersdorf}@dfki.de
2
Fachbereich 3 – Mathematik und Informatik, Universität Bremen,
E-Mail: {cman,ufrese}@informatik.uni-bremen.de
Daimler AG, Research and Advanced Engineering, 71059 Sindelfingen, Germany
Abstract. The paper presents 15 years of research conducted on the
Bremen Autonomous Wheelchair “Rolland”. Rolland is a mobility assistant for the handicapped and the elderly. The paper presents the different
versions of Rolland that were built over the years, as well as the special
input devices that are used with Rolland. Contributions were made to
the state of the art in the areas of self-localization, mapping, navigation, safety, and shared control. A number of assistants are the practical
results of this research conducted.
1
Introduction
The name “Rolland” was coined by Bernd Krieg-Brückner. It is a combination
of the German word “Rollstuhl” for “wheelchair” and the name of the symbol
of the independence and liberty of the Freie Hansestadt Bremen, the “Roland”
monument. The term is now well-established in the area of research on intelligent
mobility assistants.
This paper is structured as follows: first, the different versions of the Rolland
wheelchairs will be presented, followed by the special input devices that were
used in combination with Rolland. Afterwards the research topics that have
driven the development of Rolland are discussed. This work has resulted in
a number of applications that are presented before the paper closes with the
conclusions.
2
The Different Rolland Models
Over the years, different versions of Rolland were set-up on different commercial wheelchairs. The different versions also reflect the development of sensor
technology and computing technology. [1] describes the state of the art in smart
wheelchairs in the year 2000, while [2] presents the state of the art seven years
later. A clear trend is that the design of Rolland deviates less and less from the
256
(a) Rolland I
(b) Rolland II
(c) Rolland III
(d) Rolland IV
Fig. 1. The different Rolland models constructed from 1993 until 2008.
wheelchair used as base, i. e., the additional equipment has become smaller, and
it has been hidden better. Thereby, the additional hardware does impede the
normal usage of a power wheelchair lesser and lesser.
In addition, our 3-D simulator SimRobot [3] has been employed during the
development, i. e., each version of Rolland also has a simulated counterpart in
SimRobot. Thereby, the software development can be significantly simplified,
because algorithms can be tested in simulation before they are applied to the
real system.
2.1
Rolland I
“Rolland I” is based on an old wheelchair of the company Meyra. It was originally
acquired as a mobile platform that was powerful enough to carry a set of analog
artificial neurons that, in the mid-nineties, were quite big and heavy. The front
axle drives the wheelchair while the back axle is used for steering. Therefore, the
wheelchair moves like a car driving backwards. By the student project SAUS
[4] it was equipped with a Pentium 100 computer, twelve bumpers, six infrared
sensors, 16 ultrasonic sensors, and a camera. The infrared sensors can only detect
whether there is an obstacle within a radius of approximately 15 cm; however,
they cannot measure the distance. Two different kinds of ultrasonic sensors are
fitted to the wheelchair: half of the sensors have an opening-angle of 80◦ while
the other half only measure in a range of 7◦ . In addition, the wheelchair can
measure the rotations of its front wheels.
2.2
Rolland II – Meyra Genius
“Rolland II” is based on the commercial power wheelchair Genius 1.522 manufactured by the German company Meyra. As Rolland I, the wheelchair is a
non-holonomic vehicle driven by its front axle and steered by its rear axle. The
human operator controls the system with a joystick. The wheelchair has been
extended by a standard PC (Pentium III 600MHz, 128 MB RAM) for control
257
and user-wheelchair interaction tasks, 27 sonar sensors, and a laser range sensor behind the seat. The sonars are arranged around the wheelchair such that
they cover the whole surroundings. The electronics is able to simultaneously fire
two sensors, one on the left side and one on the right side of the wheelchair.
An intelligent adaptive firing strategy has been introduced by Röfer and Lankenau [5–7]. The sonars are mainly used for obstacle detection. The laser range
finder has an opening angle of 180◦ towards the backside of the wheelchair and
is able to provide 361 distance measurements every 30 ms. It is used for mapping and localization purposes. The original Meyra wheelchair already provides
two serial ports to set target values for the speed and the steering angle as well
as determining their actual values. Data acquired via this interface is used for
dead reckoning. The odometry system based on these measurements is not very
precise, i. e., it performs relatively well in reckoning distances but it is weak in
tracking angular changes. The overall software architecture is described in [8].
2.3
Rolland III – Meyra Champ
Based on the battery-powered wheelchair Meyra Champ 1.594, the third version
of Rolland for the first time featured two laser range finder mounted at ground
level, which allowed for scanning beneath the feet of a human operator. As an
additional sensor device, the system provides two incremental encoders which
measure the rotational velocity of the two independently actuated rear-wheels.
The differential drive kinematics comes along with two passive front castorwheels, giving it the freedom to turn on the spot. The castor-wheels require a
significant amount of force to let them turn, which requires a complex controlling
behavior when changing the driving direction. Three wheelchairs of type Rolland
III have been constructed:
1. The first instance is used as a development platform within the Transregional Collaborative Research Center SFB/TR 8 “Spatial Cognition”. Since
it has no dedicated control PC, a laptop has to be connected (via USB), and
sensors, wheelchair and software must be started in the correct order and
time.
2. The second instance was built up for a demonstration of the Safety Assistant
(cf. section 5.1) in the Heinz Nixdorf Museumsforum as a diploma thesis (see
[9]). The software runs on a PC104 embedded computer installed inside the
battery box. The system can be started using a single switch in about 80
seconds. The wheelchair was used by thousands of visitors of the exhibition
Computer.Medizin in a small demonstration area.
3. The last instance of Rolland III was built up as mobility platform for the
SHARE-it project (http://www.ist-shareit.eu) that is engaged in the field
of Ambient Assisted Living. It uses a more powerful embedded PC of type
EPIA-NX12000EG with a variety of software assistance. An additional microcontroller board observes PC and wheelchair and stops the wheelchair if
the communication is disturbed.
258
(a) Joystick
(b) Head-Joystick
(c) Speech Control
(d) Brain-Computer
Interface
Fig. 2. Different input devices developed for a variety of scenarios and target groups.
2.4
Rolland IV1 – Otto Bock Xeno
In September 2008, the Rolland software has been adapted to a prototype
wheelchair of type Xeno from Otto Bock Healthcare. Its sensor equipment is
very similar to Rolland III (cf. section 2.3), but instead of passive castor-wheels,
it uses a Single Servo Steering (S 3 ) for active steering of the two wheels. In
contrast to a classical Ackermann steering, this steering method allows turning
on the spot (as with the Champ), but without additional force from the differential drive, which results in a very smooth and precise path following. Another
advantage is the extended wheelbase that allows the front laser scanner to scan
between front and rear axles on the left and right side of the wheelchair. The
control PC is a netbook installed under the seat and connected to the CAN bus
of the wheelchair. An emergency stop can be initiated by the CAN based power
control unit if communication problems with the control PC appear.
3
Special Input Devices
Usually electrical wheelchairs are operated by joystick (cf. Fig. 2(a)). From that
perspective they handle the handicapped’s inability to walk by a control loop
that embeds the operator’s remaining sensory-motor capabilities into the vehicle’s actuating body. In the 15 years of Rolland’s development, several interface
techniques have been investigated that not only serve the walking impaired but
also the quadriplegic.
3.1
Head-Joystick
First proposed in [10] and later evaluated in [2, 11, 12], the basic idea of the headjoystick (cf. Fig. 2(b)) is to let the user of an automated wheelchair control the
translational and rotational velocity by continuous pitch and roll movements of
1
As the system is developed in cooperation with a new partner, it will have a different
name. However, since the name has not been decided yet, it is still referred to as
“Rolland IV”.
259
his/her head. Still able to observe the environment by turning the head around
the free yaw-axis without causing any control commands, the user’s head movements around the remaining two axes must exceed a so-called dead-zone in order
to evoke a desired movement. The necessary hardware configuration consists out
of a small-size 3-DOF orientation tracker (IMU) that is mounted at the back
of the operator’s head by means of an easy to wear headband. Here, the IMU
continually monitors the user’s head posture and acceleration w.r.t. the pitch-,
yaw-, and roll-axis.
3.2
Speech Control
With the interpretation of natural language route descriptions [13–15], speech
control has been tackled as a verbal interface that allows for the execution of utterances such as “Go down the corridor and take the second door to the left” (cf.
Fig. 2(c)). One of the basic concepts involved is the decomposition of instructions
given by humans into sequences of imprecise route segment descriptions. By applying fuzzy rules for the involved spatial relations and actions, a search tree is
constructed that can be searched in a depth-first branch-and-bound manner for
the most probable goal configuration w.r.t. the global workspace knowledge of
the wheelchair.
3.3
Brain-Computer Interface
Brain-Computer interfaces, or BCIs for short, are tools that facilitate communication with artificial artifacts via direct measures of the human brain’s activity.
In cooperation with the Bremen Institute of Automation 4 , classified steady-state
visual evoked potentials (SSVEPs) in brain activity have been used to derive
qualitative directional navigation commands. The overall system that has been
first described in [16] projects the given commands onto a frequently updated
route graph representation of the environment. The metrical target locations
deduced are subsequently navigated to by the application of the well-established
Nearness Diagram Navigation method (cf. section 4.3).
4
Research Topics
During development of Rolland, we have done research in many areas, some of
which are traditional topics in mobile robotics such as mapping, self-localization,
or navigation. Others are more specific to a wheelchair, i. e., a device that carries
a person who is also partially controlling it (shared control ).
4.1
Mapping and Self-Localization
Self-Localization was investigated along routes, in route graphs, and in metric maps. The latter was done in combination with mapping, i. e. simultaneous
localization and mapping (SLAM).
4
Contact: A. Gräser, and T. Lüth. Institute of Automation, 28359 Bremen, Germany.
E-Mail:{ag,thorsten.lueth}@iat.uni-bremen.de.
260
Localization Along Routes. In [23–26] a simple approach for the acquisition and representation of spatial knowledge needed for controlling a semiautonomous wheelchair is presented. Simplicity is required in the domain of
rehabilitation robotics because typical users of assistive technology are persons
with severe impairments who are not technical experts. The approach proposed
is a combination of carrying out so-called basic behaviors and the analysis of
the wheelchair’s track of motion when performing these behaviors. As a result,
autonomous navigation in the user’s apartment or place of work can be learned
by the wheelchair by teaching single routes between potential target locations.
The work focuses on the analysis of the motion tracks recorded by the vehicle’s
dead reckoning system. As a means for unveiling the structure of the environment while the system is moving, an incremental generalization is applied to the
motion tracks. In addition, it is discussed how two of such generalized motion
tracks are matched to perform a one-dimensional self-localization along the route
that is followed.
RouteLoc – Self-Localization in Route Graphs. RouteLoc is a selflocalization approach that needs only minimal input (i. e. no expensive proximity
sensors are required) to absolutely localize a robot even in large-scale environments [27–30]. RouteLoc works robustly in structured large-scale environments.
It can be seen as an extension of the approach discussed above to localize in maps
instead of a single route. As input data, RouteLoc requires a topological-metric
map and a so-called incremental route generalization. It calculates a position
estimate in a human-compatible form, e. g. “The robot is in the corridor leading
from A to B, about x meters past A”. In [27], RouteLoc solves, among others,
the so-called “kidnapped robot problem” in real world experiments with Rolland
on the campus of the Universität Bremen.
Scan-Matching-based SLAM. In [32–34, 31] an approach to generate consistent maps in real-time using a laser range sensor is presented. It improves an
existing scan-matching algorithm in several aspects. It also introduces a mapping method that is based on the scan matching method. Using a laser scanner
mounted on the wheelchair, it generates consistent maps, i. e. maps that do not
have discontinuities resulting from the accumulation of errors in the mapping
process. As such accumulations cannot be avoided, the resulting errors are corrected whenever the wheelchair returns to areas already mapped. An important
property of the approach is its real-time capability. The mapping is performed
on the fly and thus, the resulting maps can immediately be employed for selflocalization. An example of the mapping process is given in Fig. 3.
4.2
Behavior-based Navigation
Behavior-based Navigation, in contrast to metric navigation and planning, is
a reactive way to navigate. Usually, the representation of the environment is
not metric. Instead, features of the environment are associated with necessary
261
Fig. 3. Four snapshots while mapping an office floor.
changes in the behavior. Two approaches have been investigated: image-based
homing and navigation using basic behaviors.
Image-based Homing. In [17–19, 35–38] an image processing method is presented that enables a robot to orientate in unchanged, existing environments.
The approach is based on the use of one-dimensional 360◦ (panoramic) color
images that are taken by a special optical sensor. From two of these images,
the Panama algorithm determines the spatial relationship between the positions
where the images have been taken. The approach can be compared to methods
that determine the optical motion flow but it addresses a different application: it
is used to determine the spatial relations between positions that may be located
several meters apart. The image processing method is embedded in a navigation technique in which the environment is represented as a network of routes
along which the navigating agent can move. These routes are represented as sequences of panoramic images. This route knowledge is acquired by teaching. A
teacher only presets the routes that should be learned but not the images that
are required for their description. These images are independently selected by
the autonomous system during the training, depending on the particular environment and the system’s kinematic restrictions.
Basic Behaviors. In [17, 20–22] an approach is presented that describes routes
as sequences of basic behaviors, such as wall-centering, wall-following, entering
a door, etc. The recognition of routemark constellations triggers the switching
between these behaviors. The information when to use which basic behavior and
when to switch to the next one is acquired during a teaching phase (cf. Fig. 4).
The method detects possible navigational errors and tries to recover from them
by backtracking the previous way.
4.3
Metric Navigation
Local navigation approaches that provide the ability to deal with dynamic and
unforeseen obstacles typically employ a sensor-based map of the robot’s local
262
Behaviors
wall-centering
wall-following left
wall-following right
stop
Routemarks
X routemark X
routemark
constellation
7
5
1
9
2
8
6
3
2
Fig. 4. Teaching of routes as an association of routemark constellations and basic
behaviors.
neighborhood for planning purposes. By means of this data-structure, geometric path planning algorithms and reactive steering methods either calculate a
complete trajectory that leads the vehicle to the designated target, or just determine a set of velocities to be applied in the next time frame. In the following
we present local navigation approaches implemented on Rolland during the last
15 years.
The Nearness Diagram Navigation approach (NDN), initially developed by
Minguez et al., is a representative of the class of reactive steering methods. NDN
describes the sensor measurements of the visible part of the environment along
with the desired target position as a unique element of an exclusive and complete
set of situations. Each of the five situations originally defined is associated with
a specific control law that determines the translational and rotational speed to
be applied, as well as the desired direction of movement. Since Rolland is an
example for a non-circularly shaped mobile robot that cannot independently
control its kinematic degrees of freedom, we have augmented the basic NDN
control laws in such a way that they look ahead for upcoming turn maneuvers
and initiate a preparatory sheer out movement when necessary (cf. [39] for an
in-depth discussion).
Behavior-Based Local Navigation splits the local navigation problem into
two parts. The first one is to approach the goal and the second one is to avoid
obstacles on the way. The first part, i. e. the local navigation module, simply
determines the actual driving command from the current pose of the wheelchair
and a local target pose in each control cycle. A pose consists of the three components (x, y, rotation) in global coordinates. The speeds determined are used to
control the Driving Assistant that is described in section 5.2. The local navigation generates motion commands as if the wheelchair would drive in free space,
263
(a) Illustration of the Nearness Diagram Navigation approach within a simulated environment. Sod and Srd denote the borders of the free walking area, while sgoal and
θ describe the direction to the local target pg and the current orientation of the
wheelchair respectively (cf. [39]).
(b) The Bezier-Curve Path (c) The A* based Path Planning approach
Planner selects an optimal
searches the discretized configuration space
path (red) from a set of
(x,y,θ) for an optimal path. Atomic transpossible paths (green) by
lational moves are illustrated as green lines,
reducing the time of travel
while atomic rotational moves are painted
and maximizing the disas red lines.
tance to nearby obstacles.
Fig. 5. Illustration of three local navigation approaches implemented on Rolland. While
the Nearness Diagram Navigation belongs to the class of reactive navigation strategies,
the Bezier-Curve Path Planner, and the A* based Path Planning approach are geometric and complete planning algorithms respectively.
i. e., it completely ignores the current obstacle situation. However, since the
Driving Assistant avoids obstacles, the wheelchair is robustly able to navigate
even in narrow environments, as long as the target poses are selected appropriately. In general, target poses should be located at narrow passages, e.g. between door posts, with the orientation perpendicular to the narrowness. In case
264
the wheelchair gets stuck or, for any reason, misses the target pose, a shunting
behavior allows retrying and thereby ensures robustness.
Geometric Path Planning. The basic principle of geometric path planning
approaches is to continuously check sets of mathematical curves for a solution
path in order to move the robot from its current pose to a given goal-pose.
Therefore the algorithms evaluate a cost function that minimizes the length of
the path to execute, while maximizing the distance to the obstacles along the
selected path. For Rolland several such algorithms have been developed, applying
circular arc segments, clothoids, and cubic Bezier splines [40, 41, 14].
A* Path Planning. Recent developments have led to a prototypical implementation of a real-time-capable planner based on A*-search in Rolland’s configuration space (x, y, θ). Conceptional drawbacks of NDN and the geometric path
planning approaches such as the non-consideration of target orientations, or the
sparse covering of the configuration space by means of mathematical curves
are avoided. For this reason a typical A*-based planning scenario involves the
discretisation of the configuration space into 6 ∗ 106 cells, yielding a spatial resolution of 3 ∗ 3cm2 , and an orientational resolution of 3.75◦ . The algorithmic
search itself is guided by two heuristics taking the current obstacle situation
and the non-holonomic nature of Rolland into account. Hereby it is possible to
maintain planning-cycles of approximately 20ms.
4.4
Shared Control
The shared-control aspect of manned service robots is to be considered in all
applications of Rolland that share control between the human driver and an
intelligent assistance module. So-called “mode confusion” situations have to be
avoided [42, 43]. In the aviation psychology community, the problem of mode confusion has already been discussed for about a good decade. However, the notion
as such has never been rigorously defined. In addition, the pertinent publications
so far cover almost exclusively the pilot-autopilot interaction. In [27, 44], a rigorous view of mode confusion is presented. A framework based on existing formal
methods is established for separately modeling the technical system, the user’s
mental representation of it, and their safety-relevant abstractions. As a result,
an automated model checking approach can be applied to detect mode confusion
potential already in the design phase. In a case study, the obstacle avoidance
skill of Rolland is checked for mode confusion potential with tool support.
4.5
Qualitative Control
In order to solve high level tasks such as the interpretation of qualitative driving
commands or coarse qualitative route descriptions, one needs an appropriate
global data structure that represents the navigable space in an adequate way. For
Rolland we apply a graph structured representation, i. e. the Route Graph [45],
265
because of its extensibility by annotations, given either by humans or automatic
feature detectors, and because of its interface that supplies basic spatial queries
as a foundation for the evaluation of more elaborated spatial tasks.
The underlying idea of the interpretation of Coarse Verbal Route Descriptions
(CRDs) is that they can be split into route segment descriptions that describe
the start, the progression along the route, intermediate reorientation actions,
and the goal. This observation has been validated by empirical studies in which
subjects had to give in-advance route descriptions to a designated goal. For the
evaluation of CRDs, i. e. the calculation of the most likely target pose, we utilize
a search tree the nodes of which represent fuzzy rated places that result from
the evaluation of single CRD-elements. The corresponding algorithm inputs a
formalized CRD representing the current task description, a global route graph
which holds the available world knowledge, and the global pose of the system.
By evaluating fuzzy functions that model the consecutively appearing spatial
relations in the CRD, our algorithm builds up the mentioned search tree and
searches it in a depth-first branch-and-bound manner to determine the most
probable goal pose. For a more detailed elaboration of this work see [14, 15].
5
Applications
Using the techniques discussed above, several assistants have been developed for
Rolland [46]: the Safety Assistant, the Driving Assistant, the Route Assistant,
the (Autonomous) Navigation Assistant, and the Multi Modal Driving Assistant.
5.1
Safety Assistant
The Safety Assistant mainly consists of a safety layer that ensures that the
vehicle will stop in time before a collision can occur [47–50]. 30 or 50 times per
second (depending on the wheelchair model), the safety layer makes a binary
decision. Either the current driving command is safe, and it can be sent to the
wheelchair, or it is not, and the wheelchair has to stop instead. “Safe” means that
if a stop command would be initiated in the next processing cycle, the wheelchair
would still be able to stop without a collision. Otherwise, it has to be stopped in
this cycle, because in the next cycle it would be too late. Whether the wheelchair
can stop in time depends on the actual speeds of the two drive wheels and the
current drive command, because it will influence the current speeds in the future,
the shape of the wheelchair, and its current surroundings. The surroundings are
measured using the distance sensors (sonars or laser scanners) and a model of
the environment is maintained in a local obstacle map (cf. Fig. 6). Based on the
current speeds and the commanded speeds, a safety area is searched for obstacles
in the map. If the safety area is free of obstacles, the current driving command
is safe. Since the shape of such a safety area is rather complex, a large number
of safety areas were pre-computed and stored in a lookup table.
266
Fig. 6. Intervention of the Driving Assistant. The driver presses the joystick straight
ahead (indicated by the thick line); the Driving Assistant detects an obstacle on the
right side (cf. safety area in the local obstacle map above), and avoids it to the left
(thin line).
5.2
Driving Assistant
The Driving Assistant is a software component that provides obstacle avoidance
for Rolland [51, 5, 47, 48, 52]. The Driving Assistant avoids obstacles while the
wheelchair is still controlled by the user. The user remains in complete control
of the system as long as there are no obstacles on the path driven. Whenever
obstacles block the way and would result in the wheelchair being stopped by the
Safety Layer (the main part of Safety Assistant), the Driving Assistant takes
control and avoids the obstacle with as small deviations from the commands
given by the user as possible (cf. Fig. 6). The Driving Assistant on Rolland II
also provides a basic behavior for turning on the spot, because this can be quite
difficult with an Ackermann steering in a narrow environment. Since Rolland
III and IV are equipped with a differential drive, there is no need for such a
behavior.
5.3
Route Assistant
The Route Assistant of the Bremen Autonomous Wheelchair [53] has been developed in cooperation with the neurological clinic of a Bremen hospital. It provides the following functionality: During a teaching phase, the system explores
the routes and places pertinent for the future user(s). If, e. g., the wheelchair is
used in a rehabilitation center for amnesic patients, the routes to all relevant
places in the building could be learned and stored for later replay with the help
of the route generalization algorithm already mentioned. In the replay mode,
a nurse chooses a certain target for the patient in the wheelchair. Similar to a
GPS-based navigation system, the large-scale navigation is done by the Route
Assistant by giving instructions where to go at decision points, enabling the
267
Fig. 7. Multi Modal Driving Assistant: Illustration of navigable paths along with their
labelled target nodes (left), and a photograph of the corresponding environment (right).
While the left figure presents the current pose of the wheelchair by a detailed shape
that is heading to the top, the picture to the right depicts the position and orientation
of the wheelchair by a green dot and arrow.
patient to travel around on his or her own. The patient is independently responsible for controlling the vehicle with respect to local maneuvers such as obstacle
avoidance.
5.4
(Autonomous) Navigation Assistant
The Navigation Assistant goes further. It is based on a SLAM-based metric representation of the environment with an embedded route graph. The aim of the
system is to have a robust navigation component for an autonomous wheelchair
within a global frame of reference. The user is enabled to choose a specific destination – e. g. “Refrigerator”, “Entrance”, or “Wardrobe” – from a predefined list.
Given the destination, the system provides two different use cases: autonomous
navigation of the robot without any need for interventions by the user, or a
guidance mode which lets the user drive manually but provides information
about where to navigate next. The latter assistant is similar to the route assistant, but here the spatial representation is a map, not a route. The key idea
behind this assistant is to specify all possible destinations together with all possible routes between these destinations, i. e. the route graph, in advance. This
approach shifts parts of the intelligence needed from the robot to an external
human expert. Thereby, it can be assured that necessary routes always exist
and lead along paths that are actually usable by a wheelchair, i. e., they do
not contain any undetectable obstacles. Especially the latter cannot be assured
for autonomous route generation given the current sensorial equipment of the
wheelchair Rolland.
268
5.5
Multi Modal Driving Assistant
The essential idea behind the Multi Modal Driving Assistant [12] (cf. Fig. 7) is
a simple speech interface with which the operator of the wheelchair selects a
desired movement from a set of graphically presented navigable paths. Derived
from the route graph representation of the environment, the proposed paths
are selected by verbally calling their name. In order to improve the recognition
process of the applied speech recognizer VoCon, each proposed path is labelled by
a token coming from an alphabet with multisyllabic words that provide mutually
different sounds. Once established the connection between the commanded token
and the corresponding path, its endpoint is forwarded to the obstacle avoiding
navigation module, i.e. a specialized implementation of the Nearness Diagram
Navigation approach (cf. section 4.3).
6
Conclusion
It was a long way from Rolland I, the construction of which is so complex that
even healthy people have problems sitting down in it, to Rolland IV that only
stands out because of its functionality, but not because of its appearance. Hence,
the commercialization of the results is the next logical step. In cooperation with
our new partner Otto Bock Mobility Solutions, we will develop some of the
assistants presented in this paper to industrial prototypes. However, there are
still interesting areas for further wheelchair research, e. g., driving outdoors. In
addition, we are investigating another device meant for supporting the elderly:
the intelligent walker, i. e. the iWalker.
References
1. Lankenau, A., Röfer, T.: Smart wheelchairs - state of the art in an emerging market.
Künstliche Intelligenz. Schwerpunkt Autonome Mobile Systeme (4) (2000) 37–39
2. Mandel, C.: Navigation of the Smart Wheelchair Rolland. PhD thesis, University
of Bremen (2008)
3. Röfer, T.: Strategies for using a simulation in the development of the Bremen
Autonomous Wheelchair. In Zobel, R., Moeller, D., eds.: Simulation-Past, Present
and Future, Society for Computer Simulation International (1998) 460–464
4. Bühlmeier, A., Kollmann, J., Krieg-Brückner, B., Röfer, T., eds.: Studentisches
Projekt SAUS: Sensomotorik autonomer Systeme. Informatik Bericht. ISSN 07228996. Universität Bremen (1998)
5. Lankenau, A., Röfer, T.: A safe and versatile mobility assistant. Reinventing the
Wheelchair. IEEE Robotics and Automation Magazine (7) (2001) 29–37
6. Röfer, T., Lankenau, A.: Ensuring safe obstacle avoidance in a shared-control
system. In Fuertes, J.M., ed.: Proceedings of the 7th International Conference on
Emergent Technologies and Factory Automation (ETFA-99). (1999) 1405–1414
7. Röfer, T., Lankenau, A.: Ein Fahrassistent für ältere und behinderte Menschen. In
Schmidt, G., Hanebeck, U., Freyberger, F., eds.: Autonome Mobile Systeme 1999.
Informatik aktuell, Springer (1999) 334–343
269
8. Lankenau, A., Röfer, T.: Architecture of the Bremen Autonomous Wheelchair.
In Hildebrand, B., Moratz, R., Scheering, C., eds.: Architectures in Cognitive
Robotics. Technical Report. Number 98/13, SFB 360 ”Situierte Künstliche Kommunikatoren”. Universität Bielefeld (1998) 19–24
9. Gollub, J.: Umsetzung und Evaluation eines mit Laserscannern gesicherten Rollstuhls als interaktives Museumsexponat. Diplomarbeit, Fachbereich 3, Universität
Bremen (2007)
10. Mandel, C., Röfer, T., Frese, U.: Applying a 3DOF orientation tracker as a humanrobot interface for autonomous wheelchairs. In: Proceedings of the 10th International Conference on Rehabilitation Robotics. (2007)
11. Mandel, C., Frese, U., Röfer, T.: Design improvements for proportional control
of autonomous wheelchairs via 3DOF orientation tracker. In: Proceedings of the
9th International Work-Conference on Artificial Neural Networks (IWANN’2007).
Lecture Notes in Computer Science, Springer; Berlin (2007)
12. Mandel, C., Frese, U.: Comparison of wheelchair user interfaces for the paralysed:
Head-joystick vs. verbal path selection from an offered route-set. In: Proceedings
of the 3rd European Conference on Mobile Robots (ECMR 2007). (2007)
13. Müller, R., Röfer, T., Lankenau, A., Musto, A., Stein, K., Eisenkolb, A.: Coarse
qualitative descriptions in robot navigation. In Freksa, C., Brauer, W., Habel,
C., Wender, K.F., eds.: Spatial Cognition II. Number 1849 in Lecture Notes in
Artificial Intelligence, Springer (2000) 265–276
14. Mandel, C., Frese, U., Röfer, T.: Robot navigation based on the mapping of coarse
qualitative route descriptions to route graphs. In: Proceedings of the IEEE/RSJ
International Conference on Intelligent Robots and Systems (IROS 2006). (2006)
205–210
15. Shi, H., Mandel, C., Ross, R.J.: Interpreting route instructions as qualitative
spatial actions. In Barkowsky, T., Knauff, M., Ligozat, G., Montello, D.R., eds.:
Spatial Cognition V. Volume 4387 of Lecture Notes in Computer Science., 14197
Berlin, Springer Verlag (2008)
16. Graimann, B., Allison, B., Mandel, C., Lueth, T., Valbuena, D., Gräser, A.: Noninvasive Brain-Computer Interfaces for Semi-Autonomous Assistive Devices. In:
Robust Intelligent Systems. Springer Verlag (2007) to appear.
17. Röfer, T.: Panoramic Image Processing and Route Navigation. Number 7 in BISS
Monographs. Shaker-Verlag (1998)
18. Röfer, T.: Route navigation and panoramic image processing. In: Ausgezeichnete
Informatikdissertationen 1998. B. G. Teubner; Stuttgart, Leipzig (1999) 132–141
19. Röfer, T.: Route navigation and panoramic image processing. Künstliche Intelligenz. Schwerpunkt Autonome Mobile Systeme (1) (2000) 62–64
20. Krieg-Brückner, B., Röfer, T., Carmesin, H.O., Müller, R.: A taxonomy of spatial knowledge for navigation and its application to the Bremen Autonomous
Wheelchair. In Freksa, C., Habel, C., Wender, K.F., eds.: Spatial Cognition. Number 1404 in Lecture Notes in Artificial Intelligence, Springer (1998) 373–397
21. Röfer, T.: Routemark-based navigation of a wheelchair. In: Proceedings of the 3rd
ECPD International Conference on Advanced Robotics, Intelligent Automation
and Active Systems. (1997) 333–338
22. Röfer, T., Müller, R.: Navigation and routemark detection of the Bremen Autonomous Wheelchair. In Lüth, T., Dillmann, R., Dario, P., Wörn, H., eds.: Distributed Autonomous Robotics Systems, Springer (1998) 183–192
23. Röfer, T.: Routenbeschreibung durch Odometrie-Scans. In Wörn, H., Dillmann,
R., Henrich, D., eds.: Autonome Mobile Systeme 1998. Informatik aktuell, Springer
(1998) 122–129
270
24. Musto, A., Stein, K., Eisenkolb, A., Röfer, T.: Qualitative and quantitative representations of locomotion and their application in robot navigation. In: Proceedings
of the 16th International Joint Conference on Artificial Intelligence (IJCAI-99),
Morgan Kaufman Publishers, Inc; San Francisco, CA (1999) 1067–1073
25. Röfer, T.: Route navigation using motion analysis. In Freksa, C., Mark, D.M.,
eds.: Proceedings of the Conference on Spatial Information Theory (COSIT-99).
Number 1661 in Lecture Notes in Computer Science, Springer (1999) 21–36
26. Musto, A., Stein, K., Eisenkolb, A., Röfer, T., Brauer, W., Schill, K.: From motion
observation to qualitative motion representation. In Freksa, C., Brauer, W., Habel,
C., Wender, K.F., eds.: Spatial Cognition II. Number 1849 in Lecture Notes in
Artificial Intelligence, Springer (2000) 115–126
27. Lankenau, A.: The Bremen Autonomous Wheelchair ‘Rolland’: Self-Localization
and Shared Control. PhD thesis, Universität Bremen (2002)
28. Lankenau, A., Röfer, T., Krieg-Brückner, B.: Self-localization in large-scale environments for the Bremen Autonomous Wheelchair. In Freksa, C., Brauer, W.,
Habel, C., Wender, K.F., eds.: Spatial Cognition III. Number 2685 in Lecture Notes
in Artificial Intelligence, Springer (2003) 34–61
29. Lankenau, A., Röfer, T.: Mobile robot self-localization in large-scale environments.
In: Proceedings of the IEEE International Conference on Robotics and Automation
2002 (ICRA-2002), IEEE (2002) 1359–1364
30. Röfer, T., Lankenau, A.: Route-based robot navigation. Künstliche Intelligenz Themenheft Spatial Cognition (2002) 29–31
31. Kollmann, J., Röfer, T.:
Echtzeitkartenaufbau mit einem 180◦ -LaserEntfernungssensor. In Dillmann, R., Wörn, H., von M. Ehr, eds.: Autonome Mobile
Systeme 2000. Informatik aktuell, Springer (2000) 121–128
32. Röfer, T.: Konsistente Karten aus Laser Scans. In Levi, P., Schanz, M., eds.:
Autonome Mobile Systeme 2001. Informatik aktuell, Springer (2001) 171–177
33. Röfer, T.: Building consistent laser scan maps. In: Proceedings of the 4th European Workshop on Advanced Mobile Robots (Eurobot 2001). Volume 86., Lund
University Cognitive Studies (2001) 83–90
34. Röfer, T.: Using histogram correlation to create consistent laser scan maps. In:
Proceedings of the IEEE International Conference on Robotics Systems (IROS2002), EPFL; Lausanne, Switzerland (2002) 625–630
35. Röfer, T.: Controlling a wheelchair with image-based homing. In: Spatial Reasoning in Mobile Robots and Animals, AISB-97 Workshop, Manchester University
(1997) 66–75
36. Röfer, T.: Image based homing using a self-organizing feature map. In FogelmanSoulie, F., Gallinari, P., eds.: Proceedings of the International Conference on Artificial Neural Networks (ICANN-95). Volume 1., EC2 & Cie (1995) 475–480
37. Röfer, T.: Bildbasierte Navigation mit eindimensionalen 360◦ -Bildern. In Dillmann, R., Rembold, U., Lüth, T., eds.: Autonome Mobile Systeme 1995. Informatik
Aktuell, Springer (1995) 193–202
38. Röfer, T.: Controlling a robot with image based homing. In Krieg-Brückner,
B., Herwig, C., eds.: Tagungsband des Workshops ”Kognitive Robotik”. Number
3/95 in ZKW Bericht, Zentrum für Kognitionswissenschaften. Universität Bremen
(1995)
39. Kraetsch, P.: Entwicklung einer reaktiven steuerung für mobile roboter auf basis
der nearness-diagram-methode für navigation in innenraum̈en. Master’s thesis,
Universität Bremen (2007)
271
40. Mandel, C.: Trajektorienplanung und Trajektorienfolgeregelung im Konfigurationsraum nicht-holonomer Fahrzeuge. Diplomarbeit, Fachbereich 3, Universität
Bremen (2002)
41. Mandel, C., Huebner, K., Vierhuff, T.: Towards an autonomous wheelchair: Cognitive aspects in service robotics. In: Proceedings of Towards Autonomous Robotic
Systems (TAROS 2005). (2005) 165–172
42. Lankenau, A.: Avoiding mode confusion in service-robots. In Mokhtari, M., ed.:
Integration of Assistive Technology in the Information Age, Proc. of the 7th Int.
Conf. on Rehabilitation Robotics, IOS Press (2001) 162 – 167
43. Lankenau, A., Röfer, T.: The role of shared control in service robots - the Bremen
Autonomous Wheelchair as an example. In Röfer, T., Lankenau, A., Moratz, R.,
eds.: Service Robotics - Applications and Safety Issues in an Emerging Market.
Workshop Notes. (2000) 27–31
44. Bredereke, J., Lankenau, A.: A rigorous view of mode confusion. In: Proc. of Safecomp 2002, 21st Int’l Conf. on Computer Safety, Reliability and Security. Number
2434 in Lecture Notes in Computer Science, Springer-Verlag; D-69121 Heidelberg,
Germany (2002) 19–31
45. Krieg-Brückner, B., Frese, U., Lüttich, K., Mandel, C., Mossakowski, T., Ross, R.:
Specification of an ontology for route graphs. In Freksa, C., Knauff, M., KriegBrückner, B., Nebel, B., Barkowsky, T., eds.: Spatial Cognition IV. Volume 3343
of Lecture Notes in Artificial Intelligence. Springer-Verlag, D-69121 Heidelberg,
Germany (2005) 390–412
46. Krieg-Brückner, B., Shi, H., Fischer, C., Röfer, T., Cui, J., Schill, K.: Welche
Sicherheitsassistenz brauchen Rollstuhlfahrer? In: 2. Deutscher AAL-Kongress
2009, VDE-Verlag; Berlin-Offenbach, Germany
47. Röfer, T., Lankenau, A.: Architecture and applications of the Bremen Autonomous
Wheelchair. In Wang, P., ed.: Information Sciences. Volume 1-4. Elsevier Science
BV (2000) 1–20
48. Röfer, T., Lankenau, A.: Architecture and applications of the Bremen Autonomous
Wheelchair. In Wang, P.P., ed.: Proceedings of the 4th Joint Conference on Information Systems. Volume 1., Association for Intelligent Machinery (1998) 365–368
49. Lankenau, A., Meyer, O.: Formal methods in robotics: Fault tree based verification.
In: Proc. of Quality Week Europe. (1999)
50. Lankenau, A., Meyer, O.: Der autonome Rollstuhl als sicheres eingebettetes System. Diplomarbeit, Fachbereich 3, Universität Bremen (1997)
51. Lankenau, A., Meyer, O., Krieg-Brückner, B.: Safety in robotics: The Bremen
Autonomous Wheelchair. In: Proceedings of the 5th Int. Workshop on Advanced
Motion Control (AMC ’98). (1998) 524 – 529
52. Lankenau, A., Röfer, T.: Rollstuhl ¨‘Rolland¨’ unterstützt ältere und behinderte
Menschen. FIfF-Kommunikation. Informationstechnik und Behinderung (2) (2000)
48–50
53. Lankenau, A., Röfer, T.: Selbstlokalisation in Routengraphen. In Levi, P., Schanz,
M., eds.: Autonome Mobile Systeme 2001. Informatik aktuell, Springer (2001) 157–
163
272
Thomas Röfer received his diploma in computer science and his Dr.ing. degree under the supervision of
Bernd Krieg-Brückner from Universität Bremen, Germany, in 1993 and 1998, respectively. He is in the Executive Committee of the RoboCup Federation, and he
is member of the Transregional Collaborative Research
Center SFB/TR 8 “Spatial Cognition” at Bremen. He
is currently with the German Research Center for Artificial Intelligence at the research group for Safe and
Secure Cognitive Systems, Bremen, Germany. His research interests include rehabilitation robotics, robot
soccer, real-time computer vision, world modeling, and
humanoid robots.
Christian Mandel received the Dipl.Inf. and Dr.Ing.
degrees in computer science under the supervision
of Bernd Krieg-Brückner from Universität Bremen,
Germany, in 2002 and 2008, respectively. In 2008 he
worked for the German Research Center for Artificial
Cognitive Systems, Bremen, Germany. He is currently
with the University of Bremen at the Collaborative Research Center Spatial Cognition, doing research and
development on navigation techniques and advanced
interface devices for assistive devices, such as electrical wheelchairs.
Axel Lankenau received the Dipl.Inf. and Dr.Ing.
degrees in computer science under the supervision of
Bernd Krieg-Brückner from Universität Bremen, Germany, in 1997 and 2002, respectively. He was member
of the Rolland project from 1994 until 2002. Currently,
he is a manager for documentation process design in
the Research and Advanced Engineering department
of the Daimler AG in Sindelfingen, Germany.
Bernd Gersdorf received the Dipl.Inf. and Dr.Ing.
degrees in computer science under the supervision of
Bernd Krieg-Brückner from Universität Bremen, Germany, in 1986 and 1992, respectively. In 1995, he
started to work in the industry in the software development for Process Automation, and later for flight
safety systems. He joined the Rolland project early
2007 with the German Research Center for Artificial
Cognitive Systems, Bremen, Germany.
Udo Frese received his Ph.D. from University of
Erlangen-Nürnberg in 2004. From 2004 until 2008
he has been a post-doc researcher in Bernd KriegBrückner’s lab at Universität Bremen and in the
German Research Center for Artificial Intelligence
(DFKI). He is now assistant professor for real-time
computer vision at University of Bremen and further
on affiliated with the DFKI. His research topics are
real time computer vision, in particular simultaneous
localization and mapping (SLAM), and computer vision for sport robotics.
On Classical and Quantum Process Algebra as Abstract Data Types
(Detailed Abstract)
Dedicated to the 60th birthday of Prof. Bernd Krieg-Brückner
Ruqian Lu1,2,3, Lixing Li1, Yun Shang1, Xiaoyu Li4
1
CAS Key Lab of MADIS, Academy of Mathematics and Systems Science, CAS
2
Shanghai Key Lab of Intelligent Information Processing, Fudan University,
3
CAS Key Lab of IIP, Institute of Computing Technology, CAS
4
School of Information Engineering, Zhengzhou University
Keywords: process algebra, quantum process algebra, quantum programming language, formal
semantics, algebraic semantics, abstract data type
$ 1 Formal Semantics of Quantum Process Algebras
1.1 Quantum process algebra and its semantics
Together with the prospect of building quantum computers for real and practical use,
scientists have been also interested in studying theories and techniques of quantum programming
languages. Some have imperative character [Kni96][BCS03][Ome00] [Xu08] [Zul01] [Mln06], some others are
functional [Sel04b][Ton04][SV05][AG05]. For a survey of both directions see [Gay06] and [Sel04a].
Quantum programming languages of a particular kind are called quantum process
algebra[JL04][LJ04][GN05].[F07] [Y08]. There are some subtle points of quantum process algebra. First,
each quantum system is attached with a quantum state space. This will influence the form of
transition rules and of bisimulation. Second, physical constraints of quantum mechanics may
appear in different form than in other quantum programming languages. For example, the quantum
copying problem appears not in form of assignment statements, but in form of input, output and
communication rules.
Regarding the first point, most quantum process algebra proposed in the literature use the
concept of configuration <P, C> to describe the state of a quantum system, where P is the quantum
process and C is the context. For example, a context of QPALg[LJ04] is represented as
s, q
U , f ! , where s is the environment stack declaring all classical and quantum variable
names with types, q the set of quantum variables, U the density matrix characterizing the state of q,
f the classical environment assigning values to classical variables. On the other hand, according to
whether the authors adopt a probabilistic transition system, these operational semantics can be
classified as probabilistic or non-probabilistic. One advantage of the non-probabilistic technique is
avoiding dealing with probability calculation and making the explicit probability implicit, since
any probability is implied in the density matrix. As a trade-off, the non-probabilistic approach can
not process classical data and classical communication in case of quantum measuring. Apart from
[Y08], most authors[LJ04][GN05][F07] have made use of a probabilistic transition system.
Quantum bisimulation is not as widely studied as the transition rule based operational
semantics. It has been introduced in [Lal06], [F07] and [Y08]. The difference of transition systems
has a great impact on the definition of bisimulation. Those accepting probabilistic transitions adopt
naturally the concept of probabilistic bisimulation[Lal06] [F07], while the authors of [Y08], who
-------------------------------------------------*Partially supported by NSFC projects 60496324, 60736011, 60603002, 90818026
274
adopt the non-probabilistic approach, keep also their bisimulation definition non-probabilistic,
where the authors have introduced various kinds of bisimulation, including strong bisimulation,
strong reduction bisimulation and strong approximate bisimulation. Note that the strong
approximate bisimulation is an extension of Mingsheng Ying’s previous result in classical process
algebra[Y01]. Besides, the authors of [Y08] have proved a series of algebraic properties of these
different kinds of bisimulation.
1.2 Abstract data types as program semantics
The idea of abstract data type (ADT) was born in early seventies. Examples of early
important contributions to ADT research are [Zil74], [GH78], [GT75,78], [BW80a,b], for more
reference see [W89]. The advantage of using ADT as algebraic semantics is that it provides not
only a single model of semantics for a given program, but a set of different models, depending on
different choice of axiom systems.
Just as said by Wirsing: “Data stractures, algorithms and programming languages can be
described in a uniform implementation independent way by axiomatic abstract data types”[W89].
The idea of considering programming languages as ADT first appeared in 1980, where Broy &
Wirsing[BW80a,b] and Cleaveland[C80] proposed this idea separately almost at the same time.
Despite the fact that ADT had been used for defining algebraic semantics of various kinds
of classical programs, no work has been reported on using ADT to define algebraic semantics for
quantum process algebras. The authors even don’t know if there is any work done on using ADT to
define classical process algebra semantics. Therefore in this paper we first study ADT as algebraic
semantics for classical process algebra and then generalize the results to quantum process algebra.
1.3 Main contribution of this paper
In this paper we introduced an algebraic semantics for classical and quantum process algebra
in form of ADT. For that purpose, we developed a particular type of 6 algebra, the seed algebra,
which describes exactly the behavior of a process. Each non-hidden element of the seed algebra is a
state of the process. In the seed algebra, generating an element e1 from another element e2 by the
application of a non-hidden operation represents a state transition from e2 to e1 in process calculus.
We have proved that two processes bisimulate each other if and only if their corresponding seed
algebras have a deep rough seed isomorphism. Based on this result, we have given new proofs of
some known results of process algebra in form of theorems of seed algebras. We generalized these
results to study the algebraic semantics of quantum process algebra in section 3. We provided a
detailed ADT characterization of quantum processes and quantum operations and presented similar
results.
$2 ADT as semantics of Process algebra
Assume the usual definitions of abstract data types and 6 algebra are known. We introduce
additionally the ‘hidden’ concept for use in this paper.
Definition 2.1: We differentiate the operations of an ADT as hidden (hop) or non-hidden (op).
Each operation can be either hidden or non-hidden. But no operation can be both hidden and
non-hidden.
Their semantics will be shown later.
Definition 2.2: Given ADT D and 6 algebra A (D). Further assume a is an element of A (D). The
275
seed algebra A (D, a) is defined as follows:
1. a A (D, a);
2. If for some i, bi A (D, a) then f (b1 ,..., bi ,...bn ) A (D, a), where
f: s1 u s2 u … u si u … u sn Æ sn+1
is an operation of D, all b1 ,..., bi ,...bn A (D), each b j is of sort sj.
3. a is called the seed of this algebra,
4. For the case where A (D) is the ground term algebra of D, the seed algebra A (D, a) is also
called ground seed algebra.
In this paper, we only consider ground seed algebra.
Proposition 2.3: Let A (D) be the ground term algebra of D, then:
1. A (D, a) is a sub-algebra of A (D);
2. A (D, a) may be a proper sub-algebra of A (D).
3. For fixed D and a, the seed algebra A (D, a) is uniquely defined.
N
We differentiate between deterministic and non-deterministic objects.
Definition 2.4: 1. All elements of a seed algebra are deterministic objects;
2. A non-deterministic object D of sort s is an abstract entity, which represents any (deterministic)
object of a subset of seed algebra elements of sort s.
3. There are two types of non-deterministic objects: hidden extension and non-hidden closure.
4. The seed of a seed algebra is a non-hidden closure representing itself. Each constant operation is
a non-hidden closure representing itself;
5. For any non-hidden closure
E of sort s, its hidden extension [ E ] represents any legal
element f1 ( f 2 (... f k ( c)...)) , where c is any element represented by E , k t 0 , f1 , f 2 ,..., f k are
hidden functions, all of which have the functionality s Æ s.
6. if f is a non-hidden function, then f ([ E1 ],..., [ E m ]) is a non-hidden closure representing any
legal seed algebra element f (b1 ,..., bm ) , where each bi is represented by [ E i ] , which is the
hidden extension of the non-hidden closure E i .
Definition 2.5: Let A (D, a) = (Ea, Fa) and A (D, b) = (Eb, Fb) be two seed algebras of the same data
type D, where Ea, Eb are element sets; Fb, Fb are function sets; the seeds a, b are of the same sort. A
mapping from the non-hidden closures of A (D, a) to the non-hidden closures of A (D, b), denoted
with hnh, is called a rough seed homomorphism from A (D, a) to A (D, b), where
1. hnh (a) = b;
#According to definition 2.4, all seeds are non-hidden closure#
2. f Fa , where f is the interpretation of a non-hidden operation O op, g Fb , such that
h ( f ) = g , where g is the interpretation of the same O (Henceforth we will simply call f and g as
276
non-hidden operation or non-hidden function);
3. f Fa , where f is a non-hidden function, we call f ([D1 ],..., [D n ]) a non-hidden closure
of [ D i], where for 1 d i d n , D i are non-hidden closures and [D i ] their hidden extensions, there
are non-hidden g Fb , and non-hidden closures
E1 ,..., E n , hnh ( f ) = g , such that
hnh ( f ([D1 ],..., [D n ])) = g ([ E1 ],..., [ E n ]) ,
(2.1)
where g ([ E1 ],..., [ E n ]) is a non-hidden closure of [ E i ], 1 d i d n ,
and hnh ( D i ) = E i
#Read:
For any non-hidden closure f ([D1 ],..., [D n ]) , there is a non-hidden closure
g ([ E1 ],..., [ E n ]) , such that i, 1 d i d n , hnh ( D i ) = E i and hnh ( f ([D1 ],..., [D n ])) =
g ([ E1 ],..., [ E n ]) #
4. hnh is called a rough seed isomorphism if it can be uniquely reversed to hnh-1. More exactly, it
requires in addition:
i, h-1nh ( E i ) = D i ,
1
1
hnh (hnh ( f ([D1 ],...,[D n ]))) = hnh ( g ([ E1 ],...,[ E n ])) = f ([D1 ],..., [D n ]) ,
(2.2)
f ([D1 ],..., [D n ]) and its rough homomorph mapping
#Read: For any non-hidden closure
1
hnh ( f ([D1 ],..., [D n ])) , the reverse mapping hnh (hnh ( f ([D1 ],...,[D n ]))) provides the original
non-hidden closure f ([D1 ],..., [D n ])
#
We use the notation nhc (A (D, a)) to denote the set of non-hidden closures of the seed algebra
A (D, a). A rough seed homomorphism (isomorphism) from A (D, a) to A (D, b) is also called a
homomorphism (isomorphism) from nhc (A (D, a)) to nhc (A (D, b)).
Proposition 2.6: The rough seed isomorphism is an equivalence relation.
Proof: straightforward.
N
Consider a simple process grammar:
P ::= nil | y?x.P | y!x.P | P + Q | (P |Q)
x::= a | b | u
y::= c | d
with operational semantics:
Input: c ? u.P o P[a / u ] , Output: c!a.P o P
ca
c!a
277
c!a
ca
P o
P' , Q o
Q'
W
P|Q
o P'| Q'
Tau:
W
W .P
P
o
Sum:
D
D
P o
P'
P o
P'
, Compo:
D
D
D
P Q o P' , Q P o P'
P | Q o P' | Q, Q | P o
Q | P'
, Commu:
D
where D {c !a, ca,W } .Since we are using early semantics, the condition bv (D ) , fv (Q )
empty is not needed.
The following hierarchical data type describes this process grammar:
Type C-Process-Cons =
{sort token, chan, proc, trace, ptrace
op
a, b, u: Æ token
c, d: Æ chan
(): Æ trace
nil: Æ proc
tau: proc Æ proc
i-proc: chan u token u proc Æ proc
o-proc: chan u token u proc Æ proc
sum proc u procÆ proc
compo: proc u proc Æ proc
tconf: proc u trace Æ ptrace
}
End of Type C-Process-Cons
Type C-Process-Trans =
{ C-Process-Cons +
sort token, chan, proc, trace, ptrace
op
tinput: ptrace u chan u token Æ ptrace
toutput: ptrace u chan u token Æ ptrace
t-h-act: ptrace Æ ptrace
hop
it: chan u token Æ trace
ot: chan u token Æ trace
run: trace u trace Æ trace
input: proc u chan u token Æ proc
output: proc u chan u token Æ proc
h-act: proc Æ proc
subst: proc u token u token Æ proc
tleft: ptrace Æ ptrace
tright: ptrace Æ ptrace
tback: ptrace Æ ptrace
278
left: proc Æ proc
right: proc Æ proc
compol: proc u proc Æ proc
compor: proc u proc Æ proc
back: proc Æ proc }
In order to avoid too many details, we leave the axiom part to Appendix. Note that we have
introduced a ‘undefined’ predicate for describing partial semantics, e.g. t-h-act (tconf (i-proc (c, u,
p), tr)) = undefined. We do not list them in appendix to save space. Further we introduce the short
notation A’ (D, P)P in process grammar notation =def A (D, tconf (p, ()))p in element of seed algebra notation.
Definition 2.7: Two processes P and Q are trace equivalent if for any action sequence
P1P 2 ...P n and transition sequence:
P1 ... P n
P
o P '
there is a transition sequence of Q:
P1 ... P n
Q
o Q'
and vice versa, where we use Greek letters P ,Q ,... to represent actions like c?a, c!b, etc.
Proposition 2.8: Two processes are trace equivalent if and only if their corresponding seed
algebras are rough seed isomorph.
Proof: Given two trace equivalent processes P, Q and their seed algebras A’ (D, P), A’ (D, Q).
Assume
D
f n ([ f n1 (... f1 (tconf ( p, tr )...)...)]...) nhc (A’ (D, P)),
where p is the algebraic form of P and tr is any trace. It corresponds to the transition sequence:
P1P 2 ... P n
( P, tr )

o( P' , tr ' )
where
Pi {c ? u, c!a,W } are notations of process action for f i . By definition of trace equivalence,
there is a transition sequence
1P 2 ... P n
(Q, tr ) P

o(Q' , tr ' )
which corresponds to
E
f n ([ f n1 (... f1 (tconf (q, tr )...)...)]...) nhc (A’ (D, Q)),
In this way we get a rough seed isomorphism
hnh: nhc (A’ (D, P)) Æ nhc (A’ (D, Q))
with hnh ( D ) =
E . It is really a rough seed isomorphism since it satisfies all conditions of
definition 2.5. This shows the truth of the ‘only if’ part of the proposition. Similarly we can prove
the ‘if’ part.
N
Definition 2.9: Given two seed algebras A (D, a) and A (D, b), which are rough seed isomorph.
Assume elements c A (D, a), d A (D, b). (c, d) is called a corresponding pair if and only if there
279
are non-hidden closures D of nhc (A (D, a)) and E of nhc (A (D, b)), such that hnh ( D ) = E and c
and d are represented by D and E , respectively.
Definition 2.10: Two seed algebras A (D, a) and A (D, b) are called deep rough seed isomorph (or
simply: deep isomorph) if and only if:
1. A (D, a) and A (D, b) are rough seed isomorph by a mapping hnh: nhc (A (D, a)) Æ nhc (A (D, b));
2. For each c A (D, a), there is an element d A (D, b), such that (c, d) is a corresponding pair, A
(D, c) and A (D, d) are deep rough seed isomorph.
The following proposition shows that the second condition of the above definition can be
weakened.
Proposition 2.11:
Two seed algebras A (D, a) and A (D, b) are deep isomorph if and only if
1. A (D, a) and A (D, b) are rough seed isomorph by the mapping hnh: nhc (A (D, a)) Æ nhc (A (D,
b));
2. For any element c A (D, a) there is an element d A (D, b), such that (c, d) is a corresponding
pair, A (D, c) and A (D, d) are rough seed isomorph with the same mapping hnh.
Proof: First we prove that the condition presented in the statement of this proposition is necessary.
That means if A (D, a) and A (D, b) fulfill the conditions in definition 2.5, then they also have the
property stated in (the second part of) this proposition. That there is a rough seed homomorphism
hnh’: nhc (A (D, c)) Ænhc (A (D, d)) is trivial, since deep isomorphism implies rough seed
isomorphism. What we have to do is to prove that hnh’ = hnh, i.e. the new seed algebra A (D, c) is a
sub-algebra of A (D, a) and A (D, d) a sub-algebra of A (D, b). Assume there are elements u A (D,
c) and v A (D, d), such that (u, v) is a corresponding pair. According to the definition of seed
algebra there are operation symbols {fui}, {gvj} of D, such that
u = fu1 (…, fuk (…, c, …), …)
v = gv1 (…, gvq (…, d, …), …)
Remember that we always assume that each operation has only one implementation. Therefore we
can identify operations with functions. Again according to the definition of seed algebra there are
operation symbols {fci}, {gdj} of D, such that
c = fc1 (…, fcn (…, a, …), …)
d = gd1 (…, gdm (…, b, …), …)
Combine the above equations, we have
u = fu1 (…, fuk (…, fc1 (…, fcn (…, a, …), …), …), …)
v = gv1 (…, gvq (…, gd1 (…, gdm (…, b, …), …), …), …)
This shows that u A (D, a) and v A (D, b), i.e.
A (D, c) A (D, a), A (D, d) A (D, b)
This shows that A (D, c) is a sub-algebra of A (D, a) and A (D, d) a sub-algebra of A (D, b).
Therefore we may use the same rough seed isomorphism hnh for the mapping nhc (A (D, c)) Æ nhc
(A (D, d)).
Now we prove that the condition presented in the statement of this proposition is also
sufficient. If the second condition of proposition 2.11 were not true, then either there is no
corresponding pair (c, d) such that A (D, c) and A (D, d) are rough seed isomorph, or for some
element u A (D, c), there is no v A (D, d), such that (u, v) is a corresponding pair and A (D, u)
280
and A (D, v) are rough seed isomorph. Reasoning repeatedly in this way, we would get two chains
of seed algebras. We use the notation A < B to denote that A is a seed algebra constructed with a
seed from B. Then we would have …… < A (D, cn) <A (D, cn-1) <…<A (D, c1) <A (D, c0),
and ……< A (D, dn) <A (D, dn-1) <…<A (D, d1) <A (D, d0), where c = c0, d = d0, such that for all
1 d i d n, ci A (D, ci-1) and di A (D, di-1). Since A (D, c0) and A (D, d0) are known to be rough
seed isomorph, there are two possibilities. Either for all i, A (D, ci) and A (D, di) are rough seed
isomorph, then the deep isomorphism is proved, against the assumption. Otherwise, there must be
some n, A (D, cn) and A (D, dn) are not rough seed isomorph. Use the same method as above we can
prove that A (D, cn) is a sub-seed algebra of A (D, cn-1) and A (D, dn) a sub-seed algebra of A (D,
dn-1). Thus they must be rough seed isomorph. This refutes the assumption.
N
Definition 2.12: A symmetric relation SBS on the set of all processes is called strong bisimulation
if for each (P, Q) SBS, the following proposition is true:
P
P
P , P o
P ' , there is Q’ such that Q
o
Q'
and (P’, Q’) SBS, where
P = W or c?a or c!a for any channel c and any token a.
Two processes P and Q are called strongly bisimular (or: strongly bisimulate each other) if
there is a strong bisimulation relation SBS such that (P, Q) SBS.
Theorem 2.13: A pair of processes (P, Q) strongly bisimulate each other iff their corresponding
seed algebras A (D, a) and A (D, b) are deep isomorph, where a = tconf (p, ()), b = tconf (q, ()). Note
that p and q are the seed algebra element form of the processes P and Q.
Proof:
Since the proof involves lots of details, we sketch the main idea with following steps:
Step 1: We first establish a one-one correspondence between the set of all processes (generated by
the process grammar) and the set of proc elements generated by C-Process-Cons. This is
guaranteed by the following relation:
i-proc (c, u, p) ÅÆ c?u .P
o-proc (c, a, p) ÅÆ c!a .P
sum (p, q) ÅÆ P + Q
compo (p, q) ÅÆ P | Q
nil ÅÆ nil
tau (p) ÅÆ W .P
where p and q are seed algebraic forms of P and Q.
Step 2: We then establish a one-one correspondence between transition sequences of P and
elements of seed algebra with p as seed. Note that a transition can be considered both as concrete
and abstract transition. Assume process P = c!b.S + c!a.Q | c!b.R outputs b via channel c. As a
concrete transition, it may be written as
c!b
c!b
c!b.S c!a.Q | c!b.R o
S or c!b.S c!a.Q | c!b.R o
c!a.Q | R (2.3)
depending on which c!b is choosen to be performed. But as an abstract transition, we just write
c!b
P o
P'
(2.4)
where all possibilities of performing c!b are included. Clearly an abstract transition represents a
group of concrete transitions.
281
In accordance to the two kinds of transitions, there are two kinds of correspondence: the
correspondence between abstract transitions and non-hidden closures; and that between concrete
transitions and seed algebra elements whose outermost function is non-hidden. In the above
example, the abstract transition (2.4) corresponds to the non-hidden closure
toutput ([tconf (p, ())], [c], [b])
where p = sum (o-proc (c, b, s), compo (o-proc (c, a, q), o-proc (c, b, r))), whereas the concrete
transitions (2.3) correspond to seed algebra elements:
toutput (tleft (tconf (p, ())),c, b) and toutput (tright (tright (tconf (p, ()))),c, b)
Both corrspondences are obviously one-to-one. Both correspondences are needed in the proof of
the theorem.
Let’s consider the first kind of correspondence, where the transition rules no more describe
process to process transition, but transitions from process state to process state. Replace process by
process state in transition rule is here only for convenience. But it is a necessity in transition rules
of quantum process algebra.
1. Each process P considered as zero transition corresponds to the seed tconf (p, ()), which is of the
sort ptrace, where p is the algebraic form of P and () the zero trace;
2. The transitions
P1
( P, tr ) o
( P' , (tr, P1 )) ,
P1
c?u or c!a
W
( P, tr )
o
( P' , tr ) ,
correspond to the non-hidden closure f 1 ([tconf ( p, tr )],...) , where f1 is tinput, toutput or t-h-act,
corresponding to the action c?u, c!a or W that P may perform, and the dots …either represent a
channel c and a token a in case of tinput and toutput, or represent nothing (empty) in case of
invisible action W .
3. If the transition sequence
P1 P 2 ... P n
( P, tr )

o( P' , tr ' ) ,
n t1,
i, Pi { c?u, c!a, W }
corresponds to the non-hidden closure f n ([ f n 1 (... f 1 ([tconf ( p, tr )],...)...)],...) , where each
f i is the non-hidden function corresponding to action Pi and the dots … have the same meaning
as above, then the transition sequences:
P1P 2 ... P n P n 1
( P, tr )

o( P' , (tr' , P n 1 )) ,
P n 1 { c?u, c!a }
P1 P 2 ... P nW
( P, tr )
o( P' , tr ' )
correspond to the non-hidden closure f n 1 ([ f n (... f 1 ([tconf ( p, tr )],...)...)],...) , where f n 1 is
the non-hidden function representing the action
P n 1 or W , the dots … have the same meaning as
above.
In this way, we have found a one-one correspondence between the transition sequences (traces)
282
of the process P and the non-hidden closures of the process states ptrace of the seed algebra with
tconf (p, ()) as seed. At the same time we also found a one-one correspondence (2.5) between the
non-hidden closures of the process states ptrace of two seed algebras with tconf (p, ()) respectively
tconf (q, ()) as seed if the two processes bisimulate each other. More exactly, this is the one-one
correspondence:
f n ([ f n 1 (... f 1 ([tconf ( p, tr )],...)...)],...)
ÅÆ
f n ([ f n 1 (... f 1 ([tconf ( q, tr )],...)...)],...)
(2.5)
where the corresponding dots on both sides either denote the same channel and token or are both
empty.
Step 3: Prove that if P and Q are strongly bisimular, then A’ (D, P) and A’ (D, Q) are deep isomorph.
From strong bisimilarity of P and Q their trace equivalence follows. By proposition 2.8 the
rough seed isomorphism of A’ (D, P) and A’ (D, Q) is guaranteed. Now assume
a
f
p
m
(f
p
m 1
... f
p
1
(tconf ( p, ())...)...) A’ (D, P),
It corresponds to a concrete transition sequence:
P1 ... P k
( P, ())
oconc ( P' , tr )
where
P1 ,..., P k corresponds to the non-hidden subsequence f nh1 ,..., f nh k of the function
sequence f
p
1
,..., f
p
m.
By strong bisimularity there is a concrete transition sequence
P1 ... P k
(Q, ())
oconc (Q' , tr )
Such that P’ and Q’ are strongly bisimular.
This trasition sequence corresponds to some element
f q n ( f q n1... f q1 (tconf (q, ())...)...) A’ (D, Q),
b
where f
q
1
,..., f q n has the same non-hidden subsequence f nh1 ,..., f nh k . Obviously (a, b) is a
corresponding pair since they are represented by
D
f nh k (...[ f nh1 (tconf ( p, ())...)]...) and E
f nh k (...[ f nh1 (tconf (q, ())...)]...)
respectively. Remember that P’ and Q’ are strongly bisimular. Apply proposition 2.8 to the seed
algebras A’ (D, a) and A’ (D, b) once again, we get the completed proof.
Step 4: Prove that if A’ (D, P) and A’ (D, Q) are deep isomorph, then P and Q are strongly bisimular.
The proof of this part is almost the same as in the last step. We just need to reverse the proof
procedure of step 3 to get the result.
N
There is a known set of theorems about bisimulation of processes in classical theory of
process algebra. At this place, we will restate some of them, but in seed algebra form, and prove
them by using techniques of seed algebra.
283
Henceforth we will use the notation A’ (D, P) # A’ (D, Q) to denote their deep isomorphism.
Proposition 2.14: # is an equivalence relation.
N
Lemma 2.15: A (D, tconf (p, tr1)) # A (D, tconf (p, tr2))
N
Theorem 2.16: Given ADT D and two processes P and Q. If there is a deep isomorphism hnh : A’ (D,
P) # A’ (D, Q), then there are also the following deep isomorphisms:
1. A’ (D, W . P) # A’ (D, W . Q);
2. A’ (D, c!a.P) # A’ (D, c!a.Q);
3. A’ (D, c?u.P) # A’ (D, c?u.Q);
4. A’ (D, P + R) # A’ (D, Q + R) for any process R;
5. A’ (D, P | R) # A’ (D, Q | R) for any process R.
N
Proposition 2.17: Given ADT D and processes P, Q, R, T. From A’ (D, P) # A’ (D, Q) and A’ (D,
R) # A’ (D, T) it follows A’ (D, P + R) # A’ (D, Q + T).
N
Proposition 2.18: Given data type D and processes P, Q, R, T. From A’ (D, P) # A’ (D, Q) and A’ (D,
R) # A’ (D, T) it follows A’ (D, P | R) # A’ (D, Q | T).
N
$ 3 ADT as semantics of Quantum Process algebra
Due to the space limit we only report the main results about ADT semantics of quantum
process algebra in this section and omit many physical interpretations. The interested reader may
consult the listed literature. Consider the following grammar of quantum process algebra:
P ::= Act. T | (P + P’) | (P | P’)
Act ::= qc?qx | qc!qx | W | uni [un, X] | mes [X]
T:: = P | rp | nil
un ::= unitary matrix
X ::= qx | qx’, X
where uni means unitary transformation, mes is measuring operator, X is a sequence of quantum
variables, rp means recursive call. This grammar is attached with following context conditions to
prevent quantum copying.
1. Parallel processes should not contain the same free quantum variable, i.h.
If qx is free in P and qx’ is free in P’ then qx z qx’ for the process P | P’;
2. Process P outputting variable qx should not contain qx in its body (P’s body is P with its output
prefix removed), i.h, qc!qx.P is only then a legal process if qx is not free in P.
It has the following (early) semantics:
Input:
qv fv( P )
qc!qv
, Output: ( qc! qv.P, U )
o( P, U )
qc ? qv
(qc ? qu.P, U )
o( P[qv / qu ], U )
(The restriction qv fv ( P ) for input is only needed in quantum case to avoid quantum
copying. Note that neither input nor output will change the density operator U . When input or
284
output is performed, only the names of quantum variables will be moved. Only operators like
unitary operator or measure operator can change the content of U .)
Sum:
D
( P, U ) o
( P' , U ' )
D
( P Q, U ) o( P' , U ' ), (Q P, U ) o
( P' , U ' )
D
Compo:
D
( P, U )
( P' , U ' )
o
D
D
( P | Q, U )
o( P'| Q, U ' ), (Q | P, U )
o
(Q | P' , U ' )
(Just as in the case of classical process algebra in section 2, the extra condition
bv (D ) , fv (Q )
Commu:
D
D
( P, U )
o
( P' , U ), (Q, U )
o
(Q' , U )
W
, Tau: (W .P, U )
o
( P, U )
W
( P | Q, U )
o( P' | Q' , U )
,X ]
(uni[un, X ].P, U ) uni
[ un
o( P, uni[un, X ]( U ))
Unitary:
Measuring:
Recur:
empty is not needed)
X]
(mes[ X ].P, U ) mes
[
o( P, mes[ X ]( U ))
D
( P, U ) o
( P' , U )
D
(rp, U ) o
( P' , U )
rp
def
P
where for any channel qc and any variable qv, qc ? qv
qc! qv , qc! qv
qc ? qv , D {qc!qv,
qc?qv}.
Theorem 3.1: There is a hierarchical ADT (we call it Q-Process-Trans), which defines the above
quantum process algebra, such that the seed algebras of this ADT correspond to its process
behaviors, and the (equation logic) axioms describe exactly the functions of unitary and measuring
operations of quantum mechanics.
N
Definition 3.2: A quantum state 3 = <P, U > is a pair of process P and its density operator U . Let
Qconf be the set of all quantum states. A symmetric relation SQBS Qconf u Qconf is called
strong quantum bisimulation if for each ( 31 , 3 2 ) SQBS, the following proposition is true:
1.
D
D
D , 31 o
31 ' , there is 3 2 ' such that 3 2 o
32 '
and ( 31 ' , 3 2 ' ) SQBS, where
or
D = W or qc!qv for any channel qc and any quantum variable qv,
D = uni [un, X] or mes [X] for any unitary operator un and any subset of quantum variables X,
where the dimension of un is 2|X|.
2.
qv
qc, qv, 31 qc
?
o 31 ' , where qv fv(31 ) 8 fv(3 2 ) , there is 3 2 ' such that
qc ? qv
3 2
o 3 2 ' and ( 31 ' , 3 2 ' ) SQBS.
Two quantum states 31 , 3 2 are said to be strongly bisimular if and only if there is a strong
285
bisimular relation SQBS such that ( 31 , 3 2 ) SQBS.
Theorem 3.3: A pair of quantum systems ( 31 = (P1, U 1), 3 2 = (P2, U 2)) strongly bisimulate each
other iff their corresponding seed algebras A (Q-Process-Trans, a) and A (Q-Process-Trans, b) are
~
~
~
~
deep isomorph, where a = qconf ( 31 , ()), b = qconf ( 3 2 , ()) where 31 = (p1, p1, U 1), 3 2 = (p2,
p 2, U 1) .
Note that P1 and P2 are quantum processes constructed by the quantum process grammar,
whereas p1 and p2 are their seed algebraic forms constructed by Q-Process-Trans. The Greek letters
~
U 1 and U 1 denote density matrices. That 3 i are slightly different from 3 i is purely due to a
technical reason (of the need of processing recursion).
N
By modifying the axioms we can get different models of algebraic semantics for quantum
process algebra, such as weak bisimulation and late semantics. Due to space shortage we leave it to
the full paper version.
$ 4 Conclusion
In summary, the approach presented in this paper provides the following advantages:
The first advantage is its formality as compared with operational semantics and bisimulation
semantics. Other semantics need more or less the help of natural language to explain the exact
meaning they imply. For example, the difference of early and late semantics can hardly be made
clear without some literal explanation. But in algebraic semantics, the change of axioms represents
everyting rigorously.
The second advantage comes from the multiplicity of its models. One can consider different
models as different semantics. The ADT approach provides a unified view of all these semantics.
The third advantage is its unified form of representation. Traditionally, syntax and semantics
of a process algebra are represented by different formalism. In ADT, everything is represented with
the (sort, signature, axiom) three level structure. We have even ‘programmed’ the major part of the
core of quantum mechanics in this way.
Some problems discussed in this paper have been solved in the literature with different
techniques. For tackling non-determinism see e.g. [BW81] and [LER82]. In this paper we introduce
the concept of non-deterministic objects and their isomorphism. This approach not only reflects the
idea of nondeterminism in a more straightford way, but also avoids the explicit description of sets.
For hidden techniques and observability see e.g. [W89] and [ST87]. Our purpose of
introducing hidden operation is not to mask the details or private parts of a program module to
prevent it from unwanted intrusion. Rather, our purpose is to mask the unwanted details in the
isomorphic mapping of non-deterministic objects. The introduction of hidden symbols is actually a
necessity in establishing the correspondence between seed algebra elements and process states. The
granule of masking is also a difference between the various approaches: is it on the signature level,
the operation level, the sort level or the carrier set elements level? Our approach adopts an
operation level for masking.
It is worthwhile to mention that we have introduced the concept of subsort to describe the
hierarchy of linear operators on a Hilbert space for our quantum process algebra. It is not
286
paraphrased above to save the space. A subsort satisfies all axioms of some already defined sorts,
and at the same type satisfies some additional axioms. Subsort is a more delicate concept than
subtype and is close to the approach of embedding [ABK+02]. It makes our ADT not only a
many-sorted algebra but also an order-sorted algebra[ABK+02].
References
[ABK+02] E.Astesiano, M.Bidoit, H.Kirchner, B.Krieg-Brueckner, P.D.Mosses, D.Sanella,
A.Tarlecki. CASL: The Common Algebraic Specification Language. TCS. 286(2): 153-196, 2002.
[AG05] T. Altenkirch and R. Grattage. A Functional Quantum Programming Language. In
Proceedings of the 20th Annual IEEE Symposium on Logic in Computer Science(LICS). IEEE
Computer Society. 2005.
[BCS03] S.Bettelli, T. Calarco and L. Serafini. Toward an Architecture for Quantum Programming.
The European Physical Journal D. 25: 181-200, 2003.
[BPW82] M.Broy, P.Pepper, M.Wirsing, On the Algebraic Definition Programming Languages,
TUM-I8204, 1982.
[BW80a] M.Broy, M.Wirsing, Programming Languages as Abstract Data Types, In M.Dauchet
(Ed.), 5me Coll. Sur les Arbres en Algebre et Programmation, pp.160-177, 1980.
[BW80b] M.Broy, M.Wirsing, Partial Recursive Functions and Abstract Data Types, EATCS Bull.
11, pp.34-41, 1980.
[BW81] M.Broy, M.Wirsing, On the Algebraic Specification of nondeterministic programming
languages, E. Astesiano, C.Boehm (eds.), 6th CAAP, LNCS 112, pp.162-179, 1981.
[BW82] M.Broy, M.Wirsing, Partial Abstract Data Types, Acta Informatica, 18 (1): 47-64, 1982.
[C80] J.C.Cleaveland, Programming Languages Considered as Abstract Data Types, Proc. of the
ACM 1980 Annual Conference, pp. 236-245, 1980
[F07] Y. Feng, R. Y. Duan, Z. F. Ji and M. S. Ying. Probabilstic Bisimulations for Quantum
Processes. Information and Computation. 205: 1608-1639, 2007.
[Gay06] S. Gay. Quantum Programming Languages: Survey and Bibliography. Mathematical
Structures in Computer Science. 16(4): 581-600, 2006.
[GH78] J. Guttag and J Horning. The Algebraic Specification of Abstract Data Types. Acta
Information. 10: 27-52, 1978.
[GN05] S. Gay and R. Nagarajan. Communicating Quantum Processes. In Proceedings of the 32nd
ACM Symposium on Principles of Programming Languages, Long Beach, California, USA, ACM
Press, 145-157, 2005.
[GT75] J.Goguen, J. Thatcher, E. Wagner, J. Wright. Abstract Data Types as Initial Algebras and
the Correctness of Data Representation. In Proceedings of Conference on Computer Graphics,
Pattern Recognition and Data Structures, pp. 89-93, 1975.
[GT78] J. Goguen, J. Thatcher and E. Wagner. An Initial Algebraic Approach to the Specification,
Correctness and Implementation of Abstract Data Types. Currend Trends in Progr. Meth. 4: 80-149,
1978.
[Kni96] E. Knill. Conventions for Quantum Pseudocode. Technical Report LAUR-96-2724, Los
Alamos National Laboratory, 1996.
[Lal06] M. Lalire. Relations among Quantum Processes: Bisimulation and Congruence.
Mathematical Structures in Computer Science. 16: 407-428, 2006.
[Ler82] P.Lerscanne, Mod è ls non-deterministe de Types Abstraits, RAIRO Informatique
287
Theorique 16, pp.225-244, 1982.
[LJ04] M. Lalire and P. Jorrand. A Process Algebraic Approach to Concurrent and Distributed
Quantum Computing: Operational Semantics. In P. Selinger(Ed.) Proceedings of the 2nd
International Workshop on Quantum Programming Languages, pages 109-126.
[JL04] P. Jorrand and M. Lalire, Toward a Quantum Process Algebra, In Proceedings of the 1st
ACM Conference on Computing Frontiers. ACM Press, 2004.
[Jor05] P. Jorrand. A Programmer’s Survey of the Quantum Computing Paradigm. In Proceedings
of World Academy of Science, Engineering and Technology. Vol. 8, 2005.
[Lu87] R. Lu, Algebraic Semantics of Programs with Dynamic Structure, Science in China, A, 30
(1), pp. 32-44, 1987.
[Mln06] H. Mlnaík, Operational Semantics of Quantum Programming Language LanQ. Masaryk,
University Technical Reports. FIMU-RS-2006-10.
[Öme00] B. Ömer. Quantum programming in QCL. Master thesis, Institute of Information Systems,
Technical University of Vienna. 2000.
[Pap04] N.K.Papanikolaou, qSpec: A programming language for quantum communication systems design, in:
Proceedings of PREP2004 Postgraduate Research Conference in Electronics, Photonics, Communications &
Networks, and Computing Science (2004)
[Sel04a] P. Selinger. A Brief Survey of Quantum Programming Languages. Proceedings of the 7th
International Symposium on Functional and Logic Programming, Nara, Japan. Springer LNCS
2998, pp. 1-6, 2004.
[Sel04b] P. Selinger. Towards a Quantum Programming Language. Mathematical Structures in
Computer Science. 14(4): 527-586, 2004.
[ST87] D.T.Sanella, A.Tarlecki, On Observational Equivalence and Algebraic Specifications, J.
Comp. and Sys. Sceinces, 34, pp.150-178, 1987.
[SV05] P.Selinger and B.Valiron. A Lambda Calculus for Quantum Computation with Classical
Control. In Proceeding of the 7th International Conference on Typed Lambda Calculi and
Applications(TLCA), volume 3467 of Lecture Notes in Computer Science. Springer, 2005.
[SW83] D.T.Sanella, M.Wirsing. A Kernel Language for Algebraic Specification and
Implementation. LNCS 158, pp. 413-427. 1983
[Ton04] A. van Tonder, A Lambda Calculus for Quantum Computation, SIAM Journal of
Computing. 33(5): 1109-1135, 2004.
[W89] M. Wirsing, Algebraic Specification, MIP-8914, Uni.Passau, 1989.
[Xu08] J. Xu, F. Song, S. Qian, J. Dai and Y. Zhang. The Quantum Programming Language
NDQJava. Journel of Software. 19(1): 1-8, 2008. (In Chinses with English abstract)
[Y01] M. S. Ying, Topology in Process Calculus, Springer Verlag, 2001.
[Y08] M. S. Ying, Y. Feng, R. Y. Duan and Z. F. Ji. An Algebra of Quantum Processes. ACM
Transactions on Computational Logic. Vol. V. No. N. 1-12, 2008.
[Zil74] S. Zilles. Algebraic Specification of data types. Computation Structures Group Memo 119,
Lab for Computer Science, MIT, 1974.
[Zul01] P. Zuliani. Quantum Programming. PhD Thesis, University of Oxford, 2001.
Appendix
Axiom:
#non-hidden operations#
Axiom Part of C-Process-Trans
288
tinput (tconf (i-proc (c, u, p), tr), c, t) = tconf (subst (p, u, t), run (tr, it (c, t)))
toutput (tconf (o-proc (c, u, p) , tr), c, u) = tconf (p, run (tr, ot (c, t)))
tinput (tconf (compol (x, y), tr), c, t) = tconf (input (compol (x, y), c, t), run (tr, it (c, t)))
toutput (tconf (compol (x, y), tr), c, t) = tconf (output (compol (x, y), c, t), run (tr, ot (c, t)))
tinput (tconf (compor (x, y), tr), c, t) = tconf (input (compor (x, y), c, t), run (tr, it (c, t)))
toutput (tconf (compor (x, y), tr), c, t) = tconf (output (compor (x, y), c, t), run (tr, ot (c, t)))
t-h-act (tconf (p, tr)) = tconf (h-act (p), tr)
#hidden Operations#
input (compol (i-proc (c, u, p), z), c, t) = compol (subst (p, u, t), z)
output (compol (o-proc (c, u, p), z), c, u) = compol (p, z)
input (compor (z, i-proc (c, u, p)), c, t) = compor (z, subst (p, u, t))
output (compor (z, o-proc (c, u, p)), c, u) = compor (z, p)
h-act (tau (p)) = p
h-act (compo (i-proc (c, u, p), o-proc (c, v, q))) = compo (subst (p, u, v), q)
h-act (compol (x, y)) = compol (h-act (x), y)
h-act (compor (x, y)) = compor (x, h-act (y))
tleft (tconf (sum (x, y), tr)) = tconf (x, tr)
tright (tconf (sum (x, y), tr)) = tconf (y, tr)
tleft (tconf (compo (x, y), tr)) = tconf (compol (x, y), tr)
tright (tconf (compo (x, y), tr)) = tconf (compor (x, y), tr)
tleft (tconf (compol (x, y), tr)) = tconf (compol (left (x), y), tr)
tright (tconf (compol (x, y), tr)) = tconf (compol (right (x), y), tr)
tleft (tconf (compor (x, y), tr)) = tconf (compor (x, left (y)), tr)
tright (tconf (compor (x, y), tr)) = tconf (compor (x, right (y)), tr)
tback (tconf (x, tr)) = tconf (back (x), tr)
left (compo (x, y)) = compol (x, y)
right (compo (x, y)) = compor (x, y)
left (compol (x, y)) = compol (left (x), y)
right (compol (x, y)) = compol (right (x), y)
left (compor (x, y)) = compor (x, left (y))
right (compor (x, y)) = compor (x, right (y))
back (i-proc (c, u, p)) = i-proc (c, u, p)
back (o-proc (c, u, p)) = o-proc (c, u, p)
back (tau (x)) = tau (x)
back (nil) = nil
back (sum (x, y)) = sum (x, y)
back (compo (x, y)) = compo (x, y)
back (compol (x, y)) = compo (back (x), back (y))
back (compor (x, y)) = compo (back (x), back (y))
subst (i-proc (c, u, p), u, t) = i-proc (c, u, p)
subst (o-proc (c, u, p), u, t) = o-proc (c, t, subst (p, u, t))
subst (tau (x), u, t) = tau (subst (x, u, t))
subst (nil, u, t) = nil
subst (sum (x, y), u, t) = sum (subst (x, u, t), subst (y, u, t))
289
subst (compo (x, y), u, t) = compo (subst (x, u, t), subst (y, u, t))
sum (x, y) = sum (y, x)
sum (p, sum (x, y)) = sum (sum (p, x), y)
compo (x , y) = compo (y, x)
compo (p, compo (x, y)) = compo (compo (p, x), y)
#undefined operations ommited#
}
End of Type C-Process-Trans
290
Ruqian Lu received his Diplom in Mathematics from
Jena University in 1959 and is now a full professor
of Academy of Mathematics and Systems Science and
also a fellow of Chinese Academy of Sciences. He met
Bernd Krieg-Brückner for the first time in 1978 at a
workshop of IFIP 2.4 and has been keeping personal
relationship with Bernd for more than 30 years. His research focus is artificial intelligence, knowledge based
software engineering and formal semantics of quantum
programming.
Lixing Li received hisbachelor’s degree fromCentral
South Universityin 2006 majoring in computer science
and is now a PhD candidate under supervision of Professor Ruqian Lu. His research focus isformal semantics, quantum computation and quantum information.
Yun Shang received her PhD from Shannxi Normal
University in 2005 under supervision of Prof. Yongming Li. From 2005-2007, she worked as a Post-doc
in the group of Prof. Ruqian Lu. Since 2007, she has
been a lecturer at Academy of Mathematics and Systems Science. Her research focus is quantum information and quantum logic.
Xiaoyu Li received his PhD from the Institute of
Computing Technology, Chinese Academy of Sciences
in 2004 under supervision of Ruqian Lu. Then he went
to Zhengzhou University in 2005 and worked in School
of Information Engineering as lecturer. He got a position of associate professor in 2006. His research focus
is quantum information, especially quantum entanglement and non-locality, and quantum cryptography.
AG.com – Bremer Informatik-Arbeitsgemeinschaften in der
gymnasialen Sekundarstufe I
Prof. Dr. Holger Schlingloff
Humboldt-Universität zu Berlin & Fraunhofer FIRST
Holger Schlingloff war von 1996 bis 2002 Geschäftsführer des Bremer Instituts für Sichere
Systeme (BISS) im Technologie-Zentrum Informatik (TZI) der Universität Bremen, dessen
Direktor Bernd Krieg-Brückner war. Als Geschäftsführer akquirierte, leitete und bearbeitete er
viele Projekte für und zusammen mit dem Jubilar. Über eines dieser Projekte wird
nachfolgend berichtet.
Im Jahre 2000 beauftragte der Senator für Bildung und Wissenschaft des Landes Bremen,
Willi Lemke, den Dekan des Fachbereichs 3 (Mathematik / Informatik) der Universität
Bremen, Prof. Bernd Krieg-Brückner, mit der Erarbeitung eines Konzepts für BegabtenFörderkurse Informatik in den 7. und 8. Klassen an Bremer Gymnasien. In Folge dieses
Auftrags erstellte Prof. Krieg-Brückner in Zusammenarbeit mit dem Autor des vorliegenden
Berichtes eine Projektskizze und Angebot für solche Kurse, die als „AG7.com“ im Schuljahr
2001/2002 an 10 Bremer Schulen erstmals durchgeführt wurden und in leicht abgewandelter
Form als „AG.com“ noch heute (Schuljahr 2008/2009) laufen [1]. Dieser Artikel beschreibt die
pädagogischen Ziele, Inhalte und Erfahrungen, die sich bei der Durchführung ergeben
haben, und reflektiert das Projekt aus heutiger Sicht.
1.
Hintergründe und Voraussetzungen
Zur Zeit der Konzeption des Projektes gab es starke gesellschaftliche und politische
Motivationen, die Informatik an Bremer Schulen auszubauen. Wirtschaftlich befand sich die
Informatikindustrie zu dieser Zeit auf einem relativen Höchststand. In Bayern war gerade
beschlossen worden, Informatik als Pflichtfach an allen weiterführenden Schulen ab 2002
einzuführen. In Bremen war mit dem Projekt „Schulen ans Netz“ eine leistungsfähige
Infrastruktur geschaffen worden, die einer Nutzung bedurfte. Der neue Senator (seit Juli 99
im Amt) beabsichtigte eine Stärkung und Profilbildung der Bremer Schulen, gerade in
technischen Fächern. Andererseits standen dem Projekt einige Hindernisse im Wege. Schon
bei Bekanntwerden der Pläne gab es erhebliche Kompetenzstreitigkeiten, sowohl zwischen
dem Landesinstitut Schule und der Universität, als auch innerhalb des FB3 selbst. Über den
möglichen und sinnvollen Umfang gab es finanzielle Unklarheiten: während zunächst geplant
war, 50 Kurse mit je 10 Schülerinnen und Schülern und einem Finanzvolumen von 1,3 MDM
einzurichten, wurden in der ersten Phase lediglich 7 Informatik-Kurse mit je 15 Lernenden für
knapp 100 TDM eingerichtet. Es gab massive Interessenkonflikte mit anderen Protagonisten,
die die ursprüngliche Idee an weitere Ziele koppeln wollten (Mädchenförderung, Förderung
benachteiligter sozialer Gruppen, integrativer Unterricht, Stärkung der mathematischnaturwissenschaftlichen und / oder sprachlichen Kompetenzen, …). Dies führte letztlich
dazu, dass neben den 7 Informatik-AGs 3 Mathematik-, 3 Physik-, 3 Technomathematik- und
2 „Sprachen-im-Web“-AGs aus den vorhandenen Mitteln finanziert wurden und eine AG nur
für Mädchen offen war. Der Gedanke der Begabtenförderung wurde aus politischen
Überlegungen fallen gelassen; der Aufruf zur Teilnahme richtete sich an alle SekI-Schulen
und -Schüler. Er fand ein enormes Echo bei den Bremer Schulen, Lehrkräften und Kindern:
über 20 Schulen bewarben sich für die vorgesehenen 5 Standorte, trotz Mehrbelastung
waren viele Lehrkräfte freiwillig bereit, am Projekt teilzunehmen, und seitens der
Schülerinnen und Schüler gab es bis zu 10 mal so viele Anmeldungen, wie Plätze vorhanden
waren.
Das Projekt wurde mit einer Pressekonferenz am 12.2.2001 gestartet.
292
2.
Pädagogische Zielsetzung und Konzeption
Generell war und ist der Begriff „Informatik“ in der Sek 1 vielfach diskutiert und (fehl-)
interpretiert worden. Zur Abgrenzung ist zunächst zu unterscheiden zwischen der Nutzung
von Computern im Unterricht, der informationstechnischen Grundbildung (ITG) und der
Informatik als Fach.
x
Computer im Unterricht
Hier geht es darum, den Computer als Medium zur Unterstützung von Lernvorgängen
und zur Kommunikation im Unterricht zu verwenden. Beispiele sind
Sprachlernprogramme, Internetrecherchen zu bestimmten Themen oder
elektronische Abgabe von Aufgaben. Die Meinungen über die Sinnhaftigkeit des
Einsatzes des neuen Mediums sind geteilt: während viele Pädagogen der Auffassung
sind, in der nächsten Generation werde der PC ein selbstverständliches Arbeitsmittel
zu Hause und im Unterricht sein, gehen andere inzwischen schon wieder dazu über,
Hausaufgaben am Computer zu verbieten.
x
informationstechnische Grundbildung ITG
Hier geht es darum, den Schülerinnen und Schülern im Sinne eines
„Computerführerscheins“ Grundfertigkeiten in der Nutzung von Computern
beizubringen. Ziel ist die Vermittlung von vermeintlich oder auch tatsächlich
berufsrelevantem Wissen (vergleichbar dem Stenographieunterricht der 1950-er
Jahre), da inzwischen über 90% aller Berufe unmittelbar oder mittelbar mit
Computern zu tun haben. In der Erweiterung wird die informationstechnische
Grundbildung zum Programmierunterricht in einer bestimmten Sprache, z.B. Delphi
oder Java, wobei die Halbwertszeit des Gelernten oft kaum eine Rolle spielt.
x
Informatik als Fach
Hier geht es darum, Wirkprinzipien moderner Informationstechnologie zu erklären
und Systeme aus der Erfahrungswelt der Lernenden zu modellieren und zu
simulieren, um ein Verständnis für Funktionszusammenhänge als Grundlage für ein
allgemeines Weltbild zu wecken.
In der AG.com ging es nur um den dritten Aspekt, d.h. Informatik auf dem Niveau 13-jähriger
Schülerinnen und Schüler zu behandeln. Thema sollten die Möglichkeiten und Grenzen des
verantwortungsbewussten Einsatzes von Computern in ihrem Erfahrungs- und
Einflussbereich sein. Der Computer sollte als Werkzeug zur Informationsverarbeitung
verständlich gemacht werden, d.h. nicht Gegenstand, sondern Mittel zum Zweck sein.
Die Sek 1 eignet sich aus verschiedenen Gründen besonders gut für die Einführung von
Informatik als Fach. A priori ist bei den Schülerinnen und Schülern eine hohe Motivation
durch die besondere Attraktivität des Mediums Computer gegeben. Als wichtigstes Ergebnis
ist der Erwerb von Handlungskompetenz anzusehen, der die Lernenden zu
verantwortungsbewusstem Handeln verhilft. Durch den strukturierten Problemlöseprozess
ergibt sich eine allgemein anwendbare Methodenkompetenz für technischnaturwissenschaftliche Fächer. Die Erstellung „funktionierender“ Lösungen trägt zum Aufbau
von Selbstkompetenz und Selbstbewusstsein bei. Durch die Notwendigkeit von
Gruppenarbeit erwerben die Teilnehmenden erhebliche Sozialkompetenzen. Die Inhalte
vermitteln grundlegende Sachkompetenzen für den notwendigen Aufbau- Unterricht in der
Sekundarstufe II und in berufsbildenden Schulen.
Organisatorisch wurden die Kurse so eingeteilt, dass für ca. 15
Teilnehmende je eine Lehrkraft sowie eine studentische
„Lehrassistenzkraft“ zur Verfügung standen. Die AGs wurden zentral
betreut und verteilt in den Computerlabors der jeweiligen Schulen
durchgeführt. Wöchentlich gab es eine gemeinsame Vor- und
Nachbesprechung an der Uni, bei der eine direkte und indirekte
Rückkopplung zu den Konzepten und ein Austausch von Ideen statt
fanden. Von der zentralen Kursleitung wurden interaktive und
293
klassische Unterrichtsmaterialien bereitgestellt: Webseiten, Aufgabenblätter, Arbeitsbögen
und Anschauungsmaterialien. Besonders stolz ist der Autor auf das für die AG7.com
geschaffene Maskottchen „Saschi“, eine jugendliche Schildkröte, die als Identifikationsfigur
und Wegweiser im Stoffangebot fungiert. Als Lernsoftware wurde eine speziell angepasste
Version von „MicroWorlds Pro“ des kanadischen Herstellers LCSI eingesetzt; diese auf dem
klassischen LOGO basierende multimediale Programmierumgebung erlaubt ein weites
Spektrum von Anwendungen, von der Erstellung einfacher funktionaler und paralleler
Programme, Bild- und Textverarbeitung, bis hin zum komplexen Internet Design.
3.
Unterrichtseinheiten, Themen und Lerninhalte
Während für die Lernziele der AG7.com
Vorgaben in Gestalt von GIEmpfehlungen für Informatik in der SekI
[2] sowie Entwürfe für Lehrpläne
einzelner Länder vorlagen, musste eine
Strukturierung dieser Lernziele in
Unterrichtseinheiten (UE) neu erstellt
werden. Jede UE behandelte ein
bestimmtes Thema. Für die einzelnen
Themen wurden Lerninhalte erstellt, und
Fertigkeiten definiert, die die
Schülerinnen und Schüler durch die
Bearbeitung der Einheit erwerben
sollten. Zu jeder UE gab es
umfangreiche Materialien, sowohl für die
Lehrenden als auch für die Lernenden.
Bei der Auswahl der Lerninhalte wurden
verschiedene Kriterien berücksichtigt,
zuvorderst das der Übertragbarkeit:
während Inhalte der Klasse (a) für ein
konkretes IT-System (z.B. MicroWorlds
Pro) gelten, sind Inhalte der Klasse (b)
für eine Generation von IT-Systemen
anwendbar (z.B. Logo-Programmiersysteme). Inhalte der Klasse (c) sind für alle IT-Systeme
relevant (z.B. Programmiermethodik), während Inhalte der Klasse (d) auch außerhalb der
Informatik angewendet werden können (z.B. Organisation von Abläufen). Bei der
Präsentation des Stoffes wurde notwendigerweise von Inhalten der Klasse (a) ausgegangen;
es wurde jedoch Wert darauf gelegt, die Abstraktion zu den jeweils höheren Ebenen adäquat
darzustellen.
Ausgehend von den grundlegenden Aspekten der Informationsverarbeitung (Modellierung
bzw. Abstraktion eines Weltausschnittes, Verarbeitung bzw. Übermittlung von Information,
und Interpretation durch bzw. Interaktion mit Benutzern) wurden die zu vermittelnden Inhalte
jeder UE unterteilt in
x das Repräsentieren von Information und Wissen durch die Kinder,
x die Behandlung der Funktionsweise und Konstruieren von IT-Systemen, und
x die kritische Auswertung und Auseinandersetzung mit den Resultaten
Die Umsetzungsform war dabei immer projektbasiert, d.h. nach einer Problembegegnung
und -einordnung durch die Lehrkraft erfolgte eine individuelle informelle Beschreibung der
Aufgabe durch jeden einzelnen Lernenden, dann wurde eine gemeinschaftliche Modellierung
und Abstraktion durch Kleingruppen vorgenommen. Erst daran schloss sich die
Implementierung bzw. Realisierung am Computer an, in jedem Fall gefolgt durch eine
Bewertung und Auswertung durch die gesamte Gruppe, mit einem schulübergreifenden
Feedback (Wettbewerb) über die besten Lösungen.
294
Exemplarisch sei diese Vorgehensweise nachfolgend an zwei UE demonstriert.
UE3: Geschichten die das Leben schrieb...
Thema: Textverarbeitung I
Lernziele: Die Schüler sollen
die heutige Textverarbeitung
als Ergebnis einer
kulturgeschichtlichen
Entwicklung begreifen. Sie
sollen zwischen Textgehalt und
Textgestalt differenzieren und
die inhaltliche Erstellung eines
Textes vom Prozess des
Layouts separieren können.
Lerninhalte: Textverarbeitung
als häufigste Anwendung
heutiger Arbeitsplatzrechner;
kulturgeschichtliche
Entwicklung der Schrift aus
Bildern und Symbolen; Vorteil
kleiner Alphabete;
Vervielfältigung durch
manuelles (sequentielles)
Kopieren und (seitenweises)
Drucken; Analogie zwischen
der Aufteilung eines Wortes in
einzelne Buchstaben und der
Aufteilung einer Druckseite in
einzelne Lettern; nichtdruckende Lettern und
Trennzeichen; Zeichenattribute
(Font, Farbe, usw.);
Seitenlayout und Design am Beispiel einer Einladungskarte
Kompetenzen:
x Handlungskompetenz: Computer als selbstverständliches Schreibwerkzeug
x Methodenkompetenz: Inhalt versus Layout
x Selbstkompetenz: Schrift als Kulturgut
x soziale Kompetenz: Kopierproblematik
x Sachkompetenz: Erzeugen von Dokumenten
Fertigkeiten: MicroWorldsPro als Textverarbeitungsprogramm (Erzeugen von Textboxen,
Kombination von Text und Grafik, Rechtschreibprüfung).
Unterstützt wurden die Inhalte durch interaktive Webseiten und Arbeitsbögen für die Schüler,
Handreichungen für die Lehrer und weitere Materialien. Das obige Beispiel zeigt einen
Auszug aus den Internetseiten.
295
Die Handreichungen für die Lehrer umfassten neben Ontologie und pädagogischen
Hinweisen auch konkrete Tipps zum Umgang mit der Software (Inhalte Klasse (a)).
AG7.com
2.
2.1
Geschichten die das Leben schrieb...
Entwicklung der Textverarbeitung
Inhalt und didaktische Hinweise
Begriffe
Vor der Logo-Textverarbeitung soll die geschichtliche Entwicklung der Schrift
Textverarbeitung
und der Druckkunst behandelt werden Schriftsatz (siehe Arbeitsbögen und
WWW-Seiten). Insbesondere geht es um den Wandel des Arbeitslebens durch
Computereinsatz (Sachbearbeiter, Autoren, Reporter, usw.)
Die Schülerin/der Schüler soll eine Einladung zur Geburtstagsfeier schreiben.
Er/sie soll lernen, mit einfachen Textbearbeitungsmitteln zu hantieren und Bild
und Text zu kombinieren. Er/sie soll Vor- und Nachteile traditioneller Techniken
(Buntstifte, Schere, Papier) mit der elektronischen Vorgehensweise vergleichen.
Er soll weiterhin den Unterschied zwischen Textgehalt (Text als Folge von
Zeichen) und Textgestalt (Attribute jedes Zeichens: Schriftart, Schriftstil,
Schriftgröße, Schriftfarbe) begreifen. Insbesondere soll klar gemacht werden,
was beim Layout maschinell gemacht wird (Zeilenumbruch, Rechtschreibprüfung) und was nie automatisch gemacht werden kann (Textinhalt, Stil)
Textgehalt versus -gestalt
Starten des Programms und Einstellen der Projektgröße:
Datei – Projektgröße (je nach intendiertem Wiedergabemedium: Webplayer,
Postkarte, Din A4-Papier usw. Einstellen anderer Projektgrößen mit der
Anweisung
Projektgröße [1414 2000] für A4 Hochkant max.)
Import eines (Hintergrund-)bildes; Datei – Importieren – Bild.
Bilder befinden sich im englischsprachigen MW-Logo unter “Pictures”.
Projekteinstellungen
Alternativ: SchülerInnen erstellen mit den Grafikwerkzeugen eigenes
Hintergrundbild. Aus der Symbolleiste das Textwerkzeug “A” auswählen,
in “Seite” klicken, möglichst groß aufziehen und “Einladungskarte”
(oder Ähnliches) schreiben.
Schriftart und Farbe verändern: mit der Maus markieren, dann
Text – Schriftart – Schriftfarbe
Position und Größenänderung: Mit der Maus Textfeld umreissen
(Aktivierungspunkte).
Diskussion logische Zeilen (Absätze) vs. dargestellte Zeilen
(automatischer Zeilenumbruch).
rechter Mausklick ergibt Kontextmenü der Textbox, (Mac: Ctrl-Klick):
transparent / Namen / Rechtschreibung usw.
Dies machen wir nun noch ein paar Mal, in einer anderen Schriftart und Farbe.
Zum Ausdrucken: Menü “Seite einrichten”. Projekt speichern!
Bild Importieren
Textwerkzeug
Markieren
Nichtdruckbare Zeichen
296
Als Idee für eine Schülerarbeit wurde eine interaktive Geschichte angegeben (aus einer
früheren AG, Design Laura Schlingloff):
Zur Operationalisierung wurden die Schülerinnen und Schüler aufgefordert, eine interaktive
Einladungskarte zu erstellen. Ein Beispiel war auf den Internetseiten angegeben.
297
Nachfolgend sind einige Schülerarbeiten zu dieser UE wiedergegeben. Bemerkenswert war
dabei, dass die Aufgabe bei den Lehrerinnen und Lehrern nicht so gut ankam, weil sie ihnen
nicht „attraktiv“ genug erschien. Einige Pädagogen fragten, warum man „nicht gleich
Microsoft Word“ verwenden könnte, das sei ja viel praxisnäher, oder warum man nicht gleich
verlinkte Hypertext-Strukturen mit HTML einführte. Andere änderten die Aufgabenstellung
dahingehend ab, dass nicht eine normale Geburtstagseinladung erstellt werden sollte,
sondern eine „interaktive Web-Visitenkarte“, dies sei ja viel fortschrittlicher. Die Schülerinnen
und Schüler hingegen nahmen die (ursprüngliche) Aufgabenstellung (Erstellung einer
Einladungskarte für eine Party) begeistert auf, weil sie aus ihrer Erfahrungs- und Erlebniswelt
entstammte und sich auf ein Problem bezog, welches jeder selbst schon einmal mit anderen
Mitteln gelöst hatte.
298
Das zweite Beispiel betrifft die Einführung algorithmischer Konzepte (Begriff eines
„Programms“, Ablaufsteuerung, Strukturierung durch Makros).
Zur Vorbereitung war in einer vorhergehenden UE die Analogie zwischen einer Melodie (als
Folge von Tönen) und einem Programm (als Folge von
Einzelschritten) hergestellt. Diese Analogie wird von
MicroWorlds Pro recht gut unterstützt, da es einen
„Musikeditor“ enthält, mit dem man auf einem „virtuellen
Klavier“ Tonfolgen interaktiv eingeben kann. Man kann aber
auch die Befehle zum Abspielen der Noten als Befehle
eingeben. Daran lässt sich sehr gut das Erfordernis / die
Möglichkeit einer eindeutigen Notation und Eingabesyntax
vermitteln. Darüber hinaus dürfte diese Analogie einigen Jugendlichen durch das
„Programmieren“ von Klingeltönen für Mobiltelefone
vertraut sein.
Als umfangreicheres Beispiel für eine Folge von Schritten
wurde das internationale Kinderlied „Bruder Jakob“
vorgestellt, bei dem sich die Notwendigkeit einer
Strukturierung durch Makros leicht erkennen lässt.
299
Weitere Analogien für Computerprogramme sind Kinoprogramme als Folge der gezeigten
Filme, und politische Wahlprogramme als Liste der intendierten Gesetzentwürfe. Mit diesen
Vorbereitungen konnten Programme als Ablaufbeschreibungen allgemeinerer Natur
eingeführt werden.
UE6 Schritt für Schritt
Thema: Programme und Algorithmen
Lernziele: Die Schüler sollen eine algorithmische (iterative) Vorgehensweise zur Lösung von
Problemen kennenlernen, bei der eine Gesamtaufgabe in ein Folge von sequentiell zu
erledigenden Teilaufgaben zerlegt wird.
Sie sollen ein Programm als eine solche Folge von wohldefinierten Enzelanweisungen
begreifen und die Notwendigkeit einer eindeutigen sprachlichen Grundlage zur
Kommunikation mit Computern erkennen.
Lerninhalte: Begriff Programm, Algorithmus, Programmiersprache; Notwendigkeit der
Eindeutigkeit der Einzelschritte; Ausführung von Anweisungen als Abarbeitung eines
Programms (Beispiel aus dem Alltag); Definition von eingeschränkten Sprachmitteln;
Grundbefehle und Befehle mit Eingaben; Syntax von Logo; rechtwinklige Bewegungen der
Schildkröte anhand einfacher Spiele
Kompetenzen:
x Handlungskompetenz: Beschreibung von Handlungsabläufen
x Methodenkompetenz: Fähigkeit zur Definition elementarer Schritte eines Verfahrens
x Selbstkompetenz: eigene Planung von Aktionsfolgen für Arbeiten
x soziale Kompetenz: Kommunikation mit Menschen und Maschinen
x Sachkompetenz: Programmablauf als Ausführung einer Anweisungsfolge
Fertigkeiten: Beschreibung von Arbeitsabläufen als Folge wohldefinierter Einzelanweisungen
in einer wohldefinierten Sprache.
300
Zur Operationalisierung sollten die Schülerinnen
und Schüler an Hand eines Stadtplanes den Weg
von der Schule zum Bahnhof beschreiben, und
aus dieser Beschreibung einen Basissatz von
elementaren Anweisungen („100 Meter
geradeaus“, „rechts abbiegen“ usw.) extrahieren.
Mit diesen Basisanweisungen sollten dann
verschiedene Bewegungsspiele gestaltet werden
(mit verbundenen Augen um Hindernisse laufen,
den Weg zum Direktorat beschreiben usw.). Als
nächste Stufe wurde ein Spiel vorgegeben, bei
dem eine Schildkröte per Knopfdruck
Basisbewegungen durchführt („einen Schritt
vorwärts“, „rechts um“ usw.). Aufgabe ist es, die
Schildkröte aus einem einfachen Labyrinth
heraus zu führen. Die Folge der Knopfdrücke
lässt sich dabei, ähnlich wie die Folge der Tastendrücke auf dem virtuellen Klavier der
vorhergehenden UE aufzeichnen und insgesamt abspielen. Auf diese Weise entsteht
interaktiv ein erstes „Programm“ als Folge von Einzelschritten. In der nächsten Stufe ging es
dann darum, die Folge der Aktionen im Voraus zu planen, d.h., eine Folge von Anweisungen
zu finden, die die Schildkröte aus dem Labyrinth bringen, ohne dass diese während der
„Programmierung“ durchgeführt werden. Da diese Aufgabe signifikant schwieriger ist, wird
den Lernenden die Notwendigkeit von Strukturierungen und Makros erneut deutlich. In der
letzten Stufe dieser UE sollten die Schülerinnen und Schüler dann mit den aus vorherigen
UE bekannten Zeichenwerkzeugen eigene Labyrinthe erstellen. Die Schildkröte lässt sich
dabei so einstellen, dass sie sich kontinuierlich vorwärts bewegt; mit den Knöpfen „rechts“
und „links“ wird das Ergebnis dann zum interaktiven Action-Spiel, welches an kommerzielle
Produkte (Autorennen o.ä.) erinnert. Nachfolgend sind zwei solcher von Schülern
programmierten Spiele abgebildet.
301
4.
Erfahrungen, Reflektion und Ausblick
Die Erfahrungen mit dem Projekt lassen sich in verschiedene Ebenen einteilen. Auf Ebene
der Schülerinnen und Schüler lässt sich konstatieren, dass die Lerninhalte insgesamt sehr
gut und altersgerecht vermittelbar waren. Die Kinder waren zum größten Teil mit Feuereifer
bei der Sache, waren sehr engagiert und nahmen den Stoff wissbegierig auf. Sie waren stark
daran interessiert, den Stoff zu Hause weiter zu bearbeiten; insbesondere der interne
Wettbewerb und der Wettbewerb zwischen den Schulen erwies sich als
motivationsförderlich. Auch die Nachhaltigkeit war gegeben: Die meisten Teilnehmer gaben
an, Informatik weiter machen zu wollen. Jahre später traf der Autor auf einer RoboCupMeisterschaft einen der ehemaligen Teilnehmer wieder, der in den höchsten Tönen von dem
damaligen Kurs schwärmte. In Bezug auf die Bearbeitung der Aufgaben ließen sich auch
geschlechtsspezifische Unterschiede feststellen: während die Jungen eher mit den
Werkzeugen und Methoden experimentierten und die Aufgaben oft nicht fertig stellten, waren
die Mädchen eher an einer „korrekten“ Lösung interessiert und betrachteten Werkzeuge und
Methoden als Mittel zum Zweck. Die Arbeit in der nur für Mädchen reservierten AG war
insgesamt entspannter, in allen anderen AGs bildeten sich geschlechtsspezifische Gruppen,
die kaum interagierten.
Eine Haupt-Erfahrung ist, dass es erhebliche Schwierigkeiten bereitet, zusätzliche Inhalte
und Aufwände in den Schulalltag einzubringen. Das verfügbare Zeitbudget sowohl von
Schülern wie auch von Lehrern ist heute weitgehend ausgeschöpft; die Frage ist, welche
Prioritäten von Kindern, Eltern, Schule und Gesellschaft gesetzt werden. Die begabtesten
Schüler sind oft mit vielen weiteren Aktivitäten (Musik, Sport etc.) ausgelastet. Die
engagierten Lehrerinnen und Lehrer sind meist schon reichlich mit ähnlichen Aktivitäten
eingedeckt. Auch als Weiterbildung konkurriert solch eine AG mit anderen Angeboten und ist
aus Sicht der Lehrer nur von relativem Wert. Insbesondere waren die Lehrerinnen und
Lehrer in den wöchentlichen Besprechungen in erster Linie an Inhalten der Klasse (a) und
(b), d.h. an Informationen über die spezielle Programmierumgebung bzw. den Umgang mit
der Rechnerinfrastruktur der jeweiligen Schule interessiert.
Auf der Ebene der Lehrer ist weiterhin festzustellen, dass ein solcher anspruchsvoller
Unterricht sehr betreuungsintensiv ist; 15 Lernende auf eine Lehrkraft plus eine
Lehrassistenzkraft sind als Obergrenze anzusehen. Die Durchführung als AG war eher
zeitproblematisch, da die Kurse mit anderen Aktivitäten der Lernenden und Lehrenden
konkurrierten. Hier zeigten sich auch signifikante Unterschiede in der Kultur der einzelnen
Schulen: Während in einigen Schulen gegen Ende die Teilnehmerzahl deutlich abnahm,
blieben in anderen Schulen alle Schülerinnen und Schüler von Anfang bis zum Schluss
dabei. Die Mischung verschiedener Schulformen (Haupt/Realschule und Gymnasium)
funktionierte nicht, da die Motivation der Gymnasiastinnen und Gymnasiasten im
Allgemeinen höher und vor allem stetiger war.
In einzelnen Schulen ergaben sich ziemliche Schwierigkeiten mit der Infrastruktur, mit falsch
verstandenen Sicherheitskonzepten und mit administrativen Dingen. Die technischen
Probleme waren jedoch meist hausgemacht, durch falsche Systemkonfigurationen oder
unzureichende Administration verursacht. Die AGs verhalfen den Schulen zur Profilbildung,
die in den meisten Fällen noch heute (2009) das Profil mitprägen.
Insgesamt lässt sich konstatieren, dass mit der AG.com gezeigt wurde, dass Informatik als
Sek1-Fach gut geeignet ist. Die Auswahl der richtigen Lehr- und Lernsoftware ist wichtig,
jedoch nicht von entscheidender Bedeutung. Wichtiger ist es, Technik und Inhalte sauber zu
trennen und die Stoffauswahl der Erlebenswelt der Ziel-Altersgruppe anzupassen. Die
AG.com wurde, nachdem der Autor die Projektleitung abgegeben hatte, mit Schwerpunkt im
Bereich Robotik fortgesetzt. Die wesentlichen Ideen tragen dabei noch heute und werden
voraussichtlich im Schuljahr 2009/2010 in einer vom Autor organisierten und von der
Telekom-Stiftung finanzierten „Junior-Ingenieur-Akademie Informatik“ in Berlin weitergeführt.
302
Literatur
[1] AGcom – Arbeitsgemeinschaften am Computer in Bremer Schulen;
http://www.agcom.uni-bremen.de/
[2] GI-Rahmenempfehlung für die Informatik im Unterricht der Sekundarstufe 1;
Informatik-Spektrum, 9 (1986) 2, S. 141-143
[3] Lehrpläne Informatik an Gymnasien;
Deutscher Bildungsserver http://www.bildungsserver.de,
siehe auch Bundeswettbewerb Informatik, http://www.bwinf.de/index.php?id=128
Using Orientation Calculi and Route Graphs
to Interpret Route Descriptions
Hui Shi
Universität Bremen and DFKI-Lab Bremen, Germany
{shi}@informatik.uni-bremen.de
Abstract. This paper summarizes two papers Prof. Bernd Krieg-Brückner
and myself published at the 4th International Conference on Geographic
Information Science 2006 [7] and in the International Journal of Software
and Informatics 2008 [14], in memory of a successful, pleasant and hard
joint work with him.
Keywords: Qualitative Spatial Calculi, Route Graph, Navigation Space,
Human-Robot Interaction, Conceptual Model, Algebraic Specification
1
Motivation
The major research aim here is to develop effective and natural communication between humans and robots about spatial issues, e.g. dialogues between a
driver and the Bremen semi-autonomous wheelchair Rolland [10]. A particular goal is the resolution of shared-control problems caused by spatial knowledge
mismatches between humans and robots through clarification dialogues.
Following the main ideas of the Spatial Semantic Hierarchy [8] we introduce
two distinct spatial representations in the human-robot interaction on route navigation. The “metric level” represents the spatial knowledge of a robot; and the
“conceptual level” the spatial knowledge of a user. In this context we are aiming for conceptual modelling humans’ spatial knowledge by integrating qualitative orientation calculi, in particular Freksa’s Double-Cross calculus, with Route
Graphs, to interpret users’ route descriptions for natural communication, and to
obtain a semantically well-founded interface to the robot’s internal spatial representation, such that an efficient mapping between them can be realized. As an
example, we would like to give a semantic interpretation to the route description
in our office building, cf. Fig. 1.
This paper is structured as follows: We introduce qualitative spatial calculi
and Route Graphs in Section 2. The conceptual model for interpreting route
descriptions is introduced in Section 3. In Section 4 a brief formalization of the
model in the algebraic specification language CASL is presented.
2
Qualitative Spatial Calculi and Route Graphs
Route descriptions are mental constructions that are schematized [17]. Certain
information, such as exact metric data, is often systematically simplified and
304
Fig. 1. Integrating the routes from the lift and the secretariat to Prof. Krieg-Brückner’s
office into a simple Route Graph
even distorted. Several empirical studies show that the critical elements of route
descriptions are landmarks and paths, links and nodes [16, 3, 15], thus topological
maps are often used to model such graph-like structures (e.g., [8, 17, 18]). In
[6] Krieg-Brückner et al. give a standard ontological definition of the Route
Graph for navigation by various agents in different applications; we will use it to
represent route descriptions, such that structural relations of route navigation
can be inferred.
On the other hand researches on qualitative spatial representation and reasoning try to model and to abstract common sense knowledge about space, such
that an automation could model, explain and inform about a human’s behaviour
in space, even if precise quantitative information is not available or is too complicated to be computed [2]. Considering the empirical evidence collected from
some our empirical experiments [15], we chose Freksa’s qualitative spatial calculus [5, 19] to represent and to reason about orientation information involved in
route descriptions.
2.1
The Route Graph Model
RouteGraphs have been introduced as a general concept for navigation by various agents in a variety of scenarios [18, 6]. They can be used as metrical maps
with sensory input and additional metrical computation models to control the
navigation of robotic agents in the environment, or be used at the cognitive level
to model abstractly humans’ topological knowledge while they act in the space.
The most important character of Route Graphs is that different routes can be
integrated into a graph-like structure in which the information concerning these
routes are composed.
Route Graphs are a special class of graphs. A Node of a Route Graph, called
a Place, has a particular position and has its own “reference system”; it may
be rooted in a (more) global reference system. An Edge of a Route Graph is
directed from a source to a target node. We call an edge a RouteSegment; it
always has three additional attributes: an Entry, a Course and an Exit. Exactly
what infomation is associated with these attributes is specially defined for each
305
directions in natural language:
Leave the lift into the stairway
Turn left, go straight ahead to the glass door
Go through the door
Turn right, follow the corridor until the last door on the lefthand-side
– Face it, enter the room Cartesium 2.041
–
–
–
–
Fig. 2. Sample Route: from the lift to Prof. Krieg-Brückner’s office
enter the room Cartesium 2.041 mapped to a RouteSegment
–
–
–
–
–
Source: corridor
Entry: towards the door of the room Cartesium 2.041
Course: go through the door
Exit: [against the door]
Target: the room Cartesium 2.041
Fig. 3. A Route Segment and its components
Route Graph instantiation. For example, an entry/exit at the cognitive level may
contain qualitative orientation information (e.g., to the left/right), the course is
then the path between two reorientations. Consider the example in Fig. 2 and
Fig. 3. A Route is a concatenation of a sequence of route segments from one
place to another. For more information please see [18, 6].
2.2
Qualitative Spatial Reasoning using Orientation Information
In the Double-Cross calculus [5, 19], the concept orientation grid is introduced
to represent qualitative orientation information. The grid is aligned to the orientation determined by two points in 2-dimensional space, the start point and
the end point of a movement represented as an oriented edge. Combining the
front/back and the left/right dichotomy, the Double-Cross calculus may distinguish 15 meaningful disjoint orientation relations, see Fig. 4.
The edge between the two points gives rise to the orientations front and back
on this line, also leftAtExit, rightAtExit, leftAtEntry, and rightAtEntry, whose
terminology we have borrowed from Route Graphs in this paper; left and right
correspond to two areas w.r.t. the edge, similarly leftFront, rightFront, leftBack,
and rightBack; finally, the special positions atEntry, atExit and onCourse are
introduced.
306
front
rightFront
front
leftFront
rightFront
leftFront
left
right
leftBack
rightBack
back
(a)
atExit
onCourse
atEntry
leftAtExit
left
leftAtEntry
rightAtExit
right
rightAtEntry
leftBack
rightBack
back
(b)
Fig. 4. Orientation grid with 8 (a) and 15 (b) relations for the Double-Cross calculus
3
A Conceptual Model for Route Navigation
We are now going to develop a spatial model, called conceptual model, to represent humans’ route descriptions, which combines the Double-Cross calculus
and the Route Graph. Its structure and operational properties are then formally
specified in Section 4.
Let O be the type of orientations, L of locations, M of landmarks and V of
vectors. The function at defines the location of a given landmark, thus at(m) = l
means that landmark m is at location l. The conceptual model is in fact a special
kind of Route Graph P, S, where P ⊆ L is the set of reachable places and S
⊆ V the set of route segments. Furthermore, the following functions are defined:
origin:
P → V, the reference frame of a place
oCourse: S → V, the course of a route segment
oEntry: S → O, the entry of a route segment
oExit:
S → O, the exit of a route segment
The elementary relation of the conceptual model is the orientation relation ori, which defines the orientation of a location with respect to a vector: ori(v, l, rightFront), for example, means l is on the right front of v, i.e.,
v : l = rightFront in the Double-Cross calculus.
People often use spatial relations in their route descriptions, for example,
“the main stairs are on the left” just states the spatial relation between the
“main stairs” and the current position (i.e., the current place and direction);
“through the door” includes a movement and a relation: after the movement
the door is behind. Based on the relations ori and at , a set of relations can be
introduced for defining such spatial relations.
via(v, m) ⇔ ∃l. at(m) = l ∧ ori(v, l, onCourse)
passOnLeft(v, m) ⇔ ∃l. at(m) = l ∧ ori(v, l, left)
passOnRight(v, m) ⇔ ∃l. at(m) = l ∧ ori(v, l, right)
passBy(v, m) ⇔ ∃l. at(m) = l ∧ (passOnLeft(v, l) ∨ passOnRight(v, l))
(1)
(2)
(3)
(4)
As defined, a route is a sequence of connected route segments. To integrate
two routes into a route graph, one has to come up with a common location in the
environment, and all related entries and exits on one route at that location must
be recomputed to conform with the other route at that location. Furthermore,
the consistency of the spatial relations related to the common location should
be proved according to the Double-Cross calculus [5].
307
4
Formalizing the Conceptual Model in Casl
In this section we give an overview to the specification of the conceptual model
(see Section 3) using the Common Algebraic Specification Language, Casl [1,
12]. A detailed and complete specification can be found in [14]. A Casl specification basically includes declarations, to introduce components of signatures,
such as sorts to introduce types, operations or predicates, as well as axioms written in first-order logic, to give properties of those structures. Anybody, who has
some knowledge about algebraic specifications, should have no serious problem
to understand the specifications given in this section.
4.1
Ego Orientation Calculus
While the Cardinal Direction calculus (cf. [4, 11]) and the Star calculus [13]
are based on a global reference frame, the ego orientation calculus uses local
reference frame associated to each point. Depending on the application, we may
want to distinguish 2, 4, and 8 orientations (or more); the more orientations we
consider, the finer our statements become, but we generate more computational
complexity in this way.
The Casl specification EgoOrientation introduces the sort Orientation
and its three subsorts. Orientation2 has two orientations front and back; Orientation4 extends Orientation2 with left and right; finally Orientation8 extends
Orientation4 with additional four orientations: rightFront, leftFront, rightBack
and leftBack. Several operations are defined for the orientations, inverse (∼ o)
and complement ( o ); plus (+) and minus (−), denoting addition and subtraction of orientations. + is associative, commutative and has f ront as a unit
element, thus (Orientation, f ront, +) constitutes a commutative monoid.
All the properties defined in EgoOrientation hold generally for all ego
orientation calculi, no matter how fine the orientations are. Here are some examples:
•a=a
• ∼ front = back
4.2
• a + a = front
•∼∼a =a
• back + back = front • left = ∼ right
Locations and Vectors
The definition of locations extends the pre-defined specification Identities with
a new sort Location and an operator id associating each location with an identifier (Fig. 5). As an extension of EgoOrientation and Locations, the specification Vectors introduces the sort Vector that denotes directed connections
between two locations.
Each vector has a source and a target location, defined by two functions
source and target. Vectors are constructed by the operation “−→ ”. Note that
“→?” is a partial constructor operation in Location × Location →? V ector;
the additional axiom definedness states that the vector is defined, only if the
operation −→ is applied to two different locations.
308
spec Locations = Identities then
sort Location
op
id : Location → Id
end
spec Vectors = EgoOrientation and Locations then
sort Vector
ops
−→ : Location × Location →? Vector
source, target : Vector → Location
• def x −→ y ⇔ ¬ x = y
ops − : Vector → Vector ; %% inverse
:Vector × Vector → Orientation
∀ v, w : Vector
• v w = ∼ (v − w )
•v −w =−v w
•−−v =v
• v w = (w v)
then %implies
∀ v, w : Vector
•v w =−v −w
• − v w = ∼ (v w )
end
%% definedness
Fig. 5. Specification of locations, vectors, and orientations between them
The operation “−” inverts the direction of a vector; the operation “ ” yields
an orientation between two vectors: v w is called the orientation of w with respect to v. The algebraic properties nicely relate the orientation relation between
vectors ( ), vector inversion (−), and the orientation operations inverse (∼ o)
and complement (o).
4.3
The Double-Cross Calculus
We now want to define the Double-Cross calculus in terms of the Ego Orientation calculus. Note that we defined a variant of the Double-Cross calculus. The
orientation o of a point c with respect to a vector ab (i.e., ab : c = o in the
Double-Cross calculus) is denoted as the orientation relation between the two
vectors ab and bc (i.e., a −→ b b −→ c o). Additionally, we can define the
orientation between any two vectors if the source or target of one vector equals
either the source or the target of another one, specified by the axiom (O0) in
Fig. 7.
We start with the Double-Cross calculus with only eight orientation relations.
Fig. 6 shows the principle of defining each relation of the Double-Cross calculus
as a conjunction of two relations in the Ego Orientation calculus, a pattern that
will repeat in the specification. Example (a) in Fig. 6 shows the definition of left;
the other 7 relations follow the same pattern, cf. the axiom (O8). The pattern
is still the same when we extend the Double-Cross with relations at the entry,
exit on course, and at the position entry and exit, respectively, yielding fifteen
relations, the related Casl axioms are omitted here. For the predicate onCourse
we also need two ego orientation frames in the same pattern (Fig. 6(b)).
309
front
leftFront
rightFront
b
left
c
leftBack
right
left
rightBack
exit
back
left
right
a
leftBack
entry
rightFront
Double−Cross
(a)
c
front
c
leftFront
leftBack
Ego−Orientation
exit
c
back
left
rightBack
rightBack
leftBack
left
c
front
leftFront
c
front
rightFront
b
right
leftFront
rightFront
onCourse
entry
right
a
rightBack
Ego−Orientation
Double−Cross
(b)
Fig. 6. Relation between two Ego and corresponding Double-Cross orientations: (a)
the definition of left as the conjunction of leftBack and leftFront; (b) oCourse as the
conjunction of back and front
spec DoubleCrossCalculus = Vectors
then
sorts Orientation8 < OrientationDCC13 ;
OrientationDCC13 < OrientationDCC
OrientationDCC < Orientation
pred
: Vector × Vector × OrientationDCC
∀ a, b, c, d : Location; o : OrientationDCC
• a −→ b c −→ d o ⇒ a = c ∨ b = c ∨ a = d ∨ b = d
%% (O0)
∀ entry, exit, c : Location; u, v, w : Vector
• v = entry −→ exit ∧ w = exit −→ c ∧ u = entry −→ c ⇒
(v w leftFront
⇔ v w = leftFront ∧ v u = leftFront)
∧
(v w left
⇔ v w = leftBack ∧ v u = leftFront)
∧
(v w leftBack
⇔ v w = leftBack ∧ v u = leftBack )
∧
(v w front
⇔ v w = front
∧ v u = front)
∧
(v w back
⇔ v w = back
∧ v u = back )
∧
(v w rightFront
⇔ v w = rightFront ∧ v u = rightFront) ∧
(v w right
⇔ v w = rightBack ∧ v u = rightFront) ∧
(v w rightBack
⇔ v w = rightBack ∧ v u = rightBack ) %% (O8)
then
free type OrientationDCC13 ::= sort Orientation8 |
leftAtEntry | rightAtEntry | leftAtExit | rightAtExit | onCourse
free type OrientationDCC ::=
sort OrientationDCC13 | atEntry | atExit
···
end
Fig. 7. The Double-Cross calculus with 8, 13, and 15 orientations
310
4.4
Route Graphs
To introduce Route Graphs we are interested in special kinds of locations and
vectors to define concepts like places and route segments. A place is a location
and has its own local reference system, as specified in Fig. 8. The operation
oOrigin defines the inherent reference direction as a vector at a place, i.e., the
local reference frame (or origin) at that place. The origin may also be used to
ground a place in a global reference system. A route segment of the sort Segment
is a vector from a source place to a target place, thus it is in fact a subsort of
Vector, such that the source and target of a segment belong to the sort Place. In
the context of route descriptions here, an entry or an exit is in fact represented as
an orientation with respect to a given origin at this place. The operation oEntry
defines the orientation of a segment with respect to the origin at its entry (see
axiom (S1)), and oExit the orientation of the origin at its exit with respect to
the segment (see axiom (S2) in Fig. 8).
The second part of the specification Segments contains five axioms describing some properties of the orientations between segments (“ ”) and the entries
and exits of segments.
spec Places = DoubleCrossCalculus then
sort Place < Location
op
oOrigin : Place → Vector
end
spec Segments = Places then
sort Segment = {s : Vector • source(s) ∈ Place ∧ target(s) ∈ Place}
ops oEntry, oExit : Segment → OrientationDCC ;
oCourse : Segment → Vector ;
−→ : Place × Place →? Segment
∀ x, entry, exit : Place
• source(oOrigin(x )) = x
• oEntry(entry −→ exit) = oOrigin(entry) entry −→ exit
%% (S1)
• oExit(entry −→ exit) = entry −→ exit oOrigin(exit)
%% (S2)
then %% recomputation of entry or exit
∀ a, b, c, d : Place
• a −→ b b −→ c = a −→ b b −→ d + b −→ d b −→ c
%% (S3)
• a −→ b b −→ c = oExit(a −→ b) + oEntry(b −→ c)
%% (S4)
then % implied
• oExit(a −→ b) = front ⇒ a −→ b b −→ c = oEntry(b −→ c)
• oEntry(b −→ c) = front ⇒ a −→ b b −→ c = oExit(a −→ b)
• a −→ b b −→ c = a −→ d d −→ c ⇒
oExit(a −→ b) + oEntry(b −→ c) = oExit(a −→ d ) + oEntry(d −→ c)
end
Fig. 8. Specification of places, route segments
311
spec RoutePredicates = Segments then
via : Segment × Location
pred
∀ a, b, c: Place
• a−→ b via c ⇔ a−→ b b−→ c onCourse
then
preds passBy : Segment × Location;
pass on : Segment × Location × OrientationDCC
∀ a, b, c: Place; lr : OrientationDCC
• a−→ b pass c on lr ⇔
(∃ d : Location • a−→ b via d ∧ a−→ d d −→ c lr )
• a−→ b passBy c ⇔
a−→ b pass c on left ∨ a−→ b pass c on right
then
sort Landmark < Location
ops start, doorLift, doorGlass, door2041, p1, p2, p3 , p4, p5 : Place;
doorOfLift, glassDoor, doorOf2041, lift, stairWay, room2041 : Landmark
• oEntry(start−→ doorLift) = front
• at(lift)=start
• start−→ p1 via doorLift
• at(doorOfLift)=doorLift
• start−→ p1 p1 −→ p2 left
• at(stairWay)=p1
• p2 −→ p3 via doorGlass
• at(glassDoor )=doorGlass
• p2 −→ p3 p3 −→ p4 right
• p3 −→ p4 p4 −→ door2041 left
• at(doorOf2041 ) =door2041
• oEntry(p4 −→ p5 ) = left
• p4 −→ p5 via door2041
• at(room2041 )=p5
end
Fig. 9. Route predicates and the sample route
Based on the Casl specification Places and Segments the relations necessary for the interpretation of route descriptions are presented in Fig. 9, where
the sample route description (see Fig. 2) is specified by a set of axioms.
In the conceptual model discussed and specified in this paper landmarks are
treated as points and their spatial extensions are ignored. Hence, route descriptions like “go into the park” and “go along the river” can not be interpreted
in the current model. A possible extension of the model deal with region-like
landmarks is suggested in [9].
Acknowlegment. My thanks go to Dr. Klaus Lüttich and Dr. Christian Maeder
for helping us to check the consistency of CASL specifications.
References
1. E. Astesiano, M. Bidoit, B. Krieg-Brückner, H. Kirchner, P. Mosses, D. Sannella,
and A. Tarlecki. CASL - The Common Algebraic Specification Language. In
Theoretical Computer Science, number 286. Springer-Verlag, 2002.
2. A. G. Cohn, B. Bennett, J. Gooday, and N. M. Gotts. Qualitative spatial representation and reasoning with the region connection calculus. Geoinformatics, 1:1–44,
1997.
312
3. M. Denis. The description of routes: A cognitive approach to the production of
spatial discourse. Cahiers de Psychologie Cognitive, 16:409–458, 1997.
4. A. U. Frank. Qualitative spatial reasoning with cardinal directions. In Proceedings
of the Seventh Austrian Conference on Artificial Intelligence. Springer, 1991.
5. C. Freksa. Using orientation information for qualitative spatial reasoning. In
Theories and Methods of Spatio-Temporal Reasoning in Geographic Space, volume
639 of Lecture Notes in Computer Science, pages 162–178. Springer-Verlag, 1992.
6. B. Krieg-Brückner, U. Frese, K. Lüttich, C. Mandel, T. Mossakowski, and R. J.
Ross. Specification of an ontology for route graphs. In C. Freksa, M. Knauff,
B. Krieg-Brückner, B. Nebel, and T. Barkowsky, editors, Proceedings of Spatial
Cognition IV, Chiemsee, Germany, volume 3343 of Lecture Notes in Artificial Intelligence, pages 989–995. Springer, 2004.
7. B. Krieg-Brückner and H. Shi. Orientation calculi and route graphs: Towards
semantic representations for route descriptions. In Proceedings of GIScience 2006,
Münster, Germany, volume 4197 of Lecture Notes in Computer Science, 2006.
8. B. Kuipers. The spatial semantic hierarchy. Artificial Intelligence, 119:191–233,
2000.
9. Y. Kurata and H. Shi. Rfdl: Models for capturing directional and topological
characteristics of path-landmark arrangements. In N. Van de Weghe, R. Billen,
and P. Kuipers, B. Bogaert, editors, International Workshop on Moving Objects,
2008.
10. A. Lankenau and T. Röfer. Mobile robot self-localization in large-scale environments. In Proceedings of the IEEE International Conference on Robotics and Automation, pages 1359–1364, 2002.
11. G. Ligozat. Reasoning about cardinal directions. Journal of Visual Languages and
Computing, 9:23–44, 1998.
12. P. D. Mosses and M. Bidoit. Casl — the Common Algebraic Specification Language: User Manual, volume 2900 of Lecture Notes in Computer Science. Springer,
2004.
13. J. Renz and D. Mitra. Qualitative direction calculi with arbitrary granularity. In
Proceedings PRICAI 2004, volume 3157 of Lecture Notes in Artificial Intelligence,
pages 65–74. Springer, 2004.
14. H. Shi and B. Krieg-Brückner. Modelling route instructions for robust human-robot
interaction on navigation tasks. International Journal of Software and Informatics,
2(1):33–60, 2008.
15. H. Shi and T. Tenbrink. Telling Rolland where to go: HRI dialogues on route navigation. In WoSLaD Workshop on Spatial Language and Dialogue, Delmenhorst,
Germany, October 23-25, 2005.
16. L. Talmy. How language structures space. In H. L. Pick and L. P. Acredolo, editors,
Spatial Orientation: Theory, Research and Application. Plenum, NY, 1983.
17. B. Tversky and P. Lee. How space structures language. In C. Freksa, C. Habel,
and K. Wender, editors, Spatial Cognition: An interdisciplinary Approach to Representation and Processing of Spatial Knowledge, volume 1404 of Lecture Notes in
Artificial Intelligence, pages 157–175. Springer-Verlag, 1998.
18. S. Werner, B. Krieg-Brückner, and T. Hermann. Modelling navigational knowledge
by route graphs. In Spatial Cognition II: Integrating Abstract Theories, Empirical
Studies, Formal Methods, and Pratical Applications, volume 1849 of Lecture Notes
in Artificial Intelligence, pages 259–316. Springer-Verlag, 2000.
19. K. Zimmermann and C. Freksa. Qualitative spatial reasoning using orientation,
distance, and path knowledge. Applied Intelligence, 6:49–58, 1996.
313
Hui Shi received her master degree in Computer Science from the Changsha Institute and Technology,
China and her Dr.-Ing. degree from Universität Bremen, Germany, in 1987 and 1994. respectively. She
is a senior researcher at DFKI Bremen, Safe & Secure Cognitive Systems and member of the DFGfunded SFB/TR 8 “Spatial Cognition”. Among others
she is working in the following research areas: Formal
Methods, Shared Control, User Modeling and Dialogue
Modeling.
Top-down vs. Bottom-up:
Transformationelle Methoden im
wissenschaftlichen Wettbewerb
Ein essayistischer Überblick über den Stand der Kunst
Burkhart Wolff
Université de Paris-Sud,
Laboratoire de Recherche Informatique,
Parc Club, 4 Rue Jaques Monod
F-91405 Orsay Cedex, France
Mail: [email protected], WWW: http://www.lri.fr/~wolff
Zusammenfassung In diesem Beitrag wird versucht, einen Überblick
über den Wettbewerb zweier konkurrierender Forschungsprogramme —
genannt Top-down oder Transformationelle Entwicklungsmethodik versus Bottom-up oder post-hoc Programmverifikation — im Bereich “Formaler Methoden” zu geben. Als Einordnungsrahmen benutze ich Lakatos’s Konzept des “wissenschaftlichen Forschungsprogramms”. Es ergibt
sich ein bewusst altmodischer Versuch — im Gegensatz zu modischen
bibliometrischen Kriterien (vulgo: Zahlen von Veröffentlichungen) — inhaltliche Kriterien für die Qualität und damit den Fortschritt der wissenschaftlichen Arbeit in unserem Gebiet zu entwickeln.
1
Einleitung
Man könnte diesen Artikel mit dem Glaubensbekenntnis beginnen lassen: “Formale Methoden helfen dabei, die Sicherheit von Software zu erhöhen”. Oder auch
inhaltlicher, aber eklektischer: “Formale Methoden sind eine Sammlung von mathematischen Beschreibungsmitteln und Analyseverfahren, die ihre Grundlage in
diskreter Mathematik haben”. Wir alle haben solche Sätze vermutlich schon oft
gehört, und — wenn auch mit Unbehagen — geschrieben.
Statt dessen wird in diesem Beitrag versucht, “Formale Methoden” (FM) als
“Wissenschaftliches Forschungsprogramm” zur Fundierung des Software-Engineerings zu begreifen und zwei seiner wichtigsten Unterprogramme — Transformationelle Programmentwicklung vs. post-hoc Programmverifikation — gegenüberzustellen. Als Begriffsrahmen für die Grundkonzepte “Kern”, “wissenschaftliches
Programm”, “Anomalie”, etc., dient dabei die Erkenntnistheorie Lakatos’s [64].
In der Informatik fängt bekanntlich alles mit Alan Turing an. Als ausgebildeter Mathematiker mit starker Ausrichtung auf logische Grundlagen quälte
er sich allerdings nicht mit der neueren Frage, ob er “Formale Methoden” nun
benutzen sollte oder nicht bei dem Tun, das wir heute Informatik nennen —
er tat es einfach, so wie man Luft zum Atmen braucht. Er entwickelte damit
315
Konzepte wie Maschine, Zustand, und sogar Zustandsinvariante, die unbestritten zum Grundinventar moderner Programmiersprachentheorien gehören, und
beschäftigte sich mit den Zusammenhängen funktionaler und zustandsorientierter Programme. Allerdings galt Turing auch bald als akademischer Nestbeschmutzer, interessierte er sich doch (Pfui!!!) auch für die konkreten Probleme
des Computerbaus und seiner Programmierung.1
Während die Bedeutung der mathematisch-logischen Grundlagen für die Geschichte der Informatik und für den akademischen Betrieb akzeptierter Fakt ist,
ist ihre Relevanz für die ingenieursmässige Konstruktion von Software-Systemen,
also das Software-Engineering, höchst umstritten, auch im akademischen Betrieb
selbst. Sichtbarster Ausdruck für die interne Geringschätzung ihrer Grundlagen
ist die Tatsache, das die “curriculum recommandations” der ACM für das Fach
Informatik im Jahr 2005 keinerlei mathematische Fähigkeiten mehr erwähnen,
und lediglich einen Kurs zur Theorie der Programmiersprachen vorsehen[32].
Das akademische Misstrauen an FM wird zudem vertieft durch die Tatsache,
das es aus Sicht des mathematischen Mainstreams als Extrem, als Gipfelpunkt
eines älteren Forschungsprogramms wahrgenommen wird, das nach allgemeinen Dafürhalten als gescheitert gilt: dem Programm des Formalismus nämlich.
Dies begann mit Leipnitz’ Idee einer “lingua universalis”, einer Sprache in der
sich alle wissenschaftlich-mathematischen Probleme formulieren und mittels deduktiven Schliessen beantworten liessen, über erste technische Beiträge durch
Boole, Peano und Frege bis hin zu Whitehead und Russels “Principia Mathematica”, die das Programm erstmalig konkret ausformulierten. Die Unmöglichkeit
der Vollständigkeit und Entscheidbarkeit hinreichend ausdrucksstarker logischer
Sprachen, und damit das Ende des Hilbertschen Traums von “Wir müssen wissen, und wir werden wissen!”, diskreditierte in den Augen vieler auch den Formalismus als Grundlage der Mathematik. Die Debatte mag in jüngster Zeit wiederaufgeflammt sein [55,56,39,40], angefeuert durch die zunehmende Schwierigkeit,
die sich häufenden Monsterbeweise in mathematischen Journalen tatsächlich
nachzuprüfen, und diesbezügliche Erfolge durch mathematische Beweisassistenten, d.h. interaktive Theorembeweisumgebungen. Doch zunächst einmal wird
sich an der allgemeinen Formalismusskepsis nichts ändern, auch aus Gründen
der Bequemlichkeit und Opportunität.2
1
2
Hardy verhinderte noch Turings Promotionsvorschlag einer Interpreterimplementierung für den getypten Lambdakalkül mit den Worten “Nothing is worth a Phd that
can be done with a computer”.[42] Wir wissen heute recht gut Bescheid über das
Problem der Normalisierung des getypten Lambda-Kalküls und seiner Bedeutung für
die Theorie der funktionalen Programmierung als auch den Bau von Beweissystemen
für die Logiken höherer Stufe; auch die technischen Herausforderungen solcher Programme auf der Hardware der fünfziger Jahre würden heute noch Respekt abnötigen.
Nur — wer zum Teufel war doch gleich dieser Hardy???
Ich darf den Kollegen Ralf Küsters zitieren mit seinem Ausspruch: “Für mich ist ein
Beweis ein Beweis, wenn ich den Gutachter davon habe überzeugen können, das sich
daraus vielleicht ein formaler Beweis machen liesse. Das machen alle im Betrieb so!”
[48].
316
2
Exkurs: Imre Lakatos “Kritischer Rationalismus”
Die Abgrenzung der Wissenschaft von Pseudowissenschaft ist ein grundlegendes
erkenntnistheoretisches Problem: sollten wir etwa, um ein extremes Beispiel zu
gebrauchen, der Erforschung des Einflusses der Bachblütentherapie auf Programmiererteams den Zugang zu öffentlich geförderten Forschungsmitteln gewähren?
Der leicht-fertige Einwand: “Nein, das ist pseudo-wissenschaftlich”, führt unmittelbar zur Frage, was solche “Ansätze”, die sich bei Bedarf mit klingenden
Adjektiven wie “ganzheitlich-partizipativ” schmücken lassen, denn inhaltlich von
wissenschaftlicher Arbeit unterscheidet. Und weitergehend auch die Frage, was
wissenschaftlichen Fortschritt denn ausmacht und wie er sich denn bewerten liesse — eine Frage, die im Zeitalter zunehmender Ökonomisierung, in dem Erfolg
in Geld umgerechnet wird und gleichzeitig Geld Mass des Erfolges ist, leicht ein
existentielles Beigeschmäckle hat.
Die Frage ist uralt, und hat, wie wir sehen werden, keine Beil-scharfen Lösungen. Bekanntlich schlug Popper[58] folgendes Kriterium vor: “Eine Theorie ist
wissenschaftlich, wenn man bereit ist, im Voraus ein entscheidendes Experiment
(oder eine Beobachtung) anzugeben, das sie falsifizieren würde, und sie ist unwissenschaftlich, wenn man zu einem solchen ‘Experimentum Crucis’ nicht in der
Lage ist”. Demnach kann eine Theorie wissenschaftlich sein, obwohl überhaupt
keine Daten für sie sprechen (eine Situation, die gerade die Diskussion um die
String-Theorie beschäftigt), oder unwissenschaftlich, obwohl alle Daten für sie
sprechen. Zweifellos ist es interessant, einen Marxisten nach dem Experimentum
Crucis zu fragen; er wird u.U. die Frage als unmoralisch ablehnen. In der Tat
kann also diese Frage einen Anhaltspunkt dafür liefern, ob eine Theorie zu einem
Dogma erstarrt ist oder zu echter Erkenntnis beiträgt.
Ist nun das Poppersche Falsifikationskriterim die Lösung des Problems der
Abgrenzung von Wissenschaft und Pseudowissenschaft? Nein, denn es berücksichtigt nicht die bemerkenswerte Zählebigkeit wissenschaftlicher Theorien; Poppers Kriterium funktioniert einfach nicht in der wissenschaftlichen Praxis. Wissenschaftler geben eine Theorie nicht auf, nur weil ihr Tatsachen widersprechen
oder Schwierigkeiten auftauchen, weil Anomalien existieren. Mal diffamieren sie
die Anomalie als Monstrosität oder einen irrelevanten Ausnahmefall (Lakatos erfand für diese Verteidigungsstrategie den schönen Namen Monster-barring), oder
mal finden sie eine rettende Hypothese, die die Anomalie erklären soll (Lakatos’
Monster-adaption) oder, wenn das nicht möglich ist, vergisst man die Schwierigkeit einfach und wendet sich anderen Problemen zu. Das wohl berühmteste
Experimentum Crucis der Wissenschaftsgeschichte, das Michelson-Morley Experiment, das ursprünglich konzipiert war, als Richter zwischen zwei konkurrierenden Äthertheorien zu fungieren, verschwand 25 Jahre in der Schublade, bevor
es von Einstein hervorgeholt wurde um damit die spezielle Relativitätstheorie
(kein Äther) gegenüber der Newton’schen Mechanik auszuzeichnen.
Was ist also das Kennzeichen von guter Wissenschaft? Müssen wir kapitulieren und zugeben das eine wissenschaftliche Revolution nichts als eine irrationale
Änderung der Überzeugung, eine religiöse Bekehrung sein? Der amerikanische
Wissenschaftstheoretiker Thomas Kuhn kam zu diesem Ergebnis, nachdem er
317
die Naivität des Popperschen Falsifikationismus erkannt hatte. Da er Kriterien der Unterscheidung zwischem wissenschaftlichem Fortschritt und geistigem
Niedergang prinzipiell nicht mehr anerkennen will, gibt es für ihn auch keine
allgemeinen Kriterien der Rationalität mehr. Sein Schüler Paul Feyerabend [30]
hat diese Position zu einem erkenntnistheoretischen Anarchismus des “Anything
Goes” ausgebaut.
Lakatos Beitrag in der Debatte [64] ist es, die Geschichte der Wissenschaft
ernst zu nehmen und den Begriff des Fortschritts in der erkenntnistheoretischer
Debatte nicht nur auf der philosophischen Spielwiese definieren zu wollen. Für
Lakatos macht es keinen Sinn, eine wissenschaftliche Theorie nur als ein konkretes Hypothesengebäude zu begreifen, das man durch eine Anomalie widerlegen
könne. Denn alle wissenschaftlichen Theorien sind für ihn Inseln in einem “Meer
von Anomalien”, und Erkenntnisfortschritt zeichnet sich dadurch aus, das diese
Inseln Landgewinne machen. Die genaue Formulierung der Hypothesen kann sich
auch über die Zeit verändern, man hat es also eigentlich mit einer Familie von
Theorien, T1 , T2 , ... zu tun, eben dem “Forschungsprogramm”. Ein Forschungsprogramm zeichnet sich aus durch:
1. einen harten Kern, d. i. eine konkrete mathematische, stark formalisierte
Theorie, die zäh verteidigt wird, sowie
2. ein System von Hilfshypothesen, wozu insbesondere auch die Beobachtungstheorien gezählt werden. Modifikationen im System der Hilfshypothesen gehören zum wissenschaftlichen Tagesgeschäft. Und außerdem:
3. einen heuristischen Apparat — oder moderner gesagt: eine Pragmatik — mit
der Anomalien im Sinne des Programms gedeutet, also “erklärt” werden.
Zum Kern der Newtonschen Mechanik zum Beispiel gehören die vier Grundaxiome über die Zusammenhänge von Masse, Kraft, Beschleunigung und Gravitation, etc., sowie die mathematischen Theorien, die zu ihrer Fundierung benötigt
werden (z.B. Axiomatische Mengenlehre, Theorie der Funktionen, Theorie der
Integral- und Differentialrechnung, Differentialgleichungen). Zu den Hilfshypothesen gehören die Theorien über Planetenbewegungen, aber auch Theorien über
die Messinstrumente und Beobachtungstheorien über Experimentalanordnungen. Nehmen wir an, eine Anomalie taucht auf: “Teeblätter in einer Teetasse
sammeln sich nicht, wie von den Gesetzen der Zentrifugalkraft gefordert, aussen,
sondern in der Mitte. Die Newtonsche Mechanik ist folglich unwissenschaftlicher
Unsinn!” Natürlich — und sinnvollerweise — passiert nicht das, was laut naivem
Falsifikationismus zu fordern wäre: alle Newtonianer fallen vom Glauben ab, die
Physik verfällt in einen Zustand von Lethargie und Verzweiflung, und wir treten
in ein neues Zeitalter des Mystizismus ein. Stattdessen wird ein Newtonianer —
je nach Jahrhundert und Entwicklungsstand der Hilfshypothesen — argumentieren: “Mit Flüssigkeiten geben wir uns nicht ab!” (Monster-barring) oder eine
Strömungsmechanik entwickeln, nach der sich aufgrund der Reibung das Maximum der Strömungsgeschwindigkeit einer rotierenden Flüssigkeit nicht am Rand,
sondern bei etwa einem Drittel des Radius vom Rotationszentrum liegt (Monsteradaption). Tatsächlich finden neue Messungen statt — und die Teeblätter
sammeln sich gar nicht in der Mitte, sondern bewegen sich auf Kreisbahnen um
318
das Zentrum herum, und mit etwas Massage gelingt sogar die genaue empirische Vorhersage. Und Newtonianer sprechen nun erhobenen Hauptes von einer
glänzenden Bestätigung des Programms. Tatsächlich ist letzteres — eine Anomalie führt zu neuen Vorhersagen und neuen Beobachtungsergebnissen — für Lakatos Ausdruck eines progressiven Forschungsprogramms, Monster-barring sowie
Monsteranpassung ohne Erweiterung der empirischen Datenbasis sind dagegen
Ausdruck eines degenerativen. Wissenschaftliche Revolutionen finden vor allem
dann statt, wenn neuere Forschungsprogramme nicht nur progressiv sind, sondern auch die empirische Basis älterer Programme mit erklären und übernehmen
können (Ptolemäus vs. Kepler, aber auch Newton vs. Einstein). Im Gegensatz zu
Popper fordert Lakatos also keine “Sofortrationalität” von Forschungsprogrammen, was dazu führt, das sich der Fortschritt z.T. erst im Nachhinein und mit
einigem zeitlichem Verzug erkennen lässt. Dies hat wiederum Feyerabend und
viele Wissenschaftspraktiker zu einer Kritik am Lakatosschen kritischen Rationalismus veranlasst.
So ist der zeitgenössische Glaube an “moderne Evalutationstechniken” in
der Wissenschaftspraxis auch ein Versuch, eine praktikable Antwort auf das
Abgrenzungsproblem zu finden. Leider ist festzustellen, das die Evaluationitis
in Berufungskommissionen und Forschungsförderungsgremien nach wie vor ungehemmt ist und bisherige spektakuläre Fehlentscheidungen — wie jüngst die
Schliessung des fachlich gesunden Fachbereichs Chemie an der Universität Exeter — noch nicht wirklich schmerzen. So bleibt vorerst nur Sarkasmus: Der
ungebrochene Glauben einiger Wissenschaftler und Forschungspolitiker an bibliometrische Evaluations-Kriterien erinnert stark an die religiösen Gefühle von
Bankern beim Anblick der Aktienkurse kurz vor dem Platzen der Blase. Denn
er produziert einen Typus von Wissenschaftler, der Schwalle zweitklassiger Publikationen ausstößt, aber selbst aus Zeitmangel nicht mehr liest; er produziert
eine Forschungskultur, die inhärent nicht mehr fortschrittsfähig ist. Wen eine
ernsthafte, systematische Kritik an bibliometrischen Kriterien und ihrer Manipulierbarkeit wie [2,28] nicht abschreckt, dem ist nicht zu helfen.
3
Des Pudels Kern und das “Meer der Anomalien”
Man kann im Fall der Informatik ohne Schwierigkeit drei Fundamental-Systeme
identifizieren:
1. Klassische Mengentheorie (ZFC),
2. Typtheorie, und
3. Kategorientheorie.
Dies sind Systeme, die zumeist älter als die Informatik selbst sind, trotzdem von
der Informatik in Form von Personal und Fragestellungen (vulgo: Forschungsgeldern) profitieren und auch die Ausprägung gewisser Forschungsunterprogramme
wie etwa “algebraisch top-down” (siehe Abschnitt 5) bis in den heutigen Tag
bestimmen.
319
Auf dieser Grundlage werden Programmier-, Architektur- und Spezifikationssprachen semantisch begründet, die zum Ziel haben, in technisch unterstützter
Form die Praxis der Softwareentwicklung zu ändern — das ist als des Pudels
Kern des FM zu betrachten.
Bei der Forderung nach “technischer Unterstützung” einer Sprache/Methode
ist zwar auch keine “Sofort-Rationalität” zu erwarten, aber wenn ein Teil-Forschungsprogramm fortdauernd keine Erfolge bei der Entwicklung von programmiersprachlichen Konzepten und entsprechenden Compilern, oder von technischunterstützten Entwicklungsmethoden, oder von Beweis-oder Analyseverfahren
aufzuweisen hat, dann ist stark zu vermuten, das es sich um ein ziellos-degenerierendes Programm handelt. Denn Theorien zu bilden allein ist bei der Stärke
der Fundamental-Systeme keine besondere Schwierigkeit und hat beträchtliche
Beliebigkeit, ob sie dagegen tatsächlich etwas zum Bau von Systemen beitragen
können, macht die Substanz ihres Beitrags aus. Dieses Ziel computer-technisch
Unterstützung einer Sprache oder Methode ist meiner Auffassung das fachgerechte Experimentum Crucis was die Abgrenzung zu einem “Anything Goes”
erlaubt.
Von Anbeginn an waren dabei zwei Lager im FM zu unterscheiden:
1. Top-down: Der Ansatzpunkt dieses Teil-Programms sind Spezifikations formalismen, die semantisch dicht an einem der Fundamental-Systeme liegen,
und konsequenterweise weit entfernt von Programmiersprachen und insbesondere zustandsorientierten Programmiersprachen. Der Kern gründet auf
den semantischen Theorien um Sprachen wie Z, VDM, HOL, ACT-ONE,
LOTUS, CSP und neuerdings Event B. Die Entwicklungsmethodik zielt auf
formales Refinement oder Transformationelle Entwicklung.
2. Bottom-up: Der Ansatzpunkt dieses Teil-Programms sind Programmiersprachen und Programmiercode, der möglichst realistisch erfasst werden soll. Der
Kern gründet auf den operational-semantischen Theorien dieser Sprachen.
Die Entwicklungsmethodik zielt einerseits auf optimierte Übersetzung und
Programmtransformation, andererseits auf Typsysteme und prädikative oder
temporale Annotierungssprachen.
Ein typischer Top-downer (wie z.B. der geschätzte Kollege Jean-Raymond Abrial) hält einen Annotierungsansatz der Programmiersprache C für das “Gott-seibei-uns”, stellvertretend für viele Andere, für die die semantische Behandlung
“realer” Programmiersprachen lange Zeit unvorstellbar war und mit dem der
Entwicklungsprozeß nicht belastet werden sollte. Aus Sicht der Top-downer ist
eine Sprache wie C schlichtweg “dreckig”, Vertreter dieses Programms begegnen
dem Problem also zur Zeit mit klassischem Monster-barring.
Ein typischer Bottom-upper (wie z.B. der geschätzte Kollege Peter Müller) 3
hält die Idee für utopisch, das man den Entwicklungsprozeß jemals mit abstrakten Systemmodellen beginnen werde; Informatiker in der industriellen Praxis
3
Mit beiden Kollegen hatte ich über viele Jahre regelmässige, anregende Debatten zu
diesem Thema im “Formal Methods Club” an der ETH Zürich ...
320
sind zunächst einmal Prgrammierer, und an den realen Entwicklungsprozessen
müsse man ansetzen.
Interessanterweise haben beide Forschungsprogramme industrielle Anwender
— sie sind also beide wachsende Inseln mit einem mehr oder weniger breiten
Uferstreifen. Der größte Software-Produzent weltweit hat sich in den letzten
Jahren massiv in der Forschung von annotierungsorientierten Spezifikationssprachen (Spec#, VCC) engagiert, wobei abgeschwächte Formen dieses Ansatzes im großen Stil (z.B. SAL) auch bei der Produktion der aktuellen Version
des Hauptprodukts verwendet worden sind. Währenddessen engagiert sich der
zweitgrößte Software-Konzern insbesondere für modellbasierter Systementwicklung; hier interessieren vor allem Modelle von Geschäftsprozessen, Code dagegen
wird in Wesentlichen generiert und stellt oft kein Primärprodukt mehr dar.
Je nach Anwendungsdomaine haben also beide Forschungsprogramme zunächst einmal Erfolge auszuweisen, auf die im Folgenden näher eingegangen wird.
4
Modellierung
FM bietet mathematisch fundierte Beschreibungsformalismen zur Modellierung
von Aspekten, wie beispielsweise Systemanforderungen, Architekturen, oder von
lokalen Eigenschaften. Durch die Definition dieser Systeme in einem FundamentalSystem werden Mehrdeutigkeiten im Verständnis einer Modellierung ausgeschlossen, weil jedes Modell eine im mathematischen Sinne präzise, eindeutige Bedeutung, die so genannte formale Semantik hat. Diese Fundierung erlaubt darüberhinaus typischerweise die Ableitung von Kalkülen, also Mengen von Regeln, mit
deren Hilfe sich Eigenschaften einer Modellierung berechnen lassen.
4.1
Gibt es Datenorientierte Spezifikationssprachen?
Da Modellierung an für sich im Software-Entwicklungsprozeß keinen Selbstzweck
darstellt, sondern wie gesagt im Hinblick auf technisch unterstützte Analyseverfahren genutzt wird, hat sich die Unterscheidung in daten-orientierte und verhaltensorientierte Spezifikationssprachen eingebürgert, je nachdem, ob die Analysetechnik traditionell eher deduktionsbasiert oder automatenbasiert war (Vergleiche Abschnitt 7). Klassische Vertreter des datenorientierten Modellierungsstils
sind Z, VDM und sein “objekt-orientierter” Nachfahr UML/OCL (an Klassendiagrammen), diverse Hoare Logiken, Dijkstra/Floyds wp-Kalkül als auch diverse algebraische Ansätze wie ACT ONE und CASL. Klassische Vertreter des
verhaltensorientierten Ansatzes sind Prozesskalküle wie CSP als auch temporale
Logiken wie LTL, CTL, Promela oder JavaPathFinder/JML.
Datenorientierte Modellierungen zielen auf die Darstellung einer Transition eines Systemzustands, in der Regel durch Vor- und Nachbedingungen, ab.
Demgegenüber werden bei verhaltensorientierten Modellierungen Transitionsrelationen (ggf. mit Zusatzinformationen wie “Events” angereichert) zur Menge
aller möglichen Abläufe eines Systems (Traces) vervollständigt; über Mengen
321
von Traces können dann Eigenschaften formuliert werden, wie etwa dass alle erreichbaren Zustände des Systems eine gegebene Sicherheitseigenschaft erfüllen.
In Verhaltensmodellen können zudem Nebenläufigkeit, Parallelität und Zeitverhalten von Systemmodellen adäquat beschrieben werden.
Die Übertragung der Unterscheidung datenorientiert/verhaltensorientierter
Modellierung auf Spezifikationssprachen dagegen ist, obwohl weithin üblich,
blanker Traditionalismus, wie man schon an der Willkürlichkeit der Einteilung
von JML und Promela vs. Hoare-Logiken erkennen kann. Es ist kein besonderes
Problem, auch in Z (oder HOL) die Logiken LTL oder CSP zu codieren [65,10]
und dies auch analysetechnisch auszunutzen [10]. Zudem haben Sprachen wie
CSP oder Promela mit Typ-Konstruktoren für Listen, Mengen und Tupel außerordentlich ähnliche Sprachausdrucksmächtigkeiten wie z.B. Z. Bei neueren
Formalismen wie VCC-I[53], VCC-II[22] oder ACSL[11], die mittels Programmannotierungen Aussagen über das nebenläufige Verhalten von C Programmen
machen und hierzu sowohl den SMT-Beweiser Z3 als auch Isabelle/HOL als
Beweiser-Backend benutzen [14,15], wird diese Unterscheidung endgültig ad absurdum.
Sinnvoller als eine Einteilung in datenorientiert bzw. verhaltensorientiert
auf Sprachen erscheint eine Einteilung in Top-down vs. Bottom-up bzw. Konzeptionsorientiert vs. Ausführungsorientiert. Erstere Sprachklasse zeichnet sich
durch einen geringen konzeptionellen Abstand zu einem Fundamentalsystem aus,
während letzere einen geringen Abstand zu einem Ausführungsmodell einer “realen Programmiersprache”, also im Extremfall C auf einem konkreten Prozessor
anstrebt. In erstere Sprachklasse können somit Z, CSP und UML/OCL eingeordnet werden, in letztere z.B. Spec#/Boogie[8,7], JML/Krakatoa[31], JML/ESCJava[45], ACSL/Caduceus[31,11] und VCC-I/II/Boogie[53,22].
4.2
Architekturen und Muster
Musterbasierte Ansätze finden bei der Entwicklung sicherheitskritischer Systeme
an mehreren Stellen Verwendung: Beispielsweise haben Sicherheitsanforderungen
oftmals sich wiederholende Formen (z.B. Ereignis x darf erst stattfinden, nach”
dem Ereignis y stattgefunden hat“). Der Vorteil der Verwendung von Mustern
liegt hier (wie auch in der Softwareentwicklung ganz allgemein) in der Wiederverwendung etablierten Wissens. Es sind daher sog. safety patterns definiert worden,
die helfen, Sicherheitseigenschaften vollständig und präzise zu formulieren. Die
so erhaltenen Anforderungen lassen sich sowohl in einer quasi-natürlichen Fachsprache als auch in einer geeigneten Temporallogik oder einer Prozessalgebra
ausdrücken.
Weiterhin lassen sich wiederkehrende Architekturen sicherheitskritischer Systeme identifizieren. Ein Beispiel für eine solche Referenzarchitektur sind zyklische
Systeme, wo in regelmäßigen Zeitabständen die Sensorwerte abgefragt und Aktorkommandos generiert werden. Aber auch interruptgesteuerte Architekturen
sind weit verbreitet, nicht zuletzt in Mainstream-Prozessoren mit ihrem harwaretechnisch unterstützten Interruptmechanismen.
322
Ein weiterer Top-down Trend lässt sich mit der zunehmenden Verbreitung
der Unified Modeling Language (UML, der derzeitige de-facto-Standard in der
industriellen Software-Modellierung) erkennen, die bei der Modellierung von
Geschäftsprozessen, bei der Entwicklung sicherheitskritischer Systeme und bei
Datenbanksystemen immer weitere Verbreitung findet. UML stellt eine Vielzahl von Teilsprachen und assoziierten diagrammatischen Notationen bereit, mit
der verschiedene Aspekte von Systeme geeignet dargestellt werden können. Hier
sind insbesondere Klassenmodelle zur Modellierung von Daten sowie Sequenzdiagramme und Zustandsmaschinen zur Modellierung von Verhalten zu nennen. Auf
der Ebene der Spezifikationen wird UML verwendet, um sicherheitskritische Systeme zu spezifizieren und diese Spezifikationen formal auf Sicherheitslücken zu
untersuchen. Auf Basis von Expertenwissen in der Entwicklung sicherer Software sind Erweiterungen der UML definiert worden, die das einfache Einfügen von
Sicherheitsanforderungen erlauben (zum Beispiel UMLsec [44] und SecureUML
[9,17,17]). Diese Sicherheitseigenschaften können dann mit Beweiswerkzeugen
(vgl. Abschnitt 7) formal verifiziert werden. Diese Verifikation basiert jeweils auf
einer formalen Ausführungs-Semantik für das verwendete Fragment von UML.
Insbesondere können auf dieser formalen Grundlage wissenschaftliche Fragen beantwortet werden, die unabhängig vom Kontext der modell-basierten Entwicklung von Interesse sind, wie die Verfeinerung von Spezifikationen sicherheitskritischer Systeme, Sicherheitsaspekte geschichteter Architekturen (wie Protokollschichten), und die (De-)Komponierbarkeit und Modularität sicherheitskritischer Systeme.
Die Forschung nach Architekturen oder Mustern gehört also zu den Kernstücken des Top-down Programms; nach einer Zeit der Euphorie nach dem GoFBook [33] ist allerdings insgesamt eine gewisse Stagnation zu verzeichnen.
5
Programmiersprachen
Naturgemäß ist die Forschung nach Programmiersprachen, und insbesondere ihrer semantischen Begründung eine der zentralen Interessengebiete im FM. Komplementär zum Abschnitt 4.2, wird die Forschung allerdings primär von Bottomuppern vorangetrieben.
Unschwer lassen sich Top-down und Bottom-up Strömungen unterscheiden,
seitdem es Sprachen gibt: Funktionale und logische Sprachen einerseits und imperative Sprachen und Assemblersprachen mit mehr oder weniger starker Abstraktion gegenüber unterliegenden Maschinenmodellen andererseits. Aus dieser
Perspektive nehmen objektorientierte Sprachen in gewisser Weise eine Zwitterstellung ein: einerseits sind sie tiefgreifend zustandsorientiert (Objektreferenzen
bilden Objektgraphen mit mutierbaren Objektattributen...), andererseits stellen
objektorientierte Zustandsmodelle wie in Java eine beträchtliche Abstraktion
gegenüber selbst einfachsten Speichermodellen wie linearem Speicher dar. Der
Zwittercharakter wird deutlich, wenn man die Hybridsprachen von der funktionalen Seite wie OCaml, Pizza oder SCALA betrachtet, zu denen die Unterschiede
sich zunehmend verwischen.
323
Die Fundierung von Top-down - als auch Bottom-up mittels formaler, maschinengeprüfter Sprach- und Maschinenmodelle hat in den letzten 10 Jahren
große Fortschritte gebracht. Mehrfach wurde die Semantische Begründung der
funktionalen Sprachen, nämlich des getypten Lambda-Kalküls mit partieller Rekursion (LCF, Domaintheorie) oder mit total-Rekursiven Funktionen (Theorie
der Wohlfundierten Ordnungen und darauf basierender Rekursion) ihrerseits in
Logiken höherer Stufe entwickelt, und zwar sowohl in einem klassischem [54] als
auch konstruktivistischen Setting [60]. Vor Kurzem gelang sogar die semantische Fundierung von komplexen Typsystemen mit Typkonstruktorklassen durch
Reflektion auf Funktionen über dem reflexiven Bereich D ∼
= A + [D → D][43];
hierdurch können die üblichen Monaden-Kombinatoren in Haskell-artigen Bibliotheken endgültig im Rahmen einer Logik höherer Stufe wie HOL (oder je
nach Geschmack: Cartesian Closed Categories (CCC)) interpretiert werden.
Die folgende Übersicht — eine subjektive Auswahl — listet wesentliche Erfolge des Bottom-up Programms des letzten Jahrzehnts:
1. konkrete, “reale” Maschinenmodelle für Prozessoren (AMD,INTEL) und
abstrakte Maschinen (JVM) werden routinemäßig entwickelt und im industriellen Maßstab verwendet. Neue Anwendungen wie genaue Laufzeitabschätzungen werden absehbar [70],
2. konservative, d.h. nur auf definitorischen Axiomen basierende Modelle für
operationale und axiomatische Semantik für Java-artige Sprachen sind möglich
geworden [46,68],
3. JVM Modelle und darauf basierene, korrekt bewiesene Analysemethoden
wie [46],
4. axiomatische objektorientierte Speichermodelle wie für Spec# [6],
5. konservative objektorientierte Speichermodelle wie für HOL-OCL# [21],
6. axiomatische lineare Speichermodelle wie für C in VCC-I# [51,53,15],
7. axiomatische lineare Speichermodelle wie für verteiltes C in VCC-II# [22],
8. separation logics und ähnliche Abstraktionen über linearem Speicher zur
Formalisierung von Framing Conditions, [66],
9. etc., etc.,
Die Programm-Verifikationswerkzeuge wie Spec#, VCC oder Simpl[62] basieren darauf, das für gegebene operationale Semantiken ein wp-Kalkül abgeleitet
werden kann, der vollautomatisch aus einem mit Zusicherungen und Invarianten
annotierten Programm eine Formel in Logik erster Stufe generiert. Gilt diese,
dann existiert auch ein Beweis in einer Hoare-Logik, der die Gültigkeit der Zusicherungen etabliert (also insbesondere auch Vor- und Nachbedingungen). Da
die Formel unabhängig vom Programm ist, kann sie einfach als Beweisziel eines
Verifikationsverfahrens (siehe Abschnitt 7) behandelt werden. Schränkt man die
Logik geeignet ein (etwa auf Aussagen über Speicherressourcen, wie in SALAnnotations[23]), können im Hinblick auf spezielle Eigenschaften hochautomatisierte Verfahren zur (partiellen) Programmverifikation konstruiert werden.
Die Liste markiert nicht nur eine beträchtliche Dynamik, die durch die Verfügbarkeit von formalen Modelle von “realen” Prozessoren und maschinen-nahen
324
Programmiersprachen in interaktiven Theorembeweisumgebungen ausgelöst wurde, sondern auch die entscheidende Bedeutung für das Bottom-up Programm:
Sie widerlegt die Hauptkritik, welche die Möglichkeit bestreitet, die Semantiken von “real languages” formal zu handhaben und damit eine wissenschaftlich
rationale Fundierung für Werkzeuge und Methoden zu liefern.
Wesentliche andere Forschungslinien der Programmiersprachenforschung sind
natürlich Typsysteme und die Möglichkeit, sie für statische Programmanalysen zu nutzen. Für Top-down lässt sich der Trend erkennen, größere Fragmente aus System F herauszuschneiden und für neuere, mächtigere Typsysteme
in zumeist funktionalen Sprachen einzusetzen (Ausnahme: SCALA); der Preis
sind neuartige, typ-orientierte, vom Benutzer hinzuzufügende Annotierungen
(die stark semantischen Charakter haben können), und pragmatisch schlechter kontrollierbare Typinferenz-Systeme. Der Vorteil sind neue Darstellungen
von Typ-Konstruktorklassen oder, im Falle der Anwendung dieser Typsysteme
in Logiken Höherer Stufe [67], poly-typische Beweistechniken für ProgrammTransformationen im Stile der Squiggol-School (or “Algebra of Programming”)
[12] (d.h. die üblichen “Catamorphismen” und “Hylomorphismen” werden in
diesen Logiken tatsächlich First-Class-Citizens).
Übrigens ist dieser späte Erfolg der Squiggol School, zusammen mit der
Funktor-Semantik für parametrisierte Datentypen (die immerhin inspirierend für
Sprachen wie SML und das Parametrisierungskonzept in Java gewesen ist), einer
der wenigen echten Beiträge des Algebraischen Top-down Programms, was sich
im Wesentlichen durch die Verwendung von Kategorientheorie als Fundamentalsystems auszeichnet. Es scheint sich zu rächen, das in diesem Teilprogramm
niemals ernsthaft versucht worden ist, Beweisumgebungen direkt kategorientheoretisch zu begründen und einen entsprechenden Fundus an formalisierter
Mathematik aufzubauen (von wenigen Ausnahmen, etwa im MIZAR Journal,
abgesehen). Dadurch haben viele neuere Arbeiten lediglich den Charakter, andere bekannte Logiken oder Rechenmodelle kategorientheoretisch nachzuformulieren — der Vergleich mit dem Neo-Marxismus, der primär damit beschäftigt
ist, Erklärungen für ’56 und ’89 zu finden, liegt da nahe.
6
Formale Entwicklungsmodelle
Im Folgenden behandeln wir die Frage, wie man mit formalen Techniken von
der abstrakten Spezifikation und seinen formalisierten Anforderungen zu einem
ablauffähigen Programm, einer Implementierung kommen kann, das die Anforderung erfüllt. Im Gegensatz zu Abschnitt 7 geht also hier darum, den Entwicklungsprozess selbst formal zu untermauern und technisch zu unterstützen.
Grundsätzlich kann man drei Ansätze unterscheiden: Programm-Entwicklung
durch Verfeinerung, durch Programmtransformation und durch Model-Driven
Engineering.
325
6.1
Verfeinerung
Jede formalen Spezifikation ist ein mathematische Modell und damit notwendigerweise eine Abstraktion der Realität. Spezifikationen können aber auch Abstraktionen von komplexeren Systemmodellen sein: Modelle auf höherem Abstraktionsgraden sind in der Regel erheblich einfacher zu verstehen oder maschinell zu analysieren als detailliertere.
Die Verfeinerungsbeziehung ist eine formale Relation P % Q zwischen Modellen, die ausdrückt, ob ein Modell Q eine korrekte Implementierung des Modells
P ist. Der dieser Beziehung unterliegende Korrektheitsbegriff hängt einerseits
vom verwendeten Formalismus und andererseits von der Art der Anforderungen
ab, die in der Spezifikation beschrieben werden.
Aus dem Bereich Algebraisch-Top-down sind Ansätze bekannt, die zumeist
auf Theoriemorphismen basieren (von klassischem “Forget-Restrict-Identify” [41]
über injektive Theoriemorphismen à la KIDS und seinen Nachfolgesystemen), in
den letzten Jahren aber kaum weiterentwickelt worden sind. Vorherrschend sind
Systeme, die Transitionssysteme über Forward- oder Backwardsimulation (Vergleiche [50] für eine Übersicht über die verschiedensten Simulationsbegriffe) über
eine Abstraktionsrelation R zwischen abstrakten und konkreten Zuständen in
Beziehung setzen; die Verfeinerungsbeziehung wird also als Tripel P %R Q aufgefasst. Solche Transitionssysteme werden üblicherweise durch Vor- und Nachbedingungen einer Operation und dann durch Module oder Packages von Operationen spezifiziert. Ein Verfeinerungssystem kann aus den vom Benutzer gegebenen
Transitionssystemen sowie der Abstraktionsrelation Beweisverpflichtungen generieren, die dann verifiziert werden müssen (siehe Abschnitt 7). Systeme, die dieser Methodik unterliegen, sind z.B. das KIV Tool, das KeY Tool, HOL-Z[18,69],
sowie B-Tools und sein Nachfolger Rodin[1].
CVS client 1
cvs
CVS client 1
cvs
working
copy
login
| add
| update
| commit
CVS-Server
CVS client n
cvs
working
copy
login
| add
| update
| commit
(a) “system”
CVS-Server
CVS client n
cvs
repository
login
| add
| update
| commit
login
| add
| update
| commit
copy, mv, chmod, chown, . . .
filesystem
repository
and
working copy
copy, mv, chmod, chown, . . .
(b) “implementation”
Abbildung 1. Verfeinerungen einer Client-Server Sicherheitsarchitectur
Eine beispielhafte Fallstudie für eine Systementwicklung basierend auf einer
Forwardsimulation ist die CVS-Server Studie basierend auf HOL-Z. Wie in Abbildung 1 gezeigt, verfeinert sie ein ein datenorientiertes (Sicherheits-)Modell
326
einer Datenbank, deren Zugriffskontrolle durch ein role-based access control model (RBAC) modelliert wurde, auf ein konkrete Konfiguration eines Dateisystems, das mit UNIX/Posix typischen Lese-und Schreibrechten attibutiert ist.
Dabei werden die abstrakten Operationen wie login, add, update und check-in
berücksichtigt. “korrekt” ist diese Verfeinerung dann, wenn die Implementierung
eine Verfeinerung des abstrakten Modells ist, sich also so verhält wie sie sich laut
Spezifikation verhalten sollte (vgl. Abschnitt 6.1). Dieses Datenmodell kann in
ein Verhaltensmodell engebettet werden: Ein Anwendungsszenario hierfür ergibt sich, wenn man über dieser lokalen Systemtransition (eine Transaktion der
Datenbank) die Menge aller Systemläufe konstruiert und hierfür verlangt, dass
niemand in einem Systemablauf Daten bekommen kann, für die er sich vorher
nicht für hinreichend stark authentifiziert hat (durch login). Solche temporallogischen Aussagen lassen sich durch Induktion über die Position in den Läufen
zeigen (z.B. [19,10]).
Selbstverständlich gibt es auch eine reichhaltige Literatur für verhaltensorientierte Verfeinerungen; insbesondere für Prozessalgebren wie CSP oder CCS
sind in vielfältige Verfeinerungsbegriffe definiert und Modelchecker wie FDR implementiert worden. Der Ansatz stagniert aber seit einer Weile; zum Einen macht
es sich von der Modellierung her für große Systeme nicht bezahlt, Zustände nur
als Prozesse zu betrachten; das resultierende exponentielle Wachstum der Zustandsräume macht allzu viele praktische Probleme “untractable”, und Kombinationen mit Zustandsabstraktionsrelationen haben sich nicht durchsetzen können. Auch aus diesem Grunde sind Implementierungen von Protokoll-Analysetools, die an sich in natürlicher Weise durch prozessalgebraische Verfeinerungen
ausgedrückt werden können, von prozessalgebraischen Techniken abgerückt und
verwenden zumeist problemspezifisches Modelchecking (siehe z.B. der OFMC
aus AVISPA).
6.2
Transformation
Kernidee des transformationellen Entwicklungsansatzes ist, Spezifikationen oder
Programme syntaktisch so umzuformen, das sich ihre Semantik nicht oder nur
verfeinernd verändert. Transformationen sind oft regelbasiert beschrieben, können
aber im Grundsatz beliebige Programme sein, die die Übersetzung durchführen.
Frühe Top-down, d.h. spezifikations-orientierte Transformationssysteme waren CIP-S, PROSPECTRA, KIDS, sowie in HOL realisierte Implementierungen
von Back und Wrights Refinement Calculus [4,5] oder von KIDS-artiger Standardtransformationen wie GlobalSearch und DivideAndConquer [47]. Diese Forschungsrichtung ist aufgegangen in dem Teilprogramm Model-driven Engineering
der im nachfolgenden Abschnitt diskutiert wird.
Bottom-up orientierte Programmtransformationsansätze haben eine aktive
Entwicklung erfahren, insbesondere im Bereich der Compilerverifikation. Denn
auch wenn man im allgemeinen auf ihre Korrektheit vertraut, so weisen Compiler
doch immer wieder Fehler auf, vor allem wenn komplexe Optimierungsstrategien
angewendet werden, oder wenn insbesondere sehr hardware-naher Code compiliert wird (bei kombiniertem C und Assemblercode, beispielsweise). Die schon
327
erwähnte Verfügbarkeit von konkreten, realistischen Maschinenmodellen und immer leistungsfähigeren Beweisumgebungen hat auch hier entscheidende Durchbrüche gebracht. Dabei können Programme nach einem Divide et Impera-Prinzip
sowohl lokal transformiert als auch lokal verifiziert werden und anschließend ihre
Übersetzungen bzw. Beweisteile zusammen gefügt werden. Verifikationen nach
dieser Methode finden sich z.B. in [29,61]. Verifikationen, die auch optimierende, strukturverändernde Transformationen behandeln, sind in [13] beschrieben.
Zusammenfassungen zur Compiler-Verifikation von sind in [37,36] zu finden.
Eine besondere Problematik von optimierenden Übersetzungstransformationen ergibt sich im Zusammenhang mit modernen, stark nebenläufigen Speichermodellen, z.B. für die JVM, wo lediglich eine partielle Ordnung auf der Ausführung von Load- und Store-operationen durch die Semantik definiert wird. Dadurch ist sowohl die Modellierung der Korrektheit als auch der konkrete Beweis
einer optimierenden Transformation für nebenläufige Java-Programme eine Herausforderung [63].
6.3
Model-Driven Engineering
Model-Driven Engineering (MDE) bezeichnet die systematische Verwendung von
Modellen als primären Entwicklungsartefakten durch den Entwicklungsprozess
hindurch. In seinem sehr liberalen Verständnis bezeichnen “Modelle” hier einfach Beschreibungen in einem maschinengestützten Format (im Grenzfall also: einer abstrakten Syntax), während sich der Terminus “systematisch” auf
maschinengestütze Transformationen zwischen Modellen und von Modellen zu
Code bezieht. Für die Instanz von MDE, die sich auf uml bezieht und die
durch die Object Management Group (omg) definiert wird, hat sich der Begriff
model-driven architecture (mda) etabliert (Vergleiche Abschnitt 4.2). In uml,
unterschiedliche Modellelemente wie Klassen oder Zustände können zu Klassensystemen oder Zustandsmaschinen kombiniert werden. Modellelemente können
mit logischen Constraints der Object Constraint Language (ocl) annotiert werden. uml als Sprache überlässt es bewusst eher Werkzeugbauern, verschiedenen
Modellelementen oder Modelltransformationsprozessen eine formale Semantik zu
unterlegen; für einige Teile der Sprache gibt es keine (Use-Cases), für manche
Modelle eine (Klassenmodelle), für andere Teile mehrere formale Semantiken
(Sequenzdiagramme, Statemachines); für alle gibt es aber einheitliche abstrakte
Syntaxen (“Meta-modelle”), technische Infrastrukturen und Diagramm-Typen
um Aspekte der Modelle graphisch darzustellen und zu kommunizieren — Code
oder Code-Fragmente sind übrigens auch Modellelemente in diesem Paradigma.
Ein wesentlicher Aspekt dieses Ansatzes ist die Möglichkeit, Modelle zu transformieren — AndroMDA oder ArcStyler sind entsprechende generische Rahmenwerke, in denen Modelle gespeichert und die Implementierung von Modelltransformationen auf ihnen unterstützt werden. Industriell relevante Anwendungen
solcher Rahmenwerke erzeugen z.B. verteilte Applikationen für Corba- und EJB
Frameworks, dynamischen Testcode (durch entsprechende Wrapper um CodeFragmente herum), oder Zugriffs-“Watchdogs” um Zugriffskontrolle in einem
verteilten Softwaresystem durchzusetzen.
328
Class
+ Public Method
# Protected Method
− Private Method
Test Data
Proof
Class
attribute: Type
attribute: Type
1..∗
+ Public Method
Role
# Protected Method
− Private Method
Obligations
Validation
Class
attribute: Type
ArgoUML
+ Public Method
# Protected Method
− Private Method
SecureUML/OCL
or
UML/OCL
(XMI)
Model
Transformation
Model−Analysis
and Verification
(HOL−OCL)
Test
Harness
C#
+OCL
AC
Config
Model
Repository
(su4sml)
Code
Generator
...
Abbildung 2. Das HOL-OCL mda Framework
In Abbildung 2 wird das HOL-OCL framework [17] dargestellt: ein UML
Frontend wie ArgoUML wird mit einem Kernsystem verbunden, das auf einer
Einbettung von UML/OCL in Isabelle/HOL basiert, ein in SML implementiertes Repositorium für UML Modelle vorsieht (samt Parsern, Typecheckern
und import-export-Funktionen), sowie einem generischen Code-Generator. Ein
Spezifikum dieses Rahmenwerks ist es, das Beweisverpflichtungen ebenfalls Modellelemente sind und während einer Modell-oder Codetransformation erzeugt
werden können; diese können dann im Isabelle/HOL-OCL Kern mit interaktiven und automatischen Methoden bewiesen werden. Dadurch können ForwardSimulation Verfeinerungen implementiert werden genauso wie Transformationen,
die ein kombiniertes System- und Sicherheitsmodell à la SecureUML in ein angereichertes Standard-Systemmodell umwandeln und dabei Seitenbedingungen
generieren, die die Lifeness des generierten gesicherten Systems etablieren [17].
7
Verifikationstechnik
Es ist zwar grundsätzlich möglich, aus Verfeinerungen oder aus Programmannotierungen generierte Beweisverpflichtungen “von Hand” (etwa durch Inspektionen) zu beweisen. Allerdings stößt die Lösung dieser Aufgabe ohne computer-gestützte Techniken an Grenzen der Praktikabilität und Zuverlässigkeit: Erfahrungen mit VCC-I und seinem sehr feinkörnigen Speichermodell zeigen, das generierte Beweisverpflichtungen ohne weiteres ein Megabyte groß werden können
(für eine C Funktion mit ca. 100 Zeilen länge, gemessen im SMT Austauschformat das zwischen Boogie, Z3 sowie HOL-Boogie[14,15]). Es ist somit fair zu
sagen, daß Verfahren zur Lösung von mathematischen Formeln das Herz des
FM darstellen, und zwar gleichermaßen für Top-down wie für Bottom-up. Es ist
dabei bemerkenswert, das klassische Unterscheidungen wie Safety und Security
aus Verifikationssicht kaum von Bedeutung sind4 .
4
... und übrigens auch auf Modellierungsebene immer weniger Sinn machen: Egal
ob durch einen Protokoll-Fehler oder durch einen Exploit eines Buffer-Overflows
329
Grundsätzlich können drei Verfahren der Verifikation von Systemeigenschaften unterschieden werden: deduktionsbasiertes Theorembeweisen, automatenbasiertes Modelchecking und modell-basiertes Testen — letzteres verwendet, wie
wir noch sehen, nicht nur dieselben Basistechniken wie Theorembeweiser oder
Modelchecker und ähnliche Meta-Annahmen wie Modelchecking, sondern kann
eine “approximierende Verifikation” darstellen.
7.1
Theorembeweisen
Deduktionsorientiertes Theorembeweisen benutzt Kalküle, um Beweisziele (also
z.B. Beweisverpflichtungen aus einer Verfeinerung oder einer Programmverifikation) zu zerlegen. Konzeptionell sind Beweisziele Formeln in Logiken wie z.B.
Aussagenlogik (PL), Logik erster Stufe (FOL), oder Logik höherer Stufe (HOL),
die zumeist mit Hilfstheorien erweitert werden müssen (Arithmetik, Bitvektoren,
aber auch Speichermodellen mit Theorien über Load-Store-Operationen, etc.).
Grundsätzlich kann man interaktive Beweissysteme wie Isabelle/HOL und
automatische wie Vampire oder Z3[25,26] unterscheiden; bei ersteren wird die
Liste der Beweisziele und ihrer Zerlegungen zu einem Beweiszustand zusammengefaßt, der mittels Taktiken immer weiter verfeinert wird zu Endzuständen,
aus denen sich die logische Wahrheit syntaktisch ergibt. Letztere verwandeln
die Formeln in clevere Datenstrukturen (Tableaux, SAT), in denen hocheffizient
implementierte Heuristiken die Beweissuche realisieren. Erstere sind einfach zu
erweitern und haben einen beträchtlichen Fundus an formalisierter Mathematik
in ihren Bibliotheken, verfügten jedoch vor einiger Zeit noch über einen relativ
niedrigen Automatisierungsgrad. Letztere lösen Formeln von z.T. staunenerregender Komplexität in kürzester Zeit — Beweisfehlversuche sind allerdings notorisch schwer zu interpretieren und zu analysieren, und bis vor einiger Zeit war
die Erweiterbarkeit dieser Systeme ausserordentlich problematisch.
Die Situation hat sich in beiden Lagern in den letzten Jahren entscheidend
verbessert: durch die Möglichkeit, Taktiken programmgesteuert anzuwenden,
sind mächtige Beweisprozeduren (Termersetzungsprozeduren, Tableaux-Beweiser,
Arithmetische Entscheidungsprozeduren) in interaktiven Beweisern entwickelt
worden, die zudem konstruktionsbedingt eine außerordentliche hohe Zuverlässigkeit und Vertrauenswürdigkeit erreicht haben (zumindest bei Beweisern, die eine
“LCF-style Architecture” aufweisen wie Isabelle/HOL oder HOL-Light; eine Diskussion findet sich in [39]). Bei den Vollautomaten wie Z3 oder Alt-Ergo hat sich
vorläufig die DPLL(X) - Architektur [34] durchgesetzt, eine generische Erweiterung der SAT-Beweiser mit eingebauten Algorithmen für Kongruenzabschlüsse,
die mit Entscheidungsprozeduren für Arithmetik, Bitvektoren, Quantoreninstantiierungen etc. kombiniert werden kann. Durch geeignete Codierungstechniken
von Hilfsattributen ist zumindest für den Fall der Programmanalyse das Problem der Rückinterpretation von Beweisfehlversuchen erleichtert worden[49,14].
ein Virus Millionen Rechner und damit IT-Infrastukturen eines Landes zum Ausfall
bringt: es besteht in jedem Fall Gefahr für Leib und Leben von Menschen.
330
Zudem wird intensiv an Kombinationen von automatischen und interaktiven Beweistechniken gearbeitet, sei es auf Beweiser-Ebene wie bei zchaff oder Vampire
in Isabelle oder auf der Methoden-Ebene wie bei VCC-I/HOL-Boogie[15].
Interaktive Beweiser haben — wie schon erwähnt — erheblichen Anteil an
der Beherrschung der Grundlagen von “real machine models”, also Prozessoren,
Virtuelle Maschinen oder Ausführungsmodelle von Sprachen wie C gehabt[24];
diese waren für die Durchbrüche des Bottom-up Programmes von wesentlicher
Bedeutung. (Daneben gibt es beachtliche Erfolge wie die Formalisierung großer
mathematischer Beweise wie Vierfarbentheorem, Primzahl-Verteilungstheorem
oder der Kepler-Vermutung). Automatische Beweiser, deren Effektivität um
Grössenordnungen zugenommen hat, sind für den Bau von Programmanalysesystemen wie Krakatoa oder Spec# sowieso kriegsentscheidend.
Interaktives oder automatisches Theorembeweisen wird in der industriellen
Praxis zur Zeit vor allem bei hoch-kritischen Anwendungen im militärischen
Bereich, bei Java-Smartcards, bei Mikroprozessoren oder bei maschinennaher
Software wie Treiber und Betriebssysteme angewandt[57]. Die Firma Intel hat
beispielsweise mehr als 40 % des Pentium IV bis auf das Gatterlevel hinunter
so verifiziert. Prozessoren sind also vermutlich die am weitesten verbreiteten
handelsübliche Produkte, für die Verifikation in der Herstellung bedeutsam ist.
Für die schwierigen Probleme werden hier Theorembeweiser eingesetzt, weil die
im folgenden beschriebenen Modelchecker sie aus Aufwandsgründen praktisch
nicht mehr bewältigen können.
7.2
Modelchecking
Modelchecking (auch: Modellprüfverfahren) versucht zumeist, für Widerlegungsvollständige Logiken (PL, FOL, Monadische Logik 2. Stufe,LTL, CTL,...) für das
negierte Beweisziel ein Modell zu finden; wenn das gelingt, ist das Beweisziel widerlegt. Durch geeignete Datenstrukturen können Modelle vollautomatisch und
z.T. hocheffizient gesucht werden. Das Konzept ist auch auf verhaltensorientierte
Modelle in LTL und CTL, ja sogar auf Prozessalgebren anwendbar (die nichts
mit Widerlegungsvollständigkeit zu tun haben), und läuft dort zumeist auf die
Exploration von kompakt repräsentierten Automaten oder “Labelled Transition Systems” heraus. Für die kompakte Repräsentation dienen zumeist binary
decision diagrams (BDD), die boolesche Funktionen eindeutig (kanonisch) repräsentieren; sie setzen eine Variablenordnung voraus, aufgrund der die Boolesche Funktion mehr oder weniger kompakt repräsentiert werden können.
In etwas mehr Detail läßt sich das Verfahren so beschreiben; Ist das zu modellierende System endlich, kann die Systemtransitionsrelation als aussagenlogische
Formel φ dargestellt werden kann — sämtliche Daten müssen nur binär codiert
werden. Stellt man die Frage, ob φ eine Anforderung ψ erfüllt, bedeutet dies,
dass man das Beweisziel φ → ψ negieren und dafür ein Modell suchen muss; gibt
es keins, gilt das Beweisziel. Das Verfahren ist für Aussagenlogik vollständig,
allerdings oft unpraktikabel (“Zustandsexplosion”). BDD’s erlauben für viele
relevante Boolesche Funktionen (z.B. die Addition auf binär codierten Zahlen)
sehr kompakte Darstellungen, die die Zustandsexplosion umgehen.
331
Verallgemeinert man diese Techniken zur Behandlung von verhaltensorientieren Systemeigenschaften, so kann z.B. die transitive Hülle der Systemtransitionsrelation bilden (für Aussagen der Form: “alle erreichbaren Zustände erfüllen ψ”)
oder aus ihr einen endlichen Automaten erzeugen. In letzterem kann man auch
Aussagen der Form entscheiden: “irgendwann werden auf allen Pfaden Zustände
erreicht, auf denen ψ gilt”. Mit endlichen Automaten können auch nebenläufige
Systeme analysiert werden; hierbei werden Automaten konstruiert, die die Menge
aller möglichen Verzahnungen lokaler Teilsystemtransitionsrelationen enthalten.
Besonders erfolgreich kann Modelchecking für die Programmanalyse nebenläufiger Programme mit trivialem Datenanteil herangezogen werden (SPIN, Java/Pathfinder, ...), oder in der Protokollanalyse herangezogen werden, da man es
hier mit nebenläufigen Protokollabläufen zu tun hat, deren Interaktionen schwer
zu überblicken sind. Es stehen mittlerweile Spezialwerkzeuge zur semi- und vollautomatischen Analyse kryptographischer Protokolle zur Verfügung [3], die erfolgreich zum Aufdecken von Fehlern bzw. Nachweisen der Sicherheit veröffentlichter Protokolle eingesetzt worden sind und zudem den Entwurf und die Standardisierung von Protokollen unterstützen [52].
Während die Erfolge von Modelcheckern in sehr spezialisierten Anwendungsdomänen unbestreitbar sind, muss ihre Verwendbarkeit als allgemeine Modellierungs- und Analysetechnik skeptisch beurteilt werden. Es gibt dafür auch theoretische Gründe: Für BDD’s ist bekannt, das keine Variablenordnung existiert,
die gleichermaßen für Multiplikation und Addition kompaktifiziert; bekannte
Challenge-Probleme wie (x div y) ∗ y + (x mod y) = x können mit aktuellen High-End Modelcheckern auf BDD-basis lediglich für maximal fünfbittige
Zahldarstellungen für x und y bewiesen werden[59] ... Pragmatisch sind die Constraints für die Modellierung realer Probleme derart einschneidend, das auch die
Arbeitseffektivität der Verifikation gering ist, trotz eines automatischen Verifikationsverfahrens (siehe auch [10]). Erfolgreiche und etablierte Verifikationsabteilungen in der Industrie (Intel,AMD,Microsoft) setzen daher auf eine geschickte
Kombination von Testen, Modelchecking und interaktivem Theorembeweisen.
7.3
Testen
Wie beim Modelchecking muss beim systematischen, modell-basierten Testen der
Zustandsraum eines realen Systems sowie die Menge der möglichen Eingabedaten endlich beschränkt werden; während man pragmatisch bei modelcheckingbasierter Verifikation den Bereich der Quantoren einer Systemeigenschaft beschränkt, sucht man beim systematischen Testen andere endliche Teilbereiche
von Eingabedaten, die sich nach Testadäquatheitskriterien richten. Solche Kriterien, die eine Aussage darüber machen wann eine Eigenschaft eines Systems,
also ein Beweisziel, genug getestet worden ist, lassen sich teilweise durch Fehlermodelle von Schaltwerken, Programmen oder Spezifikationen begründen. Solche
Adäquatheitskriterien können spezifikationsbasiert sein (z.B. Partition-Coverage;
ein Test für jedes Glied der DNF der Spezifikation) oder programmbasiert sein
(z.B. Path-Coverage; ein Test für jeden Pfad durch den Kontrollflussgraphen
332
eines Programms) und sich auf das Systemverhalten beziehen (z.B. TransitionCoverage der Spezifikation; alle Transitionen der Spezifikation in Form eines LTS
müssen in einer Testsequenz vorkommen).
Vollständige, z.B. mit einem Theorembeweiser durchgeführte Verifikation ist
so gesehen kein Gegensatz zum Testen. Systematische, modellbasierte Tests verwenden nicht nur dieselben Basistechniken wie Theorembeweiser oder Modelchecker, sondern können eine “approximierende Verifikation” darstellen [20]; in
dem dort beschriebenen System HOL-TestGen wird eine Testspezifikation T S
automatisch in ein Testtheorem der Form:
Case1 =⇒ . . . =⇒ Casen =⇒ T HY P (H1 ) =⇒ . . . =⇒ T HY P (Hm ) =⇒ T S
äquivalent zerlegt, wobei die Casei (die Testfälle) der Form
Constraint1 x =⇒ . . . Constraintk x =⇒ post x (sut x)
sind. Constraint-Solving-Techniken erlauben nun die Konstruktion von Zeugen
für x, die die Constraints erfüllen. Aus post x (sut x) generiert man dann ein
Testorakel, das das System-Unter-Test sut mit diesem Zeugen aufruft und die
Zulässigkeit seines Outputs mittels des Codes für post prüft. Der Aspekt, das
gegebener Code gegenüber einem Modell abgeprüft wird und das man mit dem
Modell solange experimentieren kann, bis man durch das Modell den Code “erfaßt” hat, ist ein Spezifikum des Testansatzes und macht Modell-basiertes Testen
für das Reverse-Engineering unverzichtbar, auch im industriellen Maßstab [38].
HOL-TestGen ist für sehr ambitionierte Fallstudien angewendet worden;
diese nutzen auch die Möglichkeit, Scenarien für Sequenztest und reaktivem
Sequenztest in diesem Rahmenwerk darzustellen [16].
Die T HY P (Hi ) im obigen Testtheorem sind übrigens die explizite Testhypothesen, d.h. Formeln, die die genaue “logische Differenz” zwischen Test und
Verifikation darstellen. Das obige Testtheorem bedeutet demnach, daß wenn sut
den Test für alle Testfälle besteht und wenn die Testhypothesen gelten, dann
erfüllt sut genau die Testspezifikation. Klassische Testhypothesen [35] sind z.B.
Uniformität (wenn der Test für einen Testdatum der Klasse gelingt, gelingt er
für alle der Klasse) oder Regularität (es werden alle Daten bis zu einer gewissen
Komplexitätsstufe getestet).
Erschöpfendes Testen aller möglichen Eingabesequenzen ist selbst im Hinblick auf die üblichen Adäquatheitskriterien wegen der exponentiell wachsenden
Anzahl der Testabläufe in der Praxis oft nicht durchführbar. Wünschenswert
sind somit Adäquatheitskriterien, die bei einem gegebenen Aufwand zu einer
Menge von Testabläufen führen, die mit hoher Wahrscheinlichkeit sicherheitskritische Fehler aufdecken, und somit ein größtmögliches Vertrauen in die Sicherheit der Implementierung liefern. Dies führt zur Idee der probabilistischen
Adäquatheitskriterien, (z.B. probabilistische Uniformität[27]), bei der für jede
Testklasse verlangt wird, daß sie mit der gleichen Wahrscheinlichkeit wie alle
anderen getestet werden.
333
8
Schlussfolgerungen
Man kann einen Trend zu einem dichteren Netz von Anwendungsszenarien für
FM beobachten, das immer weitere Bereiche der Softwaretechnik durchzieht.
Dies gilt für Top-down, aber z. Zt. in scheinbar stärkerem Maße für Bottomup. Es fragt sich allerdings, ob sich die starke Dynamik, die sich insbesondere
auf Durchbrüche bei den vollautomatischen Beweissystemen wie Z3 stützt, nicht
abschwächt und abstraktere Modellierungstechniken bald wieder stärker im Vordergrund stehen.
Neben dem prinzipiellen Nutzen von FM, der in einer weitergehenden wissenschaftlichen Fundierung der Softwaretechnik als solcher besteht—sei es in der
Bedarfsanalyse, dem Entwurf, der Implementierung oder der Verifikation—wird
auch ein immer größerer praktischer Nutzen erkennbar. Drei praktisch relevante
Anwendungsszenarien lassen sich identifizieren:
– FM “under-the-hood”. In immer mehr Entwicklungswerkzeugen und Compilern werden intern Formale Methoden Techniken wie Abstrakte Interpretation, Modelchecking, Extended Typechecking und Theorembeweisen verwendet, ohne dass der Programmentwickler das direkt sieht (Java BytecodeVerifier, PolySpace, . . . ).
– FM “light-weighed”. Dies bezeichnet eine Reihe von Migrationsversuchen
von Formalen Methoden wie Runtime-Testing von Annotierungssprachen wie
OCL, JML oder Spec#, oder wie hochautomatische Verfahren basierend auf
eingeschränkten Annotierungen à la SAL oder modelcheck-fähige temporale Constraints aus Bibliotheken. FM “light-weighed” umfasst auch Techniken wie MDA (auch spezialisiert für gewisse Zwecke wie die systematische
Einführung von Sicherheitsmechanismen) oder Reverse-Engineering durch
Modell-basiertes Testen.
– FM “hard-core”. Damit werden theorembeweiser-basierten Ansätze wie
Verfeinerung und Codeverifikation zusammengefasst, die einen speziell ausgebildeten Verifikationsingenieur erfordern und aus diesem Grund in der
industriellen Praxis zur Zeit auf hardware-nahe, sicherheitskritische oder
höchste Zertifizierungsstufen erfordernde Systeme beschränkt ist.
Es sei hierbei explizit festgestellt, dass alle drei Bereiche sich gegenseitig bedingen; Techniken, die in FM “hard-core” entwickelt werden, finden mitunter ihren
Weg in FM “under-the-hood”-Szenarien. Umgekehrt ist ein höherer Kenntnisstand und die Verbreitung von FM “light-weighed”-Techniken in der industriellen Praxis für Projekte, die FM “hard-core” etwa aufgrund einer angestrebten
Zertifizierung anstreben, von Vorteil: Von Softwareentwicklern erstellte Modelle
etwa in UML/OCL können eine wertvolle Grundlage für ein verfeinertes und von
Verifikationsingenieuren erstelltes Systemmodell sein.
Danksagung: Ganz herzlich möchte ich mich bei Bernd Krieg-Brückner bedanken, der mich mit FM vertraut gemacht hat, mir viel Raum gab, mich zu
entwickeln und mich ein Stück meines Weges begleitet hat.
334
Literatur
1. Jean-Raymond Abrial. Modeling in Event-B: System and Software Engineering.
Cambridge University Press, 2009. to appear.
2. Nancy J. Adler and Anne-Wil Harzing. When Knowledge Wins: Transcending the
Sense and Nonsense of Academic Rankings. Learning & Education, 8(1), 2009.
3. A. Armando, D. Basin, M. Bouallagui, Y. Chevalier, L. Compagna, S. Mödersheim,
M. Rusinowitch, M. Turuani, L. Vigano, and L. Vigneron. The AVISS Security
Protocol Analysis Tool. In CAV 2002, LNCS 2404, pages 349–353, 2002.
4. R.-J. Back and J. von Wright. Refinement Calculus. 1998.
5. Ralph-Johan Back, Jim Grundy, and Joakim von Wright. Structured calculational
proof. Formal Asp. Comput., 9(5-6):469–483, 1997.
6. Michael Barnett, Robert DeLine, Manuel Fähndrich, K. Rustan M. Leino, and
Wolfram Schulte. Verification of object-oriented programs with invariants. Journal
of Object Technology, 3(6):27–56, 2004.
7. Mike Barnett, Manuel Fähndrich, K. Rustan M. Leino, Francesco Logozzo, Peter
Müller, Wolfram Schulte, Herman Venter, and Songtao Xia. Spec#. Microsoft
Research, Redmond, 2008. http://research.microsoft.com/specsharp.
8. Mike Barnett, K. Rustan M. Leino, Michal Moskal, and Philipp Rümmer. Boogie
program verification. Microsoft Research, Redmond, 2008. http://research.
microsoft.com/boogie/.
9. D. Basin, J. Doser, and T. Lodderstedt. Model driven security: from UML models
to access control infrastructures. ACM Transactions on Software Engineering and
Methodology, 2005.
10. David Basin, Hironobu Kuruma, Kunihiko Miyazaki, Kazuo Takaragi, and Burkhart Wolff. Verifying a signature architecture: a comparative case study. Formal
Aspects of Computing, 19(1):63–91, March 2007. http://www.springerlink.com/
content/u368650p18557674/?p=8851693f5ba14a3fb9d493dae37783b8&pi=0.
11. Patrick Baudin, Jean-Christophe Filliatre, Claude Marché, Benjamin Monate, Yannick Moy, and Virgile Prevosto. ACSL: ANSI/ISO C Specification Language –
version 1.3. Technical report, INRIA Saclay, 22. Oct, 2008.
12. Bird, Moore, Backhouse, Gibbons, et al. Algebra of programming research group.
Home Page. http://www.comlab.ox.ac.uk/research/pdt/ap/pubs.html.
13. J. Blech, S. Glesner, J. Leitner, and S. M¸lling. Optimizing Code Generation
from SSA Form: A Comparison Between Two Formal Correctness Proofs in Isabelle/HOL. In ETAPS 2005.
14. Sascha Böhme, Rustan Leino, and Burkhart Wolff. HOL-Boogie — an Interactive
Prover for the Boogie Program Verifier. In Sofiene Tahar, Otmane Ait Mohamed,
and César Muñoz, editors, 21th International Conference on Theorem proving in
Higher-Order Logics (TPHOLs 2008), LNCS 5170. Springer-Verlag, Montreal, Canada, 2008.
15. Sascha Böhme, Michal Moskal, Wolfram Schulte, and Burkhart Wolff. HOL-Boogie
— an Interactive Prover-Backend for the Verified C Compiler. Journal of Automated Reasoning (JAR), 2009. submitted.
16. Achim D. Brucker, Lukas Brügger, and Burkhart Wolff. Model-based firewall conformance testing. In Kenji Suzuki and Teruo Higashino, editors, Testcom/FATES
2008, LNCS 5047, pages 103–118. Springer-Verlag, Tokyo, Japan, 2008.
17. Achim D. Brucker, Jürgen Doser, and Burkhart Wolff. An MDA framework supporting OCL. Electronic Communications of the EASST, 5, 2007.
335
18. Achim D. Brucker, Frank Rittinger, and Burkhart Wolff. HOL-Z 2.0: A proof
environment for z-specifications. Journal of Universal Computer Science, 9(2):152–
172, February 2003.
19. Achim D. Brucker and Burkhart Wolff. A verification approach for applied system
security. International Journal on Software Tools for Technology Transfer (STTT),
7(3):233–247, 2005.
20. Achim D. Brucker and Burkhart Wolff. Test-sequence generation with hol-testgen
– with an application to firewall testing. In Bertrand Meyer and Yuri Gurevich,
editors, TAP 2007: Tests And Proofs, number 4454 in Lecture Notes in Computer
Science, pages 149–168. Springer-Verlag, Zurich, 2007.
21. Achim D. Brucker and Burkhart Wolff. An extensible encoding of object-oriented
data models in hol with an application to IMP++. Journal of Automated Reasoning (JAR), Selected Papers of the AVOCS-VERIFY Workshop 2006, 2008. Serge
Autexier, Heiko Mantel, Stephan Merz, and Tobias Nipkow (eds).
22. Ernie Cohen, Michal Moskal, Wolfram Schulte, and Stephan Tobies. A Precise
Yet Efficient Memory Model For C. In Proceedings of the European Conference of
Object-Oriented Programing-Languages (ECOOP ’09), Lecture Notes in Computer
Science. Springer-Verlag, July 2009. submitted paper.
23. Manuvir Das. Formal specifications on industrial-strength code-from myth to reality. In Thomas Ball and Robert B. Jones, editors, CAV, volume 4144 of Lecture
Notes in Computer Science, page 1. Springer, 2006.
24. Matthias Daum, Jan Dörrenbächer, and Burkhart Wolff. Proving fairness and
implementation correctness of a microkernel scheduler. Journal of Automated Reasoning (JAR), page 29 pages, 2009. Accepted (with minor revisions) by G. Klein,
R. Huuck and B. Schlich: Special Issue on Operating System Verification (2008).
To appear.
25. Leonardo de Moura and Nikolaj Bjørner. Efficient incremental E-matching for
SMT solvers. In 21st Conference on Automated Deduction (CADE 2007), LNCS
4603, 2007.
26. Leonardo de Moura and Nikolaj Bjørner. Z3: An efficient SMT solver. In TACAS
2008, volume 4963 of Lecture Notes in Computer Science, pages 337–340. Springer,
March–April 2008.
27. A. Denise, M.-C. Gaudel, S.-D. Gouraud, R. Lassaigne, and S. Peyronnet. Uniform random sampling of traces in very large models. In 1st International ACM
Workshop on Random Testing, pages 10 –19, July 2006.
28. Commission d’Evaluation 2007. Une évaluation des indicateurs bibliométriques.
Technical report, INRIA, 2007. http://www.inria.fr/inria/organigramme/
documents/ce_indicateurs.pdf.
29. A. Dold, F. W. von Henke, and W. Goerigk. A Completely Verified Realistic
Bootstrap Compiler. International Journal of Foundations of Computer Science,
14(4):659–680, 2003.
30. Paul Feyerabend. Wider den Methodenzwang. Suhrkamp (stw 597), Frankfurt am
Main, 1975. ISBN 3-518-28197-6.
31. Jean-Christophe Filliâtre and Claude Marché. The why/krakatoa/caduceus platform for deductive program verification. In Werner Damm and Holger Hermanns,
editors, CAV, volume 4590 of Lecture Notes in Computer Science, pages 173–177.
Springer, 2007.
32. Joint Taskforce for Computing Curricula. Computing curricula 2005: The overview
report. Technical report, ACM/AIS/ IEEE, 2005, 2005. www.acm.org/education/
curric_vols/CC2005-March06Final.pdf.
336
33. Erich Gamma, Richard Helm, Ralph Johnson, and John M. Vlissides. Design
Patterns, Elements of Reusable Object-Oriented Software. Addison-Wesley International, 1994.
34. Harald Ganzinger, George Hagen, Robert Nieuwenhuis, Albert Oliveras, and Cesare Tinelli. Dpll( t): Fast decision procedures. In Rajeev Alur and Doron Peled,
editors, CAV, volume 3114 of Lecture Notes in Computer Science, pages 175–188.
Springer, 2004.
35. Marie-Claude Gaudel. Testing can be formal, too. In Peter D. Mosses, Mogens
Nielsen, and Michael I. Schwartzbach, editors, TAPSOFT 95, volume 915 of Lecture
Notes in Computer Science, pages 82–96. Springer-Verlag, Aarhus, Denmark, 1995.
36. S. Glesner and J. Blech. Logische und softwaretechnische herausforderungen bei
der verifikation optimierender compiler. In SE 2005. LNI, März 2005.
37. S. Glesner, G. Goos, and W. Zimmermann. Verifix: Konstruktion und Architektur verifizierender Übersetzer (Verifix: Construction and Architecture of Verifying
Compilers). it - Information Technology, 46:265–276, 2004. Print ISSN: 1611-2776.
38. Wolfgang Grieskamp, Nicolas Kicillof, Dave MacDonald, Alok Nandan, Keith Stobie, and Fred L. Wurden. Model-based quality assurance of windows protocol
documentation. In ICST, pages 502–506, 2008.
39. Thomas C. Hales. Formal proof. Notices of the American Mathematical Society,
55(11):1370–1382, 2008.
40. John Harrison. Formal proof-theory and practice. Notices of the American Mathematical Society, 55(11):1305–1407, 2008.
41. Rolf Hennicker. Context induction: A proof principle for behavioural abstractions
and algebraic implementations. Formal Asp. Comput., 3(4):326–345, 1991.
42. Andrew Hodges. Alan Turing: the Enigma. London: Burnett; New York: Simon
and Schuster, 1983.
43. Brian Huffman, John Matthews, and Peter White. Axiomatic constructor classes
in isabelle/holcf. In Joe Hurd and Thomas F. Melham, editors, TPHOLs, volume
3603 of Lecture Notes in Computer Science, pages 147–162. Springer, 2005.
44. J. J¸rjens. Secure Systems Development with UML. 2004. ISBN: 3-540-00701-6.
45. Joseph Kiniry. ESC/Java2 Home Page, 2005. http://kind.ucd.ie/products/
opensource/ESCJava2.
46. Gerwin Klein and Tobias Nipkow. Verified bytecode verifiers. Theor. Comput. Sci.,
3(298):583–626, 2003.
47. Kolyang, T. Santen, and B. Wolff. Correct and user-friendly implementation of
transformation systems. In M.-C. Gaudel and J. Woodcock, editors, FME 96 —
Industrial Benefits and Advances in Formal Methods, LNCS 1051, pages 629–648.
Springer Verlag, 1996.
48. Ralf Küsters. ETH Zürich, personal communication, 2006.
49. K. Rustan M. Leino, Todd D. Millstein, and James B. Saxe. Generating error
traces from verification-condition counterexamples. Sci. Comput. Program., 55(13):209–226, 2005.
50. Nancy A. Lynch and Frits W. Vaandrager. Forward and backward simulations: I.
untimed systems. Inf. Comput., 121(2):214–233, 1995.
51. Stefan Maus, Michal Moskal, and Wolfram Schulte. Vx86: x86 Assembler Simulated
in C Powered by Automated Theorem Proving. In AMAST, pages 284–298, 2008.
52. C. Meadows, P. Syverson, and I. Cervesato. Formalizing GDOI group key management requirements in NPATRL. In Proceedings of the 8th ACM Computer and
Communications Security Conference (CCS 2001), pages 235–244. ACM Press,
2001.
337
53. Michal Moskal, Wolfram Schulte, and Herman Venter. Bits, words, and types:
Memory models for a verifying c compiler. Science of Computer Programming
(SCP), 2008. to appear.
54. Olaf Müller, Tobias Nipkow, David von Oheimb, and Oscar Slotosch.
Holcf=hol+lcf. J. Funct. Program., 9(2):191–223, 1999.
55. Special issue on formal proof, 2008. http://www.ams.org/notices/200811/.
56. Proof by computer: Harnessing the power of computers to verify mathematical
proofs. http://www.physorg.com/news145200777.html.
57. Wolfgang Paul, Thomas Santen, and Stefan Tobies. Verifying 50000 lines of code.
Futures — Microsoft’s European Innovation Magazine, pages 42–43, June 2008.
58. Karl Popper. Die Logik der Forschung. Verlags Mohr Siebeck, 1934.
59. Nicole Rauch and Burkhart Wolff. Formalizing Java’s two’s-complement integral
type in Isabelle/Hol. In Electronic Notes in Theoretical Computer Science, volume 80. Elsevier Science Publishers, 2003.
60. Bernhard Reus and Thomas Streicher. General synthetic domain theory - a logical
approach. Mathematical Structures in Computer Science, 9(2), 1999.
61. G. Schellhorn and W. Ahrendt. Reasoning about Abstract State Machines: The
WAM Case Study. Journal of Universal Computer Science, 3(4):377–413, 1997.
62. Norbert Schirmer. Verification of Sequential Imperative Programs in Isabelle/ hol.
PhD thesis, Technische Universität München, 2006.
63. Jaroslav Sevcı́k and David Aspinall. On validity of program transformations in the
Java memory model. In Jan Vitek, editor, ECOOP, volume 5142 of Lecture Notes
in Computer Science, pages 27–51. Springer, 2008.
64. Imre Lakatos (Übersetzung Arpád Szabó). Die Methodologie der wissenschaftlichen Forschungsprogramme. Vieweg Braunschweig; Wiesbaden, 1982. ISBN 3528-08429-4.
65. H. Tej and B. Wolff. A corrected failure-divergence model for CSP in Isabelle/HOL.
In J. Fitzgerald, C.B. Jones, and P. Lucas, editors, Proceedings of the FME 97 —
Industrial Applications and Strengthened Foundations of Formal Methods, LNCS
1313, pages 318–337. Springer Verlag, 1997.
66. Harvey Tuch, Gerwin Klein, and Michael Norrish. Types, bytes, and separation
logic. In Martin Hofmann and Matthias Felleisen, editors, POPL, pages 97–108.
ACM, 2007.
67. Norbert Völker. HOL2P - a system of classical higher order logic with second order
polymorphism. In Klaus Schneider and Jens Brandt, editors, TPHOLs, volume
4732 of Lecture Notes in Computer Science, pages 334–351. Springer, 2007.
68. David von Oheimb and Tobias Nipkow. Machine-Checking the Java Specification:
Proving Type-Safety. In Jim Alves-Foss, editor, Formal Syntax and Semantics of
Java, volume 1523 of Lecture Notes in Computer Science, pages 119–156. Springer,
1999.
69. Makarius Wenzel and Burkhart Wolff. Building formal method tools in the isabelle/isar framework. In Klaus Schneider and Jens Brandt, editors, TPHOLs 2007,
LNCS 4732, pages 351–366. Springer-Verlag, 2007.
70. Reinhard Wilhelm, Jakob Engblom, Andreas Ermedahl, Niklas Holsti, Stephan
Thesing, David B. Whalley, Guillem Bernat, Christian Ferdinand, Reinhold Heckmann, Tulika Mitra, Frank Mueller, Isabelle Puaut, Peter P. Puschner, Jan Staschulat, and Per Stenström. The worst-case execution-time problem - overview of
methods and survey of tools. ACM Trans. Embedded Comput. Syst., 7(3), 2008.
338
Burkhart Wolff came in 1991 into Bernd-Krieg
Brückners group and worked on various approaches to construct a successor of the ProSpecTraTransformation system developed earlier there. In
1997, he received his Phd and moved to Freiburg,
where he held a research assistent position till 2003
(for which he eventually got his Habilitation degree in
2005). From 2004 till 2006, he was assistant professor (Öberassistent”) in the computer security group
at the ETH Z¸rich, and was invited researcher at Microsoft Research, Redmond, in 2007. Since 2008, he is
full professor at the Universié Paris-Sud in the formal
testing and software-engineering group ForTesSE. His
main work area is the field of environments for verification and validation of software systems.
Author Index
Autexier, Serge
35
Bibel, Wolfgang 15
Birbach, Oliver 88, 103
Catesbeiana, Erwin R. 40
Catesbeiana, Erwin R. jr. 17
Codescu, Mihai 51
de la Cruz Ramos, Pedro
Dietrich, Dominik 35
Dovland, Johan 72
Drechsler Rolf 140
28
Fey, Görschwin 140
Frese, Udo 88, 103, 255
Gersdorf, Bernd 1, 255
Gimblett, Andy 121
Gogolla, Martin 18
Große, Daniel 140
Hoffmann, Berthold
Hutter, Dieter 35
Ibraheem, Modal
1, 152
19
Johnsen, Einar Broch
72
Kahrs, Stefan 168
Kahsai, Temesghen 121
Kohlhase, Andrea 184
Kohlhase, Michael 184, 201
Kreowski, Hans-Jörg 217
Kurlbaum, Jörg 103
Lankenau, Axel 255
Laue, Tim 103
Lemburg, Johannes 201
Li, Lixing 273
Li, Xiaoyu 273
Lu, Ruqian 273
Maeder, Christian 51
Mandel, Christian 255
Mossakowski, Till 1, 51
Mosses, Peter 23
Nake, Frieder
24
O’Reilly, Liam 121
Owe, Olaf 72
Peleska, Jan
Qian, Zhenyu
229
26
Röfer, Thomas 1, 103, 255
Rauer, Sylvie 29
Reichel, Horst 246
Roggenbach, Markus 121
Sannella, Don 30
Schlingloff, Holger 291
Schröder, Lutz 201
Schulz, Ewaryst 201
Shang, Yun 273
Shi, Hui 303
Steffen, Martin 72
Tarlecki, Andrzej
Lüth, Christoph 20
Lüttich, Klaus 22
Langenstein, Bruno 51
32
Werner, Mattias 13, 34
Wolff, Burkhart 314