Lavagno / Martin / Selic UML for Real

Design of Embedded Real-Time Systems
1. Auflage 2007
ISBN: 978-0-306-48738-5
Verlag: Springer US
Format: PDF
Kopierschutz: 1 - PDF Watermark

E-Book, Englisch, 383 Seiten

The Unified Modeling Language is rapidly gaining acceptance as the mechanism of choice to model complex software systems at various steps of their specification and design, using a number of orthogonal views that illustrate use cases, class diagrams and even detailed state machine-based behaviors of objects.

UML for Real: Design of Embedded Real-Time Systems aims to show the reality of UML as a medium for specification and implementation of real-time systems, illustrating both the current capabilities and limits of UML for this task, and future directions that will improve its usefulness for real-time and embedded product design. It will also cover selected applications examples. The book is an edited volume of solicited chapters.

The table of contents covers:

-UML and the Real-time/Embedded Domain, with chapters on the role of UML in software development and on UML and Real-Time Systems.

-Representing Key Real-Time Concepts with UML, with chapters on logical structure, on modeling system-level behavior using MSCs and extensions, on platform modeling, on hardware and software object modeling, on fine-grain and high-level patterns for real-time systems, on modeling Quality Of Service and metric time, and finally on performance and schedulability analysis using UML.

-Specific Applications, with chapters on UML in the automotive and telecom domains.
-Process and Tools, with chapters on software performance engineering and on UML tools for real-time processes.

Autoren/Hrsg.

Lavagno, Luciano

Martin, Grant

Selic, Bran

Selic, Bran V.

Inhaltsverzeichnis

1;Contents;5
2;About the Editors;7
3;Acknowledgements;9
4;Preface;11
5;Chapter 1 Models, Software Models and UML;14
5.1;1. ON MODELS;14
5.1.1;1.1 The Role of Models in Engineering;14
5.1.2;1.2 Characteristics of Good Engineering Models;16
5.1.3;1.3 Models of Software;16
5.2;2. THE UNIFIED MODELING LANGUAGE;21
5.2.1;2.1 Customizing UML;23
5.2.2;2.2 UML Profiles;26
5.3;3. SUMMARY;27
5.4;REFERENCES;28
6;Chapter 2 UML for Real-Time;30
6.1;1. INTRODUCTION;30
6.2;2. QUALITATIVE REAL-TIME FEATURES;32
6.2.1;2.1 Concurrency Modeling;32
6.2.2;2.2 Communication Modeling;36
6.2.3;2.3 Behavior Modeling;41
6.3;3. QUANTITATIVE REAL-TIME FEATURES;52
6.3.1;3.1 RT modeling within state diagrams;52
6.3.2;3.2 RT modeling within sequence diagrams;54
6.3.3;3.3 UML Profile for Scheduling, Performance, and Time;55
6.4;4. FROM NOTATIONS TO DEVELOPMENT PLATFORMS: THE ACCORD/UML APPROACH;56
6.5;5. OMG PERSPECTIVES;61
6.6;REFERENCES;62
7;Chapter 3 Structural Modeling with UML 2.0;66
7.1;1. STRUCTURAL CONCEPTS OF UML 2.0 – THE ORIGINS;66
7.2;2. EXAMPLE – AN ACCESS CONTROL SYSTEM;68
7.2.1;2.1 Introducing the Example – Domain Statement;68
7.2.2;2.2 Domain Class Model;69
7.2.3;2.3 Behavior Modeling with Interactions (I);71
7.2.4;2.4 Modeling with Internal Structures;74
7.2.5;2.5 Behavior Modeling with Interactions (II) – Decomposition;76
7.2.6;2.6 Finalizing the Internal Structure;79
7.2.7;2.7 Behavioral Modeling with State machines;81
7.2.8;2.8 The Consistency of Interactions and State Machines;85
7.3;3. CONCLUSIONS;88
7.4;REFERENCES;88
8;Chapter 4 Message Sequence Charts;90
8.1;1. MSCS AND HMSCS;92
8.1.1;1.1 Basic MSCs;93
8.1.2;1.2 Regular collections of MSCs;94
8.1.3;1.3 High-level MSCs and message sequence graphs;96
8.1.4;1.4 Other work on MSCs;98
8.2;2. LIVE SEQUENCE CHARTS;99
8.2.1;2.1 The duality of possible and necessary;100
8.2.2;2.2 Control constructs;104
8.3;3. THE PLAY-IN/PLAY-OUT APPROACH;105
8.3.1;3.1 Playing in Behavior;106
8.3.2;3.2 Play-out;108
8.4;4. COMMUNICATING TRANSACTION PROCESSES;109
8.5;5. SOME EXTENSIONS;113
8.5.1;5.1 Object Features;113
8.5.2;5.2 Timing Constraints;115
8.6;REFERENCES;117
9;Chapter 5 UML and Platform-based Design;120
9.1;1. INTRODUCTION;120
9.1.1;1.1 Platform-based Design;121
9.1.2;1.2 UML and Embedded System Design;122
9.2;2. BACKGROUND;124
9.2.1;2.1 Related work;124
9.2.2;2.2 The Metropolis design environment;125
9.3;3. UML PLATFORM PROFILE;126
9.3.1;3.1 Modeling Platforms Using UML;126
9.3.2;3.2 Stereotypes;127
9.4;4. UML PLATFORM DESIGN METHODOLOGY;129
9.4.1;4.1 Design Problem Formulation;130
9.4.2;4.2 Functional Specification;131
9.4.3;4.3 Platform Specification;134
9.4.4;4.4 Communication Refinement;135
9.4.5;4.5 Mapping;137
9.5;5. CONCLUSIONS;139
9.6;REFERENCES;139
10;Chapter 6 UML for Hardware and Software Object Modeling;140
10.1;1. INTRODUCTION;140
10.2;2. EMBEDDED SYSTEM DEVELOPMENT METHODS;142
10.3;3. THE HASOC DESIGN LIFECYCLE;143
10.3.1;3.1 Product Concept;144
10.3.2;3.2 Uncommitted Modeling;145
10.3.3;3.3 Committed Modeling;146
10.3.4;3.4 System Integration;147
10.3.5;3.5 Platform Modeling;147
10.4;4. CASE STUDY: DIGITAL CAMERA;149
10.4.1;4.1 Uncommitted Model;150
10.4.2;4.2 Committed Modelling;152
10.4.3;4.3 System Integration;153
10.4.4;4.4 Platform Modelling;155
10.5;5. CONCLUSIONS AND FURTHER WORK;158
10.6;REFERENCES;159
11;Chapter 7 Fine Grained Patterns for Real-Time Systems;162
11.1;1. INTRODUCTION;162
11.1.1;1.1 What is a Design Pattern?;163
11.1.2;1.2 Basic Structure of Design Patterns;166
11.2;2. USING DESIGN PATTERNS IN DEVELOPMENT;169
11.2.1;2.1 Pattern Hatching – Locating the right patterns;169
11.2.2;2.2 Pattern Mining – Rolling your own patterns;171
11.2.3;2.3 Pattern Instantiation – Applying Patterns in your designs;172
11.3;3. CATEGORIES OF MECHANISTIC PATTERNS;173
11.3.1;3.1 Resource Management;174
11.3.2;3.2 Concurrency;175
11.3.3;3.3 Distribution;177
11.3.4;3.4 Safety and Reliability;178
11.3.5;3.5 Reuse and Software Quality Patterns;181
11.3.6;3.6 Reactive (behavioral) patterns;182
11.4;REFERENCES;183
12;Chapter 8 Architectural Patterns for Real-Time Systems;184
12.1;1. INTRODUCTION;184
12.2;2. THE BASIC STRUCTURAL MICRO-PATTERNS;185
12.2.1;2.1 The Peer-to-Peer Micro-Pattern;186
12.2.2;2.2 The Container Micro-Pattern;186
12.2.3;2.3 The Layering Micro-Pattern;189
12.3;3. THE VIRTUAL-MACHINE LAYERING PATTERN;189
12.4;4. THE RECURSIVE CONTROL PATTERN;195
12.5;5. SUMMARY;200
12.6;REFERENCES;200
13;Chapter 9 Modeling Quality of Service with UML;202
13.1;1. INTRODUCTION;202
13.2;2. REQUIREMENTS FOR THE REAL-TIME PROFILE;203
13.3;3. COMPONENTS OF THE REAL-TIME PROFILE;205
13.4;4. MODELING RESOURCES AND QOS;207
13.4.1;4.1 Resources;207
13.4.2;4.2 Analysis contexts;209
13.4.3;4.3 Categories of resources;211
13.5;5. MODELING TIME AND TIMING MECHANISMS;212
13.5.1;5.1 The model of time;212
13.5.2;5.2 Modeling timing mechanisms;214
13.6;6. MODELING PLATFORMS;215
13.7;7. SUMMARY;216
13.8;REFERENCES;217
14;Chapter 10 Modeling Metric Time;218
14.1;1. INTRODUCTION;218
14.2;2. PHILOSOPHICAL AND PHYSICAL TIME;221
14.2.1;2.1 Continuous and discrete time;222
14.3;3. METRIC TIME AS USED IN OMG PRODUCTS;223
14.3.1;3.1 Point versus interval semantics of time;225
14.4;4. TIMING ANALYSIS IN RT UML – THE USER PERSPECTIVE;226
14.4.1;4.1 Interaction-centered models of computation;227
14.4.2;4.2 Time modeling in interaction-centered model of computation – an example;228
14.5;5. CONCLUSIONS;230
14.6;REFERENCES;232
15;Chapter 11 Performance Analysis with UML;234
15.1;1. INTRODUCTION;234
15.2;2. DEFINING PERFORMANCE REQUIREMENTS AND MEASURES;237
15.3;3. INPUTS TO ANALYSIS: WORKLOAD PARAMETERS;239
15.3.1;3.1 Resource Annotations;239
15.3.2;3.2 Annotations for a Step on a Sequence Diagram;241
15.3.3;3.3 Annotations for Load Intensity and Path Probability;242
15.4;4. DEFINING A SCENARIO IN UML;242
15.4.1;4.1 Defining a Scenario by a Sequence Diagram;243
15.4.2;4.2 Defining a Scenario by an Activity Diagram;244
15.5;5. PERFORMANCE MODELING;245
15.5.1;5.1 Layered Queueing Model;247
15.5.2;5.2 LQN for the Building Security System;247
15.5.3;5.3 Analysis Results;249
15.6;6. CONCLUSIONS;252
15.7;REFERENCES;252
16;Chapter 12 Schedulability Analysis with UML;254
16.1;1. INTRODUCTION;254
16.1.1;1.1 The logical model;257
16.1.2;1.2 The physical architecture;259
16.2;2. INTRODUCTION TO SCHEDULABILITY ANALYSIS;261
16.2.1;2.1 Rate Monotonic Analysis;261
16.2.2;2.2 Shared resources and priority inversion;264
16.3;3. SCHEDULABILITY ANALYSIS OF OO DESIGNS USING RMA: TASK CENTRIC DESIGN;268
16.3.1;3.1 Single event synchronization;270
16.3.2;3.2 Multiple-event synchronization;271
16.4;4. EVENT CENTRIC DESIGN;272
16.4.1;4.1 Schedulability analysis approach;274
16.4.2;4.2 Single thread implementation;275
16.4.3;4.3 Multi-thread implementation: dynamic thread priorities;276
16.4.4;4.4 Multi-thread implementation: problems with static thread priorities;278
16.5;5. AUTOMATED SYNTHESIS;279
16.6;6. OTHER APPROACHES;279
16.7;7. CONCLUSIONS;280
16.8;REFERENCES;280
17;Chapter 13 Automotive UML;284
17.1;1. THE AUTOMOTIVE DOMAIN;284
17.1.1;1.1 Reconciling the Needs of Automotive Software Development with Model-Based Approaches;285
17.1.2;1.2 Automotive Specific Constraints;287
17.1.3;1.3 (Meta) Model-Based Development Processes;288
17.1.4;1.4 Structure of the Chapter;289
17.2;2. AML SURVEY;289
17.2.1;2.1 The AML History;290
17.2.2;2.2 AML Features in a Nutshell;290
17.2.3;2.3 Using AML for Automotive Systems Development;292
17.3;3. THE AML;293
17.3.1;3.1 Abstraction Levels;294
17.3.2;3.2 Definition of Metamodel Fragments;296
17.3.3;3.3 Use of the Metamodel;299
17.4;4. CASE STUDY;304
17.4.1;4.1 The Window Regulator System;304
17.4.2;4.2 Modeling;305
17.5;5. CONCLUSIONS;311
17.6;REFERENCES;311
18;Chapter 14 Specifying Telecommunications Systems with UML;314
18.1;1. ITU SERVICE DESCRIPTION METHODOLOGY;315
18.2;2. ITU SPECIFICATION LANGUAGES;318
18.3;3. ENTER UML;319
18.4;4. SPECIFYING SERVICE DESCRIPTIONS;320
18.5;5. THE UML TELECOM PROFILES;330
18.6;REFERENCES;334
19;Chapter 15 Leveraging UML to Deliver Correct Telecom Applications;336
19.1;1. VERIFICATION AND VALIDATION;337
19.1.1;1.1 A UML MSC Profile;338
19.1.2;1.2 MSC Pathologies;341
19.2;2. FEATURE ANALYSIS;343
19.2.1;2.1 Consistency and Completeness of Protocols;344
19.2.2;2.2 Example Verification;345
19.3;3. TEST CASE GENERATION;348
19.3.1;3.1 Semantic Model;349
19.3.2;3.2 Test Generation;350
19.3.3;3.3 Test Strategies;351
19.4;4. END-TO-END V&V;353
19.5;REFERENCES;355
20;Chapter 16 Software Performance Engineering;356
20.1;1. INTRODUCTION;356
20.2;2. OVERVIEW OF SOFTWARE PERFORMANCE ENGINEERING;358
20.3;3. THE SPE MODELING PROCESS;360
20.4;4. CASE STUDY;364
20.4.1;4.1 Overview;365
20.5;5. SUMMARY;377
20.6;REFERENCES;378
21;Index;380
22;More eBooks at www.ciando.com;0

Leseproben

Chapter 13 Automotive UML
A (Meta) Model-Based Approach for Systems Development

Reconciling the Needs of Automotive Software Development with Model-Based Approaches (p.272-273)

Along with the evolution of the complexity of automotive embedded systems, the development processes of car manufacturers have been redefined to large degree. In the very beginning, electronic functions were developed in isolated development teams at the manufacturer’s site. As long as these functions had to fulfill a truly isolated task, the corresponding development processes were localized, i.e. easy to control and to maintain. However, with the increasing number of functions and the increasing number of interactions resulting in complex communication protocols the integration task for these functions failed due to insufficient support provided by the actual local development process in use. As a result severe technical problems such as incorrect feature interactions and timing latencies emerged. This lead to the well known symptoms of the "software crisis": blown budgets, late delivery, and unfulfilled requirements.

To overcome these difficulties one has to take into account the specific needs of a distributed development of automotive systems leading to a truly delocalized development process. Accordingly, the obtained development artifacts have to be communicated properly across the different development teams on a regular basis in order to gain an understanding of mutual dependencies between subsystems. Unfortunately, most developed systems lack well defined documentation, so that typically just the source code of realized functions would be exchanged. However, this is not sufficient to achieve a deeper understanding of the system’s functionality. Abstract models that could help to constitute an improvement were hardly ever used.

The complexities of a distributed development scenario were reinforced when third party suppliers took over the development of parts and components. In addition to the evolving deficiencies during the integration of those components into existing systems, car manufacturers complained about a progressive lack of knowledge of their own systems.

About 15 years ago, model-based techniques [17] were employed with great expectations to overcome the recognized difficulties of current development processes. Whereas in "traditional" engineering disciplines such as electrical and mechanical engineering, model-based techniques, like CAD (Computer Aided Design), FEM (Finite Element Method), and hardware design tools were employed with enormous success, a discipline called "software engineering" was hardly established. Since then various tools supporting visual modeling languages, configuration management tools, requirements management tools, and test tools were brought in, but the great diversity of model-based techniques, their abstract nature, and the strict focus of these tools on usually just one aspect of the development process limited their success and effectiveness within the actual development environment. As a consequence, car manufacturers started expensive integration projects to realize a model-based approach with the goal to achieve a seamless development process technically supported by a tailored tool chain.

Step by step car manufacturers developed a new perception of their systems’ architectures [4]. Nowadays, the partitioning of the system’s architecture into different abstraction levels, introducing a domain specific terminology, concepts for the formation of variants, and the understanding of model-based configurations seem to be potential steps towards a successful deployment of model-based techniques. In order to achieve a comprehensive and tightly-bound model-based paradigm for the automotive domain, only a well defined so called "metamodel-based" approach can be successful (cf. Section 1.3).

The AML includes abovementioned issues of a rigorous metamodelbased approach to simultaneously cover all different aspects of the heterogeneous system development needs within the automotive domain by providing a common conceptual framework.