Naming Associations
by Craig Larman
Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process, Second Edition
- Copyright
- Sample UML Notation
- Praise for Applying UML and Patterns
- Foreword
- Preface
- Introduction
- Object-Oriented Analysis and Design
- Iterative Development and the Unified Process
- Introduction
- 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
- Inception
- Inception
- Understanding Requirements
- Use-Case Model: Writing Requirements in Context
- Introduction
- 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
- Introduction
- 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
- Elaboration Iteration 1
- Use-Case Model: Drawing System Sequence Diagrams
- Moving on to Iteration 1
- Introduction
- 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
- Introduction
- 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
- Introduction
- 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
- Use-Case Model: Adding Detail with Operation Contracts
- Introduction
- 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
- Interaction Diagram Notation
- GRASP: Designing Objects with Responsibilities
- Introduction
- 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
- Introduction
- Use-Case Realizations
- Artifact Comments
- Use-Case Realizations for the NextGen Iteration
- Object Design: makeNewSale
- Object Design: enterItem
- Object Design: endSale
- Object Design: makePayment
- Object Design: startUp
- Connecting the UI Layer to the Domain Layer
- Use-Case Realizations Within the UP
- Summary
- Design Model: Determining Visibility
- Design Model: Creating Design Class Diagrams
- Implementation Model: Mapping Designs to Code
- Introduction
- 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 to the Program Solution
- Use-Case Model: Drawing System Sequence Diagrams
- Elaboration Iteration 2
- Iteration 2 and its Requirements
- GRASP: More Patterns for Assigning Responsibilities
- Designing Use-Case Realizations with GoF Design Patterns
- Introduction
- Adapter (GoF)
- “Analysis” Discoveries During Design: Domain Model
- Factory (GoF)
- Singleton (GoF)
- Conclusion of the External Services with Varying Interfaces Problem
- Strategy (GoF)
- Composite (GoF) and Other Design Principles
- Facade (GoF)
- Observer/Publish-Subscribe/Delegation Event Model (GoF)
- Conclusion
- Further Readings
- Elaboration Iteration 3
- Iteration 3 and Its Requirements
- Relating Use Cases
- Modeling Generalization
- Introduction
- New Concepts for the Domain Model
- Generalization
- Defining Conceptual Superclasses and Subclasses
- When to Define a Conceptual Subclass
- When to Define a Conceptual Superclass
- NextGen POS Conceptual Class Hierarchies
- Abstract Conceptual Classes
- Modeling Changing States
- Class Hierarchies and Inheritance in Software
- Refining the Domain Model
- Introduction
- Association Classes
- Aggregation and Composition
- Time Intervals and Product Prices—Fixing an Iteration 1 “Error”
- Association Role Names
- Roles as Concepts vs. Roles in Associations
- Derived Elements
- Qualified Associations
- Reflexive Associations
- Ordered Elements
- Using Packages to Organize the Domain Model
- Adding New SSDs and Contracts
- Modeling Behavior in Statechart Diagrams
- Introduction
- Events, States, and Transitions
- Statechart Diagrams
- Statechart Diagrams in the UP?
- Use Case Statechart Diagrams
- Use Case Statechart Diagrams for the POS Application
- Classes that Benefit from Statechart Diagrams
- Illustrating External and Interval Events
- Additional Statechart Diagram Notation
- Further Readings
- Designing the Logical Architecture with Patterns
- Organizing the Design and Implementation Model Packages
- Introduction to Architectural Analysis and the SAD
- Introduction
- Architectural Analysis
- Types and Views of Architecture
- The Science: Identification and Analysis of Architectural Factors
- Example: Partial NextGen POS Architectural Factor Table
- The Art: Resolution of Architectural Factors
- Summary of Themes in Architectural Analysis
- Architectural Analysis within the UP
- Further Readings
- Designing More Use-Case Realizations with Objects and Patterns
- Introduction
- Failover to Local Services; Performance with Local Caching
- Handling Failure
- Failover to Local Services with a Proxy (GoF)
- Designing for Non-Functional or Quality Requirements
- Accessing External Physical Devices with Adapters; Buy vs. Build
- Abstract Factory (GoF) for Families of Related Objects
- Handling Payments with Polymorphism and Do It Myself
- Conclusion
- Designing a Persistence Framework with Patterns
- Introduction
- The Problem: Persistent Objects
- The Solution: A Persistence Service from a Persistence Framework
- Frameworks
- Requirements for the Persistence Service and Framework
- Key Ideas
- Pattern: Representing Objects as Tables
- UML Data Modeling Profile
- Pattern: Object Identifier
- Accessing a Persistence Service with a Facade
- Mapping Objects: Database Mapper or Database Broker Pattern
- Framework Design with the Template Method Pattern
- Materialization with the Template Method Pattern
- Configuring Mappers with a MapperFactory
- Pattern: Cache Management
- Consolidating and Hiding SQL Statements in One Class
- Transactional States and the State Pattern
- Designing a Transaction with the Command Pattern
- Lazy Materialization with a Virtual Proxy
- How to Represent Relationships in Tables
- PersistentObject Superclass and Separation of Concerns
- Unresolved Issues
- Special Topics
- On Drawing and Tools
- Introduction to Iterative Planning and Project Issues
- Introduction
- Ranking Requirements
- Ranking Project Risks
- Adaptive vs. Predictive Planning
- Phase and Iteration Plans
- Iteration Plan: What to Do in the Next Iteration?
- Requirements Tracking Across Iterations
- The (In)Validity of Early Estimates
- Organizing Project Artifacts
- Some Team Iteration Scheduling Issues
- You Know You Didn't Understand Planning in the UP When...
- Further Readings
- Comments on Iterative Development and the UP
- Additional UP Best Practices and Concepts
- The Construction and Transition Phases
- Other Interesting Practices
- Motivations for Timeboxing an Iteration
- The Sequential “Waterfall” Lifecycle
- Usability Engineering and User Interface Design
- The UP Analysis Model
- The RUP Product
- The Challenge and Myths of Reuse
- More UML Notation
- Bibliography
- Glossary
- Sample UML Notation
- Index
11.7. Naming Associations
|
Name an association based on a TypeName-VerbPhrase-TypeName format where the verb phrase creates a sequence that is readable and meaningful in the model context. |
Association names should start with a capital letter, since an association represents a classifier of links between instances; in the UML, classifiers should start with a capital letter. Two common and equally legal formats for a compound association name are:
Paid-by
PaidBy
In Figure 11.6, the default direction to read an association name is left to right or top to bottom. This is not a UML default, but a common convention.
Figure 11.6. Association names.
-
No Comment
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.