Douglass Real-Time UML Workshop for Embedded Systems

2. Auflage 2014
ISBN: 978-0-12-407830-7
Verlag: Elsevier Science & Techn.
Format: EPUB
Kopierschutz: 6 - ePub Watermark

E-Book, Englisch, 576 Seiten

Reihe: Embedded Technology

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

Autoren/Hrsg.

Douglass, Bruce Powel

Inhaltsverzeichnis

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

Leseproben

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