127,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
A guide to the application of the theory and practice of computing to develop and maintain software that economically solves real-world problem
How to Engineer Software is a practical, how-to guide that explores the concepts and techniques of model-based software engineering using the Unified Modeling Language. The author—a noted expert on the topic—demonstrates how software can be developed and maintained under a true engineering discipline. He describes the relevant software engineering practices that are grounded in Computer Science and Discrete Mathematics.
Model-based software engineering uses semantic modeling to reveal as many precise requirements as possible. This approach separates business complexities from technology complexities, and gives developers the most freedom in finding optimal designs and code. The book promotes development scalability through domain partitioning and subdomain partitioning. It also explores software documentation that specifically and intentionally adds value for development and maintenance. This important book:
- Contains many illustrative examples of model-based software engineering, from semantic model all the way to executable code
- Explains how to derive verification (acceptance) test cases from a semantic model
- Describes project estimation, along with alternative software development and maintenance processes
- Shows how to develop and maintain cost-effective software that solves real-world problems
Written for graduate and undergraduate students in software engineering and professionals in the field, How to Engineer Software offers an introduction to applying the theory of computing with practice and judgment in order to economically develop and maintain software.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 1568
Veröffentlichungsjahr: 2019
Ähnliche
Table of Contents
Cover
Foreword
Preface
Why This Book?
Who Is This Book for?
History of the Author and of This Approach
Acknowledgments
Online Resources
Part 1: Introduction and Foundations
1 Introduction
1.1 Mainstream Software Projects Perform Poorly
1.2 Problem #1: Vague, Ambiguous, Incomplete Requirements
1.3 Problem #2: Overdependence on Testing
1.4 Problem #3: “Self‐Documenting Code” Is a Myth
1.5 Why Agile Development Doesn't Solve These Problems
1.6 Truth in Advertising
1.7 Software Engineering
1.8 Overview of Model‐Based Software Engineering
1.9 Relation to Other Similar Approaches
1.10 An Overview of This Book
1.11 Summary
2 The Nature of Code
2.1 Syntax and Semantics in Natural Languages
2.2 Syntax and Semantics in Programming Languages
2.3 Design by Contract™ and Software Semantics
2.4 Liskov Substitutability and Software Semantics
2.5 The Importance of Semantics in Programming
2.6 Software Automates “Business”
2.7 Model‐Based Software Requirements
2.8 Semantic Models of Automation Technology
2.9 We're Finally Ready to Write Code
2.10 Code Is a Mapping
2.11 The Most Important Implication of “Code Is a Mapping”
2.12 Summary
3 Fundamental Principles
3.1 Focus on Semantics
3.2 Control Complexity
3.3 Use Appropriate Abstractions
3.4 Encapsulate Accidental Complexity
3.5 Maximize Cohesion and Minimize Coupling
3.6 Design to Invariants and Design for Change
3.7 Avoid Premature Design and Optimization
3.8 Name Things Carefully
3.9 Quality Criteria
3.10 Relationship to the SOLID Principles
3.11 Summary
4 Functional and Nonfunctional Requirements
4.1 What Is a Requirement?
4.2 Who Made the Decision?
4.3 Is It Really a Requirement?
4.4 An Example: Tic Tac Toe Smart Phone App
4.5 A Tinker Toy™ Computer That Plays Tic Tac Toe
4.6 Kinds of Requirements
4.7 Separating Functional and Nonfunctional Requirements
4.8 Why Separate Functional from Nonfunctional Requirements?
4.9 More on Nonfunctional Requirements
4.10 Quality Criteria
4.11 Summary
5 UML Overview
5.1 Object Management Group (OMG®)
5.2 Object‐Oriented Development and Unified Modeling Language (UML)
5.3 Dialects of UML
5.4 Generic UML Facilities
5.5 Diagrams vs. Models
5.6 More to UML
5.7 Summary
6 Partitioning Systems into Domains
6.1 What Is a Domain?
6.2 Identifying Domains
6.3 Domain Diagrams: Domains and Their Relationships
6.4 Reduced Models Versus Expanded Models
6.5 Quality Criteria
6.6 Implications of Domain Separation on Software Architecture
6.7 Implications of Domain Separation on Software Documentation
6.8 Domain Separation and the Fundamental Principles
6.9 Implications of Domain Separation on Organizational Structure
6.10 Summary
Part II: Semantic Modeling
7 Use Case Diagrams
7.1 On the Relative Unimportance of Use Case Diagramming
7.2 Actor
7.3 Use Case
7.4 “Participates In”
7.5 Levels of Use Cases to Manage Big Domains
7.6 Identifying Sea Level Event Use Cases Through Business Events
7.7 Business Events as Errors
7.8 Event Use Case Naming Conventions
7.9 Specifying Sea Level Event Use Cases
7.10 Sea Level Data Use Cases
7.11 Model Net Flow of Information
7.12 Use Cases Without Actor Participation
7.13 «include» Use Cases
7.14 «extend» Use Cases
7.15 Generalizing Use Cases
7.16 Generalizing Actors
7.17 Fundamental Versus Custodial (“CRUD”) Dynamics
7.18 WebBooks 2.0 Order fulfillment Use Cases
7.19 Quality Criteria
7.20 Economic Considerations
7.21 Describing Overall Workflow
7.22 Summary
8 Class Models
8.1 Class
8.2 Attribute
8.3 Specifying the Range of an Attribute
8.4 Key
8.5 Derived Attribute
8.6 Class and Attribute Normalization
8.7 Exceptions to Class and Attribute Normalization
8.8 Class and Attribute Descriptions
8.9 Association
8.10 Specifying the Multiplicity of an Association
8.11 Reflexive Associations
8.12 Multiple Associations
8.13 Aggregation and Composition
8.14 Foreign Key
8.15 Association Class
8.16 n‐ary Association
8.17 Association Descriptions
8.18 Generalization
8.19 e‐Book and Print Media in WebBooks 2.0 Order fulfillment
8.20 Quality Criteria
8.21 Economic Considerations
8.22 Summary
9 Interaction Diagrams
9.1 On the Relative Unimportance of Interaction Diagramming
9.2 Basic Concepts
9.3 Basic Interaction Diagram Notation
9.4 Messages and Net Flow of Information
9.5 Message Naming
9.6 Which Objects Communicate?
9.7 Object Creation
9.8 Object Deletion
9.9 Single Message Conditional
9.10 Single Message Repetition and Multiobjects
9.11 Messaging Self
9.12 Multiple Message Conditional, “opt”
9.13 Multiple Message Conditional, “alt”
9.14 Multiple Message Iteration, “loop”
9.15 Referencing a Separate Sequence Diagram
9.16 A Tactic for Developing Sequence Diagrams
9.17 Error Handling in Interaction Diagrams
9.18 Interaction Diagram Descriptions
9.19 Brokers
9.20 Cohesion and Coupling in Interaction Diagrams
9.21 Quality Criteria
9.22 Economic Considerations
9.23 Summary
10 State Models
10.1 Event
10.2 State
10.3 Transition
10.4 Initial State
10.5 Self‐Transition
10.6 Guard
10.7 Sequential Substates
10.8 Final State
10.9 State–Event–Transition Completeness
10.10 Correlating States and Attributes
10.11 Action
10.12 Transition Action
10.13 State Action
10.14 Action Reuse
10.15 Transition Action and State Action Equivalence
10.16 Action Specifications
10.17 Specifying Actions as Requires‐Guarantees (Contracts)
10.18 Specifying Actions with Models
10.19 Specifying Actions with UML Action Semantics
10.20 Specifying Actions with Pseudo‐code or Code Fragments
10.21 Cohesion and Coupling Guidelines for Actions
10.22 Actions and Enforcing Association Multiplicities
10.23 Action Parameters
10.24 Modeling “in Any Order” Events
10.25 Error Handling in State Models
10.26 Dynamic Classification and State Models
10.27 Broker State Models
10.28 State–Event Matrix Notation
10.29 Modifying Sequence Diagrams to Show Object State
10.30 Quality Criteria
10.31 Economic Considerations
10.32 Summary
11 Partitioning Domains into Subdomains
11.1 Subdomain Partitioning and the Fundamental Principles
11.2 An Example Domain to Partition
11.3 Partitioning a Domain
11.4 Subdomain Diagrams
11.5 Quality Criteria
11.6 Summary
12 Wrapping Up Semantic Modeling
12.1 Reviewing the Semantic Model
12.2 Organizing Semantic Model Content into a Written Specification
12.3 Validating a Semantic Model
12.4 Validating a Semantic Model by Peer Review
12.5 Validating a Semantic Model by Simulation
12.6 Deriving Verification Test Cases from a Semantic Model
12.7 Economics of Software Testing: Risk‐Based Testing
12.8 Test Elements Versus Test Cases
12.9 Comments Regarding Acceptance Test‐Driven Development
12.10 Translating a Semantic Model into Natural Language Requirements Documentation
12.11 Analysis Patterns Versus Design Patterns
12.12 Product Families and Semantic Models
12.13 Alternate Semantic Model Development Processes
12.14 Build Versus Buy: The Role of Semantic Models in Package Acquisition
12.15 Summary
Part III: Model‐Based Design and Code
13 Introduction to Design and Code
13.1 Semantic Modeling Versus Design Modeling
13.2 Selecting Automation Technologies
13.3 Establishing a Boundary of Automation
13.4 Two Kinds of Design
13.5 Overview of the Software Design Activity
13.6 Summary
14 Designing Interfaces
14.1 Interface Design in the Context of Software Process
14.2 Importance of Usability
14.3 Whose Interface Is It?
14.4 Net Flow of Information and Push Versus Pull at Interfaces
14.5 Two Kinds of Actor
14.6 Dealing with Collections
14.7 User (Human) Interface Design
14.8 Task Analysis
14.9 Dialog Map
14.10 User Interface Prototype
14.11 User Interface Design, a Case Study
14.12 User Guide Documentation
14.13 API Design
14.14 Handling Interface Errors
14.15 Packaging the Interface Specification
14.16 Quality Criteria
14.17 Summary
15 High‐Level Design
15.1 Comments on High‐Level Design
15.2 UML Notation for High‐Level Design
15.3 Deriving Design Classes for Model Region
15.4 Deriving Operations for Model Region
15.5 Deriving Operations in Model Region for Order fulfillment
15.6 High‐Level Design for View‐Controller Region
15.7 High‐Level Design for a User Interface View‐Controller Region
15.8 High‐Level Design for Single‐User Desktop View‐Controller Region
15.9 High‐Level Design for Distributed Client‐Server View‐Controller Region
15.10 High‐Level Design for an API View‐Controller Region
15.11 High‐Level Design for a Real‐Time/Embedded View‐Controller Region
15.12 High‐Level Design for Infrastructure Region
15.13 Quality Criteria
15.14 Summary
16 High‐Level Design
16.1 High‐Level Design as a Deliberate Encapsulation Barrier
16.2 Deriving Contracts and Signatures for Model Region Pulled Data
16.3 Deriving Contracts and Signatures for Model Region Pushed Events
16.4 Deriving Contracts and Signatures for Pushed Events: Concrete Examples
16.5 Defensive Programming and Design by Contract
16.6 Defensive Programming and Trust Boundaries
16.7 Handling Contract‐Level Errors
16.8 Deriving Class Invariants for Model Region
16.9 Deriving Contracts and Signatures for Model Region Pulled Events
16.10 Deriving Contracts and Signatures for Model Region Pushed Data
16.11 Contracts and Signatures in View‐Controller and Infrastructure Regions
16.12 Documenting the Initial High‐Level Design
16.13 Quality Criteria
16.14 Summary
17 Detailed Design and Code
17.1 Comments on Detailed Design
17.2 Implementing Attributes in Model Region
17.3 Implementing Associations in Model Region
17.4 Implementing Associations in Memory‐Resident Objects
17.5 Implementing Associations in a Persistence Layer
17.6 Data Access Object Pattern
17.7 Implementing Derived Attributes in Model Region
17.8 Completing Operation Signatures: Parameters and Return Types
17.9 Designing and Implementing Methods in Model Region
17.10 Designing and Implementing Dynamic Classification
17.11 Connecting Domains
17.12 Detailed Design and Code in View‐Controller Region for a User Interface
17.13 Detailed Design and Code in View‐Controller Region for an API or Embedded
17.14 Detailed Design and Code in Infrastructure Region
17.15 Handling Method‐Level Errors
17.16 A Few Comments on Code Comments
17.17 Wrapping Up Method‐Level Design and Code
17.18 Detailed Design and Code Documentation
17.19 Quality Criteria
17.20 Summary
18 Formal Disciplines of Design and Code
18.1 Programming by Intent
18.2 Assertions
18.3 Software Proof of Correctness: Revealing the True, Formal Nature of Code
18.4 Proofs Involving Sequence
18.5 Proofs Involving Invocation
18.6 Proofs Involving Selection
18.7 Proofs Involving Iteration
18.8 A Complete Proof of Correctness
18.9 Intend‐Act‐Prove‐Assert Format
18.10 Quality Criteria
18.11 Summary
19 Optimization
19.1 An Engineering Approach to Optimization
19.2 Usage Matrix
19.3 High‐Level Design Optimizations
19.4 High‐Level Design Optimization: Horizontal Split
19.5 High‐Level Design Optimization: Vertical Split
19.6 High‐Level Design Optimization: Horizontal Merge
19.7 Detailed Design and Code Optimization
19.8 SQL Optimization
19.9 Design and Implement in a Lower‐Level Language
19.10 Run‐Time Environment Optimization
19.11 Hardware Optimization
19.12 Solidify Optimizations
19.13 Quality Criteria
19.14 Summary
20 Model Compilation
20.1 Open Versus Closed Model Compilers
20.2 Regular Versus Irregular Mappings
20.3 CIMs, PIMs, and PSMs
20.4 UML Action Semantics
20.5 Open Model Compilation, in Detail
20.6 A Nontrivial Example of Code Generation
20.7 A Brief Review of Programming Language Evolution
20.8 Quality Criteria
20.9 Summary
21 Advanced Open Model Compilation
21.1 Optimizing Generated Application Code
21.2 Building a New Open Model Compiler on an Existing Rule Interpreter
21.3 Generating Output Other Than Application Source Code
21.4 Building a New Production Rule Interpreter
21.5 Quality Criteria
21.6 Weaknesses in UML Semantics
21.7 Summary
22 Wrapping Up Model‐Based Design and Code
22.1 Reviewing Model‐Based Design and Code
22.2 Comparing and Contrasting Semantic and Design Models
22.3 Documenting Design in a Written Specification
22.4 Design Versus Code: What's the Difference?
22.5 Knuth's Literate Programming
22.6 Verification Testing of Design and Code
22.7 Design and Code for Product Families
22.8 The Myth of Source Code Reuse
22.9 Summary
Part IV: Related Topics
23 Estimation
23.1 Estimation, Commitment, Uncertainty, and Risk
23.2 Estimating Nominal Effort and Nominal Schedule
23.3 Trading Effort and Schedule
23.4 Making Reasonable Commitments
23.5 Effort by Activity, Without a Model Compiler
23.6 Effort by Activity, with a Model Compiler
23.7 Estimating Replacement of Legacy Systems
23.8 Estimating Small‐Scale Maintenance
23.9 Quality Criteria
23.10 Summary
24 Development and Maintenance Processes
24.1 Separating Phase and Activity
24.2 Agile Development
24.3 Model‐Based Software Engineering Under Agile Development
24.4 Advantages of Agile Development
24.5 Disadvantages of Agile Development
24.6 Waterfall Development
24.7 Model‐Based Software Engineering, Waterfall, and Feedback Loops
24.8 Advantages of Waterfall Development
24.9 Disadvantages of Waterfall Development
24.10 One Size Does Not Fit All
24.11 A Meta‐Process: Right‐Sizing Your Software Process
24.12 Quality Criteria
24.13 Summary
25 Economics of Error Handling
25.1 Simple Analysis
25.2 Sophisticated Analysis
25.3 Informal Analysis
25.4 Reanalyzing Earlier Examples, Informally
25.5 Summary
26 Arguments Against Model‐Based Software Engineering
26.1 Claim #1: Code Can Be Produced as Fast or Faster Without Models
26.2 Claim #2: Model‐Based Software Engineering Requires “Big Design Up Front”
26.3 Claim #3: Stakeholders Don't Know UML or Modeling
26.4 Claim #4: Some People Don't Like Drawings, They Prefer Text
26.5 Claim #5: Semantic Models Are Just Code in a Different Language
26.6 Claim #6: Semantic Models Aren't Requirements, They Are Design
26.7 Claim #7: Semantic Modeling Isn't Practical Without a Sophisticated, Expensive Tool
26.8 Claim #8: It Is Not Clear Who Should Do the Semantic Modeling
26.9 Claim #9: If Model‐Based Software Engineering Is So Great, Then Why Isn't Everyone Already Doing It?
26.10 Summary
Part V: Summary
27 Closing Remarks
27.1 Review of This Book
27.2 Revisiting the Big Picture
27.3 Solving Mainstream Software's Primary Problems
27.4 Solving Problem #1: Vague, Ambiguous, Incomplete Requirements
27.5 Solving Problem #2: Overdependence on Testing to Find Software Defects
27.6 Solving Problem #3: “Self‐Documenting Code” Is a Myth
27.7 Complexity Management in Model‐Based Software Engineering
27.8 Bug == Defect == Semantic Inconsistency
27.9 Summary
Part VI: Appendices
Appendix A: Documentation Principles
A.1 No Write‐Only Documentation
A.2 Read‐Time Convenience Is Far More Important Than Write‐Time Convenience
A.3 Document for an Average 10–15‐Year Service Life
A.4 One Fact, One Place
A.5 Cohesion and Coupling Apply to Documentation, Too
A.6 Content and Packaging of Documentation Can Be Different
A.7 Summary
Appendix B: WebBooks 2.0 Background
B.1 Project Justification and Goals
B.2 High‐Level Scope
B.3 Minimum Conditions of Acceptance
Appendix C: WebBooks 2.0 Domains
C.1 Domain Diagram
C.2 Order fulfillment
C.3 Payment
C.4 User Security
C.5 Scalability
C.6 High availability
C.7 «realized» Web UI
C.8 «realized» Dedicated Terminal UI
Appendix D: Semantic Model for Order fulfillment
D.1 Use Case Diagram
D.2 Class Diagram
D.3 Interaction Diagrams
D.4 Class Dictionary
D.5 Association Dictionary
D.6 Relevant Notes
Appendix E: (Pro Forma) Order fulfillment Design
E.1 Interface Specification
E.2 High‐Level Design
E.3 Detailed Design
Appendix F: Semantic Model for Payment
F.1 Use Case Diagram
F.2 Class Diagram
F.3 Interaction Diagrams
F.4 Class Dictionary
F.5 Association Dictionary
F.6 Relevant Notes
Appendix G: (Pro Forma) Payment Design
G.1 Interface Specification
G.2 High‐Level Design
G.3 Detailed Design
Appendix H: Semantic Model for Scalability
H.1 Use Case Diagram
H.2 Class Diagram
H.3 Interaction Diagrams
H.4 Class Dictionary
H.5 Association Dictionary
H.6 Relevant Notes
Appendix I: (Pro Forma) Scalability Design
I.1 Interface Specification
I.2 High‐Level Design
I.3 Detailed Design
Appendix J: Semantic Model for High availability
J.1 Use Case Diagram
J.2 Class Diagram
J.3 Interaction Diagrams
J.4 Class Dictionary
J.5 Association Dictionary
J.6 Relevant Notes
Appendix K: (Pro Forma) High availability Design
K.1 Interface Specification
K.2 High‐Level Design
K.3 Detailed Design
Appendix L: Semantics of Semantic Modeling
L.1 Use Case Diagram
L.2 Class Diagram
L.3 Interaction Diagrams
L.4 Class Dictionary
L.5 Association Dictionary
L.6 UML Profile for Semantic Modeling
L.7 On Measurement Theory and Programming Languages
Appendix M: Sample Production Rules
Appendix N: Software Structural Complexity Metrics
N.1 Cyclomatic Complexity
N.2 Depth of Decision Nesting
N.3 Number of Parameters
N.4 Fan‐Out
N.5 Local Versus Global Structural Complexity
N.6 Trading Local and Global Structural Complexity
N.7 Minimize Total Structural Complexity
N.8 More Needs to Be Known About Structural Complexity
References
Index
End User License Agreement
List of Tables
Preface
Table P.1 Comprehension levels used in Table P.2.
Table P.2 Recommended comprehension levels, by project role.
Chapter 1
Table 1.1 Credible, published reports confirming the defect cost increase eff...
Table 1.2 Software project effort: what most people think happens.
Table 1.3 Software project effort: what really happens.
Chapter 2
Table 2.1 Sentences in three languages.
Table 2.2 Three more sentences.
Table 2.3 One more sentence.
Chapter 3
Table 3.1 Overall quality criteria for work products.
Table 3.2 Quality criteria for naming.
Chapter 4
Table 4.1 Quality criteria for requirements.
Chapter 6
Table 6.1 Quality criteria for domain partitioning.
Chapter 7
Table 7.1 Business events and responses in Silly Bank loan processing.
Table 7.2 Naming use cases by business event versus response.
Table 7.3 Quality criteria for use cases.
Table 7.4 Quality criteria for consistency between use cases and (sub)domain ...
Chapter 8
Table 8.1 UML notation for multiplicities.
Table 8.2 Quality criteria for class models.
Table 8.3 CRUD matrix for Order fulfillment.
Table 8.4 Quality criteria for class model to use case consistency.
Chapter 9
Table 9.1 Comparing good and bad cohesion and coupling in sequence diagrams.
Table 9.2 Quality criteria for interaction diagrams.
Table 9.3 Quality criteria for consistency between interaction diagrams and u...
Table 9.4 Quality criteria for consistency between interaction diagrams and c...
Chapter 10
Table 10.1 An example state vector correlating attribute values to states.
Table 10.2 Correlating states to subclasses for class Part in Figure 8.29.
Table 10.3 The state model in Figure 10.32 in state–event matrix form.
Table 10.4 Quality criteria for state models.
Table 10.5 Quality criteria for consistency between state and class models.
Table 10.6 Quality criteria for consistency between state models and interact...
Chapter 11
Table 11.1 Quality criteria for subdomain partitioning.
Chapter 12
Table 12.1 A starting configuration for simulating the Fill a bottle scenario...
Table 12.2 Expected ending configuration for the Fill a bottle scenario.
Table 12.3 Transcript of the Fill a bottle simulation.
Table 12.4 Transcript of the Packable orders? simulation.
Table 12.5 Transcript of the Pack order o3 simulation.
Chapter 14
Table 14.1 Excellent resources on usability.
Table 14.2 State model concepts mapped onto user interface design.
Table 14.3 Quality criteria for overall interface design.
Table 14.4 Quality criteria for general usability.
Table 14.5 Quality criteria for user interfaces.
Table 14.6 Quality criteria for APIs.
Chapter 15
Table 15.1 Quality criteria for high‐level design.
Chapter 16
Table 16.1 Objectively contrasting error codes and exceptions.
Table 16.2 Quality criteria for designing contracts and signatures.
Chapter 17
Table 17.1 Quality criteria for detailed design and code.
Chapter 18
Table 18.1 Quality criteria for programming by intent.
Table 18.2 Quality criteria for assertions.
Table 18.3 Quality criteria for software proofs of correctness.
Chapter 19
Table 19.1 Example levels and techniques for optimization.
Table 19.2 Categories of semantics preserving transforms.
Table 19.3 Trading time for space transforms.
Table 19.4 Trading space for time transforms.
Table 19.5 Loop transforms.
Table 19.6 Logic transforms.
Table 19.7 Procedure transforms.
Table 19.8 Expression transforms.
Table 19.9 Example class prefixes for Order fulfillment.
Table 19.10 Possible selection criteria for collection types.
Table 19.11 Quality criteria for design and code optimization.
Chapter 20
Table 20.1 High‐level semantic model to technology mappings in Chapters 15–19...
Table 20.2 Summarizing generated code for several classes in Order fulfillmen...
Table 20.3 Quality criteria for open model compilation.
Chapter 21
Table 21.1 A State model encoded as data in a state–event matrix.
Table 21.2 Quality criteria for optimizing an open model compiler.
Table 21.3 Quality criteria for a new open model compiler on an existing inte...
Table 21.4 Quality criteria for a new production rule interpreter.
Chapter 23
Table 23.1 Risks with ratio‐scaled probabilities, severities, and calculated ...
Table 23.2 Risks with ordinal‐scaled probability and severity.
Table 23.3 Assets with ratio‐scaled probabilities, benefits, and calculated g...
Table 23.4 Example assets with ordinal‐scaled probabilities and benefits
Table 23.5 Nominal staffing for different situations.
Table 23.6
Schedule compression options according to [Symons91].
Table 23.7 Statisticians' “Z Table.”
Table 23.8 Source of defect injection: requirements, design, and code.
Table 23.9 Quality criteria for estimates and estimation.
Chapter 24
Table 24.1 External drivers in relation to published lifecycles.
Table 24.2 Internal decision criteria in relation to published lifecycles.
Table 24.3 Quality criteria for lifecycle/process selection
Chapter 25
Table 25.1 Cash flow estimates for the Warehouse worker click error if not ha...
Table 25.2 Cash flow estimates for using a confirm dialog.
Table 25.3 Cash flow estimates for using a confirm dialog.
Table 25.4 Cash flow stream for the value of the confirm proposal.
Table 25.5 Cash flow stream for the value of the undo proposal.
Table 25.6 Cash flow stream for the value of the confirm and undo proposals c...
Table 25.7 PW(13%) for each of the alternatives.
Table 25.8 Decision table for when the damage rating is high.
Table 25.9 Decision table for when the damage rating is medium.
Table 25.10 Decision table for when the damage rating is low.
Table 25.11 Comparing formal and informal analysis recommendations.
Appendix N
Table N.1 Structural complexity metrics ranges in terms of zones.
Table N.2 Suggested quality zones for cyclomatic complexity in a method.
Table N.3 Suggested quality zones for depth of decision nesting in a method.
Table N.4 Suggested quality zones for number of parameters on an operation.
Table N.5 Suggested quality zones for fan‐out in a method.
List of Illustrations
Chapter 1
Figure 1.1 House design notation for doors.
Figure 1.2 The full test‐driven development process.
Figure 1.3 Primary deliverables from a model‐based software engineering proj...
Chapter 2
Figure 2.1 Three superclass–subclass‐related classes.
Figure 2.2 Use case diagram for Silly Bank.
Figure 2.3 Class diagram for Silly Bank.
Figure 2.4 Sequence diagram for deposit at Silly Bank.
Figure 2.5 Sequence diagram for withdraw at Silly Bank.
Figure 2.6 State diagram for Silly Savings Accounts.
Figure 2.7 Partial use case diagram for Java development and maintenance.
Figure 2.8 Partial class diagram for Java development and maintenance.
Figure 2.9 Annotated state diagram for Silly Savings Accounts.
Chapter 3
Figure 3.1 A simple test for abstraction skills.
Figure 3.2 A harder test for abstraction skills.
Chapter 4
Figure 4.1 A set of decisions about software.
Figure 4.2 The decisions partitioned by who made them.
Figure 4.3 Separating requirements from non‐requirements.
Figure 4.4 A Tinker Toy Tic Tac Toe computer.
Figure 4.5 Encodings for the Tinker Toy Tic Tac Toe computer.
Figure 4.6 Configurations for the memory spindle and core piece in Figure 4....
Figure 4.7 Two kinds of decisions: business versus automation technology.
Figure 4.8 Two kinds of requirements, functional and nonfunctional.
Figure 4.9 How to separate functional from nonfunctional requirements?
Figure 4.10 Separating functional and nonfunctional requirements using perfe...
Figure 4.11 Fail, requirement, and perfection points, illustrated.
Figure 4.12 Value compared to cost of delivering that level of performance....
Chapter 5
Figure 5.1 UML's notation for a note.
Figure 5.2 Associating notes to model elements.
Figure 5.3 UML's notation for constraints.
Figure 5.4 The aerospace salary policy expressed as a UML constraint.
Figure 5.5 An example stereotype, in this case “«hardware»”.
Figure 5.6 An example of UML's package notation.
Chapter 6
Figure 6.1 Example of brainstormed concepts for WebBooks 2.0.
Figure 6.2 Grouped concepts for WebBooks 2.0.
Figure 6.3 Named domains in WebBooks 2.0.
Figure 6.4 Domain diagram for WebBooks 2.0.
Figure 6.5 A fragment of the domain diagram for Automated Test Equipment.
Figure 6.6 Executing Step‐110 in Block‐9.
Figure 6.7 Executing Step‐120 in Block‐9
Figure 6.8 Functional requirements are captured and represented in a domain'...
Figure 6.9 Some nonfunctional requirements are fully addressed in a domain's...
Figure 6.10 Some nonfunctional requirements are partially addressed in the d...
Figure 6.11 Some nonfunctional requirements bypass a domain entirely.
Figure 6.12 Requirements can be created (derived) in the design and code of ...
Figure 6.13 Requirements flowing into, through, and around and being derived...
Figure 6.14 Deliverables from model‐based software engineering projects.
Chapter 7
Figure 7.1 South front elevation for the White House, Washington, DC, 1817....
Figure 7.2 UML's “stick man” notation for actors.
Figure 7.3 UML's «actor» stereotyped class notation.
Figure 7.4 UML use case notation.
Figure 7.5 Partial use case diagram for Silly Bank with several “participate...
Figure 7.6 Adding the rectangle and (sub)domain name to emphasize scope and ...
Figure 7.7 Modeling a sea level data use case as if it were a sea level even...
Figure 7.8 Use case diagram showing a recommended sea level data use case na...
Figure 7.9 Final use case diagram for Silly Bank loan processing.
Figure 7.10 An example of an «include» mud level use case.
Figure 7.11 An example of an «extend» mud level use case.
Figure 7.12 An example of use case generalization.
Figure 7.13 An example of actor generalization.
Figure 7.14 Use case diagram for Order fulfillment in WebBooks 2.0.
Figure 7.15 Activity diagram for Silly Bank loan processing.
Chapter 8
Figure 8.1 UML's notation for a class.
Figure 8.2 A rough first approximation of classes in WebBooks 2.0 Order fulf...
Figure 8.3 Proposed attributes for classes in Order fulfillment.
Figure 8.4 An attribute can sometimes take on its own attributes.
Figure 8.5 Using “{Ix}” notation for keys.
Figure 8.6 UML notation for a derived attribute.
Figure 8.7 Using a UML constraint to specify a derivation policy.
Figure 8.8 Fragment of a class diagram for Order fulfillment.
Figure 8.9 Normalized classes and attributes in Order fulfillment.
Figure 8.10 UML's notation for associations.
Figure 8.11 Naming associations and using UML's “taco chip.”
Figure 8.12 UML's role end name notation.
Figure 8.13 Association multiplicity on a class diagram.
Figure 8.14 Class diagram for Order fulfillment with associations and multip...
Figure 8.15 A reflexive association.
Figure 8.16 Multiple associations between the same classes.
Figure 8.17 UML's notation for aggregation.
Figure 8.18 UML's notation for composition.
Figure 8.19 Published UML designs for Bridge and Decorator patterns.
Figure 8.20 Examples of foreign keys.
Figure 8.21 UML's notation for an association class.
Figure 8.22 The same situation modeled without an association class.
Figure 8.23 n‐ary association notation.
Figure 8.24 Generalization notation in UML.
Figure 8.25 Constraints {complete} and {incomplete}.
Figure 8.26 Constraints {disjoint} and {overlapping}.
Figure 8.27 The preferred alternative to {overlapping}.
Figure 8.28 Constraint “{dynamic}” on generalizations.
Figure 8.29 Class Part seen in the engineering perspective.
Figure 8.30 Class Part seen in the billing perspective.
Figure 8.31 Multiple classification: class Part seen in the combined perspec...
Figure 8.32 Class diagram for WebBooks 2.0 Order fulfillment, with generaliz...
Chapter 9
Figure 9.1 Object naming styles for interaction diagrams.
Figure 9.2 A use case in another simple banking application.
Figure 9.3 A class diagram for the simple banking application.
Figure 9.4 A sequence diagram for the check‐cashing scenario.
Figure 9.5 A communication diagram for the check‐cashing scenario.
Figure 9.6 A design sequence diagram with activation context bars (flow of c...
Figure 9.7 A sequence diagram for a simple sea level event use case.
Figure 9.8 A sequence diagram for a simple sea level data use case.
Figure 9.9 A sequence diagram showing object creation.
Figure 9.10 A sequence diagram showing object deletion.
Figure 9.11 A sequence diagram showing single message conditional.
Figure 9.12 A sequence diagram showing single message repetition and multiob...
Figure 9.13 A sequence diagram showing recursion.
Figure 9.14 A sequence diagram showing multiple message conditional.
Figure 9.15 A sequence diagram showing multiple message alternatives.
Figure 9.16 A sequence diagram showing multiple message loop.
Figure 9.17 A sequence diagram showing reference to another diagram.
Figure 9.18 The sequence diagram after step two.
Figure 9.19 The sequence diagram after step three.
Figure 9.20 The sequence diagram after step four.
Figure 9.21 The complete sequence diagram for receiving a replenish order.
Figure 9.22 Sequence diagram for determining which Book orders are packable....
Figure 9.23 Sequence diagram for receiving a replenish order, bad cohesion, ...
Chapter 10
Figure 10.1 Class diagram for Silly Bank Loan processing.
Figure 10.2 Class diagram for Silly Bank loan processing, showing events.
Figure 10.3 UML notation for states.
Figure 10.4 Partial state diagram for Silly Bank loans.
Figure 10.5 Silly Bank loan state diagram with initial state added.
Figure 10.6 Silly Bank loan state diagram with self‐transitions added.
Figure 10.7 Silly Bank loan state diagram with guards added to restore deter...
Figure 10.8 Violating the mutually exclusive guard rule.
Figure 10.9 Deterministically modeling a stochastic process.
Figure 10.10 Underlying formalism for guards.
Figure 10.11 Underlying formalism for sequential substates.
Figure 10.12 History transition on substates.
Figure 10.13 Example of the potential problem with history transitions.
Figure 10.14 Final states in Silly Bank loan example.
Figure 10.15 Silly Bank loan state diagram including newly surfaced transiti...
Figure 10.16 The complete state diagram for Silly bank loans.
Figure 10.17 Entry/ and exit/ actions.
Figure 10.18 Interpreting entry/ and exit/ actions.
Figure 10.19 Eventname/ actions are equivalent to actions on self‐transition...
Figure 10.20 State actions in the state diagram for an automobile cruise con...
Figure 10.21 State actions in transition action form (Moore form to Mealy fo...
Figure 10.22 A transition action in state action form (Mealy form to Moore f...
Figure 10.23 A modified fragment of Order fulfillment's class diagram.
Figure 10.24 A class diagram for a simplified parameter specification langua...
Figure 10.25 A brute‐force approach to in‐any‐order for two events.
Figure 10.26 A brute‐force approach to three events in any order.
Figure 10.27 A more elegant approach to in‐any‐order for (in this example) f...
Figure 10.28 Handling business failure in a state model.
Figure 10.29 State model for the superclass and states mapped to subclasses....
Figure 10.30 State diagram fragments for each subclass of Part in Figure 8.2...
Figure 10.31 Example state diagram for a broker class.
Figure 10.32 Simplified state diagram for airplane landing gear control.
Figure 10.33 Sequence diagram with overlaid state information.
Chapter 11
Figure 11.1 Use case diagram for WebBooks 2.0 Order fulfillment domain.
Figure 11.2 Class diagram for WebBooks 2.0 Order fulfillment domain.
Figure 11.3 Sequence diagram for half of the Pack order sea level use case....
Figure 11.4 Sequence diagram for the other half of the Pack order sea level ...
Figure 11.5 Sequence diagram for the Receive replenish received sea level us...
Figure 11.6 Subdomains in Order fulfillment domain class diagram.
Figure 11.7 Sequence diagram for the other half of the Pack order sea level ...
Figure 11.8 Sequence diagram for the Receive replenish sea level use case wi...
Figure 11.9 Use case diagram for Customer ordering subdomain.
Figure 11.10 Class diagram for Customer ordering subdomain.
Figure 11.11 Sequence diagram for Pack order use case in Customer ordering s...
Figure 11.12 Sequence diagram for Restock use case in Customer ordering subd...
Figure 11.13 Use case diagram for Inventory management subdomain.
Figure 11.14 Class diagram for Inventory management subdomain.
Figure 11.15 Sequence diagram for Request replenish use case.
Figure 11.16 Sequence diagram for Receive replenish use case in Order manage...
Figure 11.17 Subdomain diagram for Order fulfillment domain.
Figure 11.18 Domain diagram for Atomic Vapor Laser Isotope Separation contro...
Figure 11.19 Subdomain diagram for the Separator control domain.
Chapter 12
Figure 12.1 Schematic overview of the Bottle Filling Line case study.
Figure 12.2 Use case diagram for the Filling Line case study.
Figure 12.3 Class diagram for the Filling Line.
Figure 12.4 Sequence diagram for the Fill a bottle use case.
Figure 12.5 State diagram for Filling line.
Figure 12.6 State diagram for Filling station.
Figure 12.7 State diagram for Bottle loader.
Figure 12.8 Starting configuration for the Fill a bottle simulation in table...
Figure 12.9 Starting configuration for Order fulfillment simulation.
Figure 12.10 Ending configuration for Pack order o3 simulation.
Figure 12.11 Cost of testing can be considered linear.
Figure 12.12 Maximum exposure from damage caused by defective software.
Figure 12.13 Cumulative value of testing.
Figure 12.14 Test until the incremental value is close to the incremental co...
Figure 12.15 Assembling test elements into test cases.
Chapter 13
Figure 13.1 Two kinds of design: external software interface and internal so...
Figure 13.2 Extending the requirements filtering process.
Figure 13.3 Overview of the software design activity.
Chapter 14
Figure 14.1 Iterator pattern interface.
Figure 14.2 A fragment of a dialog map for an automated teller machine.
Figure 14.3 Sample dialog map for Customer user interface in Order fulfillme...
Figure 14.4 Relating the Customer dialog map to use cases.
Figure 14.5 A low‐fidelity user interface prototype for some sample screen....
Chapter 15
Figure 15.1 A design class with public, private, instance (member), and clas...
Figure 15.2 High‐level design for Order fulfillment Model region after the f...
Figure 15.3 Example of dynamic classification in a semantic model.
Figure 15.4 Collapsing subclasses to implement dynamic classification in hig...
Figure 15.5 Using State pattern to implement dynamic classification in high‐...
Figure 15.6 High‐level design for Order fulfillment domain Model region afte...
Figure 15.7 A simple, generic semantic model sequence diagram.
Figure 15.8 High‐level design for Source as client and Destination as server...
Figure 15.9 High‐level design for Destination as client and Source as server...
Figure 15.10 Another generic semantic model sequence diagram.
Figure 15.11 Design alternative 1: A is client of B (push), and B is client ...
Figure 15.12 Alternative 2: C is client of B (pull), and B is client of A (p...
Figure 15.13 Alternative 3: B is client of A (pull), and B is client of C (p...
Figure 15.14 Alternative 4: A is client of B (push), and C is client of B (p...
Figure 15.15 Semantic model sequence diagram for use case Packable orders?
Figure 15.16 Design sequence diagram for use case Packable orders?
Figure 15.17 Model region high‐level design for use case Packable orders?
Figure 15.18 Semantic model sequence diagram for part of use case Pack order...
Figure 15.19 Design sequence diagram for part of use case Pack order.
Figure 15.20 Semantic model sequence diagram for extending use case Replenis...
Figure 15.21 Model region design incorporating use case Pack order with Repl...
Figure 15.22 Semantic model sequence diagram for use case Catalog?
Figure 15.23 Model region design incorporating use case Catalog?
Figure 15.24 Semantic model sequence diagram for use case Drop from cart.
Figure 15.25 Model region design incorporating use case Add to cart.
Figure 15.26 Semantic model sequence diagram for use case Drop from cart.
Figure 15.27 Model region design incorporating use case Drop from cart.
Figure 15.28 Semantic model sequence diagram for use case Check out.
Figure 15.29 Model region design incorporating use case Check out.
Figure 15.30 Semantic model sequence diagram for use case eBook user keys?
Figure 15.31 Model region design incorporating use case Check out.
Figure 15.32 Initial high‐level design for Model region of Order fulfillment...
Figure 15.33 First approximation View‐controller region design for Customer ...
Figure 15.34 Model region, View‐controller region, and real world.
Figure 15.35 A fragment of View‐controller region design showing UIScreen.
Figure 15.36 A more elegant View‐controller region design.
Figure 15.37 View‐controller region design for client‐server Customer user i...
Figure 15.38 View‐controller region design for client‐server Customer user i...
Figure 15.39 High‐level design for a REST application.
Figure 15.40 Relating high‐level REST design to Model–View–Controller.
Chapter 16
Figure 16.1 Relationship of operation contract to state model, a generic, no...
Figure 16.2 Contract dependencies for action2, action3, and action4.
Figure 16.3 State model for Book order, annotated for transitions on the Pla...
Figure 16.4 Signature and contract for BookOrder.place() annotated to match ...
Figure 16.5 Decision criteria and options for data flow‐based error notifica...
Figure 16.6 Semantic model sequence diagram for part of use case Pack order....
Figure 16.7 Design sequence diagram for part of Pack order in push form.
Figure 16.8 Design for same part of Pack order in pull form.
Figure 16.9 Design sequence diagram for Pack order, with only one event pull...
Figure 16.10 Semantic model sequence diagram for use case Packable orders?
Figure 16.11 Design sequence diagram for use case Packable orders? in pull f...
Figure 16.12 Design for packable orders? use case in push form.
Figure 16.13 Design sequence diagram for Packable orders, with only one data...
Chapter 17
Figure 17.1 Order fulfillment attributes as instance variables and types in ...
Figure 17.2 Instance variables for Order fulfillment, including associations...
Figure 17.3 First approximation relational database schema considering only ...
Figure 17.4 Second approximation relational database schema, implementing as...
Figure 17.5 Generic Data access object pattern.
Figure 17.6 Data access object pattern applied to class BookOrder.
Figure 17.7 Collapsed dynamic classification with a type discriminator.
Figure 17.8 Dynamic classification using State pattern.
Chapter 18
Figure 18.1 Programming by intent process.
Figure 18.2 Proofs involving sequence, graphically.
Figure 18.3 Proofs involving invocation, graphically.
Figure 18.4 Proof involving selection, graphically.
Figure 18.5 Proof for switch‐case.
Figure 18.6 Proof involving iteration.
Figure 18.7 Proof of a for() loop, graphically.
Figure 18.8 An abstract example of intend‐act‐prove‐assert format.
Chapter 19
Figure 19.1 Value compared to cost of delivering that level of performance....
Figure 19.2 An engineering process for optimization.
Figure 19.3 Sample fragment of a usage matrix.
Figure 19.4 Horizontal split, conceptually.
Figure 19.5 BookOrder, horizontally split.
Figure 19.6 Vertical split, conceptually.
Figure 19.7 Title, before introduction of Medium, vertically split.
Figure 19.8 Vertical merge, conceptually.
Figure 19.9 BookOrder vertically merged with BookOrderLine.
Figure 19.10 Horizontal merge, conceptually.
Figure 19.11 Example horizontal merge.
Figure 19.12 Translating object‐oriented design and code into structured des...
Chapter 20
Figure 20.1 A production rule interpreter is the heart of an open model comp...
Figure 20.2 Separating PIM content into overlays on a semantic model.
Figure 20.3 Complete picture of open model compilation.
Figure 20.4 Semantic model of Hello World.
Chapter 21
Figure 21.1 Shaded components are needed for a new compiler on an existing i...
Figure 21.2 State diagram for Simple class.
Figure 21.3 Semantic model class diagram for a simple production rule interp...
Figure 21.4 Compiling your new rule interpreter on an existing open model co...
Figure 21.5 Compiling your rule interpreter on your new open model compiler....
Chapter 22
Figure 22.1 Knuth's WEB literate programing system.
Figure 22.2 Top‐level of WebBooks 2.0 design and code in literate programmin...
Figure 22.3 Implementation view of Customer Server in literate programming....
Figure 22.4 Implementation view of Order fulfillment in literate programming...
Chapter 23
Figure 23.1 A schedule cone of uncertainty for a real software organization...
Figure 23.2 Sprint burn down with uncertainty.
Figure 23.3 Release burn down with uncertainty for a scope‐driven release.
Figure 23.4 Release burn down for a scope‐driven release, considering scope ...
Figure 23.5 Release burn down with uncertainty for a schedule‐driven release...
Figure 23.6 Actual staffing compared with nominal staffing.
Figure 23.7 Ultimate sources of defects in software.
Chapter 24
Figure 24.1 Separating “phase” from “activity.”
Figure 24.2 Cost and value delivered over time for a typical waterfall proje...
Figure 24.3 Cost and value delivered over time for an agile project, ideally...
Figure 24.4 Cost and value delivered over time, compared.
Figure 24.5 A spectrum of software development processes.
Figure 24.6 External drivers and their influence on lifecycle characteristic...
Chapter 25
Figure 25.1 Cash flow stream for damage from the unhandled warehouse worker ...
Figure 25.2 Cash flow diagram for handling the error with a confirm dialog....
Figure 25.3 Cash flow diagram for handling the error with undo.
Figure 25.4 Cash flow diagram for the value of the confirm proposal.
Figure 25.5 Cash flow diagram for the value of the undo proposal.
Figure 25.6 Cash flow diagram for the value of the confirm and undo proposal...
Chapter 27
Figure 27.1 Primary deliverables for a model‐based software engineering proj...
Appendix C
Figure C.1 WebBooks 2.0 domains.
Appendix D
Figure D.1 Use case diagram for Order fulfillment.
Figure D.2 Class diagram for Order fulfillment.
Figure D.3 Sequence diagram for Catalog? use case.
Figure D.4 Sequence diagram for Add to cart use case.
Figure D.5 Sequence diagram for Drop from cart use case.
Figure D.6 Sequence diagram for Order? use case.
Figure D.7 Sequence diagram for Check out use case.
Figure D.8 Sequence diagram for eBook user keys? use case.
Figure D.9 Sequence diagram for Cancel order use case.
Figure D.10 Sequence diagram for Order status? use case.
Figure D.11 Sequence diagram for Packable orders? use case.
Figure D.12 Sequence diagram for Pack order use case.
Figure D.13 Sequence diagram for Replenish extending use case.
Figure D.14 Sequence diagram for Ship order use case.
Figure D.15 Sequence diagram for Receive replenish use case.
Figure D.16 Sequence diagram for Inventory? use case.
Figure D.17 Sequence diagram for Sales? use case.
Figure D.18 Sequence diagram for Profit? use case.
Figure D.19 Sequence diagram for Send replenish use case.
Figure D.20 State diagram for Book Order.
Figure D.21 State diagram for Book order line.
Figure D.22 State diagram for eBook medium.
Figure D.23 State diagram for Print medium.
Figure D.24 State diagram for Title.
Figure D.25 State diagram for Publisher.
Figure D.26 State diagram for Replenish order.
Figure D.27 State diagram for Replenish order line.
Appendix E
Figure E.1 Example dialog map for Customer user interface.
Figure E.2 High‐level design for a generic Customer UI Web page.
Figure E.3 High‐level design for Customer server.
Figure E.4 High‐level design Warehouse Worker Client.
Figure E.5 High‐level design for Warehouse Worker server.
Figure E.6 High‐level design for Manager client.
Figure E.7 High‐level design for Manager server.
Figure E.8 High‐level design for Publisher server.
Appendix F
Figure F.1 Use case diagram for Payment domain of WebBooks 2.0.
Figure F.2 Class diagram for Payment.
Figure F.3 Sequence diagram for Process create payment use case.
Figure F.4 Sequence diagram for Process add payment method use case.
Figure F.5 Sequence diagram for Process edit payment amount use case.
Figure F.6 Sequence diagram for Process drop payment method use case.
Figure F.7 Sequence diagram for Process cancel payment use case.
Figure F.8 Sequence diagram for Process payment use case.
Figure F.9 Sequence diagram for Payment status? use case.
Figure F.10 Sequence diagram for Process payment method time out use case.
Figure F.11 Sequence diagram for Process approve use case.
Figure F.12 Sequence diagram for Process decline use case.
Figure F.13 Sequence diagram for Process refund use case.
Figure F.14 Sequence diagram for Drop credit/debit account use case.
Figure F.15 Sequence diagram Purge records use case.
Figure F.16 State diagram for Payment.
Figure F.17 State diagram for Payment method.
Figure F.18 State diagram for Credit/debit Account.
Appendix G
Figure G.1 Dialog map for Customer user interface.
Figure G.2 High‐level design for Customer client in Payment.
Figure G.3 High‐level design for Customer server in Payment.
Appendix H
Figure H.1 Use case diagram for Scalability.
Figure H.2 Class diagram for Scalability.
Figure H.3 Sequence diagram for Connect shared use case.
Figure H.4 Sequence diagram for Connect owner use case.
Figure H.5 Sequence diagram for Search‐results use case.
Figure H.6 Sequence diagram for Request‐response use case.
Figure H.7 Sequence diagram for New owned datum use case.
Figure H.8 Sequence diagram for Read owned datum use case.
Figure H.9 Sequence diagram for Update owned datum use case.
Figure H.10 Sequence diagram for Delete owned datum use case.
Figure H.11 Sequence diagram for Create shared data use case.
Figure H.12 Sequence diagram for Update shared data use case.
Figure H.13 Sequence diagram for Delete shared data use case.
Figure H.14 Sequence diagram for Bulk load use case.
Figure H.15 Sequence diagram for Propagate bulk shared data use case.
Figure H.16 Sequence diagram for Disconnect use case.
Figure H.17 Sequence diagram for Disconnect use case.
Figure H.18 State diagram for Home.
Figure H.19 State diagram for Data Center.
Figure H.20 State diagram for Owned Data Server.
Figure H.21 State diagram for Shared Data Server.
Figure H.22 State diagram for Index Data Server.
Figure H.23 State diagram for Server App.
Figure H.24 State diagram for Session.
Appendix I
Figure I.1 High‐level design for ClientApp.
Figure I.2 High‐level design for Home.
Figure I.3 High‐level design for DataCenter.
Figure I.4 High‐level design for AppServer.
Figure I.5 High‐level design for OwnedDataServer.
Figure I.6 High‐level design for SharedDataServer.
Figure I.7 High‐level design for IndexDataServer.
Appendix J
Figure J.1 Use case diagram for High availability.
Figure J.2 Class diagram for High availability.
Figure J.3 Sequence diagram for Run cluster use case.
Figure J.4 Sequence diagram for Activate checkpoint server use case.
Figure J.5 Sequence diagram for Activate cluster manager use case.
Figure J.6 Sequence diagram for Deactivate cluster manager use case.
Figure J.7 Sequence diagram for Deactivate checkpoint server use case.
Figure J.8 Sequence diagram for Deactivate node use case.
Figure J.9 Sequence diagram for Stop cluster use case.
Figure J.10 Sequence diagram for Stop cluster use case.
Figure J.11 Sequence diagram for Poll use case.
Figure J.12 Sequence diagram for Save state use case.
Figure J.13 Sequence diagram for Find service? use case.
Figure J.14 State diagram for Cluster.
Figure J.15 State diagram for HA Node.
Figure J.16 State diagram for HA Checkpoint Server.
Figure J.17 State diagram for Checkpoint.
Figure J.18 State diagram for HA Cluster Manager.
Appendix K
Figure K.1 High‐level design for SysAdmin Console.
Figure K.2 High‐level design for Cluster and Cluster Manager.
Figure K.3 High‐level design for HA Node.
Figure K.4 High‐level design for HA Checkpoint Server.
Appendix L
Figure L.1 Use case diagram for semantic modeling.
Figure L.2 Class diagram for associations and generalizations.
Figure L.3 Class diagram for attributes and ranges.
Figure L.4 Class diagram for state models.
Figure L.5 Class diagram for action parameters (i.e., formal parameters).
Figure L.6 Executing an event use case in a semantic model.
Figure L.7 Default implicit state model for a class.
Figure L.8 Initial Transition instead of UML's Initial State.
Appendix N
Figure N.1 Flowchart for function Bubble sort.
Figure N.2 Correlating cyclomatic complexity and defects at the method level...
Figure N.3 Flowchart for Code Sample N.5.
Figure N.4 Structure chart for a simple payroll processing application.
Figure N.5 Correlating fan‐out and defects at the method level.
Figure N.6 Method‐level cyclomatic complexity versus operation count.
Figure N.7 Method‐level fan‐out versus operation count.
Figure N.8 Effect of enforcing a local structural complexity limit.
Figure N.9 Effect of enforcing a global structural complexity limit.
Figure N.10 Total complexity as the sum of local complexity plus global comp...
Guide
Cover
Table of Contents
Begin Reading
Pages
ii
iii
iv
v
xi
xii
xiii
xiv
xv
xvii
xviii
xix
xx
xxi
xxii
xxiii
xxiv
xxv
xxvi
xxvii
1
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
151
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
369
370
371
372
373
374
375
376
377
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
849
850
851
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1081
1082
1083
1084
1085
1086
1087
1088
1089
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
