Real-Time UML Workshop for Embedded Systems (eBook)

Bruce Powel Douglass (Autor)

eBook Download: PDF | EPUB

2014 | 2. Auflage
576 Seiten
Elsevier Science (Verlag)
978-0-12-407830-7 (ISBN)

Infos

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.

Embedded Software Methodologist. Triathlete. Systems engineer. Contributor to UML and SysML specifications. Writer. Black Belt. Neuroscientist. Classical guitarist. High school dropout. Bruce Powel Douglass, who has a doctorate in neurocybernetics from the USD Medical School, has over 35 years of experience developing safety-critical real-time applications in a variety of hard real-time environments. He is the author of over 5700 book pages from a number of technical books including Real-Time UML, Real-Time UML Workshop for Embedded Systems, Real-Time Design Patterns, Doing Hard Time, Real-Time Agility, and Design Patterns for Embedded Systems in C. He is the Chief Evangelist at IBM Rational, where he is a thought leader in the systems space and consulting with and mentors IBM customers all over the world. He can be followed on Twitter @BruceDouglass. Papers and presentations are available at his Real-Time UML Yahoo technical group (http://tech.groups.yahoo.com/group/RT-UML) and from his IBM thought leader page (www-01.ibm.com/software/rational/leadership/thought/brucedouglass.html).

Inhalt

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

Textauszug

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...

Produkt-Details

• Erscheint lt. Verlag: 5.2.2014
• Sprache: englisch
• Themenwelt: Informatik ► Weitere Themen ► Hardware
• Themenwelt: Technik ► Elektrotechnik / Energietechnik
• Themenwelt: Wirtschaft ► Volkswirtschaftslehre ► Mikroökonomie
• ISBN-10: 0-12-407830-3 / 0124078303
• ISBN-13: 978-0-12-407830-7 / 9780124078307