book

Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition

Name: Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition
Author: Craig Larman
ISBN: 0131489062

by Craig Larman

October 2004

Beginner to intermediate

736 pages

15h 38m

English

Pearson

Read now

Unlock full access

Copyright
Dedication
Contents by Major Topics
Foreword
Preface
Educator and Web ResourcesIntended Audience—an Introduction!PrerequisitesJava Examples, But ...Book OrganizationAbout the AuthorContactEnhancements to the Previous EditionAcknowledgmentsTypographical ConventionsProduction Notes
1. Introduction
1. Object-Oriented Analysis and Design
1.1. What Will You Learn? Is it Useful?UML vs. Thinking in ObjectsOOD: Principles and PatternsCase StudiesUse CasesIterative Development, Agile Modeling, and an Agile UPMany Other Skills Are Important!1.2. The Most Important Learning Goal?1.3. What is Analysis and Design?1.4. What is Object-Oriented Analysis and Design?1.5. A Short ExampleDefine Use CasesDefine a Domain ModelAssign Object Responsibilities and Draw Interaction DiagramsDefine Design Class DiagramsSummary1.6. What is the UML?Three Ways to Apply UMLThree Perspectives to Apply UMLThe Meaning of “Class” in Different PerspectivesUML 1 and UML 2Why Won't We See Much UML for a Few Chapters?1.7. Visual Modeling is a Good Thing1.8. History1.9. Recommended Resources
2. Iterative, Evolutionary, and Agile
Introduction2.1. What is the UP? Are Other Methods Complementary?What If I Don't Care About the UP?2.2. What is Iterative and Evolutionary Development?How to Handle Change on an Iterative Project?Are There Benefits to Iterative Development?How Long Should an Iteration Be? What is Iteration Timeboxing?2.3. What About the Waterfall Lifecycle?Guideline: Don't Let Waterfall Thinking Invade an Iterative or UP ProjectWhy is the Waterfall so Failure-Prone?The Need for Feedback and Adaptation2.4. How to do Iterative and Evolutionary Analysis and Design?2.5. What is Risk-Driven and Client-Driven Iterative Planning?2.6. What are Agile Methods and Attitudes?The Agile Manifesto and PrinciplesThe Agile ManifestoThe Agile Principles2.7. What is Agile Modeling?Agile Modeling in this Book: Why the Snapshots of UML Sketches?2.8. What is an Agile UP?2.9. Are There Other Critical UP Practices?2.10. What are the UP Phases?2.11. What are the UP Disciplines?What is the Relationship Between the Disciplines and Phases?How is the Book Structure Influenced by UP Phases and Disciplines?2.12. How to Customize the Process? The UP Development CaseAre There Optional Artifacts or Practices in the UP?Definition: What is the Development Case?2.13. You Know You Didn't Understand Iterative Development or the UP When...2.14. History2.15. Recommended Resources
3. Case Studies
Introduction3.1. What is and isn't Covered in the Case Studies?3.2. Case Study Strategy: Iterative Development + Iterative Learning3.3. Case One: The NextGen POS System3.4. Case Two: The Monopoly Game System
2. Inception
4. Inception is Not the Requirements Phase
Introduction4.1. What is Inception?Does this Analogy Help?4.2. How Long is Inception?4.3. What Artifacts May Start in Inception?Isn't That a Lot of Documentation?4.4. You Know You Didn't Understand Inception When...4.5. How Much UML During Inception?

5. Evolutionary Requirements
Introduction5.1. Definition: Requirements5.2. Evolutionary vs. Waterfall Requirements5.3. What are Skillful Means to Find Requirements?5.4. What are the Types and Categories of Requirements?5.5. How are Requirements Organized in UP Artifacts?What is the Correct Format for these Artifacts?5.6. Does the Book Contain Examples of These Artifacts?5.7. Recommended Resources
6. Use Cases
Introduction6.1. Example6.2. Definition: What are Actors, Scenarios, and Use Cases?6.3. Use Cases and the Use-Case Model6.4. Motivation: Why Use Cases?6.5. Definition: Are Use Cases Functional Requirements?6.6. Definition: What are Three Kinds of Actors?6.7. Notation: What are Three Common Use Case Formats?6.8. Example: Process Sale, Fully Dressed Style6.9. What do the Sections Mean?Preface ElementsScopeLevelPrimary ActorStakeholders and Interests List—Important!Preconditions and Success Guarantees (Postconditions)Main Success Scenario and Steps (or Basic Flow)Extensions (or Alternate Flows)Performing Another Use Case ScenarioSpecial RequirementsTechnology and Data Variations List6.10. Notation: Are There Other Formats? A Two-Column VariationThe Best Format?6.11. Guideline: Write in an Essential UI-Free StyleNew and Improved! The Case for FingerprintingEssential Style WritingContrasting ExamplesEssential StyleConcrete Style—Avoid During Early Requirements Work6.12. Guideline: Write Terse Use Cases6.13. Guideline: Write Black-Box Use Cases6.14. Guideline: Take an Actor and Actor-Goal Perspective6.15. Guideline: How to Find Use CasesStep 1: Choose the System BoundarySteps 2 and 3: Find Primary Actors and GoalsAre There Questions to Help Find Actors and Goals?How to Organize the Actors and Goals?Why Ask About Actor Goals Rather Than Use Cases?Is the Cashier or Customer the Primary Actor?Other Ways to Find Actors and Goals? Event AnalysisStep 4: Define Use Cases6.16. Guideline: What Tests Can Help Find Useful Use Cases?The Boss TestThe EBP TestThe Size TestExample: Applying the TestsReasonable Violations of the Tests6.17. Applying UML: Use Case DiagramsGuideline: DiagrammingGuideline: Downplay Diagramming, Keep it Short and Simple6.18. Applying UML: Activity Diagrams6.19. Motivation: Other Benefits of Use Cases? Requirements in ContextHigh-Level System Feature Lists Are AcceptableWhen Are Detailed Feature Lists Appropriate Rather than Use Cases?6.20. Example: Monopoly Game6.21. Process: How to Work With Use Cases in Iterative Methods?How to Evolve Use Cases and Other Specifications Across the Iterations?When Should Various UP Artifact (Including Use Cases) be Created?How to Write Use Cases in Inception?How to Write Use Cases in Elaboration?How to Write Use Cases in Construction?Case Study: Use Cases in the NextGen Inception Phase6.22. History6.23. Recommended Resources
7. Other Requirements
IntroductionOther Requirement Artifacts7.1. How Complete are these Examples?7.2. Guideline: Should We Analyze These Thoroughly During Inception?Reliable Specifications: An Oxymoron?7.3. Guideline: Should These Artifacts be at the Project Website?7.4. NextGen Example: (Partial) Supplementary Specification7.5. Commentary: Supplementary SpecificationQuality AttributesFunctionality in the Supplementary Spec? Shouldn't that be in the Use Cases?Application-Specific Domain (Business) RulesInformation in Domains of Interest7.6. NextGen Example: (Partial) Vision7.7. Commentary: VisionThe Key High-Level Goals and Problems of the StakeholdersGuideline: What are Some Facilitation Methods?Summary of System FeaturesGuideline: How to Write the Feature List?Guideline: Should We Duplicate Other Requirements in the Vision?Guideline: Should You Write the Vision or Use Cases First?7.8. NextGen Example: A (Partial) Glossary7.9. Commentary: Glossary (Data Dictionary)Glossary as Data DictionaryGuideline: Can We use the Glossary to Record Composite Terms?7.10. NextGen Example: Business Rules (Domain Rules)7.11. Commentary: Domain Rules7.12. Process: Evolutionary Requirements in Iterative MethodsInceptionElaborationConstruction7.13. Recommended Resources
3. Elaboration Iteration 1—Basics
8. Iteration 1—Basics
Introduction8.1. Iteration 1 Requirements and Emphasis: Core OOA/D SkillsNextGen POSMonopolyIn Iterative Development We Don't Implement All the Requirements at OnceIncremental Development for the Same Use Case Across Iterations8.2. Process: Inception and ElaborationWhat Happened in Inception?On to ElaborationWhat Artifacts May Start in Elaboration?You Know You Didn't Understand Elaboration When...8.3. Process: Planning the Next Iteration
9. Domain Models
Introduction9.1. Example9.2. What is a Domain Model?Definition: Why Call a Domain Model a “Visual Dictionary”?Definition: Is a Domain Model a Picture of Software Business Objects?Definition: What are Two Traditional Meanings of “Domain Model”?Definition: What are Conceptual Classes?Definition: Are Domain and Data Models the Same Thing?9.3. Motivation: Why Create a Domain Model?Motivation: Lower Representational Gap with OO Modeling9.4. Guideline: How to Create a Domain Model?9.5. Guideline: How to Find Conceptual Classes?What are Three Strategies to Find Conceptual Classes?Method 2: Use a Category ListMethod 3: Finding Conceptual Classes with Noun Phrase Identification9.6. Example: Find and Draw Conceptual ClassesCase Study: POS DomainCase Study: Monopoly Domain9.7. Guideline: Agile Modeling—Sketching a Class Diagram9.8. Guideline: Agile Modeling—Maintain the Model in a Tool?9.9. Guideline: Report Objects—Include 'Receipt' in the Model?9.10. Guideline: Think Like a Mapmaker; Use Domain Terms9.11. Guideline: How to Model the Unreal World?9.12. Guideline: A Common Mistake with Attributes vs. Classes9.13. Guideline: When to Model with 'Description' Classes?Motivation: Why Use 'Description' Classes?Guideline: When Are Description Classes Useful?Example: Descriptions in the Airline Domain9.14. AssociationsGuideline: When to Show an Association?Guideline: Why Should We Avoid Adding Many Associations?Perspectives: Will the Associations Be Implemented In Software?Applying UML: Association NotationGuideline: How to Name an Association in UML?Applying UML: RolesApplying UML: MultiplicityApplying UML: Multiple Associations Between Two ClassesGuideline: How to Find Associations with a Common Associations List9.15. Example: Associations in the Domain ModelsCase Study: NextGen POSCase Study: Monopoly9.16. AttributesGuideline: When to Show Attributes?Applying UML: Attribute NotationMore NotationGuideline: Where to Record Attribute Requirements?Derived AttributesGuideline: What are Suitable Attribute Types?Focus on Data Type Attributes in the Domain ModelData TypesPerspectives: What About Attributes in Code?Guideline: When to Define New Data Type Classes?Applying UML: Where to Illustrate These Data Type Classes?Guideline: No Attributes Representing Foreign KeysGuideline: Modeling Quantities and Units9.17. Example: Attributes in the Domain ModelsCase Study: NextGen POSCase Study: Monopoly9.18. Conclusion: Is the Domain Model Correct?9.19. Process: Iterative and Evolutionary Domain ModelingDomain Models Within the UPInceptionElaborationThe UP Business Object Model vs. Domain Model9.20. Recommended Resources
10. System Sequence Diagrams
Introduction10.1. Example: NextGen SSD10.2. What are System Sequence Diagrams?10.3. Motivation: Why Draw an SSD?10.4. Applying UML: Sequence DiagramsLoops in Sequence Diagrams10.5. What is the Relationship Between SSDs and Use Cases?Applying UML: Should We Show Use Case Text in the SSD?10.6. How to Name System Events and Operations?10.7. How to Model SSDs Involving Other External Systems?10.8. What SSD Information to Place in the Glossary?10.9. Example: Monopoly SSD10.10. Process: Iterative and Evolutionary SSDsSSDs Within the UPUP Phases10.11. History and Recommended Resources
11. Operation Contracts
Introduction11.1. Example11.2. Definition: What are the Sections of a Contract?11.3. Definition: What is a System Operation?11.4. Definition: PostconditionsHow are Postconditions Related to the Domain Model?Motivation: Why Postconditions?Guideline: How to Write a Postcondition?Analogy: The Spirit of Postconditions: The Stage and CurtainGuideline: How Complete Should Postconditions Be? Agile vs. Heavy Analysis11.5. Example: enterItem PostconditionsInstance Creation and DeletionAttribute ModificationAssociations Formed and Broken11.6. Guideline: Should We Update the Domain Model?11.7. Guideline: When Are Contracts Useful?11.8. Guideline: How to Create and Write ContractsWriting ContractsWhat's the Most Common Mistake?11.9. Example: NextGen POS ContractsSystem Operations of the Process Sale Use CaseChanges to the POS Domain Model11.10. Example: Monopoly Contracts11.11. Applying UML: Operations, Contracts, and the OCLOperation Contracts Expressed with the OCL11.12. Process: Operation Contracts Within the UPPhases11.13. HistoryProgramming Language Support for Contracts11.14. Recommended Resources
12. Requirements to Design—Iteratively
Introduction12.1. Iteratively Do the Right Thing, Do the Thing Right12.2. Provoking Early Change12.3. Didn't All That Analysis and Modeling Take Weeks To Do?
13. Logical Architecture and UML Package Diagrams
Introduction13.1. Example13.2. What is the Logical Architecture? And Layers?13.3. What Layers are the Focus in the Case Studies?13.4. What is Software Architecture?13.5. Applying UML: Package DiagramsUML Tools: Reverse-engineer Package Diagrams from Code13.6. Guideline: Design with LayersBenefits of Using LayersGuideline: Cohesive Responsibilities; Maintain a Separation of ConcernsCode: Mapping Code Organization to Layers and UML PackagesUML Tools: Reverse-engineer Package Diagrams from CodeDefinition: Domain Layer vs. Application Logic Layer; Domain ObjectsWhat's the Relationship Between the Domain Layer and Domain Model?Definition: Tiers, Layers, and PartitionsGuideline: Don't Show External Resources as the Bottom Layer13.7. Guideline: The Model-View Separation Principle13.8. What's the Connection Between SSDs, System Operations, and Layers?13.9. Example: NextGen Logical Architecture and Package Diagram13.10. Example: Monopoly Logical Architecture?13.11. Recommended Resources
14. On to Object Design
Introduction14.1. Agile Modeling and Lightweight UML Drawing14.2. UML CASE Tools14.3. How Much Time Spent Drawing UML Before Coding?14.4. Designing Objects: What are Static and Dynamic Modeling?Dynamic Object ModelingStatic Object Modeling14.5. The Importance of Object Design Skill over UML Notation Skill14.6. Other Object Design Techniques: CRC Cards
15. UML Interaction Diagrams
Introduction15.1. Sequence and Communication DiagramsWhat are the Strengths and Weaknesses of Sequence vs. Communication Diagrams?Example Sequence Diagram: makePaymentExample Communication Diagram: makePayment15.2. Novice UML Modelers Don't Pay Enough Attention to Interaction Diagrams!15.3. Common UML Interaction Diagram NotationIllustrating Participants with Lifeline BoxesBasic Message Expression SyntaxSingleton Objects15.4. Basic Sequence Diagram NotationLifeline Boxes and LifelinesMessagesFocus of Control and Execution Specification BarsIllustrating Reply or ReturnsMessages to “self” or “this”Creation of InstancesObject Lifelines and Object DestructionDiagram Frames in UML Sequence DiagramsLoopingConditional MessagesConditional Messages in UML 1.x Style—Still Useful?Mutually Exclusive Conditional MessagesIteration Over a CollectionNesting of FramesHow to Relate Interaction Diagrams?Messages to Classes to Invoke Static (or Class) MethodsPolymorphic Messages and CasesAsynchronous and Synchronous Calls15.5. Basic Communication Diagram NotationLinksMessagesMessages to “self” or “this”Creation of InstancesMessage Number SequencingConditional MessagesMutually Exclusive Conditional PathsIteration or LoopingIteration Over a CollectionMessages to a Classes to Invoke Static (Class) MethodsPolymorphic Messages and CasesAsynchronous and Synchronous Calls
16. UML Class Diagrams
Introduction16.1. Applying UML: Common Class Diagram Notation16.2. Definition: Design Class Diagram16.3. Definition: Classifier16.4. Ways to Show UML Attributes: Attribute Text and Association LinesGuideline: When to Use Attribute Text versus Association Lines for Attributes?The UML Notation for an Association EndHow to Show Collection Attributes with Attribute Text and Association Lines?16.5. Note Symbols: Notes, Comments, Constraints, and Method Bodies16.6. Operations and MethodsOperationsHow to Show Methods in Class Diagrams?Operation Issues in DCDsThe create OperationOperations to Access Attributes16.7. Keywords16.8. Stereotypes, Profiles, and Tags16.9. UML Properties and Property Strings16.10. Generalization, Abstract Classes, Abstract Operations16.11. DependencyDependency Labels16.12. Interfaces16.13. Composition Over Aggregation16.14. Constraints16.15. Qualified Association16.16. Association Class16.17. Singleton Classes16.18. Template Classes and Interfaces16.19. User-Defined Compartments16.20. Active Class16.21. What's the Relationship Between Interaction and Class Diagrams?
17. GRASP: Designing Objects with Responsibilities
17.1. UML versus Design Principles17.2. Object Design: Example Inputs, Activities, and OutputsWhat Are Inputs to Object Design?What Are Activities of Object Design?What Are the Outputs?17.3. Responsibilities and Responsibility-Driven Design17.4. GRASP: A Methodical Approach to Basic OO Design17.5. What's the Connection Between Responsibilities, GRASP, and UML Diagrams?17.6. What are Patterns?Patterns Have Names—Important!'New Pattern' is an OxymoronThe Gang-of-Four Design Patterns BookIs GRASP a Set of Patterns or Principles?17.7. Where are We Now?17.8. A Short Example of Object Design with GRASPCreatorProblem: Who creates the Square object?Information ExpertProblem: Who knows about a Square object, given a key?Low CouplingQuestion: Why Board over Dog?ControllerHigh Cohesion17.9. Applying GRASP to Object Design17.10. Creator17.11. Information Expert (or Expert)17.12. Low CouplingPick Your Battles17.13. ControllerWeb UIs and Server-Side Application of ControllerImplementation with Java Swing: Rich Client UIImplementation with Java Struts: Client Browser and WebUIBloated ControllersUI Layer Does Not Handle System EventsMessage Handling Systems and the Command Pattern17.14. High CohesionAnother Classic Principle: Modular DesignCohesion and Coupling; Yin and Yang17.15. Recommended Resources
18. Object Design Examples with GRASP
IntroductionThe No-Magic Zone18.1. What is a Use Case Realization?18.2. Artifact CommentsSSDs, System Operations, Interaction Diagrams, and Use Case RealizationsUse Cases and Use Case RealizationsInvolve the Customer FrequentlyOperation Contracts and Use Case RealizationsThe Domain Model and Use Case Realizations18.3. What's Next?18.4. Use Case Realizations for the NextGen IterationInitialization and the 'Start Up' Use CaseHow to Design makeNewSale?Choosing the Controller ClassCreating a New SaleConclusionHow to Design enterItem?Choosing the Controller ClassDisplay Item Description and Price?Creating a New SalesLineItemFinding a ProductDescriptionVisibility to a ProductCatalogThe Final DesignRetrieving ProductDescriptions from a DatabaseHow to Design endSale?Choosing the Controller ClassSetting the Sale.isComplete AttributeCalculating the Sale TotalThe Sale.getTotal DesignHow to Design makePayment?Creating the PaymentLogging a SaleCalculating the BalanceThe Final NextGen DCD for Iteration-1How to Connect the UI Layer to the Domain Layer?Initialization and the 'Start Up' Use CaseWhen to Create the Initialization Design?How do Applications Start Up?Choosing the Initial Domain ObjectStore.create Design18.5. Use Case Realizations for the Monopoly IterationHow to Design playGame?Choosing the Controller ClassThe Game-Loop AlgorithmWho is Responsible for Controlling the Game Loop?Who Takes a Turn?Taking a TurnWho Coordinates All This?The Problem of VisibilityThe Final Design of playGameThe Command-Query Separation PrincipleMotivation: Why Bother?Initialization and the 'Start Up' Use Case18.6. Process: Iterative and Evolutionary Object DesignObject Design Within the UP18.7. Summary
19. Designing for Visibility
Introduction19.1. Visibility Between Objects19.2. What is Visibility?Attribute VisibilityParameter VisibilityLocal VisibilityGlobal Visibility
20. Mapping Designs to Code
IntroductionLanguage Samples20.1. Programming and Iterative, Evolutionary DevelopmentCreativity and Change During Implementation20.2. Mapping Designs to Code20.3. Creating Class Definitions from DCDsDefining a Class with Method Signatures and Attributes20.4. Creating Methods from Interaction DiagramsThe Register.enterItem Method20.5. Collection Classes in Code20.6. Exceptions and Error Handling20.7. Defining the Sale.makeLineItem Method20.8. Order of Implementation20.9. Test-Driven or Test-First Development20.10. Summary of Mapping Designs to Code20.11. Introduction to the NextGen POS Program SolutionClass PaymentClass ProductCatalogClass RegisterClass ProductDescriptionClass SaleClass SalesLineItemClass Store20.12. Introduction to the Monopoly Program SolutionClass SquareClass PieceClass DieClass BoardClass PlayerClass MonopolyGame
21. Test-Driven Development and Refactoring
Introduction21.1. Test-Driven DevelopmentExampleIDE Support for TDD and xUnit21.2. RefactoringExampleIDE Support for Refactoring21.3. Recommended Resources
22. UML Tools and UML as Blueprint
Introduction22.1. Forward, Reverse, and Round-Trip Engineering22.2. What is a Common Report of Valuable Features?22.3. What to Look For in a Tool?22.4. If Sketching UML, How to Update the Diagrams After Coding?22.5. Recommended Resources
4. Elaboration Iteration 2—More Patterns
23. Iteration 2—More Patterns
Introduction23.1. From Iteration 1 to 2Simplifications in the Case Study23.2. Iteration-2 Requirements and Emphasis: Object Design and PatternsNextGen POSIncremental Development for a Use Case Across IterationsMonopoly
24. Quick Analysis Update
Introduction24.1. Case Study: NextGen POSUse CasesSSDsDomain ModelSystem Operation Contracts24.2. Case Study: MonopolyUse Cases, etc.Domain Model
25. GRASP: More Objects with Responsibilities
Introduction25.1. PolymorphismNextGen Problem: How Support Third-Party Tax Calculators?Monopoly Problem: How to Design for Different Square Actions?Guideline: When to Design with Interfaces?25.2. Pure FabricationNextGen Problem: Saving a Sale Object in a DatabaseMonopoly Problem: Handling the Dice25.3. IndirectionTaxCalculatorAdapterPersistentStorage25.4. Protected VariationsMechanisms Motivated by Protected VariationsCore Protected Variations MechanismsData-Driven DesignsService LookupInterpreter-Driven DesignsReflective or Meta-Level DesignsUniform AccessStandard LanguagesThe Liskov Substitution Principle (LSP)Caution: Speculative PV and Picking Your BattlesPV is applied to both variation and evolution points.Information HidingOpen-Closed Principle
26. Applying GoF Design Patterns
IntroductionThe Gang-of-Four Design Patterns26.1. Adapter (GoF)26.2. Some GRASP Principles as a Generalization of Other PatternsWhat's the Problem? Pattern Overload!A Solution: See the Underlying PrinciplesExample: Adapter and GRASP26.3. “Analysis” Discoveries During Design: Domain Model26.4. Factory26.5. Singleton (GoF)Implementation and Design Issues26.6. Conclusion of the External Services with Varying Interfaces Problem26.7. Strategy (GoF)Creating a Strategy with a FactoryReading and Initializing the Percentage ValueSummary26.8. Composite (GoF) and Other Design PrinciplesCreating Multiple SalePricingStrategiesConsidering GRASP and Other Principles in the DesignSummary26.9. Facade (GoF)Summary26.10. Observer/Publish-Subscribe/Delegation Event Model (GoF)Why Is It Called Observer, Publish-Subscribe, or Delegation Event Model?Observer Is Not Only for Connecting UIs and Model ObjectsOne Publisher Can Have Many Subscribers for an EventImplementationEventsJavaSummary26.11. Conclusion26.12. Recommended Resources
5. Elaboration Iteration 3—Intermediate Topics
27. Iteration 3—Intermediate Topics
Introduction27.1. NextGen POS27.2. Monopoly
28. UML Activity Diagrams and Modeling
Introduction28.1. Example28.2. How to Apply Activity Diagrams?Business Process ModelingData Flow ModelingConcurrent Programming and Parallel Algorithm Modeling28.3. More UML Activity Diagram Notation28.4. Guidelines28.5. Example: NextGen Activity Diagram28.6. Process: Activity Diagrams in the UP28.7. Background
29. UML State Machine Diagrams and Modeling
Introduction29.1. Example29.2. Definitions: Events, States, and Transitions29.3. How to Apply State Machine Diagrams?State-Independent and State-Dependent ObjectsModeling State-dependent ObjectsComplex Reactive ObjectsProtocols and Legal Sequences29.4. More UML State Machine Diagram NotationTransition Actions and GuardsNested States29.5. Example: UI Navigation Modeling with State Machines29.6. Example: NextGen Use Case State Machine Diagram29.7. Process: State Machine Diagrams in the UP29.8. Recommended Resources
30. Relating Use Cases
IntroductionGuideline: Avoid Agonizing Over Use Case Relationships30.1. The include RelationshipUsing include with Asynchronous Event HandlingSummary30.2. Terminology: Concrete, Abstract, Base, and Addition Use Cases30.3. The extend Relationship30.4. The generalize Relationship30.5. Use Case Diagrams
31. Domain Model Refinement
Introduction31.1. New Concepts for the NextGen Domain ModelConcepts Category ListNoun Phrase Identification from the Use CasesAuthorization Service Transactions31.2. Generalization31.3. Defining Conceptual Superclasses and SubclassesGeneralization and Conceptual Class DefinitionGeneralization and Class SetsConceptual Subclass Definition ConformanceConceptual Subclass Set ConformanceWhat Is a Correct Conceptual Subclass?31.4. When to Define a Conceptual Subclass?Motivations to Partition a Conceptual Class into Subclasses31.5. When to Define a Conceptual Superclass?31.6. NextGen POS Conceptual Class HierarchiesPayment ClassesAuthorization Service ClassesAuthorization Transaction Classes31.7. Abstract Conceptual ClassesAbstract Class Notation in the UML31.8. Modeling Changing States31.9. Class Hierarchies and Inheritance in Software31.10. Association Classes31.11. Aggregation and CompositionHow to Identify CompositionA Benefit of Showing CompositionComposition in the NextGen Domain Model31.12. Time Intervals and Product Prices—Fixing an Iteration 1 “Error”31.13. Association Role Names31.14. Roles as Concepts versus Roles in Associations31.15. Derived Elements31.16. Qualified Associations31.17. Reflexive Associations31.18. Using Packages to Organize the Domain ModelOwnership and ReferencesPackage DependenciesHow to Partition the Domain ModelPOS Domain Model PackagesCore/Misc PackagePaymentsProductsSalesAuthorization Transactions31.19. Example: Monopoly Domain Model Refinements
32. More SSDs and Contracts
Introduction32.1. NextGen POSNew System Sequence DiagramsCommon Beginning of Process Sale ScenarioCredit PaymentCheck PaymentNew System OperationsNew System Operation Contracts
33. Architectural Analysis
Introduction33.1. Process: When Do We Start Architectural Analysis?33.2. Definition: Variation and Evolution Points33.3. Architectural Analysis33.4. Common Steps in Architectural Analysis33.5. The Science: Identification and Analysis of Architectural FactorsArchitectural FactorsQuality ScenariosPick Your BattlesDescribing FactorsFactors and UP Artifacts33.6. Example: Partial NextGen POS Architectural Factor Table33.7. The Art: Resolution of Architectural FactorsRecording Architectural Alternatives, Decisions, and MotivationPrioritiesPriorities and Evolution Points: Under- and Over-engineeringBasic Architectural Design PrinciplesSeparation of Concerns and Localization of ImpactPromotion of Architectural Patterns33.8. Summary of Themes in Architectural Analysis33.9. Process: Iterative Architecture in the UPArchitectural Information in the UP ArtifactsPhases33.10. Recommended Resources
34. Logical Architecture Refinement
Introduction34.1. Example: NextGen Logical ArchitectureInter-Layer and Inter-Package CouplingInter-Layer and Inter-Package Interaction Scenarios34.2. Collaborations with the Layers PatternSimple Packages versus SubsystemsFacadeSession Facades and the Application LayerControllerSystem Operations and LayersUpward Collaboration with ObserverRelaxed Layered CouplingIsn't Coupling to Technical and Foundation Layers Dangerous?34.3. Other Layer Pattern IssuesLogical versus Process and Deployment Views of the ArchitectureIs the Application Layer Optional?Fuzzy Set Membership in Different LayersContraindications and Liabilities for LayersKnown UsesVirtual Machines and Operating SystemsInformation Systems: The Classic Three-Tier ArchitectureRelated PatternsAlso Known As34.4. Model-View Separation and “Upward” Communication34.5. Recommended Resources
35. Package Design
IntroductionSource Code Physical Design in the Implementation Model35.1. Package Organization GuidelinesGuideline: Package Functionally Cohesive Vertical and Horizontal SlicesGuideline: Package a Family of InterfacesGuideline: Package by Work and by Clusters of Unstable ClassesGuideline: Most Responsible Are Most StableGuideline: Factor out Independent TypesGuideline: Use Factories to Reduce Dependency on Concrete PackagesDomain Object Factory PatternGuideline: No Cycles in Packages35.2. Recommended Resources
36. More Object Design with GoF Patterns
Introduction36.1. Example: NextGen POS36.2. Failover to Local Services; Performance with Local CachingCaching StrategiesStale CacheThreads in the UML36.3. Handling FailureThrowing ExceptionsExceptions in the UMLHandling Errors36.4. Failover to Local Services with a Proxy (GoF)36.5. Designing for Non-Functional or Quality Requirements36.6. Accessing External Physical Devices with Adapters36.7. Abstract Factory (GoF) for Families of Related ObjectsAn Abstract Class Abstract Factory36.8. Handling Payments with Polymorphism and Do It MyselfFine-Grained Classes?Credit Payment AuthorizationRelevant Credit Payment Domain InformationA Design Scenario36.9. Example: Monopoly36.10. ConclusionCaution: Pattern-itis
37. Designing a Persistence Framework with Patterns
Introduction37.1. The Problem: Persistent ObjectsStorage Mechanisms and Persistent Objects37.2. The Solution: A Persistence Service from a Persistence Framework37.3. FrameworksFrameworks Are Reusable37.4. Requirements for the Persistence Service and Framework37.5. Key Ideas37.6. Pattern: Representing Objects as Tables37.7. UML Data Modeling Profile37.8. Pattern: Object Identifier37.9. Accessing a Persistence Service with a Facade37.10. Mapping Objects: Database Mapper or Database Broker PatternMetadata-Based Mappers37.11. Framework Design with the Template Method Pattern37.12. Materialization with the Template Method PatternThe UP and the Software Architecture DocumentSynchronized or Guarded Methods in the UML37.13. Configuring Mappers with a MapperFactory37.14. Pattern: Cache Management37.15. Consolidating and Hiding SQL Statements in One Class37.16. Transactional States and the State Pattern37.17. Designing a Transaction with the Command Pattern37.18. Lazy Materialization with a Virtual ProxyWho Creates the Virtual Proxy?Implementation of a Virtual Proxy37.19. How to Represent Relationships in Tables37.20. PersistentObject Superclass and Separation of Concerns37.21. Unresolved Issues
38. UML Deployment and Component Diagrams
38.1. Deployment Diagrams38.2. Component Diagrams
39. Documenting Architecture: UML & the N+1 View Model
Introduction39.1. The SAD and Its Architectural ViewsThe Software Architect DocumentMotivation: Why Create a SAD?Architectural ViewsThe N+1 (or 4+1) View ModelArchitectural Views in More DetailGuideline: Don't Forget the Motivation!39.2. Notation: The Structure of a SAD39.3. Example: A NextGen POS SAD39.4. Example: A Jakarta Struts SAD39.5. Process: Iterative Architectural DocumentationUP and the SAD39.6. Recommended Resources
6. Special Topics
40. More on Iterative Development and Agile Project Management
Introduction40.1. How to Plan an Iteration?40.2. Adaptive versus Predictive Planning40.3. Phase and Iteration Plans40.4. How to Plan Iterations with Use Cases and Scenarios?40.5. The (In)Validity of Early Estimates40.6. Organizing Project Artifacts40.7. You Know You Didn't Understand Iterative Planning When...40.8. Recommended Resources
Bibliography
Glossary
Inside Front Cover
Praise for Applying UML and Patterns
Inside Back Cover

Content preview from Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition

Chapter 21. Test-Driven Development and Refactoring

	Logic is the art of going wrong with confidence.
	--Joseph Wood Krutch

Introduction

Extreme Programming (XP) promoted an important testing practice: writing the tests first. It also promoted continuously refactoring code to improve its quality—less duplication, increased clarity, and so forth. Modern tools support both practices, and many OO developers swear by their value.

Test-Driven Development

An excellent practice promoted by the iterative and agile XP method [Beck00], and applicable to the UP (as ...

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

UML Distilled: A Brief Guide to the Standard Object Modeling Language, Third Edition

Publisher Resources

ISBN: 0131489062Purchase book

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design