Design and Validation Computer Protocols

Total Page:16

File Type:pdf, Size:1020Kb

Design and Validation Computer Protocols DESIGN AND VALIDATION OF COMPUTER PROTOCOLS Gerard J. Holzmann -----------, PRE NTI CE HALL SOFTWARE SERI ES www.spinroot.com DESIGN AND VALIDATION OF COMPUTER PROTOCOLS Gerard J. Holzmann Bell Laboratories Murray Hill, New Jersey 07974 PRENTICE-HALL Englewood Cliffs, New Jersey 07632 www.spinroot.com Prentice Hall Software Series Brian W. Kernighan, Advisor Copyright 1991 by Lucent Technologies, Bell Laboratories, Incorporated. This book is typeset in Times Roman by the author, using an Linotronic 200P phototypesetter and a DEC VAX 8550 running the 10th Edition of the UNIX operating system. DEC and VAX are trademarks of Digital Equipment Corporation. UNIX is a registered trademark of AT&T. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher. Printed in the United States of America 10 9 8 7 6 5 4 3 2 1 Prentice-Hall International (UK) Limited, London Prentice-Hall of Australia Pty. Limited, Sydney Prentice-Hall Canada Inc., Toronto Prentice-Hall Hispanoamericana, S.A., Mexico Prentice-Hall of India Private Limited, New Delhi Prentice-Hall of Japan, Inc., Tokyo Simon & Schuster Asia Pte. Ltd., Singapore Editora Prentice-Hall do Brasil, Ltda., Rio de Janeiro www.spinroot.com CONTENTS Foreword ix Preface xi Part I Ð Basics 1. Introduction 1.1 Early Beginnings 1 1.2 The First Networks 9 1.3 Protocols as Languages 12 1.4 Protocol Standardization 13 1.5 Summary 15 Exercises 16 Bibliographic Notes 16 2. Protocol Structure 2.1 Introduction 19 2.2 The Five Elements of a Protocol 21 2.3 An Example 22 2.4 Service and Environment 26 2.5 Vocabulary and Format 32 2.6 Procedure Rules 35 2.7 Structured Protocol Design 35 2.8 Ten Rules of Design 38 2.9 Summary 39 Exercises 39 Bibliographic Notes 40 3. Error Control 3.1 Introduction 43 3.2 Error Model 44 3.3 Types of Transmission Errors 46 3.4 Redundancy 46 3.5 Types of Codes 47 3.6 Parity Check 48 3.7 Error Correction 48 3.8 A Linear Block Code 52 3.9 Cyclic Redundancy Checks 56 www.spinroot.com 3.10 Arithmetic Checksum 63 3.11 Summary 64 Exercises 64 Bibliographic Notes 65 4. Flow Control 4.1 Introduction 66 4.2 Window Protocols 70 4.3 Sequence Numbers 74 4.4 Negative Acknowledgments 80 4.5 Congestion Avoidance 83 4.6 Summary 86 Exercises 87 Bibliographic Notes 88 Part II Ð Specification and Modeling 5. Validation Models 5.1 Introduction 90 5.2 Processes, Channels, Variables 91 5.3 Executability of Statements 91 5.4 Variables and Data Types 92 5.5 Process Types 93 5.6 Message Channels 96 5.7 Control Flow 100 5.8 Examples 102 5.9 Modeling Procedures and Recursion 104 5.10 Message Type Definitions 104 5.11 Modeling Timeouts 105 5.12 Lynch's Protocol Revisited 106 5.13 Summary 107 Exercises 108 Bibliographic Notes 109 6. Correctness Requirements 6.1 Introduction 111 6.2 Reasoning about Behavior 112 6.3 Assertions 114 6.4 System Invariants 115 6.5 Deadlocks 117 6.6 Bad Cycles 118 6.7 Temporal Claims 119 6.8 Summary 125 Exercises 126 Bibliographic Notes 127 7. Protocol Design 7.1 Introduction 128 www.spinroot.com 7.2 Service Specification 129 7.3 Assumptions about the Channel 130 7.4 Protocol Vocabulary 131 7.5 Messsage Format 133 7.6 Procedure Rules 140 7.7 Summary 160 Exercises 160 Bibliographic Notes 161 8. Finite State Machines 8.1 Introduction 162 8.2 Informal Description 162 8.3 Formal Description 169 8.4 Execution of Machines 170 8.5 Minimization of Machines 171 8.6 The Conformance Testing Problem 174 8.7 Combining Machines 175 8.8 Extended Finite State Machines 176 8.9 Generalization of Machines 178 8.10 Restricted Models 181 8.11 Summary 184 Exercises 185 Bibliographic Notes 185 Part III Ð Conformance Testing, Synthesis and Validation 9. Conformance Testing 9.1 Introduction 187 9.2 Functional Testing 188 9.3 Structural Testing 189 9.4 Deriving UIO Sequences 195 9.5 Modified Transition Tours 196 9.6 An Alternative Method 197 9.7 Summary 199 Exercises 200 Bibliographic Notes 200 10. Protocol Synthesis 10.1 Introduction 203 10.2 Protocol Derivation 203 10.3 Derivation Algorithm 208 10.4 Incremental Design 210 10.5 Place Synchronization 210 10.6 Summary 211 Exercises 212 Bibliographic Notes 212 11. Protocol Validation www.spinroot.com 11.1 Introduction 214 11.2 Manual Proof Method 214 11.3 Automated Validation Methods 218 11.4 The Supertrace Algorithm 226 11.5 Detecting Non-Progress Cycles 231 11.6 Detecting Acceptance Cycles 234 11.7 Checking Temporal Claims 235 11.8 Complexity Management 235 11.9 Boundedness of PROMELA Models 237 11.10 Summary 238 Exercises 239 Bibliographic Notes 240 Part IV Ð Design Tools 12. A Protocol Simulator 12.1 Introduction 243 12.2 SPIN Ð Overview 244 12.3 Expressions 245 12.4 Variables 255 12.5 Statements 265 12.6 Control Flow 275 12.7 Process and Message Types 282 12.8 Macro Expansion 292 12.9 SPIN Options 293 12.10 Summary 294 Exercises 295 Bibliographic Notes 296 13. A Protocol Validator 13.1 Introduction 297 13.2 Structure of the Validator 298 13.3 The Validation Kernel 299 13.4 The Transition Matrix 302 13.5 The Validator-Generator Code 303 13.6 Overview of the Code 306 13.7 Guided Simulation 308 13.8 Some Applications 310 13.9 Coverage in Supertrace Mode 315 13.10 Summary 316 Exercises 316 Bibliographic Notes 317 www.spinroot.com 14. Using the Validator 14.1 Introduction 318 14.2 An Optical Telegraph Protocol 318 14.3 Dekker's Algorithm 320 14.4 A Larger Validation 322 14.5 Flow Control Validation 325 14.6 Session Layer Validation 336 14.7 Summary 349 Exercises 349 Bibliographic Notes 349 Conclusion 351 References 352 Appendices A. Data Transmission 367 B. Flow Chart Language 380 C. PROMELA Language Report 383 D. SPIN Simulator Source 393 E. SPIN Validator Source 436 F. PROMELA File Transfer Protocol 528 Name Index 537 Subject Index 539 www.spinroot.com www.spinroot.com FOREWORD It is now ove r 15 years since the first, tentative efforts were made to assemble theories and tool s that cou ld help with the development of communications proto­ cols - the rules and procedures that control and manage the flow of information within computer networks. During the intervening years, a significant body of knowledge has been accumu­ lated that can be successfully applied to the various phases of protocol develop­ ment. There are now international standards for languages designed for the formal specification of the protocols upon which we will build our future computer net­ works. We have learne d that even the most carefully developed protocol specifications contain subtle errors unless they are subjected to a thorough error analysis. Much progress has been made in the deve lopment of automated tools to support this. There have also been significant advances in testing techniques that make it possible to build reliable heterogeneous network s using hardware and software from a wide spectrum of manufacturers and development organizations. We are fortunate that Gerard Holzmann has made the effo rt to write this book that summarizes much of what we know about designing protocols and documents his own considerable experience in the field.His book has four major sections. The first gives an introd uction to the problems that are enco untered during the develop­ ment of protocols and discusses the principles of protocol design. The historical examples used to introduce the subject are a delight. The second section discusses ways in which a protocol can be modeled and specified. The third explains how protocol models can be analyzed to determine their properties and evaluate their correctness. The final section presents protocol design tools which complement the material in the earlier sections of the book. This is an important section. Protocols have proved to be extreme ly difficult to understand without automated analysis tools. The serious student of the field will learn a great deal by using the tools presented here to build and analyze his own protocols. Colin H. West ix www.spinroot.com www.spinroot.com PREFACE Protocols are sets of rules that govern the interaction of concurrent processes in distri- buted systems. Protocol design is therefore closely related to a number of established fields, such as operating systems, computer networks, data transmission, and data communications. It is rarely singled out and studied as a discipline in its own right. Designing a logically consistent protocol that can be proven correct, however, is a challenging and often frustrating task. It can already be hard to convince ourselves of the validity of a sequentially executed program. In distributed systems we must rea- son about concurrently executed, interacting programs. Books about distributed systems, computer networks, or data communications often do no better than describe a set of standard solutions that have been accepted as correct by, for instance, large international organizations. They do not tell us why the solutions work, what problems they solve, or what pitfalls they avoid. This text is intended as a guide to protocol design and analysis, rather than as a guide to standards and formats. It discusses design issues instead of applications. Two issues, therefore, are beyond the scope of this text: network control (including routing, addressing, and congestion control) and implementation.
Recommended publications
  • Dash1.Gz.Pdf
    6DEI >ook M=I JOFAIAJ troff -ms -mpictures|lp -dstdout|ps2pdf En LK?E@= 5=nI >O JDA =KJDoH, KIEnC = LAnoLo 6DEnk2=@ : ! 6=>lAJ HKnnEnC JDA 'BHonJ oFAH=JEnC IOI­ JAm. 4An@AHA@: %--$ '.4ON6 'BHonJ.oHC 6DEI EI = MoHk oB BE?JEon. N=mAI, ?D=H=?JAHI, Fl=?AI =n@ En?E@AnJI AEJDAH =HA JDA FHo@K?J oB JDA =KJDoHߣI Em=CEn=JEon oH =HA KIA@ BE?JEJEoKIlO, =n@ =nO HAIAm>l=n?A Jo =?JK=l FAH­ IonI,lELEnCoH@A=@,>KIEnAIIAI,?omF=nEAI,ALAnJIoHlo?=lAIEIAnJEHAlO?oEn?E@AnJ=l. M16/++/2K>lE?,om=En 9FRONT FREQUENTLY QUESTIONED ANSWERS Those who can do, those who can’t write and those who can’t write make ezines. ߞ 5=FAMKllAn@AH ACHTUNG! 6DEI @o?KmAnJߣI 5647+674- ߞ =n@ IomA oB EJI 6-:6 ߞ EI Fl=CE=HEzA@ ߞ BHomJDAO2-N*5,.)3 ACHTUNG! 601515NO6)52)+- ACHTUNG! 1nBoHm=JEon FHoLE@A@ >O JDEI @o?KmAnJ m=O >A oKJ@=JA@ oH jKIJ Fl=En MHonC.7IAOoKH>H=En.NO4-.7N,5. _sl’s info is incorrect. ߞ =nJD_N i really hate the openbsd content in the fqa ߞ =EjK 0 − Introduction to Plan 9 .-9D=JEI2l=n'? ..-2l=n'EInoJ7N1: ...-2l=n'EInoJFl=n'FoHJ ... -2l=n'EInoJ1nBAHno .. -2l=n'EInoJ=FHo@K?J ..!-2l=n'EInoJBoHOoK . -9DO2l=n'? . .-9D=J@oFAoFlAlEkA=>oKJ2l=n'? . ..-9D=J@oOoKKIA2l=n'BoH? . -9D=J@oFAoFlAD=JA=>oKJ2l=n'? . .-9D=JEInoJEn2l=n' . .!-9DO@E@2l=n'ߣI?HA=JoHICELAKFon2l=n'? . ."-9D=JEIJDA@A=lMEJD2l=n'ߣIMAEH@lE?AnIA? . .".-4E?D=H@5J=llm=nD=JAIJDA2l=nNEnAlE?AnIA?EH?= .
    [Show full text]
  • Groov RIO User's Guide
    Form 2324 groov RIO USER’S GUIDE groov RIO USER’S GUIDE for GRV-R7-MM1001-10 GRV-R7-MM2001-10 Form 2324-210514 — May 2021 43044 Business Park Drive • Temecula • CA 92590-3614 Phone: 800-321-OPTO (6786) or 951-695-3000 Fax: 800-832-OPTO (6786) or 951-695-2712 www.opto22.com Product Support Services 800-TEK-OPTO (835-6786) or 951-695-3080 Fax: 951-695-3017 Email: [email protected] Web: support.opto22.com groov RIO User’s Guide Form 2324-210514 — May 2021 Copyright © 2020-2021 Opto 22. All rights reserved. Printed in the United States of America. The information in this manual has been checked carefully and is believed to be accurate; however, Opto 22 assumes no responsibility for possible inaccuracies or omissions. Specifications are subject to change without notice. Opto 22 warrants all of its products to be free from defects in material or workmanship for 30 months from the manufacturing date code. This warranty is limited to the original cost of the unit only and does not cover installation, labor, or any other contingent costs. Opto 22 I/O modules and solid-state relays with date codes of 1/96 or newer are guaranteed for life. This lifetime warranty excludes reed relay modules, groov and SNAP serial communication modules, SNAP PID modules, and modules that contain mechanical contacts or switches. Opto 22 does not warrant any product, components, or parts not manufactured by Opto 22; for these items, the warranty from the original manufacturer applies. Refer to Opto 22 form 1042 for complete warranty information.
    [Show full text]
  • The Alta Operating System
    THE ALTA OPERATING SYSTEM by Patrick Alexander Tullmann A thesis submitted to the faculty of The University of Utah in partial fulfillment of the requirements for the degree of Master of Science Department of Computer Science The University of Utah December 1999 Copyright c Patrick Alexander Tullmann 1999 All Rights Reserved THE UNIVERSITY OF UTAH GRADUATE SCHOOL SUPERVISORY COMMITTEE APPROVAL of a thesis submitted by Patrick Alexander Tullmann This thesis has been read by each member of the following supervisory committee and by majority vote has been found to be satisfactory. Chair: Frank J. Lepreau Wilson C. Hsieh John B. Carter THE UNIVERSITY OF UTAH GRADUATE SCHOOL FINAL READING APPROVAL To the Graduate Council of the University of Utah: I have read the thesis of Patrick Alexander Tullmann in its final form and have found that (1) its format, citations, and bibliographic style are consistent and acceptable; (2) its illustrative materials including figures, tables, and charts are in place; and (3) the final manuscript is satisfactory to the Supervisory Committee and is ready for submission to The Graduate School. Date Frank J. Lepreau Chair, Supervisory Committee Approved for the Major Department Robert R. Kessler Chair/Dean Approved for the Graduate Council David S. Chapman Dean of The Graduate School ABSTRACT Many modern systems, including web servers, database engines, and operating system kernels, are using language-based protection mechanisms to provide the safety and integrity traditionally supplied by hardware. As these language-based systems become used in more demanding situations, they are faced with the same problems that traditional operating systems have solved—namely shared resource management, process separation, and per-process resource accounting.
    [Show full text]
  • Rio: Design of a Concurrent Window System
    Rio: Design of a Concurrent Window System Rob Pike Computing Sciences Research Center Bell Labs Lucent Technologies [email protected] February 4, 2000 1 History Topic: the external and, particularly, internal design of Rio, the (new) Plan 9 window system. Descendant of 8½: Pike, Rob, ‘‘8½, the Plan 9 Window System’’, Proceedings of the Summer 1991 USENIX Conference, Nashville, 1991, pp. 257-265. 8½ originally written in C, using processes and hand-built coroutines based on setjmp and longjmp (an interesting exercise). For Brazil, rewritten from scratch in Alef in 1995, and converted to true threads and procs. Converted (in an afternoon) in 1999 to use the thread library. Historical note: although Alef was a fruitful language, it proved too difficult to maintain a variant language across multiple architectures, so we took what we learned from it and built the thread library for C. 2 Overall Design Window system provides three things beyond the obvious: System interface (to access underlying hardware) Program interface (to manipulate windows) User interface (mouse, keyboard, menus...) Then it must multiplex all these things in parallel for multiple clients. Rio is unusual among window systems (although not among Plan 9 services) because it is implemented as a file server. 3 9P: the Plan 9 File Server Protocol (Almost) Everything in Plan 9 is a file server or at least represented as one: Processes (for debugging) Environment variables Console Graphics Network ... Client attaches to a server. Client requests, server responds. Requests: Attach Walk, Open, Read, Write, Close, Create Remove, Stat Can be provided over any reliable channel: TCP/IP, pipe, ..
    [Show full text]
  • An Infinite-Pane, Zooming User Interface Window Manager and Survey of X Window Managers
    An Infinite-Pane, Zooming User Interface Window Manager and Survey of X Window Managers Submitted by Evan Bradley Computer Science To The Honors College Oakland University In partial fulfillment of the requirement to graduate from The Honors College Mentor: Serge Kruk, Professor of Mathematics Department of Mathematics and Statistics Oakland University (02/15/2018) Abstract: This thesis describes a zoomable user interface window manager for the X Window System that aims to provide mechanisms for easily managing a large number of windows. This is motivated in part by greatly increased memory capabilities provided to modern computers as well as the relative stagnation of window managers since the desktop metaphor was first implemented. To address this, a window manager was written that allows the user to zoom over an infinite plane, on which windows may be arbitrarily placed. Taking advantage of the properties emerging from this model, algorithms were written to manage the windows using their associated Euclidean coordinates. Furthermore, a menu system similar to those employed in Oberon and Acme was written to provide the user with the ability to exercise greater control over the window manager. To ensure that it is usable on standard systems for a typical user workflow, it was developed on the X Window System, despite the system’s shortcomings. While this is the first window manager developed for the X Window System with the synthesis of these features, it takes inspiration from other window managers, user interfaces, and HCI research. As such, a brief discussion on other research interfaces is included alongside a more extensive survey on X11 window managers, which provide a substantial source for contemporary window management research.
    [Show full text]
  • WHY SOME DEAD OSES STILL MATTER 5 Failed to Gain Widespread Adoption
    WITH ITS CURRENTLY UNCHALLENGED ubiquity, the Linux operating system has be - ANDREY MIRTCHOVSKI AND LATCHESAR IONKOV come the de facto standard research OS in academia. The consequent waning of gener - al systems research has been well docu - mented [2], with the number of alternative why some dead operating systems in existence that signifi - cantly depart from the UNIX model and OSes still matter that are actively in development rapidly ap - Andrey Mirtchovski has been a Plan 9 aficionado proaching zero. In this article we will discuss since, as an undergraduate student, he found Plan 9’s Third Release disks hidden in the waste bin of a uni - one such alternative operating system that versity server room. Since then he has devoted a sig - has refused to disappear completely, and we nificant amount of time to the system, because it simply gets things done with less code. will attempt to evaluate the features of that [email protected] OS that make it suitable as a vehicle in our Latchesar Ionkov is a Linux kernel developer responsi - research projects and as a research environ - ble in part for the 9p kernel module, which allows Lin - ux to speak Plan 9’s 9p protocol. Latchesar has been ment. instrumental in translating Plan 9’s ideas into main - line operating systems such as Linux. We describe and share our experience working [email protected] with the “Plan 9 from Bell Labs” operating system. This article will not attempt to compare the virtues of this OS with other, well-established systems. In - stead, we will examine the environment Plan 9 provides as it pertains to researchers in academia, graduate students, and even undergraduates taking their first steps in exploring the inner workings of their first operating system.
    [Show full text]
  • Process-Oriented Patterns for Concurrent Software Engineering
    PROCESS-ORIENTED PATTERNS FOR CONCURRENT SOFTWARE ENGINEERING A THESIS SUBMITTED TO THE UNIVERSITY OF KENT IN THE SUBJECT OF COMPUTER SCIENCE FOR THE DEGREE OF DOCTOR OF PHILOSOPHY. By Adam T. Sampson 2008 Abstract Concurrency is unavoidable in modern software development, owing to the increasing complexity of computer systems and the widespread use of parallel computer hard- ware. Conventional approaches to concurrency are fraught with danger: in particular, uncontrolled access to shared resources, poor scalability and the inability of the pro- grammer to reason about the correctness of a program. Process-oriented programming is a software design approach that offers solutions to many of these problems. A process-oriented program is constructed as a network of isolated, concurrent processes that interact only using synchronisation objects such as channels and barriers. Using techniques drawn from CSP and the p-calculus, de- sign rules can be constructed that enable the programmer to easily build systems with known safety properties. Since process-oriented programs expose by their nature a high degree of explicit concurrency, they can be efficiently distributed across multiple processors and clusters of machines. This thesis describes a pattern language for the engineering of process-oriented pro- grams. Design patterns describe reusable, adaptable solutions to common problems that may arise during the design and development of a system. A pattern language serves the dual purposes of documenting the proven design solutions developed by a community, and providing a common technical vocabulary. The patterns described in this thesis are drawn from a variety of existing process- oriented real-world applications, and have been used to construct new applications in fields such as embedded systems, multimedia processing, and complex systems simu- lation.
    [Show full text]
  • Concurrent Patterns: Parallels in System and Language Design
    concurrency and parallelism are usually discussed together, and they are jason dusek both important in reorganizing a program for execution on multiple cores or multiple concurrent patterns: computers. Parallelism asks, “How can we break a program up into independently exe- parallels in system cuting parts?” It is very much in the domain and language design of compiler writers and library providers, as the necessary program transformations are Jason Dusek is a systems architect with a self- tedious at best. Concurrency asks, “How can funded startup in the Bay Area. His technical independent programs share a value once interests include distributed computing, functional programming, and serialization. in a while?” It bedevils program designers at [email protected] every level—providers of parallelism tool- kits, operating systems designers, applica- tion programmers, system administrators providing distributed network services, and even folks just trying to sell a few books. sharing For programs to share a value, they may both pos- sess a copy or they may both possess a handle. If they both have a handle, that is cheapest and allows them to communicate most efficiently. For example, with file handles, two applications open- ing the same file are using less memory than two applications with one sending a copy to the other. They also communicate more quickly. However, handles can result in confusion and danger—for example, memmapped files. If two programs mem- map the same file, and the “receiver” is not careful to close it and reopen it at the right time, one can very likely crash the receiver by writing into the memmapped file.
    [Show full text]
  • RIO: Restful INTERFACE to ONTOLOGY by CHINMAY
    RIO: RESTful INTERFACE TO ONTOLOGY by CHINMAY KALE (Under the Direction of Krzysztof J. Kochut) ABSTRACT The vision of the Semantic Web is to transform the World Wide Web from a web of linked documents to a web of linked data. Using the RESTful style, Web applications can navigate among resources, discover new resources, modify them and perform other tasks. If we view an ontology as a set of triples forming a graph, it is similar in its organization to the World Wide Web. Hence, using a set of RESTful style services, we should be able to perform similar operations on an ontology. In this thesis, we present a design and a prototype implementation of RIO, a RESTful Interface to Ontologies. RIO provides a RESTful interface to manage, edit, and query OWL ontologies. RIO also provides a novel way of navigation within an ontology based on URIs representing ontology paths. In addition, RIO provides a unique way to execute SPARQL queries in a RESTful way. INDEX WORDS: RESTful Web Services, Ontologies, SPARQL Endpoints, Ontology Servers, And Semantic Web RIO: RESTful INTERFACE TO ONTOLOGY by CHINMAY KALE B.E. Computer Engineering, University of Pune, India, 2006 A Thesis Submitted to the Graduate Faculty of The University of Georgia in Partial Fulfillment of the Requirements for the Degree MASTER OF SCIENCE ATHENS, GEORGIA 2011 © 2011 CHINMAY KALE All Rights Reserved RIO: RESTful INTERFACE TO ONTOLOGY by CHINMAY KALE Major Professor: Krzysztof J. Kochut Committee: John A. Miller William York Electronic Version Approved: Maureen Grasso Dean of the Graduate School The University of Georgia December 2011 DEDICATION To my parents, brother and loved ones.
    [Show full text]
  • Model Transformation Languages with Modular Information Hiding the Karlsruhe Series on Software Design and Quality Volume 17
    The Karlsruhe Series on Software Design and Quality 17 Model Transformation Languages with Modular Information Hiding Andreas Rentschler Model Transformation Languages Model Transformation with Modular Information Hiding transformation module M export I1 import I2 { mapping A::m1():B { } Andreas Rentschler 17 Andreas Rentschler Model Transformation Languages with Modular Information Hiding The Karlsruhe Series on Software Design and Quality Volume 17 Chair Software Design and Quality Faculty of Computer Science Karlsruhe Institute of Technology and Software Engineering Division Research Center for Information Technology (FZI), Karlsruhe Editor: Prof. Dr. Ralf Reussner Model Transformation Languages with Modular Information Hiding von Andreas Rentschler Dissertation, Karlsruher Institut für Technologie (KIT) Fakultät für Informatik Tag der mündlichen Prüfung: 14. Januar 2015 Referenten: Prof. Dr. Ralf Reussner Prof. Dr. Bernhard Beckert Impressum Karlsruher Institut für Technologie (KIT) KIT Scientific Publishing Straße am Forum 2 D-76131 Karlsruhe KIT Scientific Publishing is a registered trademark of Karlsruhe Institute of Technology. Reprint using the book cover is not allowed. www.ksp.kit.edu This document – excluding the cover – is licensed under the Creative Commons Attribution-Share Alike 3.0 DE License (CC BY-SA 3.0 DE): http://creativecommons.org/licenses/by-sa/3.0/de/ The cover page is licensed under the Creative Commons Attribution-No Derivatives 3.0 DE License (CC BY-ND 3.0 DE): http://creativecommons.org/licenses/by-nd/3.0/de/ Print on Demand 2015 ISSN 1867-0067 ISBN 978-3-7315-0346-0 DOI: 10.5445/KSP/1000045910 Model Transformation Languages with Modular Information Hiding zur Erlangung des akademischen Grades eines Doktors der Ingenieurwissenschaften der Fakultät für Informatik des Karlsruher Instituts für Technologie genehmigte Dissertation von Andreas Rentschler aus Eberbach (Baden) Tag der mündlichen Prüfung: 14.
    [Show full text]
  • Dash1.Thinkaboutthefuture.Pdf
    6DEI >ook M=I JOFAIAJ troff -ms -mpictures|lp -dstdout|ps2pdf En LK?E@= 5=nI >O JDA =KJDoH, KIEnC = LAnoLo 6DEnk2=@ : ! 6=>lAJ HKnnEnC JDA 'BHonJ oFAH=JEnC IOI­ JAm. 4An@AHA@: $-- # '.4ON6 'BHonJ.oHC 6DEI EI = MoHk oB BE?JEon. N=mAI, ?D=H=?JAHI, Fl=?AI =n@ En?E@AnJI AEJDAH =HA JDA FHo@K?J oB JDA =KJDoHߣI Em=CEn=JEon oH =HA KIA@ BE?JEJEoKIlO, =n@ =nO HAIAm>l=n?A Jo =?JK=l FAH­ IonI,lELEnCoH@A=@,>KIEnAIIAI,?omF=nEAI,ALAnJIoHlo?=lAIEIAnJEHAlO?oEn?E@AnJ=l. M16/++/2K>lE?,om=En 9FRONT FREQUENTLY QUESTIONED ANSWERS Those who can do, those who can’t write and those who can’t write make ezines. ߞ 5=FAMKllAn@AH ACHTUNG! 6DEI @o?KmAnJߣI 5647+674- ߞ =n@ IomA oB EJI 6-:6 ߞ EI Fl=CE=HEzA@ ߞ BHomJDAO2-N*5,.)3 ACHTUNG! 601515NO6)52)+- ACHTUNG! 1nBoHm=JEon FHoLE@A@ >O JDEI @o?KmAnJ m=O >A oKJ@=JA@ oH jKIJ Fl=En MHonC.7IAOoKH>H=En.NO4-.7N,5. _sl’s info is incorrect. ߞ =nJD_N 0 − Introduction to Plan 9 .-9D=JEI2l=n'? ..-2l=n'EInoJ7N1: ...-2l=n'EInoJFl=n'FoHJ ... -2l=n'EInoJ1nBAHno .. -2l=n'EInoJ=FHo@K?J ..!-2l=n'EInoJBoHOoK . -9DO2l=n'? . .-9D=J@oFAoFlAlEkA=>oKJ2l=n'? . ..-9D=J@oOoKKIA2l=n'BoH? . -9D=J@oFAoFlAD=JA=>oKJ2l=n'? . .-9D=JEInoJEn2l=n' . .!-9DO@E@2l=n'ߣI?HA=JoHICELAKFon2l=n'? . ."-9D=JEIJDA@A=lMEJD2l=n'ߣIMAEH@lE?AnIA? . .".-4E?D=H@5J=llm=nD=JAIJDA2l=nNEnAlE?AnIA?EH?= . .". -6DAo@A4==@JD=JAIJDA2l=n'lE?AnIA?EH?= ! ! .
    [Show full text]
  • Pandora 1910
    t LXP5 P189 1910 WAKE nog* C THE LIBRARY OF THE UNIVERSITY OF GEORGIA PANDORA 1910 VOLUME XXIII. Published by the Students OF THE UNIVERSITY OF GEORGIA ATHENS, GEORGIA. b&IJ Hn tbe name of even? lov.al alumnus of tbe "University of (Beoraia since 1882 ano of tbe present stubent boov., tbe eottors of tbe 1910 Ipanbora lov­ ingly oebicate tbis volume to flUiss Sarab aoeline jfrierson, tban wbom tbe inniverstt^ bas never bao a more faitbful servant or one wbo bas won a warmer place in tbe hearts of all wbom sbe bas toucbeo. Cbttor* of <panbora Volume XXIII, 1910 EDITORS-IN-CHIEF : John Moore Walker, i A K II. Al>it Nix ART EDITOR: Hugh King Alien, 2 N ASSOCIATE EDITORS: Fred C. Alien. <l> A ( > H. 1'. White, K A Aubrey Matthews. I". 1'. L. Corbin C. Small. P K A Hughes Spalding. X * Eugene S. Taylor. K i O. Milledge Gresham, A T n Henry A. Newinan. X * D. Robert Cuminin<i. BUSINESS MANAGER: Romney L. Campbell. /> ,/ /) 2 1909-1910. SEPTEMBER 11.—Faculty meets. SEPTEMBER 1 3-16.—Entrance examinations. SEPTEMBER 15.—Recitations begin in all departments. NOVEMBER 25.—National Thanksgiving Day. DECEMBER 23.—Christmas Recess begins at noon. JANUARY 4.—Recitations begin for second term. Cotton school begins second session. JANUARY 19.—Birthday of Gen. Robert E. Lee. FEBRUARY 19.—One hundred and ninth anniversary of the Demosthen- ian Society. FEBRUARY 21.—Exercises in commemoration of the founding of the Demosthenian and Phi Kappa Literary Societies. FEBRUARY 22. — Washington's birthday; ninetieth anniversary of the founding of Phi Kappa.
    [Show full text]