Chris A. Vissers
•Luís Ferreira Pires
Dick A.C. Quartel
•Marten van Sinderen
Architectural Design
Conception and Specification
of Interactive Systems
Chris A. Vissers University of Twente Enschede
The Netherlands Luís Ferreira Pires University of Twente Enschede
The Netherlands
Dick A.C. Quartel BiZZdesign Enschede The Netherlands Marten van Sinderen University of Twente Enschede
The Netherlands
ISBN 978-3-319-43297-7 ISBN 978-3-319-43298-4 (eBook) DOI 10.1007/978-3-319-43298-4
Library of Congress Control Number: 2016947019 © Springer International Publishing Switzerland 2016
This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use.
The publisher, the authors and the editors are safe to assume that the advice and information in this book are believed to be true and accurate at the date of publication. Neither the publisher nor the authors or the editors give a warranty, express or implied, with respect to the material contained herein or for any errors or omissions that may have been made.
Printed on acid-free paper
This Springer imprint is published by Springer Nature
Preface
This book is entitled Architectural Design—Conception and Specification of Interactive Systems. What do we mean by this and what is the purpose of this book?
Architectural Design
By architectural design we mean the design of the functional behaviour of a system, and the design of the internal structure of the system as a composition of (high level) functional units. This means that this book introduces a design methodology that starts with and remains close to the requirements of the end users of the system. At this so-called architectural level, we are not yet concerned with detailing and defining the low-level mechanisms that implement and perform this functional behaviour, which should happen in later design steps. However, some general knowledge of the implementation level, which is often quite specific for various types of systems, may appear supportive for understanding this book. For ICT systems, for example, we consider the choice of detailed algorithms, software programs and hardware units as implementation concerns.
Amongst the target systems we aim at are ICT systems, such as large software systems and various process-oriented systems in business, production, organisa-tions and administraorganisa-tions.
Conception and Speci
fication
In our design methodology, we make a sharp distinction between the conception of a design and the specification of a design.
We consider the conception of a design as an intellectual process that takes place in the mind of designers in which a design is created as a composition of conceptual (functional) building blocks. If these building blocks are close to the intuitive understanding of the designers, they contribute positively to the insight in and overview of what is being conceived, and thus to the ability of these designers to master the design process. The availability of building blocks that can be effectively applied in the design of a broad range of possibly complex systems is of particular
interest for a methodology that focuses on the design of these systems. We call these conceptual functional building blocks as basic design concepts in this book and they form the basic constituent of our design methodology. The interaction concept and the causality relation concept are examples of basic design concepts. We consider the specification of a design as a human and machine interpretable representation of a conception and an inherent and indispensable complement to the design itself. The specification of a design plays four roles in our design methodology:
– As a window through which a designer can view a conception and get better grips on what is being conceived.
– As a communication means between the designer and the end user of a system, while discussing and possibly reformulating the user requirements for the system.
– As a communication means amongst designers and design groups, while refining a design in further design steps.
– As a basis for verification, correctness preserving transformations towards implementation and software tool development.
To perform its communication roles effectively, the specification language should posses ‘expressive power’. This means that designers should be able to express their basic design concepts directly and concisely in the language, so that these concepts can be unambiguously recognised. In contrast, the designer should not be forced to express a basic design concept by an unwieldy and relatively arbitrary composition of too elementary language elements, where neither the language elements nor their composition have a direct relationship to the basic design concept. Expressive power allows the hand-in-hand application of a con-ception and its specification in a seamless way. We consider the latter as essential in architectural design.
To properly perform all the above-mentioned roles, the specification language should have a concrete syntax and formal semantics, so that precision is guaranteed and ambiguity is excluded.
The specification language that we present in this book has been devised to allow the direct representation of our basic design concepts. In this way, we can focus on architectural design and we avoid language constructs that are only rel-evant at implementation level.
When using the term design, we generally mean the hand-in-hand conception and specification of a design.
Interactive Systems
A system that does not interact with its environment is quite useless and as such it should not be designed. In this respect, our use of the term Interactive in the title sounds like a tautology, since useful systems always interact.
Apart from considering systems in general, however, we have a special interest in the interactions between systems1 that, together, form a total system. Usually, when considering interactive systems, we are inclined tofirst focus on the systems as individual objects and only in second instance consider their interactions as additional phenomena. However, we also know from practice that mechanisms such as protocols and interfaces strongly influence the structure and functioning of a system in its totality. This raises several questions as follows:
– Which explicit functional goal do these interactions aim to achieve in the functioning of the system in its totality?
– How can this functional goal be recognised and designed?
– Can we use the design of this functional goal as a building block in the design of the system consisting of the interactive systems?
– What are the merits of designing a system this way?
Similar questions apply to the interactions, both at a high and low functional level, between the subsystems that are internal to a system and together form this system. Answers to these questions are highly relevant, since interacting systems and subsystems appear at very large scale in thefields of engineering, organisation and administration. In this book we discuss the Interaction System concept as a basic design concept that provides such answers.
We consider distributed systems as important representatives of interactive systems. Examples are business processes, production systems and ICT systems, such as the Internet and mobile phone systems.
Design Methodology
In this book we present a design methodology that is practically applicable to the architectural design of a broad range of systems in variousfields of discipline.
In thefirst instance, it enables the system architect to assist the user in choosing and defining appropriate functional requirements for the system in its totality, and specify them in their most precise, concise, surveyable and understandable way. In the sec-ond instance, it enables the designer to devise the internal structure of the system, i.e. as a composition of subsystems, in increasingly more detail, until a structure is obtained that can act as a prescription for the implementation of the system.
Our design methodology is based on design concepts with a basic and funda-mental nature that are not susceptible to ageing or fashion, proving long-lasting applicability. The concepts are independent of specific functions and technologies that can be chosen to eventually implement a concrete system. This implies that we do not focus on these choices nor advocate for them.
1Seen from the outside, a human being that interacts with a system acts just as another system. This
implies that HCI (Human Computer Interfacing or Human Computer Interaction) is implicitly covered by our approach, although it is not an explicit point of attention in this book.
To facilitate the understanding of our concepts and methods, we provide many tangible, appealing and easy-to-recognise examples from variousfields. We think that recognising and understanding these examples not only provides eye-opening insights, but is also fun. The examples can be often related to ICT problems, showing that we can often treat ICT and non-ICT problems with a coherent approach. In these examples, certain specific functional choices necessarily have to be made, but these choices are only meant for illustrative purposes.
Applicability of the Methodology
The main condition for the applicability of our methodology is that the target system can be properly represented with our concepts. This is particularly true for systems where the dynamic part of their behaviour, i.e. the mutual dependency and sequencing of discrete interactions, is dominant. Since this is the case for many types of systems, our methodology is applicable and has been effectively applied to a large variety of systems.
In the presentation of our methodology we spend marginal attention to methods where the represention by discrete values that are established in interactions, the ontological relationships between these values, the storage and retrieval of large volumes of such representations, the integrity of these representations, and the operations on them are the dominant factors. However, our methodology can in principle be linked to such methods.
The work is not applicable tofields where the design concepts cannot properly be represented by interactions, for example, when these concepts come close to low-level software and hardware engineering or the monitoring and control of continuous values.
Target Audience
The target audience of this book consists of professionals, practitioners, managers and administrators in industry and large organisations who are responsible for design, development, installation, testing, maintenance, extension, management, supervision and control of large and complex systems. We also aim at students in graduate courses who want to develop professional insights and skills in developing complex systems. For this purpose, we paid special attention to the didactics in the text. Earlier versions of this text have indeed been used as lecture notes in courses on services, protocols and interfaces presented at the University of Twente. This implies that the book can be used as a textbook in graduate courses.
Brief History
Our insights in design methodology came forward out of research in distributed (ICT or Telematics) systems in general. This research has been carried out at the University of Twente, the Netherlands, and was started back in 1967. Therefore, our methodology builds on a long tradition and rich history of original work. In 1992, the Telematics Institute (one of the four Dutch national top technological institutes) joined in this research.
Around 1992 we observed that contemporary techniques, such as the Formal Specification Methods (FMSs) CSS, CSP, SDL, Petri Nets and LOTOS too often forced a designer to conceive and specify a system by defining unwieldy compo-sitions of very elementary language primitives. Some of these techniques appear even averse from engineering practice, and they force a designer to think more in terms of a mathematical theory rather than providing a focus on practical design. This formed the background for our ambition to strive for more pragmatic, engineering-oriented and intuitively appealing design constructs with direct and high-design capabilities, yet without compromising precision and unambiguity. This work resulted in the design methodology presented in this book.
This research has led to several publications, of which we mention three Ph.D. theses in particular because theyfirst introduced the original insights, concepts and motivation for our design methodology: the Ph.D. thesis of Chris A. Vissers, ‘Interface, a dispersed Architecture’ (1977); the Ph.D. thesis of Luís Ferreira Pires, ‘Architectural Notes: a Framework for Distributed Systems Development’ (1994); and the Ph.D. thesis of Dick A.C. Quartel,‘Action relations, basic design concepts for behaviour modelling and refinement’ (1998).
Our research has also led to many contributions to international conferences, large-scale European projects, periodicals and standardisation committees.
Industrial Impact
The ideas and concepts presented in this book formed the inspiration and basis of two large language and software tool development projects: Testbed (1996–2001) and ArchiMate (2002–2004). Both projects were carried out by the Telematics Institute, Enschede, the Netherlands, and involved several universities and large organisations. The result of Testbed was a model-based test environment for the analysis, improvement and redesign of business processes in (large) organisations. This environment consisted of a process modelling language, called Amber, sup-ported with methods and techniques and an extensive toolset. A company called BiZZdesign was founded in 2001 as a spin-off of the Testbed project, and this company turned this environment into a successful product in the Business Process Management market, branded under the name BiZZdesigner. The main result of ArchiMate was a language for modelling the architecture of enterprises. An enterprise architecture typically describes (the relationships among) the products and services of an organisation, the business processes that realise these products and services, the software applications that support these processes, and the infrastructure on which these applications are deployed.
ArchiMate has become an international standard in 2009, and its development is fostered by the ArchiMate forum of The Open Group. Version 2.1 of the language was published in 2013. The language is now supported by many tool vendors, among which BiZZdesign, who was the first to offer a native and user-friendly implementation of a tools suite to support ArchiMate, called BiZZdesign Architect. This implementation supports various powerful analysis techniques in addition to modelling. With the products BiZZdesigner and BiZZdesign Architect, BiZZdesign has become a major player in the areas of Business Process Management and Enterprise Architecture, and now employs more than 100 people worldwide.
Reading Guidelines
The difficulty in reading this text may come mainly from the several concepts that at first sight may appear artificial, sophisticated and abstract. The precise definition we choose for these concepts may add another dimension to this difficulty. Abstraction and precision, however, are the indispensable attributes for understanding complex systems and precisely conceiving and representing them at a high functional level. Once understood, these concepts only appear as natural, self-evident and extremely powerful, because they can reflect directly, precisely and concisely what is con-sidered essential in the functional behaviour of a system, i.e. they emerge as eminent architectural concepts.
Chapters1and2present our global views on how to design systems and how to interpret terms and meta-concepts that are frequently used in design and design specification approaches. These chapters are introductory and informal in nature, and provide the general context in which the remaining chapters can be read.
Chapters3 through6 present most of our basic design concepts, and illustrate them with examples. Language notations are introduced along with the basic design concepts. These chapters are formal in nature and more difficult to read. After fully mastering the material of these chapters, the reader should be capable of designing an arbitrarily complex system, both as a totality and as a composition of subsystems.
Chapters 7 through 12 discuss the more intricate basic design concept of interaction system, which forms the core of many interactive systems by focusing on their common functional goal. These chapters are recommended to readers who have a particular interest in the design of protocols and interfaces for various systems. The chapters use the concepts introduced in Chaps.3through6. Examples are predominantly taken from ICT systems.
Chapter7 elaborates on the interaction system concept, leading to a particular view on the notion of service and protocol, where a protocol implements a service. A global design approach for interaction systems leads to the notions of separation of concerns and layered architectures. Some well-known instances of practical interaction systems are shown as examples.
Chapter8 presents a generally applicable method for structuring a service that allows to control its complexity. The method is based on the constraint oriented structuring method introduced in Chap.5.
Chapter10provides a generally applicable method for structuring a protocol that provides insight in the generally high complexity of a protocol and allows to control its design. The method builds further on Chap.8and on the notion of separation of concerns.
Chapters9 and11 are much more targeted to ICT systems engineering. They present concrete technical functions and their possible relationships that can be frequently encountered in concrete services and protocols. In particular, it shows how protocol functions can implement service functions.
Chapter 12discusses the concept of reference model as a structure of related services and protocols that together form a complex interaction system. By only specifying the key functions in these services and protocols, a reference model can be defined first and used later to organise the cooperation of different design teams to work concurrently to complete the design of an interaction system. The concept of reference model can mutatis mutandis be used for the design of complex systems in general.
Thefigure below shows the relationships between the chapters of this book.
Closing Remarks
For reasons of keeping this book coherent, accessible and feasible, we restrict ourselves to only presenting the basic technology-independent principles that underlie our design methodology. This implies that we refrain from entering into or amply referring to the overwhelming amount of contacts, publications, activities, projects, software tool productions and other developments that came forward out of, are inspired by, or are associated with our original work. We trust that these principles, once understood, contribute to essential and proper insights for a better control of the architectural design of systems.
Enschede, The Netherlands Chris A. Vissers April 2016 Luís Ferreira Pires Dick A.C. Quartel Marten van Sinderen
Contents
1 Systems and System Design. . . 1
1.1 What Are Systems? . . . 1
1.1.1 The External and the Internal Perspective on Systems . . . 2
1.1.2 Natural Versus Artificial Systems . . . 2
1.2 The External System Perspective. . . 3
1.3 The Internal System Perspective . . . 6
1.3.1 Uniqueness of Service Versus Diversity of Implementations . . . 9
1.4 System as a Top-Down Recursive Notion . . . 10
1.4.1 Recursion . . . 10
1.5 System Design and System Construction . . . 14
1.5.1 Levels of Decomposition and Composition . . . 16
1.5.2 Early Warnings . . . 17
1.5.3 Choosing Decomposition Levels . . . 21
1.6 What Are Distributed Systems? . . . 23
1.6.1 Logical and Physical Distribution . . . 23
1.6.2 Distributed Systems . . . 24
1.6.3 Examples of Distributed Systems. . . 25
1.7 Wrapping-up . . . 26
2 Design Models and Design Languages. . . 29
2.1 Design Model. . . 29 2.1.1 Alternative Models . . . 31 2.1.2 Model Requirements . . . 32 2.1.3 Purposes of Modelling . . . 32 2.2 Abstraction. . . 33 2.2.1 Equivalent Abstractions . . . 34
2.2.2 Viewpoints, Perspectives or Projections . . . 34
2.2.3 Abstraction and Refinement . . . 35
2.2.4 Abstraction Levels. . . 35
2.2.5 Common Properties . . . 36
2.2.6 Service as Common Property of Different Implementations . . . 37
2.3 Design Language . . . 37
2.3.1 A Property and Its Expression Are Different Notions . . . 38
2.3.2 Language Alternatives . . . 40
2.3.3 Natural and Artificial Languages . . . 40
2.4 Design Model and Design Language Relationship . . . 41
2.4.1 Design Concepts . . . 42
2.4.2 Broad Spectrum Elementary Design Concepts . . . 44
2.4.3 Language Elements for Design Concepts . . . 45
2.4.4 Characteristics of Design Languages . . . 46
2.4.5 Specification Versus Description . . . 48
2.5 System Design . . . 49
2.6 General Purpose Languages and UML . . . 50
3 Basic Design Concepts . . . 53
3.1 A System, Its Existence and Its Behaviour . . . 54
3.2 The Entity Concept . . . 55
3.2.1 Origins of These Concepts . . . 56
3.2.2 Entity: Identity and Identification . . . 57
3.2.3 Entity: The Graphical Language Expression . . . 57
3.2.4 Attributes of the Entity Concept . . . 58
3.3 The Interaction Point Concept . . . 58
3.3.1 Interaction Point: Identity and Identification . . . 61
3.3.2 Interaction Point: The Graphical Language Expression . . . 62
3.3.3 Attributes of the Interaction Point Concept . . . 63
3.4 The Interaction Concept . . . 63
3.4.1 Properties of the Interaction Concept . . . 65
3.4.2 Interaction: Identity and Identification . . . 68
3.4.3 Interaction: The Graphical Language Expression . . . . 69
3.4.4 Attributes of the Interaction Concept . . . 70
3.5 The Behaviour Concept . . . 77
3.5.1 Behaviour: Identity and Identification. . . 77
3.5.2 Behaviour: The Graphical Language Expression . . . . 78
3.5.3 Attributes Modelled by the Behaviour Concept . . . 78
3.5.4 Design Implications of the Behaviour Concept . . . 81
3.6 Assigning Behaviours to Entities. . . 82
3.7 Entity (De)Composition and Action Points . . . 83
3.7.1 The Action Point Concept . . . 84
3.7.2 Action Point: The Graphical Language Expression . . . 84
3.8 The Action Concept . . . 85
3.8.1 Action: Identity and Identification . . . 86
3.8.2 Action: The Graphical Language Expression. . . 87
3.8.3 Actions as Integrated Interactions . . . 88
3.9 Behaviour with Actions and Interactions . . . 89
3.10 Action Refinement . . . 89
3.11 Elements of an Architecture . . . 91
3.12 Basic and Composite Design Concepts . . . 92
4 Behaviour Modelling with Causally Related Actions. . . 93
4.1 The Causality Relation Concept . . . 93
4.1.1 Causality Relation Identification . . . 96
4.1.2 Causality Relation: Notation . . . 96
4.1.3 Probability and Uncertainty Attribute . . . 97
4.1.4 Semantics . . . 98
4.1.5 Attribute References . . . 99
4.1.6 Implementation Concerns . . . 99
4.2 Basic Causality Conditions. . . 100
4.2.1 Initial Condition and Initial Action . . . 100
4.2.2 Independent Conditions and Independent Actions . . . 102
4.2.3 Enabling . . . 103
4.2.4 Disabling . . . 105
4.2.5 Synchronisation. . . 108
4.3 Conjunction and Disjunction of Basic Causality Conditions . . . 110
4.3.1 Conjunction of Causality Conditions . . . 110
4.3.2 Disjunction of Causality Conditions . . . 113
4.3.3 Consistency . . . 119
4.3.4 Distributivity Laws . . . 121
4.4 Information, Time and Location Attributes . . . 122
4.4.1 Information Attribute . . . 123
4.4.2 Location Attribute . . . 128
4.4.3 Time Attribute . . . 129
4.4.4 Relating Different Attribute Types . . . 131
5 Behaviour Structuring. . . 135
5.1 Goals of Structuring . . . 135
5.2 How to Express Structure. . . 136
5.3 Two Structuring Possibilities . . . 137
5.4 Causality-Oriented Structuring . . . 138
5.4.1 Entries and Exits . . . 139
5.4.2 Parameterised Entries and Exits. . . 143
5.4.3 Behaviour Instantiation . . . 145
5.4.4 Recursive Behaviour Instantiation . . . 147
5.5 Constraint-Oriented Structuring . . . 148
5.5.1 Decomposition of Actions . . . 149
5.5.2 Alternative Decompositions . . . 150
5.5.3 Action Attribute Constraints . . . 151
5.5.4 Multiple Sub-behaviours. . . 152
5.5.5 Interaction Structure. . . 153
5.5.6 Relation with Entity Decomposition. . . 153
5.6 Combination of Causality-and Constraint-Oriented Structuring . . . 155
5.6.1 Behaviour Definition Template . . . 155
5.6.2 Example: Mail Ordering . . . 157
6 Interaction Refinement and Abstraction. . . 163
6.1 Concepts Applied . . . 164
6.2 Patterns of Interaction Refinement. . . 164
6.2.1 Interface Refinement . . . 164
6.2.2 Peer-Entity Introduction . . . 165
6.2.3 Intermediary Entity Introduction . . . 166
6.2.4 Interaction Distribution. . . 167
6.3 Conformance Assessment. . . 168
6.3.1 Causality Context of an Interaction . . . 168
6.3.2 Conformance Requirements . . . 169
6.3.3 Abstraction Method . . . 170
6.4 Example: Provider-Confirmed Message Passing . . . 172
6.4.1 Step 1 . . . 172
6.4.2 Step 2 . . . 173
6.4.3 Step 3 . . . 174
6.4.4 Step 4 . . . 175
6.5 Example: Unconfirmed Message Passing . . . 175
6.5.1 Step 1 . . . 176 6.5.2 Step 2 . . . 176 7 Interaction Systems. . . 179 7.1 Universe of Discourse . . . 180 7.2 Analytical Perspective . . . 182 7.2.1 Connectability. . . 182 7.2.2 Connectable Systems . . . 184
7.2.3 Connectable Protocol Functions. . . 186
7.2.4 Service of the Interaction System . . . 187
7.2.5 A-P Functions Border: A New Interaction System? . . . 188
7.2.6 Overview of the Analysis . . . 190
7.3 Syntactical Perspective. . . 190
7.3.1 Service Design . . . 191
7.3.2 Protocol Design . . . 193
7.3.3 Lower Level Service Design . . . 194
7.4 Definition of Interaction System . . . 198
7.5 Implementation Aspects . . . 199
7.5.1 Implementing Connectability. . . 199
7.6 Duality of System and Interaction System . . . 201
7.6.1 Designing the Service of (Interaction) Systems . . . 203
7.6.2 Recurrent Decomposition and Specification Preferences . . . 206
7.7 Service and Protocol Versus Interaction and Action. . . 206
7.8 Classes of Interaction Systems . . . 207
7.9 The Service Concept in Service-Oriented Architecture . . . 208
7.10 Examples . . . 210
7.10.1 Bolt and Nut. . . 210
7.10.2 Chess. . . 213
7.10.3 Airline Reservation System. . . 213
7.10.4 File System . . . 215
7.10.5 Message Transfer System . . . 218
8 Service Design . . . 221
8.1 Service Structuring . . . 221
8.1.1 Service Users . . . 223
8.1.2 Service Primitives . . . 225
8.1.3 Service Definition . . . 225
8.1.4 A Constraint-Oriented Service Structuring Principle. . . 228
8.1.5 Remote Interaction Function . . . 230
8.2 Refinement of LSIs and RIFs . . . 234
8.2.1 Quality Design Principles . . . 234
8.2.2 Service Elements . . . 236
8.3 Implementation Aspects of LSIs and RIFs . . . 238
8.4 Example: Data Transfer Service . . . 239
9 Service Elements. . . 241
9.1 Associations . . . 241
9.1.1 Data . . . 242
9.2 User Needs for Data Transfer . . . 243
9.2.1 Cost. . . 243
9.2.2 Time . . . 244
9.2.3 Reliability . . . 244
9.2.4 Other Needs . . . 245
9.2.5 User Needs Versus Provider Constraints. . . 246
9.2.6 Quality of Service . . . 246
9.3 Classification of Service Types . . . 246
9.3.1 Connectionless Services . . . 247
9.3.2 Connection-Oriented Service. . . 254
9.4 Service Element Types . . . 258
9.4.1 Formal Specification of the Connection-Oriented Service. . . 259
10 Protocol Design. . . 263
10.1 Protocol Structuring . . . 263
10.1.1 Protocol Entities and Lower Level Service . . . 264
10.1.2 Preserving the Service Structure in the Protocol . . . . 269
10.2 The Concept of Protocol Data Unit . . . 271
10.3 Protocol Elements . . . 273
10.4 Refined Protocol Entity Structure . . . 274
10.4.1 Upper Protocol Functions and a Lower Level Service . . . 274
10.4.2 Intermediate Level Service . . . 276
10.4.3 Lower Protocol Functions. . . 277
10.5 ILS and LLS Design . . . 281
10.6 Complexity of Protocol (Revisited) . . . 282
10.7 Examples . . . 284
10.7.1 Data Transfer Protocol . . . 284
10.7.2 Alternating Bit Protocol . . . 284
11 Protocol Elements. . . 287
11.1 Service and Protocol Elements . . . 287
11.1.1 Protocol Elements (Revisited) . . . 289
11.1.2 Association Control . . . 289
11.1.3 Addressing . . . 290
11.1.4 Data Transfer . . . 291
11.1.5 QoS, Time Performance . . . 295
11.1.6 QoS, Reliability . . . 298
11.1.7 Security and Protection . . . 299
11.1.8 Cost. . . 299
11.1.9 Iterative Protocol Design . . . 300
11.1.10 Protocol Implementation. . . 302
11.2 Example of Protocol Design: Delivery Confirmation . . . 303
11.2.1 Required Service . . . 303
11.2.2 Underlying Service . . . 305
11.2.3 Protocol Design . . . 307
11.2.4 Simplified Protocol Design . . . 317
12 Reference Models and Standard Interaction Systems . . . 321
12.1 Reference Model. . . 321
12.2 Standard Interaction System . . . 324
12.2.1 Adaptation Layer. . . 325
12.2.2 Recurrent Extension of the Layering Structure . . . 326
12.2.3 Incompletely Defined Functions . . . 327
12.3 Examples: The ISO-OSI Reference Model
and the Internet Protocol Suite . . . 327
12.4 Manipulation of Standard Interaction Systems. . . 330
12.4.1 Separation of Concerns Revisited . . . 331
Appendix: Work Lectures: Exercises with Answers. . . 333
References. . . 377
Index . . . 383
List of Definitions
Definition 1.1 System . . . 2
Definition 1.2 Environment of a system . . . 5
Definition 1.3 Service of a system. . . 5
Definition 1.4 Architecture . . . 7
Definition 1.5 Implementation. . . 7
Definition 1.6 Distributed system . . . 24
Definition 2.1 Model . . . 30
Definition 2.2 Abstraction . . . 33
Definition 2.3 Refinement . . . 35
Definition 2.4 Consecutive abstraction levels . . . 35
Definition 2.5 Language. . . 37
Definition 2.6 Natural language . . . 40
Definition 2.7 Artificial language . . . 41
Definition 2.8 Elementary design concept. . . 43
Definition 3.1 Entity . . . 55
Definition 3.2 Interaction point . . . 59
Definition 3.3 Information value constraint . . . 64
Definition 3.4 Interaction . . . 64
Definition 3.5 Interaction contribution . . . 67
Definition 3.6 Interaction attribute . . . 70
Definition 3.7 Behaviour of a system. . . 77
Definition 3.8 Action point. . . 84
Definition 3.9 Action. . . 85
Definition 4.1 Causality relation . . . 94
Definition 4.2 Execution . . . 98
Definition 4.3 Initial action. . . 100
Definition 4.4 Independence . . . 102
Definition 7.1 Connecting structure . . . 183
Definition 7.2 Connectability . . . 184
Definition 7.3 Connectable systems . . . 185
Definition 7.4 Protocol function . . . 186
Definition 7.5 Application function . . . 186
Definition 7.6 Protocol. . . 186
Definition 7.7 Interaction System Service . . . 188
Definition 7.8 Service primitive . . . 190
Definition 7.9 Interaction System . . . 198
Definition 8.1 SAP name . . . 224
Definition 8.2 SAP address . . . 224
Definition 12.1 Reference Model . . . 322
