Reis Information Technology

Selected Tutorials
1. Auflage 2006
ISBN: 978-1-4020-8159-0
Verlag: Springer
Format: PDF
Kopierschutz: 1 - PDF Watermark

E-Book, Englisch, Band 157, 339 Seiten

Reihe: IFIP Advances in Information and Communication Technology

This volume reports on several important and state-of-the-art topics in information technology, including: quality of service in information networks; risk-driven development of security-critical systems using umlsec; developing portable software; formal reasoning about systems, software and hardware using functionals, predicates and relations; the problematic of distributed systems supervision; software rejuvenation modeling and analysis; test and design-for-test of mixed-signal integrated circuits; web services; applications of multi-agent systems; discrete event simulation; human-centered automation.

"Information Technology: Selected Tutorials" comprises papers presented at the IFIP 18th World Computer Congress, which was held in August 2004 in Toulouse, France and sponsored by the International Federation for Information Processing (IFIP).

Autoren/Hrsg.

Reis, Ricardo

Inhaltsverzeichnis

1;Contents;6
2;Preface;8
3;Quality of Service in Information Networks;9
3.1;1. QUALITY OF SERVICE IN IP NETWORKS;9
3.2;2. RESOURCE ALLOCATION MECHANISMS IN ROUTERS;12
3.2.1;2.1 Classification of packets;12
3.2.2;2.2 Policing and marking;13
3.2.3;2.3 Management of queues;14
3.2.4;2.4 Scheduling;15
3.3;3. THE INTEGRATED SERVICES MODEL;16
3.4;4. THE DIFFERENTIATED SERVICES MODEL;18
3.5;5. INTEGRATED SERVICES OVER DIFFSERV NETWORKS;20
3.6;6. MULTIPROTOCOL LABEL SWITCHING;21
3.7;7. QUALITY OF SERVICE IN THIRD GENERATION WIRELESS NETWORKS;23
3.8;8. CONCLUSIONS;26
3.9;REFERENCES;27
4;Risk-Driven Development Of Security-Critical Systems Using UMLsec;29
4.1;1. Introduction;29
4.2;2. Related Work;30
4.3;3. Distributed System Security;31
4.4;4. UMLsec;32
4.5;5. Security evaluation of UML diagrams using formal semantics;34
4.5.1;5.1. Security analysis of UML diagrams;37
4.5.2;5.2. Important security properties;40
4.5.3;5.3. Tool support;42
4.6;6. Risk-Driven Development;42
4.6.1;6.1. IEC 61508;44
4.6.2;6.2. Model-based risk assessment: The CORAS approach;46
4.7;7. MBRA Development Process for Security-Critical Systems;47
4.8;8. Development of a AIBO-Lego Mindstorm Prototype Using the Approach;49
4.8.1;8.1. Concept and overall scope definition;50
4.8.2;8.2. Preliminary hazard analysis (PHA);51
4.8.3;8.3. Risk management and specification of security requirements;55
4.8.4;8.4. Design and implementation;56
4.8.5;8.5. Testing and security validation;58
4.9;9. Conclusion;58
4.10;Acknowledgments;59
4.11;References;60
5;Developing Portable Software;63
5.1;1. INTRODUCTION;63
5.2;2. THE WHAT AND WHY OF PORTABILITY;64
5.2.1;2.1 What is Portability?;64
5.2.2;2.2 Why should we Port?;65
5.2.3;2.3 Why shouldn’t we Port?;66
5.2.4;2.4 Levels of Porting;67
5.2.5;2.5 Portability Myths;67
5.3;3. INTERFACES AND MODELS;67
5.4;4. THE ROLE OF STANDARDS;70
5.5;5. STRATEGIES FOR PORTABILITY;72
5.5.1;5.1 Three Key Principles;72
5.5.1.1;5.1.1 Control the Interfaces;72
5.5.1.2;5.1.2 Isolate Dependencies;72
5.5.1.3;5.1.3 Think Portable;73
5.5.2;5.2 Classifying the Strategies;73
5.5.3;5.3 Three Types of Strategies;74
5.5.3.1;5.3.1 Standardize the Interface;74
5.5.3.2;5.3.2 Port the Other Side;74
5.5.3.3;5.3.3 Translate the Interface;75
5.5.4;5.4 Language Based Strategies;75
5.5.4.1;5.4.1 Standard Languages;76
5.5.4.2;5.4.2 Porting the Compiler;76
5.5.4.3;5.4.3 Language Translation;77
5.5.5;5.5 Library Strategies;77
5.5.5.1;5.5.1 Standard Libraries;78
5.5.5.2;5.5.2 Portable Libraries;79
5.5.5.3;5.5.3 Interface Translation;79
5.5.6;5.6 Operating System Strategies;79
5.5.6.1;5.6.1 Standard APIs;80
5.5.6.2;5.6.2 Porting the Operating System;81
5.5.6.3;5.6.3 Interface Translation;81
5.5.7;5.7 Architecture Strategies;82
5.5.7.1;5.7.1 Standard Architectures;82
5.5.7.2;5.7.2 Generic Architectures;83
5.5.7.3;5.7.3 Binary Translation;84
5.6;6. THE SOFTWARE DEVELOPMENT PROCESS;84
5.6.1;6.1.1 The Software Lifecycle;84
5.6.2;6.1.2 Specification;85
5.6.3;6.1.3 Design;86
5.6.4;6.1.4 Implementation;87
5.6.5;6.1.5 Testing and Debugging;87
5.6.6;6.1.6 Documentation;88
5.6.7;6.1.7 Maintenance;89
5.6.8;6.1.8 Measuring Success;89
5.7;7. OTHER ISSUES;90
5.7.1;7.1.1 Transportation and Data Portability;90
5.7.2;7.1.2 Cultural Adaptation;91
5.8;8. CONCLUSION;91
5.9;REFERENCES;92
6;Formal Reasoning About Systems, Software and Hardware Using Functionals, Predicates and Relations;93
6.1;Introduction: motivation and overview;94
6.2;1. Calculating with expressions and propositions;95
6.2.1;1.1 Expressions, substitution and equality;95
6.2.2;1.2 Pointwise and point-free styles of expression;96
6.2.3;1.3 Calculational proposition logic;99
6.2.4;1.4 Binary algebra and conditional expressions;101
6.3;2. Introduction to Generic Functionals;102
6.3.1;2.1 Sets, functions and predicates;102
6.3.2;2.2 Concrete generic functionals, first batch;104
6.4;3. Functional Predicate Calculus;106
6.4.1;3.1 Axioms and basic calculation rules;106
6.4.2;3.2 Expanding the toolkit of calculation rules;108
6.5;4. Generic Applications;110
6.5.1;4.1 Applications to functions and functionals;110
6.5.2;4.2 Calculating with relations;112
6.5.3;4.3 Induction principles;113
6.6;5. Applications in Computing;114
6.6.1;5.1 Calculating with data structures;114
6.6.2;5.2 Systems specification and implementation;115
6.6.3;5.3 Formal semantics and programming theories;117
6.7;6. Applications in ncontinuous mathematics;119
6.7.1;6.1 An example in mathematical analysis;119
6.7.2;6.2 An example about transform methods;119
6.8;7. Some final notes on the Funmath formalism;120
6.9;References;121
7;The Problematic of Distributed Systems Supervision – An Example: Genesys;123
7.1;1. INTRODUCTION;123
7.2;2. STATE OF THE ART;125
7.2.1;2.1 Standards in Distributed Management;126
7.2.1.1;2.1.1 SMTP;126
7.2.1.2;2.1.2 JMX;128
7.2.1.3;2.1.3 Distributed Management Task Forces Standards;130
7.2.2;2.2 Supervision Frameworks;130
7.2.2.1;2.2.1 Tivoli (IBM) (http://www.tivoli.com);130
7.2.2.1.1;2.2.1.1 Overview;131
7.2.2.1.2;2.2.1.2 TME Management Services;132
7.2.2.1.3;2.2.1.3 Communications and networks;133
7.2.2.2;2.2.2 Unicenter (Computer Associates) (http://www.cai.com);134
7.2.2.2.1;2.2.2.1 Unicenter architecture;134
7.2.2.2.2;2.2.2.2 Unicenter TNG’s distributed management approach;135
7.2.2.2.3;2.2.2.3 Unicenter TNG agent technology and integration;136
7.2.2.2.4;2.2.2.4 Unicenter TNG’s Agent Factory environment;137
7.2.2.3;2.2.3 Openview (HP) (http://www.hp.com);137
7.2.2.3.1;2.2.3.1 Overview;137
7.2.2.3.2;2.2.3.2 ITO functioning;138
7.2.2.3.3;2.2.3.3 ITO architecture;139
7.2.2.3.4;2.2.3.4 Integration of applications into ITO;139
7.2.2.4;2.2.4 Other frameworks;140
7.2.3;2.3 Related Projects;140
7.2.4;2.4 Intelligent Supervision;141
7.2.4.1;2.4.1 Case Database Approach;142
7.2.4.2;2.4.2 Topology Analysis;142
7.2.4.3;2.4.3 Prediction Systems;143
7.3;3. INTRODUCTION TO GENESYS;143
7.3.1;3.1 What is GeneSyS ?;143
7.3.2;3.2 Contexts;143
7.3.2.1;3.2.1 Preliminary Design Review;144
7.3.2.2;3.2.2 Distributed Training;145
7.3.2.3;3.2.3 Web-Servers Monitoring;146
7.3.3;3.3 Requirements;147
7.4;4. GENESYS FRAMEWORK;148
7.4.1;4.1 Constraints of Existing Solutions;148
7.4.2;4.2 Design Objectives;148
7.4.3;4.3 Web Technologies as a Platform for a Supervision Framework;149
7.4.4;4.4 Basic Components and Communication Model;152
7.4.5;4.5 Intelligence;153
7.5;5. APPLICABILITY RESULTS;154
7.5.1;5.1 Preliminary Design Review Scenario;154
7.5.2;5.2 Distributed Training Scenario;155
7.5.3;5.3 Web Servers Scenario;156
7.6;6. CONCLUSION;157
7.7;REFERENCIES;158
8;Software Rejuvenation - Modeling and Analysis;159
8.1;1. Introduction;159
8.2;2. Classification and Treatment of Software Faults;161
8.3;3. Analytic Models for Software Rejuvenation;164
8.4;4. Measurement Based Models for Software Rejuvenation;174
8.5;5. Implementation of a Software Rejuvenation Agent;185
8.6;6. Approaches and Methods of Software Rejuvenation;185
8.7;7. Conclusions;187
8.8;Notes;187
8.9;References;187
9;Test and Design-for-Test of Mixed-Signal Integrated Circuits;191
9.1;1. INTRODUCTION;192
9.2;2. TEST METHODS;193
9.2.1;2.1 General background;193
9.2.2;2.2 Defects and fault models;195
9.2.3;2.3 Functional Test;197
9.2.4;2.4 Structural Test;199
9.2.4.1;2.4.1 Fault simulation;199
9.2.4.2;2.4.2 Test generation;201
9.3;3. DESIGN-FOR-TEST;202
9.3.1;3.1 Design-for-testability;203
9.3.2;3.2 Built-in self-test;206
9.3.2.1;3.2.1 Test generation and test compaction;207
9.3.2.2;3.2.2 Current testing;210
9.3.3;3.3 Self-checking circuits;211
9.3.4;3.4 Unified built-in self-test;213
9.4;4. CONCLUSIONS;215
9.5;5. REFERENCES;217
10;Web Services;221
10.1;1. INTRODUCTION;221
10.1.1;1.1 Characteristics of Web Services;222
10.1.2;1.2 Web Services Technologies;223
10.2;2. WEB SERVICES ARCHITECTURE;224
10.2.1;2.1 SOAP;225
10.2.1.1;2.1.1 SOAP Message Exchange;228
10.2.2;2.2 WSDL;229
10.2.2.1;2.2.1 WSDL Document Types;229
10.2.3;2.3 UDDI;231
10.2.3.1;2.3.1 Why UDDI?;232
10.2.3.2;2.3.2 UDDI Business Registry;232
10.3;3. TOWARDS SEMANTIC WEB SERVICES;233
10.3.1;3.1 Introduction;233
10.3.2;3.2 Web Services and their Complexity;234
10.3.3;3.3 Functionalities Required for Successful Web Services;235
10.3.4;3.4 Semantic Markup for Web Services;237
10.3.5;3.5 Services Composition;239
10.3.6;3.6 Web Services and Security;240
10.3.6.1;3.6.1 Typing and Pattern Matching;241
10.3.6.2;3.6.2 Trust in Web Services;242
10.4;4. CONCLUSION;242
10.5;References;243
11;Applications of Multi-Agent Systems;247
11.1;1. INTRODUCTION;247
11.2;2. MULTI-AGENT SYSTEMS;250
11.2.1;2.1 Agent architectures;252
11.2.2;2.2 Communication;254
11.2.3;2.3 Coordination;256
11.2.4;2.4 Negotiation;258
11.2.4.1;2.4.1 Distributive negotiation;258
11.2.4.2;2.4.2 Integrative negotiation;259
11.2.5;2.5 Learning;261
11.2.5.1;2.5.1 Reinforcement learning;261
11.2.5.2;2.5.2 Bayesian learning;262
11.2.5.3;2.5.3 Model-based learning;262
11.2.5.4;2.5.4 Nested representations;263
11.2.6;2.6 Methodologies for multi-agent system development;263
11.2.7;2.7 Multi-agent system development software;264
11.3;3. APPLICATIONS;266
11.3.1;3.1 Multi-agent systems infrastructures;266
11.3.1.1;3.1.1 RETSINA;266
11.3.1.2;3.1.2 SICS;267
11.3.2;3.2 Application areas;267
11.3.3;3.3 ARCHON’s electricity transportation management application;268
11.3.4;3.4 ADEPT business process management application;269
11.3.5;3.5 FACTS telecommunication service management;269
11.3.6;3.6 Challenger;269
11.3.7;3.7 Tele-MACS;270
11.3.8;3.8 TELE TRUCK;270
11.3.9;3.9 MetaMorphII;271
11.3.10;3.10 Fishmarket;271
11.3.11;3.13 MACIV;272
11.3.12;3.14 SMACE;272
11.3.13;3.15 COM_ELECTRON;272
11.3.14;3.16 VIRT_CONSTRUCT;273
11.4;4. CONCLUSION;274
12;Discrete Event Simulation with Applications to Computer Communication Systems Performance;279
12.1;1. FROM SYSTEM TO MODEL;280
12.2;2. CLASSIFICATION OF SIMULATION MODELS;283
12.3;3. CLASSIFICATION OF SIMULATION TOOLS;284
12.4;4. THE ROLE OF STATISTICS IN SIMULATION;285
12.4.1;4.1 Random Variate generation;285
12.4.2;4.2 Output Analysis;290
12.4.2.1;4.2.1 Point and Interval Estimates;291
12.4.2.2;4.2.2 Terminating vs. Steady State simulation;292
12.4.2.3;4.2.3 Initialization Bias;293
12.4.2.4;4.2.4 Dealing with Dependency [1];293
12.4.2.5;4.2.5 Method of Batch Means;295
12.4.2.6;4.2.6 Variance Reduction Techniques;295
12.5;5. SOME APPLICATIONS;296
12.5.1;5.1 OPNET MODELER;296
12.5.1.1;5.1.1 Construction of Model in OPNET MODELER [19];297
12.5.1.2;5.1.2 Example- Comparison of RED vs. FIFO with Tail-drop;300
12.5.2;5.2 ns-2 and NAM;305
12.5.2.1;5.2.1 Overview and Model construction in ns-2;305
12.5.2.2;5.2.2 Network Components (ns objects);305
12.5.2.3;5.2.3 Event Schedulers;306
12.5.2.4;5.2.4 Data collection and Execution;307
12.5.2.5;5.2.5 Network Animator;307
12.5.2.6;5.2.6 Example- RED Analysis;307
12.6;6. SUMMARY;309
12.7;REFERENCES;310
13;Human-Centered Automation: A Matter of Agent Design and Cognitive Function Allocation;313
13.1;1. INTRODUCTION;313
13.2;2. LESSONS LEARNED FROM AERONAUTICS;315
13.3;3. WHAT IS AN AGENT?;317
13.4;4. POSSIBLE AGENT-TO-AGENT INTERACTION;318
13.5;5. AN ECOLOGICAL APPROACH: LOOKING FOR MATURITY;321
13.5.1;5.1Hiding unnecessary complexity while promoting necessary operations;321
13.5.2;5.2 Affordance: The ultimate maturity of an artifact;322
13.5.3;5.3 Discovering affordances using active design documents;324
13.5.4;5.4 Human-centered design of artificial agents;325
13.5.5;5.5 Adapting Henderson’s design cycle to agents;326
13.6;6. AN EXAMPLE OF COGNITIVE FUNCTION ANALYSIS;327
13.6.1;6.1 Design case 1: Allocation of cognitive functions to User;328
13.6.2;6.2 Design case 2: Allocation of cognitive functions to User and Artifact;330
13.6.3;6.3 Design case 3: Allocation of cognitive functions to Artifact;331
13.6.4;6.4 Design case 4: Allocation of cognitive functions to Organizational Environment;332
13.7;7. INTERPRETATION VERSUS AMPLIFICATION;334
13.8;8. CONCLUSION AND PERSPECTIVES;336
13.9;9. ACKNOWLEDGMENTS;338
13.10;10. REFERENCES;338
14;More eBooks at www.ciando.com;0

Leseproben

5. Security evaluation of UML diagrams using formal semantics (p. 26- 27)

For some of the constraints used to define the UMLsec extensions we need to refer to a precisely defined semantics of behavioral aspects, because verifying whether they hold for a given UML model may be mathematically non-trivial. Firstly, the semantics is used to define these constraints in a mathematically precise way. Secondly, in ongoing work, we are developing mechanical tool support for analyzing UML specifications (for example in [Sha03; Men], and a few other student projects). For this, a precise definition of the meaning of the specifications is necessary, and it is useful to formulate this as a formal model for future reference before coding it up. For security analysis, the security-relevant information from the security-oriented stereotypes is then incorporated.

Note that because of the complexities of the UML, it would take up too much space to recall our formal semantics here completely. Instead, we just define precisely and explain the interfaces of the semantics that we need here to define the UMLsec profile. More details on the formal semantics can be found in [Jür03b]. Our formal semantics of a simplified fragment of UML using Abstract State Machines (ASMs) includes the following kinds of diagrams:

Class diagrams define the static class structure of the system: classes with attributes, operations, and signals and relationships between classes.
On the instance level, the corresponding diagrams are called object diagrams.

Statechart diagrams (or state diagrams) give the dynamic behavior of an individual object or component: events may cause a change in state or an execution of actions.

Sequence diagrams describe interaction between objects or system components via message exchange.

Activity diagrams specify the control flow between several components within the system, usually at a higher degree of abstraction than statecharts and sequence diagrams. They can be used to put objects or components in the context of overall system behavior or to explain use cases in more detail.

Deployment diagrams describe the physical layer on which the system is to be implemented.

Subsystems (a certain kind of packages) integrate the information between the different kinds of diagrams and between different parts of the system specification.

There is another kind of diagrams, the use case diagrams, which describe typical interactions between a user and a computer system. They are often used in an informal way for negotiation with a customer before a system is designed. We will not use it in the following. Additionally to sequence diagrams, there are collaboration diagrams, which present similar information. Also, there are component diagrams, presenting part of the information contained in deployment diagrams.

The used fragment of UML is simplified significantly to keep a formal treatment that is necessary for some of the more subtle security requirements feasible and to allow model-checking of UML specifications. Note also that in our approach we identify system objects with UML objects, which is suitable for our purposes. Also, as with practical all analysis methods, also in the real-time setting [Wat02], we are mainly concerned with instance-based models.

Although simplified, our choice of a subset of UML is reasonable for our needs, as we have demonstrated in several industrial case-studies (some of which are documented in [Jür03b]).