How to Engineer Software, A Model-Based Approach by Tockey, Steve -- Read -- Imperial Library of Trantor

Index

Cover Table of Contents 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

← Prev
Back
Next →

← Prev
Back
Next →