| |
| |
| Foreword | |
| |
| |
| Preface | |
| |
| |
| |
| Introduction | |
| |
| |
| |
| Object-Oriented Analysis and Design | |
| |
| |
| Applying UML and Patterns in OOA/D | |
| |
| |
| Assigning Responsibilities | |
| |
| |
| What Is Analysis and Design? | |
| |
| |
| What Is Object-Oriented Analysis and Design? | |
| |
| |
| An Example | |
| |
| |
| The UML | |
| |
| |
| Further Readings | |
| |
| |
| |
| Iterative Development and the Unified Process | |
| |
| |
| The Most Important UP Idea: Iterative Development | |
| |
| |
| Additional UP Best Practices and Concepts | |
| |
| |
| The UP Phases and Schedule-Oriented Terms | |
| |
| |
| The UP Disciplines (was Workflows) | |
| |
| |
| Process Customization and the Development Case | |
| |
| |
| The Agile UP. | |
| |
| |
| The Sequential “Waterfall” Lifecycle | |
| |
| |
| You Know You Didn''t Understand the UP When… | |
| |
| |
| Further Readings | |
| |
| |
| |
| Case Study | |
| |
| |
| The NextGen POS System | |
| |
| |
| The NextGen POS System | |
| |
| |
| Architectural Layers and Case Study Emphasis | |
| |
| |
| The Book''s Strategy: Iterative Learning and Development | |
| |
| |
| |
| Inception | |
| |
| |
| |
| Inception | |
| |
| |
| Inception: An Analogy | |
| |
| |
| Inception May Be Very Brief | |
| |
| |
| What Artifacts May Start in Inception? | |
| |
| |
| You Know You Didn''t Understand Inception When… | |
| |
| |
| |
| Understanding Requirements | |
| |
| |
| Types of Requirements | |
| |
| |
| Further Readings | |
| |
| |
| |
| Use-Case Model | |
| |
| |
| Writing Requirements in Context | |
| |
| |
| Goals and Stories | |
| |
| |
| Background | |
| |
| |
| Use Cases and Adding Value | |
| |
| |
| Use Cases and Functional Requirements | |
| |
| |
| Use Case Types and Formats | |
| |
| |
| Fully Dressed Example: Process Sale | |
| |
| |
| Explaining the Sections | |
| |
| |
| Goals and Scope of a Use Case | |
| |
| |
| Finding Primary Actors, Goals, and Use Cases | |
| |
| |
| Congratulations: Use Cases Have Been Written, and Are Imperfect | |
| |
| |
| Write Use Cases in an Essential UI-Free Style | |
| |
| |
| Actors | |
| |
| |
| Use Case Diagrams | |
| |
| |
| Requirements in Context and Low-Level Feature Lists | |
| |
| |
| Use Cases Are Not Object-Oriented | |
| |
| |
| Use Cases Within the UP | |
| |
| |
| Case Study: Use Cases in the NextGen Inception Phase | |
| |
| |
| Further Readings | |
| |
| |
| UP Artifacts and Process Context | |
| |
| |
| |
| Identifying Other Requirements | |
| |
| |
| NextGen POS Examples | |
| |
| |
| NextGen Example: (Partial) Supplementary Specification | |
| |
| |
| Commentary: Supplementary Specification | |
| |
| |
| NextGen Example: (Partial) Vision | |
| |
| |
| Commentary: Vision | |
| |
| |
| NextGen Example: A (Partial) Glossary | |
| |
| |
| Commentary: Glossary (Data Dictionary) | |
| |
| |
| Reliable Specifications: An Oxymoron? | |
| |
| |
| Online Artifacts at the Project Website | |
| |
| |
| Not Much UML During Inception? | |
| |
| |
| Other Requirement Artifacts Within the UP | |
| |
| |
| Further Readings | |
| |
| |
| UP Artifacts and Process Context | |
| |
| |
| |
| From Inception to Elaboration | |
| |
| |
| Checkpoint: What Happened in Inception? | |
| |
| |
| On to Elaboration | |
| |
| |
| Planning the Next Iteration | |
| |
| |
| Iteration 1 Requirements and Emphasis: Fundamental OOA/D Skills | |
| |
| |
| What Artifacts May Start in Elaboration? | |
| |
| |
| You Know You Didn''t Understand Elaboration When… | |
| |
| |
| |
| Elaboration Iteration | |
| |
| |
| |
| Use-Case Model | |
| |
| |
| Drawing System Sequence Diagrams | |
| |
| |
| System Behavior | |
| |
| |
| System Sequence Diagrams | |
| |
| |
| Example of an SSD | |
| |
| |
| Inter-System SSDs | |
| |
| |
| SSDs and Use Cases | |
| |
| |
| System Events and the System Boundary | |
| |
| |
| Naming System Events and Operations | |
| |
| |
| Showing Use Case Text | |
| |
| |
| SSDs and the Glossary | |
| |
| |
| SSDs Within the UP | |
| |
| |
| Further Readings | |
| |
| |
| UP Artifacts | |
| |
| |
| |
| Domain Model | |
| |
| |
| Visualizing Concepts | |
| |
| |
| Domain Models | |
| |
| |
| Conceptual Class Identification | |
| |
| |
| Candidate Conceptual Classes for the Sales Domain | |
| |
| |
| Domain Modeling Guidelines | |
| |
| |
| Resolving Similar Conceptual Classes-Register vs. “POST” | |
| |
| |
| Modeling the Unreal World | |
| |
| |
| Specification or Description Conceptual Classes | |
| |
| |
| UML Notation, Models, and Methods: Multiple Perspectives | |
| |
| |
| Lowering the Representational Gap | |
| |
| |
| Example: The NextGen POS Domain Model | |
| |
| |
| Domain Models Within the UP | |
| |
| |
| Further Readings | |
| |
| |
| UP Artifacts | |
| |
| |
| |
| Domain Model | |
| |
| |
| Adding Associations | |
| |
| |
| Associations | |
| |
| |
| The UML Association Notation | |
| |
| |
| Finding Associations-Common Associations List | |
| |
| |
| Association Guidelines | |
| |
| |
| Roles | |
| |
| |
| How Detailed Should Associations Be? | |
| |
| |
| Naming Associations | |
| |
| |
| Multiple Associations Between Two Types | |
| |
| |
| Associations and Implementation | |
| |
| |
| NextGen POS Domain Model Associations | |
| |
| |
| NextGen POS Domain Model | |
| |
| |
| |
| Domain Model | |
| |
| |
| Adding Attributes | |
| |
| |
| Attributes | |
| |
| |
| UML Attribute Notation | |
| |
| |
| Valid Attribute Types | |
| |
| |
| Non-primitive Data Type Classes | |
| |
| |
| Design Creep: No Attributes as Foreign Keys | |
| |
| |
| Modeling Attribute Quantities and Units | |
| |
| |
| Attributes in the NextGen Domain Model | |
| |
| |
| Multiplicity From SalesLineItem to Item | |
| |
| |
| Domain Model Conclusion | |
| |
| |
| |
| Use-Case Model | |
| |
| |
| Adding Detail with Operation Contracts | |
| |
| |
| Contracts | |
| |
| |
| Example Contract: enterItem | |
| |
| |
| Contract Sections | |
| |
| |
| Postconditions | |
| |
| |
| Discussion-enterItem Postconditions | |
| |
| |
| Writing Contracts Leads to Domain Model Updates | |
| |
| |
| When Are Contracts Useful? | |
| |
| |
| Contracts vs. Use Cases? | |
| |
| |
| Guidelines: Contracts | |
| |
| |
| NextGen POS Example: Contracts | |
| |
| |
| Changes to the Domain Model | |
| |
| |
| Contracts, Operations, and the UML | |
| |
| |
| Operation Contracts Within the UP | |
| |
| |
| Further Readings | |
| |
| |
| |
| From Requirements to Design in this Iteration | |
| |
| |
| Iteratively Do the Right Thing, Do the Thing Right | |
| |
| |
| Didn''t That Take Weeks To Do? | |
| |
| |
| No, Not Exactly | |
| |
| |
| On to Object Design | |
| |
| |
| |
| Interaction Diagram Notation | |
| |
| |
| Sequence and Collaboration Diagrams | |
| |
| |
| Example Collaboration Diagram: make Payment | |
| |
| |
| Example Sequence Diagram: make Payment | |
| |
| |
| Interaction Diagrams Are Valuable | |
| |
| |
| Common Interaction Diagram Notation | |
| |
| |
| Basic Collaboration Diagram Notation | |
| |
| |
| Basic Sequence Diagram Notation | |
| |
| |
| |
| GRASP | |
| |
| |
| Designing Objects with Responsibilities | |
| |
| |
| Responsibilities and Methods | |
| |
| |
| Responsibilities and Interaction Diagrams | |
| |
| |
| Patterns | |
| |
| |
| GRASP: Patterns of General Principles in Assigning Responsibilities | |
| |
| |
| The UML Class Diagram Notation | |
| |
| |
| Information Expert (or Expert) | |
| |
| |
| Creator | |
| |
| |
| Low Coupling | |
| |
| |
| High Cohesion | |
| |
| |
| Controller | |
| |
| |
| Object Design and CRC Cards | |
| |
| |
| Further Readings | |
| |
| |
| |
| Design Model | |
| |
| |
| Use-Case Realizations with GRASP Patterns | |
| |
| |
| Use-Case Realizations | |
| |
| |
| Artifact Comments | |
| |
| |
| Use-Case Realizations for the NextGen Iteration | |
| |
| |
| Object Design: make NewSale | |
| |
| |
| Object Design: enter Item | |
| |
| |
| Object Design: end Sale | |
| |
| |
| Object Design: make Payment | |
| |
| |
| Object Design: start Up | |
| |
| |
| Connecting the UI Layer to the Domain Layer | |
| |
| |
| Use-Case Realizations Within the UP | |
| |
| |
| Summary | |
| |
| |
| |
| Design Model | |
| |
| |
| Determining Visibility | |
| |
| |
| Visibility Between Objects | |
| |
| |
| Visibility | |
| |
| |
| Illustrating Visibility in the UML | |
| |
| |
| |
| Design Model | |
| |
| |
| Creating Design Class Diagrams | |
| |
| |
| When to Create DCDs | |
| |
| |
| Example DCD | |
| |
| |
| DCD and UP Terminology | |
| |
| |
| Domain Model vs. Design Model Classes | |
| |
| |
| Creating a NextGen POS DCD | |
| |
| |
| Notation for Member Details | |
| |
| |
| DCDs, Drawing, and CASE Tools | |
| |
| |
| DCDs Within the UP | |
| |
| |
| UP Artifacts | |
| |
| |
| |
| Implementation Model | |
| |
| |
| Mapping Designs to Code | |
| |
| |
| Programming and the Development Process | |
| |
| |
| Mapping Designs to Code | |
| |
| |
| Creating Class Definitions from DCDs | |
| |
| |
| Creating Methods from Interaction Diagrams | |
| |
| |
| Container/Collection Classes in Code | |
| |
| |
| Exceptions and Error Handling | |
| |
| |
| Defining the Sale—makeLineItem Method | |
| |
| |
| Order of Implementation | |
| |
| |
| Test-First Programming | |
| |
| |
| Summary of Mapping Designs to Code | |
| |
| |
| Introduction | |