Real-Time UML Workshop for Embedded Systems -  Bruce Powel Douglass

Real-Time UML Workshop for Embedded Systems (eBook)

eBook Download: PDF | EPUB
2014 | 2. Auflage
576 Seiten
Elsevier Science (Verlag)
978-0-12-407830-7 (ISBN)
Systemvoraussetzungen
Systemvoraussetzungen
53,95 inkl. MwSt
  • Download sofort lieferbar
  • Zahlungsarten anzeigen

Written as a workbook with a set of guided exercises that teach by example, this book gives a practical, hands-on guide to using UML to design and implement embedded and real-time systems.


  • A review of the basics of UML and the Harmony process for embedded software development: two on-going case examples to teach the concepts, a small-scale traffic light control system and a large scale unmanned air vehicle show the applications of UML to the specification, analysis and design of embedded and real-time systems in general.
  • A building block approach: a series of progressive worked exercises with step-by-step explanations of the complete solution, clearly demonstrating how to convert concepts into actual designs.
  • A walk through of the phases of an incremental spiral process: posing the problems and the solutions for requirements analysis, object analysis, architectural design, mechanistic design, and detailed design.

Written as a workbook with a set of guided exercises that teach by example, this book gives a practical, hands-on guide to using UML to design and implement embedded and real-time systems. A review of the basics of UML and the Harmony process for embedded software development: two on-going case examples to teach the concepts, a small-scale traffic light control system and a large scale unmanned air vehicle show the applications of UML to the specification, analysis and design of embedded and real-time systems in general. A building block approach: a series of progressive worked exercises with step-by-step explanations of the complete solution, clearly demonstrating how to convert concepts into actual designs. A walk through of the phases of an incremental spiral process: posing the problems and the solutions for requirements analysis, object analysis, architectural design, mechanistic design, and detailed design.

Front Cover 1
Real-Time UML Workshop for Embedded Systems 4
Copyright 5
Dedication 6
Contents 8
Preface 14
Acknowledgements 18
About the Author 20
Chapter 1 - Introduction to UML 22
1.1 UML Basic Modeling Concepts 22
1.2 Structural Elements and Diagrams 25
1.3 Behavioral Elements and Diagrams 39
1.4 Use Case and Requirements Models 49
Chapter 2 - The Harmony Process 54
2.1 Introduction 54
2.2 The Harmony Development Process 55
2.3 The Systems Engineering Harmony Workflows in Detail 65
2.4 The Hand-off from Systems Engineering 67
2.5 The Software Workflows in Detail 71
Chapter 3 - Meeting Industry Standards 88
3.1 Overview 88
3.2 On the Importance of Being Standard 88
3.3 Architectural Framework Standards (I’m looking at you UPDM) 89
3.4 IEC 61508 93
3.5 DO-178B/C 97
3.6 IEC 62304 105
3.7 CMMI-DEV 105
References 109
Chapter 4 - Specifying Requirements 110
4.1 Overview 110
4.2 Representing Requirements in UML and SysML 111
4.3 Specification View: State Machines for Requirements Capture 122
References 130
Chapter 5 - Systems Architecture: Deployment and Subsystems Architecture 132
5.1 Overview 132
5.2 The Hand-off from Systems to Downstream Engineering 157
5.3 Looking Ahead 167
Chapter 6 - Dependability Architecture 170
6.1 Overview 170
6.2 A (Not-So) Quick Note about Design Patterns5 173
6.3 What is a Design Pattern? 176
Chapter 7 - High-Fidelity Modeling1 201
7.1 Overview 200
7.2 A Quick Note about Structured Design with UML 201
7.3 High-Fidelity Modeling Workflow 202
7.4 Key Strategies for Object Identification 203
Chapter 8 - Distribution Architecture 240
8.1 Overview 240
Chapter 9 - Concurrency and Resource Architecture 246
9.1 What is the Concurrency and Resource Architecture? 246
9.2 Harmony Concurrency and Resource Architecture Workflow 255
Chapter 10 - Collaboration and Detailed Design 264
10.1 Overview 264
10.2 Collaboration Design 265
10.3 Detailed Design 272
Chapter 11 - Specifying Requirements: Answers 298
11.1 Answer 4.1: Identifying Kinds of Requirements 298
11.2 Answer 4.2: Identifying Use Cases for the Roadrunner Traffic Light Control System 298
11.3 Answer 4.3: Mapping Requirements to Use Cases 301
11.4 Answer 4.4: Identifying Use Cases for the Coyote UAV System 302
11.5 Answer 4.5: Create a Requirements Table 304
11.6 Answer 4.6: Capturing Quality of Service Requirements 304
11.7 Answer 4.7: Operational View: Identifying Traffic Light Scenarios 305
11.8 Answer 4.8: Operational View: Coyote UAV Optical Surveillance Scenarios 312
11.9 Answer 4.9: Specification View: Use Case Descriptions 315
11.10 Answer 4.10: Simple State Machine Specification 316
11.11 Answer 4.11: Specification View: Capturing Complex Requirements 317
11.12 Answer 4.12: Operational to Specification View: Capturing Operational Contracts 326
References 333
Chapter 12 - Deployment and Subsystems Architecture: Answers 334
12.1 Answer 5.1: Organizing the Systems Model 334
12.2 Answer 5.2: Subsystem Identification 337
12.3 Answer 5.3: Mapping Operational Contracts into the Subsystem Architecture 344
12.4 Answer 5.4: Identifying Subsystem Use Cases 352
12.5 Answer 5.5: Creating the Shared Model 358
12.6 Answer 5.6: Initiating the Subsystem Model 361
Chapter 13 - Dependability Architecture: Answers 370
13.1 Answer 6.1: Safety Architecture 370
13.2 Answer 6.2: Reliability Architecture 381
13.3 Answer 6.3: Security Architecture 382
Chapter 14 - High-Fidelity Modeling: Answers 390
14.1 Answer 7.1: Apply Nouns and Causal Agents Strategies 390
14.2 Answer 7.2: Apply Services and Messages Strategies 403
14.3 Answer 7.3: Apply the Strategies with a Test-Driven Development Approach 406
Chapter 15 - Distribution Architecture: Answers 432
15.1 Answer 8.1: Roadrunner Distribution Architecture 432
15.2 Answer 8.2: Coyote UAV Distribution Architecture 432
Chapter 16 - Concurrency and Resource Architecture: Answers 440
16.1 Answer 9.1: Roadrunner Concurrency and Resource Architecture 440
16.2 Answer 9.2: Reconnaissance Concurrency and Resource Architecture 440
Chapter 17 - Collaboration and Detailed Design: Answers 444
17.1 Answer 10.1: Applying Collaboration Design Patterns: Part 1 444
17.2 Answer 10.2: Applying Collaboration Design Patterns: Part 2 445
17.3 Answer 10.3: Applying Detailed Design State Behavioral Patterns 450
17.4 Answer 10.4: Applying Detailed Design Idioms 455
Appendix A - The Roadrunner™ Intersection Controller System Specification 464
Overview 464
The Intersection Controller 464
Front Panel Display 472
Remote Communications 475
Power 475
Appendix B - The Coyote Unmanned Aerial Vehicle System (CUAVS) 476
Overview 476
Primary CUAV System Components 476
Detailed Requirements 479
Appendix C - UML Notational Summary 488
Index 512

Chapter 2

The Harmony Process


Abstract


This chapter describes the Harmony process. The Harmony process is an agile approach to systems and software development that is, requirements–centric, and architecture focused. Harmony exists at three timescales – project, iteration, and nancocycle–and contains best practices at each level. The process emphasizes model-based engineering of systems and software.

Keywords


Harmonyprocessrolework producttask (work)spiraliterationprototypemacrocyclemicrocycleworkflowPDRCDRsystem engineering workflowsystem engineering hand-offpre-iteration planningchange managementconfiguration managementquality assuranceauditreviewsystem functional analysisshared modelsoftware development workflowarchitectural viewsverificationvalidationincrement reviewparty
What You Will Learn
 The Harmony development process
 Why a process?
 Harmony process overview
 Key enabling technologies
 Process timescales
 Harmony process variants
 Harmony development iteration in detail
 Analysis
 Design
 Translation
 Verification and validation
 Party!

Introduction


A methodology consists of a language to specify elements and relations of interest and a process that tells the developer what parts of the language to use, how to use them, and when to use them. The Harmony process1 uses UML and variants as the language. This includes profiles such as the Systems Modeling Language (SysML) or the UML Profile for DoDAF and MODFAF (UPDM) for Department of Defense Architecture Framework models. The Harmony Process also specifies an integrated set of workflows to guide the developer so that they can use UML to its fullest advantage in developing robust, capable, and safe systems.
There is a very broad range of development processes in use today, from “We don’t need no stinking process” to very formal rigorous processes. This chapter begins the discussion with an overview of the two major variants of the Harmony process, and then gives detailed workflows for each of the phases in the process.
Beginning with the next chapter, problems will presented for you to work on. The set of problems is presented, roughly, in the order in which they appear when you follow the Harmony process. The order of these problems may vary from how they would appear to you if you follow a different process.

The Harmony Development Process


A process is an integrated set of workflows. Each workflow takes some aspect, typically a phase in the process, and elaborates what activities are necessary for the workers to accomplish, when and how they are going to accomplish it, and what work products they generate.
A good process provides guidance on an effective way to develop high-quality systems at a minimal cost. Far too many processes are either completely nonexistent or waste valuable developer time and resources doing the wrong things, such as generating reams of paperwork. A good process usually produces some paper work products, but only those that add value, and even then in a cost-effective manner.

Why a Process?


The basic reason why we, as software and system developers, should be concerned about and use a good process is to improve our lives and our products. Specifically, a good process
 Provides a project template to guide workers through the development and delivery of a product
 Improves product quality in terms of
 Decreased number of defects
 Lowered severity of defects
 Improved reusability
 Improved stability and maintainability
 Improves project predictability in terms of
 Total amount of effort
 Length of calendar time required for completion
 Communicates project information appropriate to different stakeholders in ways that they can use effectively
If you have a process that doesn’t achieve these goals, then you have a bad process and should think about changing it for the better. These goals can be achieved with a good process or they can be inhibited by a bad process.
So what’s a process? In Harmony, we define a process in the following way:
A process is the specification of sequenced set of activities performed by a collaborating set of worker roles resulting in a coherent set of project products, one of which is the desired system.
A process consists of worker roles, the “hats” worn by workers while doing various project activities. Each activity results in the creation or modification of one or more work products (also known as artifacts). For example, most processes have requirements capture (activity) somewhere early on before design occurs. This is performed by a requirements analyst (worker) acting as a software modeler (a worker role), and might result in a work product, such as a portion of the software model from which code will be generated. Figure 2.1 depicts these fundamental aspects and relations inherent in a development process.
The activities are the tasks that the worker does in performance of his or her duty. The activities are grouped together into workflows focused around a common thread, such as
 The work done in a development phase
 To achieve a specific goal
 To create a specific work product.
 The work done by a particular worker role
A process is normally organized into phases, which might be thought of as the largest-scale work activities. Each phase is specified with one more workflows. Each workflow is a sequenced set of activities – simple tasks performed by workers – with resulting work products. A common way to represent workflows is with UML activity diagrams. Another is to use a tool specifically designed to create and manage process content, such as Rational Method Composer2 (RMC), the approach that will be used here.
Work products are the things created or modified during activities. The singularly most important work product is the system being produced, but there are many others, such as the source code, the software model, the requirements specification, hazard analysis, safety analysis, test vectors, and so on. Generally speaking, every activity results in the creation or modification of at least one work product.
The Harmony process, described in more detail in the next section, is applicable to (and in current use in) projects of widely different scale. Harmony achieves this scalability in a couple of different ways. First, the process is viewed at multiple timescales – macro (project timescale), micro (iteration timescale), and nano (work item timescale). Smaller projects will give much more attention to the micro- and nanocycles, but as the projects grow in size, more attention is shifted to the macro scale to organize and orchestrate the entire development process. Secondly, a number of work products are optional and created during the process only as needed. Hazard analysis, for example, is only used for safety-critical applications. The subsystem architecture view, for another example, is only created when systems are large enough to profit from such decomposition. In fact, the Harmony process has two major variants: one, called the Full Harmony process, includes a detailed systems engineering process that precedes subsystem development, and another, called Harmony/ESW (Embedded SoftWare), focuses on software development only.
Despite its well-known problems, the waterfall lifecycle is still by far the most common way to schedule and manage projects, especially for embedded systems. Nevertheless, the most fundamental issue with the waterfall lifecycle is that defects introduced early in the process are not...

Erscheint lt. Verlag 5.2.2014
Sprache englisch
Themenwelt Informatik Weitere Themen Hardware
Technik Elektrotechnik / Energietechnik
Wirtschaft Volkswirtschaftslehre Mikroökonomie
ISBN-10 0-12-407830-3 / 0124078303
ISBN-13 978-0-12-407830-7 / 9780124078307
Haben Sie eine Frage zum Produkt?
PDFPDF (Adobe DRM)
Größe: 82,9 MB

Kopierschutz: Adobe-DRM
Adobe-DRM ist ein Kopierschutz, der das eBook vor Mißbrauch schützen soll. Dabei wird das eBook bereits beim Download auf Ihre persönliche Adobe-ID autorisiert. Lesen können Sie das eBook dann nur auf den Geräten, welche ebenfalls auf Ihre Adobe-ID registriert sind.
Details zum Adobe-DRM

Dateiformat: PDF (Portable Document Format)
Mit einem festen Seiten­layout eignet sich die PDF besonders für Fach­bücher mit Spalten, Tabellen und Abbild­ungen. Eine PDF kann auf fast allen Geräten ange­zeigt werden, ist aber für kleine Displays (Smart­phone, eReader) nur einge­schränkt geeignet.

Systemvoraussetzungen:
PC/Mac: Mit einem PC oder Mac können Sie dieses eBook lesen. Sie benötigen eine Adobe-ID und die Software Adobe Digital Editions (kostenlos). Von der Benutzung der OverDrive Media Console raten wir Ihnen ab. Erfahrungsgemäß treten hier gehäuft Probleme mit dem Adobe DRM auf.
eReader: Dieses eBook kann mit (fast) allen eBook-Readern gelesen werden. Mit dem amazon-Kindle ist es aber nicht kompatibel.
Smartphone/Tablet: Egal ob Apple oder Android, dieses eBook können Sie lesen. Sie benötigen eine Adobe-ID sowie eine kostenlose App.
Geräteliste und zusätzliche Hinweise

Buying eBooks from abroad
For tax law reasons we can sell eBooks just within Germany and Switzerland. Regrettably we cannot fulfill eBook-orders from other countries.

EPUBEPUB (Adobe DRM)
Größe: 38,0 MB

Kopierschutz: Adobe-DRM
Adobe-DRM ist ein Kopierschutz, der das eBook vor Mißbrauch schützen soll. Dabei wird das eBook bereits beim Download auf Ihre persönliche Adobe-ID autorisiert. Lesen können Sie das eBook dann nur auf den Geräten, welche ebenfalls auf Ihre Adobe-ID registriert sind.
Details zum Adobe-DRM

Dateiformat: EPUB (Electronic Publication)
EPUB ist ein offener Standard für eBooks und eignet sich besonders zur Darstellung von Belle­tristik und Sach­büchern. Der Fließ­text wird dynamisch an die Display- und Schrift­größe ange­passt. Auch für mobile Lese­geräte ist EPUB daher gut geeignet.

Systemvoraussetzungen:
PC/Mac: Mit einem PC oder Mac können Sie dieses eBook lesen. Sie benötigen eine Adobe-ID und die Software Adobe Digital Editions (kostenlos). Von der Benutzung der OverDrive Media Console raten wir Ihnen ab. Erfahrungsgemäß treten hier gehäuft Probleme mit dem Adobe DRM auf.
eReader: Dieses eBook kann mit (fast) allen eBook-Readern gelesen werden. Mit dem amazon-Kindle ist es aber nicht kompatibel.
Smartphone/Tablet: Egal ob Apple oder Android, dieses eBook können Sie lesen. Sie benötigen eine Adobe-ID sowie eine kostenlose App.
Geräteliste und zusätzliche Hinweise

Buying eBooks from abroad
For tax law reasons we can sell eBooks just within Germany and Switzerland. Regrettably we cannot fulfill eBook-orders from other countries.

Mehr entdecken
aus dem Bereich