Muutke küpsiste eelistusi

E-raamat: Fundamentals of Dependable Computing for Software Engineers

(University of Virginia, Charlottesville, USA)
Teised raamatud teemal:
  • Formaat - PDF+DRM
  • Hind: 67,59 €*
  • * hind on lõplik, st. muud allahindlused enam ei rakendu
  • Lisa ostukorvi
  • Lisa soovinimekirja
  • See e-raamat on mõeldud ainult isiklikuks kasutamiseks. E-raamatuid ei saa tagastada.
Teised raamatud teemal:

DRM piirangud

  • Kopeerimine (copy/paste):

    ei ole lubatud

  • Printimine:

    ei ole lubatud

  • Kasutamine:

    Digitaalõiguste kaitse (DRM)
    Kirjastus on väljastanud selle e-raamatu krüpteeritud kujul, mis tähendab, et selle lugemiseks peate installeerima spetsiaalse tarkvara. Samuti peate looma endale  Adobe ID Rohkem infot siin. E-raamatut saab lugeda 1 kasutaja ning alla laadida kuni 6'de seadmesse (kõik autoriseeritud sama Adobe ID-ga).

    Vajalik tarkvara
    Mobiilsetes seadmetes (telefon või tahvelarvuti) lugemiseks peate installeerima selle tasuta rakenduse: PocketBook Reader (iOS / Android)

    PC või Mac seadmes lugemiseks peate installima Adobe Digital Editionsi (Seeon tasuta rakendus spetsiaalselt e-raamatute lugemiseks. Seda ei tohi segamini ajada Adober Reader'iga, mis tõenäoliselt on juba teie arvutisse installeeritud )

    Seda e-raamatut ei saa lugeda Amazon Kindle's. 

Fundamentals of Dependable Computing for Software Engineers presents the essential elements of computer system dependability. The book describes a comprehensive dependability-engineering process and explains the roles of software and software engineers in computer system dependability.

Readers will learn:











Why dependability matters What it means for a system to be dependable How to build a dependable software system How to assess whether a software system is adequately dependable

The author focuses on the actions needed to reduce the rate of failure to an acceptable level, covering material essential for engineers developing systems with extreme consequences of failure, such as safety-critical systems, security-critical systems, and critical infrastructure systems. The text explores the systems engineering aspects of dependability and provides a framework for engineers to reason and make decisions about software and its dependability. It also offers a comprehensive approach to achieve software dependability and includes a bibliography of the most relevant literature.

Emphasizing the software engineering elements of dependability, this book helps software and computer engineers in fields requiring ultra-high levels of dependability, such as avionics, medical devices, automotive electronics, weapon systems, and advanced information systems, construct software systems that are dependable and within budget and time constraints.

Arvustused

The book is an important addition to ones bookshelf. it is insightful, close to faultless, and a wonderful reference. Read it from front to back and cite it in your proposals and professional and scholarly papers. This book can and should be taught as part of an undergraduate or graduate software engineering program. I wish it had been available when I was setting up a graduate software engineering program . Larry Bernstein, Computing Reviews, June 2012

This book takes full advantage of the extensive work that has been undertaken over many years on the creation of a rich set of system dependability concepts. John Knight makes excellent use of these concepts in producing a very well-argued and comprehensive account, aimed squarely at software engineers, of the variety of dependability issues they are likely to find in real systems and of the strategies that they should use to address these issues. Appropriately qualified students who study this book thoroughly and computer professionals seeking a greater understanding of the various dependability-related problems that they have encountered already in their careers should gain much from this book. I therefore take great pleasure in enthusiastically recommending it to both classes of reader. From the Foreword by Brian Randell, Newcastle University, UK

Foreword xiii
Preface xv
Chapter 1 Introduction
1(26)
1.1 The Elements of Dependability
1(4)
1.1.1 A Cautionary Tale
1(3)
1.1.2 Why Dependability?
4(1)
1.2 The Role of the Software Engineer
5(2)
1.3 Our Dependence on Computers
7(2)
1.4 Some Regrettable Failures
9(4)
1.4.1 The Ariane V
9(1)
1.4.2 Korean Air Flight 801
10(1)
1.4.3 The Mars Climate Orbiter
11(1)
1.4.4 The Mars Polar Lander
11(1)
1.4.5 Other Important Incidents
12(1)
1.4.6 How to Think about Failures
12(1)
1.5 Consequences of Failure
13(4)
1.5.1 Non-Obvious Consequences of Failure
13(1)
1.5.2 Unexpected Costs of Failure
14(1)
1.5.3 Categories of Consequences
15(1)
1.5.4 Determining the Consequences of Failure
16(1)
1.6 The Need for Dependability
17(1)
1.7 Systems and Their Dependability Requirements
18(4)
1.7.1 Critical Systems
18(2)
1.7.2 Systems That Help Build Systems
20(1)
1.7.3 Systems That Interact with Other Systems
21(1)
1.8 Where Do We Go from Here?
22(1)
1.9 Organization of This Book
23(4)
Exercises
25(2)
Chapter 2 Dependability Requirements
27(46)
2.1 Why We Need Dependability Requirements
27(1)
2.2 The Evolution of Dependability Concepts
28(2)
2.3 The Role of Terminology
30(1)
2.4 What Is a System?
31(3)
2.5 Requirements and Specification
34(1)
2.6 Failure
35(6)
2.6.1 The Notion of Service Failure
35(1)
2.6.2 Sources of Service Failure
36(2)
2.6.3 A Practical View of Requirements and Specification
38(1)
2.6.4 Viewpoints of Service Failure
39(1)
2.6.5 Informing the User about Failure
40(1)
2.7 Dependability and Its Attributes
41(14)
2.7.1 Reliability
43(1)
2.7.2 Availability
44(4)
2.7.3 Failure per Demand
48(1)
2.7.4 Safety
48(3)
2.7.5 Confidentiality
51(1)
2.7.6 Integrity
52(1)
2.7.7 Maintainability
53(1)
2.7.8 A Word about Security
53(1)
2.7.9 The Notion of Trust
54(1)
2.8 Systems, Software, and Dependability
55(3)
2.8.1 Computers Are neither Unsafe nor Insecure
55(1)
2.8.2 Why Application System Dependability?
55(1)
2.8.3 Application System Dependability and Computers
56(2)
2.9 Defining Dependability Requirements
58(7)
2.9.1 A First Example, an Automobile Cruise Control
60(1)
2.9.2 A Second Example, a Pacemaker
61(4)
2.10 As Low As is Reasonably Practicable ALARP
65(8)
2.10.1 The Need for ALARP
65(1)
2.10.2 The ALARP Concept
66(1)
2.10.3 ALARP Carrot Diagrams
67(2)
Exercises
69(4)
Chapter 3 Errors, Faults, and Hazards
73(30)
3.1 Errors
73(2)
3.2 The Complexity of Erroneous States
75(1)
3.3 Faults and Dependability
76(3)
3.3.1 Definition of Fault
76(2)
3.3.2 Identifying Faults
78(1)
3.3.3 Types of Fault
78(1)
3.3.4 Achieving Dependability
78(1)
3.4 The Manifestation of Faults
79(1)
3.5 Degradation Faults
80(4)
3.5.1 Degradation Fault Probabilities --- The "Bathtub" Curve
80(1)
3.5.2 An Example of Degradation Faults --- Hard Disks
81(3)
3.6 Design Faults
84(1)
3.7 Byzantine Faults
85(4)
3.7.1 The Concept
85(1)
3.7.2 An Example Byzantine Fault
86(2)
3.7.3 Nuances of Byzantine Faults
88(1)
3.8 Component Failure Semantics
89(2)
3.8.1 Disk Drive Example
89(1)
3.8.2 Achieving Predictable Failure Semantics
90(1)
3.8.3 Software Failure Semantics
90(1)
3.9 Fundamental Principle of Dependability
91(2)
3.9.1 Fault Avoidance
92(1)
3.9.2 Fault Elimination
92(1)
3.9.3 Fault Tolerance
92(1)
3.9.4 Fault Forecasting
93(1)
3.10 Anticipated Faults
93(1)
3.11 Hazards
94(3)
3.11.1 The Hazard Concept
94(1)
3.11.2 Hazard Identification
95(1)
3.11.3 Hazards and Faults
96(1)
3.12 Engineering Dependable Systems
97(6)
Exercises
100(3)
Chapter 4 Dependability Analysis
103(20)
4.1 Anticipating Faults
103(1)
4.2 Generalizing the Notion of Hazard
104(1)
4.3 Fault Tree Analysis
105(12)
4.3.1 Basic Concept of a Fault Tree
105(1)
4.3.2 Basic and Compound Events
106(2)
4.3.3 Inspection of Fault Trees
108(1)
4.3.4 Probabilistic Fault Tree Analysis
108(1)
4.3.5 Software and Fault Trees
109(2)
4.3.6 An Example Fault Tree
111(2)
4.3.7 Defense in Depth
113(3)
4.3.8 Other Applications of Fault Trees
116(1)
4.4 Failure Modes, Effects, and Criticality Analysis
117(2)
4.4.1 FMECA Concept
117(2)
4.5 Hazard and Operability Analysis
119(4)
4.5.1 The Concept of HazOp
119(1)
4.5.2 The Basic HazOp Process
120(1)
4.5.3 HazOp and Computer Systems
120(2)
Exercises
122(1)
Chapter 5 Dealing with Faults
123(24)
5.1 Faults and Their Treatment
123(1)
5.2 Fault Avoidance
124(2)
5.2.1 Degradation Faults
124(1)
5.2.2 Design Faults
125(1)
5.3 Fault Elimination
126(1)
5.3.1 Degradation Faults
126(1)
5.3.2 Design Faults
126(1)
5.4 Fault Tolerance
127(6)
5.4.1 Familiarity with Fault Tolerance
127(1)
5.4.2 Definitions
127(2)
5.4.3 Semantics of Fault Tolerance
129(1)
5.4.4 Phases of Fault Tolerance
130(1)
5.4.5 An Example Fault-Tolerant System
131(2)
5.5 Fault Forecasting
133(4)
5.5.1 Fault Forecasting Process
134(1)
5.5.2 The Operating Environment
134(1)
5.5.3 Degradation Faults
135(1)
5.5.4 Design Faults
135(2)
5.6 Applying the Four Approaches to Fault Treatment
137(1)
5.7 Dealing with Byzantine Faults
137(10)
5.7.1 The Byzantine Generals
138(1)
5.7.2 The Byzantine Generals and Computers
139(2)
5.7.3 The Impossibility Result
141(2)
5.7.4 Solutions to the Byzantine Generals Problem
143(2)
Exercises
145(2)
Chapter 6 Degradation Faults and Software
147(34)
6.1 Impact on Software
147(1)
6.2 Redundancy
148(5)
6.2.1 Redundancy and Replication
148(3)
6.2.2 Large vs. Small Component Redundancy
151(1)
6.2.3 Static vs. Dynamic Redundancy
152(1)
6.3 Redundant Architectures
153(15)
6.3.1 Dual Redundancy
155(3)
6.3.2 Switched Dual Redundancy
158(6)
6.3.3 N-Modular Redundancy
164(2)
6.3.4 Hybrid Redundancy
166(2)
6.4 Quantifying the Benefits of Redundancy
168(2)
6.4.1 Statistical Independence
168(1)
6.4.2 Dual-Redundant Architecture
169(1)
6.5 Distributed Systems and Fail-Stop Computers
170(11)
6.5.1 Distributed Systems
170(1)
6.5.2 Failure Semantics of Computers
171(1)
6.5.3 Exploiting Distributed Systems
172(1)
6.5.4 The Fail-Stop Concept
172(2)
6.5.5 Implementing Fail-Stop Computers
174(1)
6.5.6 Programming Fail-Stop Computers
175(3)
Exercises
178(3)
Chapter 7 Software Dependability
181(40)
7.1 Faults and the Software Lifecycle
181(5)
7.1.1 Software and Its Fragility
182(1)
7.1.2 Dealing with Software Faults
183(1)
7.1.3 The Software Lifecycle
184(1)
7.1.4 Verification and Validation
185(1)
7.2 Formal Techniques
186(4)
7.2.1 Analysis in Software Engineering
186(3)
7.2.2 Formal Specification
189(1)
7.2.3 Formal Verification
189(1)
7.2.4 The Terminology of Correctness
190(1)
7.3 Verification by Model Checking
190(3)
7.3.1 The Role of Model Checking
190(1)
7.3.2 Analyzing Models
191(1)
7.3.3 Using a Model Checker
192(1)
7.4 Correctness by Construction
193(1)
7.5 Approaches to Correctness by Construction
194(3)
7.6 Correctness by Construction --- Synthesis
197(4)
7.6.1 Generating Code from Formal Specifications
197(1)
7.6.2 The Advantages of Model-Based Development
198(1)
7.6.3 Examples of Model-Based Development Systems
199(1)
7.6.4 Mathworks Simulink®
200(1)
7.7 Correctness by Construction --- Refinement
201(2)
7.8 Software Fault Avoidance
203(4)
7.8.1 Rigorous Development Processes
204(1)
7.8.2 Appropriate Notations
205(1)
7.8.3 Comprehensive Standards for All Artifacts
206(1)
7.8.4 Support Tools
207(1)
7.8.5 Properly Trained Personnel
207(1)
7.8.6 Formal Techniques
207(1)
7.9 Software Fault Elimination
207(5)
7.9.1 Static Analysis
208(1)
7.9.2 Dynamic Analysis
209(1)
7.9.3 Eliminating a Fault --- Root-Cause Analysis
210(2)
7.10 Managing Software Fault Avoidance and Elimination
212(3)
7.10.1 Fault Freedom as Properties
212(3)
7.11 Misconceptions about Software Dependability
215(6)
Exercises
218(3)
Chapter 8 Software Fault Avoidance in Specification
221(36)
8.1 The Role of Specification
221(1)
8.2 Difficulties with Natural Languages
222(1)
8.3 Specification Difficulties
223(3)
8.3.1 Specification Defects
223(1)
8.3.2 Specification Evolution
224(2)
8.4 Formal Languages
226(8)
8.4.1 Formal Syntax and Semantics
226(2)
8.4.2 Benefits of Formal Languages
228(2)
8.4.3 Presentation of Formal Languages
230(1)
8.4.4 Types of Formal Languages
231(1)
8.4.5 Discrete Mathematics and Formal Specification
232(1)
8.4.6 The Before and After State
232(1)
8.4.7 A Simple Specification Example
233(1)
8.5 Model-Based Specification
234(3)
8.5.1 Using a Model-Based Specification
235(2)
8.6 The Declarative Language Z
237(7)
8.6.1 Sets
237(1)
8.6.2 Propositions and Predicates
238(2)
8.6.3 Quantifiers
240(1)
8.6.4 Cross Products
241(1)
8.6.5 Relations, Sequences, and Functions
241(1)
8.6.6 Schemas
242(1)
8.6.7 The Schema Calculus
243(1)
8.7 A Simple Example
244(1)
8.8 A Detailed Example
245(7)
8.8.1 Version 1 of the Example
247(1)
8.8.2 Version 2 of the Example
248(1)
8.8.3 Version 3 of the Example
248(3)
8.8.4 Version 4 of the Example
251(1)
8.9 Overview of Formal Specification Development
252(5)
Exercises
254(3)
Chapter 9 Software Fault Avoidance in Implementation
257(34)
9.1 Implementing Software
257(4)
9.1.1 Tool Support for Software Implementation
258(1)
9.1.2 Developing an Implementation
258(1)
9.1.3 What Goes Wrong with Software?
259(2)
9.2 Programming Languages
261(3)
9.2.1 The C Programming Language
262(2)
9.3 An Overview of Ada
264(6)
9.3.1 The Motivation for Ada
264(1)
9.3.2 Basic Features
265(3)
9.3.3 Packages
268(1)
9.3.4 Concurrent and Real-Time Programming
268(1)
9.3.5 Separate Compilation
269(1)
9.3.6 Exceptions
270(1)
9.4 Programming Standards
270(3)
9.4.1 Programming Standards and Programming Languages
270(2)
9.4.2 Programming Standards and Fault Avoidance
272(1)
9.5 Correctness by Construction --- SPARK
273(18)
9.5.1 The SPARK Development Concept
274(2)
9.5.2 The SPARK Ada Subset
276(2)
9.5.3 The SPARK Annotations
278(1)
9.5.4 Core Annotations
278(3)
9.5.5 Proof Annotations
281(2)
9.5.6 Loop Invariants
283(4)
9.5.7 The SPARK Tools
287(2)
Exercises
289(2)
Chapter 10 Software Fault Elimination
291(28)
10.1 Why Fault Elimination?
291(2)
10.2 Inspection
293(10)
10.2.1 Artifacts and Defects
293(2)
10.2.2 Fagan Inspections
295(3)
10.2.3 Active Reviews
298(1)
10.2.4 Phased Inspections
299(4)
10.3 Testing
303(16)
10.3.1 Exhaustive Testing
303(1)
10.3.2 The Role of Testing
304(1)
10.3.3 The Testing Process
305(2)
10.3.4 Software Form
307(1)
10.3.5 Output Checking
308(1)
10.3.6 Test Adequacy
309(2)
10.3.7 Modified Condition Decision Coverage
311(2)
10.3.8 Test Automation
313(1)
10.3.9 Real-Time Systems
314(3)
Exercises
317(2)
Chapter 11 Software Fault Tolerance
319(36)
11.1 Components Subject to Design Faults
319(2)
11.2 Issues with Design Fault Tolerance
321(5)
11.2.1 The Difficulty of Tolerating Design Faults
321(2)
11.2.2 Self-Healing Systems
323(1)
11.2.3 Error Detection
324(1)
11.2.4 Forward and Backward Error Recovery
324(2)
11.3 Software Replication
326(1)
11.4 Design Diversity
327(12)
11.4.1 N-Version Systems
328(3)
11.4.2 Recovery Blocks
331(2)
11.4.3 Conversations and Dialogs
333(1)
11.4.4 Measuring Design Diversity
334(1)
11.4.5 Comparison Checking
335(2)
11.4.6 The Consistent Comparison Problem
337(2)
11.5 Data Diversity
339(5)
11.5.1 Faults and Data
339(1)
11.5.2 A Special Case of Data Diversity
340(1)
11.5.3 Generalized Data Diversity
341(1)
11.5.4 Data Reexpression
342(1)
11.5.5 N-Copy Execution and Voting
343(1)
11.6 Targeted Fault Tolerance
344(11)
11.6.1 Safety Kernels
345(2)
11.6.2 Application Isolation
347(2)
11.6.3 Watchdog Timers
349(1)
11.6.4 Exceptions
349(2)
11.6.5 Execution Time Checking
351(2)
Exercises
353(2)
Chapter 12 Dependability Assessment
355(38)
12.1 Approaches to Assessment
355(2)
12.2 Quantitative Assessment
357(5)
12.2.1 The Basic Approach
357(2)
12.2.2 Life Testing
359(1)
12.2.3 Compositional Modeling
360(1)
12.2.4 Difficulties with Quantitative Assessment
361(1)
12.3 Prescriptive Standards
362(9)
12.3.1 The Goal of Prescriptive Standards
364(1)
12.3.2 Example Prescriptive Standard --- RTCA/DO-178B
364(5)
12.3.3 The Advantages of Prescriptive Standards
369(1)
12.3.4 The Disadvantages of Prescriptive Standards
370(1)
12.4 Rigorous Arguments
371(17)
12.4.1 The Concept of Argument
372(1)
12.4.2 Safety Cases
373(2)
12.4.3 Regulation Based on Safety Cases
375(1)
12.4.4 Building a Safety Case
376(1)
12.4.5 A Simple Example
377(3)
12.4.6 The Goal Structuring Notation
380(2)
12.4.7 Software and Arguments
382(3)
12.4.8 Types of Evidence
385(2)
12.4.9 Safety Case Patterns
387(1)
12.5 Applicability of Argumentation
388(5)
Exercises
391(2)
Bibliography 393(12)
Index 405
John Knight is a professor of computer science at the University of Virginia. Prior to joining the University of Virginia, he was with NASAs Langley Research Center. Dr. Knight has been a recipient of the Harlan D. Mills award from the IEEE Computer Society and the Distinguished Service award from ACMs Special Interest Group on Software Engineering (SIGSOFT). He is an editorial board member of the Empirical Software Engineering Journal and was editor of the IEEE Transactions on Software Engineering from January 2002 to December 2005.