0.0 by Claude

Chapter 7: Interaction Diagrams (交互图)

7.1 Introduction to Interaction Diagrams

Core Concepts

• Collaboration (协作): A group of objects or classes that work together to provide functionality or behavior
• Interaction (交互): Defines message passing between lifelines (e.g., objects) within a collaboration context to achieve specific behavior
• Object Messaging (对象消息传递): Objects communicate by sending messages
  • Example: currentadvertCost = anAdvert.getCost()

Types of Interaction Diagrams

1. Interaction Sequence Diagrams (交互序列图)
2. Communication/Collaboration Diagrams (通信/协作图)
3. Interaction Overview Diagrams (交互概览图)
4. Timing Diagrams (时序图)

Design Resilience

• Resilient Design (弹性设计): When changes in requirements cause proportional changes in software
• Poor resilience: Small requirement change → Large software change
• Good resilience: Equivalent areas of change between requirements and software

7.2 Sequence Diagrams (序列图)

Key Characteristics

• Shows interaction between lifelines (生命线) arranged in time sequence
• Vertical dimension represents time
• Horizontal dimension shows objects involved in interaction
• Used to represent detailed object interaction for:
  • One use case
  • One operation

Basic Elements

1. Lifelines

• Represent objects, subsystems, or other connectable objects
• Shown as rectangles with dashed lines extending downward

2. Messages

• Synchronous Message (同步消息):

  • Solid arrow with filled arrowhead
  • Invoking operation suspends until control returns
  • Causes blocking behavior

• Asynchronous Message (异步消息):

  • Solid arrow with open arrowhead
  • Does not halt execution while awaiting return
  • Non-blocking behavior

• Reply Message (返回消息):

  • Dashed arrow
  • Returns control to originating object
  • Optional to show (implied at end of activation)

3. Activation/Execution

• Activation Rectangle (激活矩形): Shows when an operation is executing
• Focus of Control (控制焦点):
  • Shaded parts indicate active processing
  • Unshaded parts indicate waiting for return

4. Object Creation and Destruction

• Object Creation: Dashed arrow pointing to new object
• Object Destruction: X mark at end of lifeline

Interaction Operators (交互操作符)

Operator	Description	Usage
alt	Alternative behaviors	Shows if-else branching
opt	Optional behavior	Executes only if condition is true
loop	Iteration	Repeats until condition is false
break	Exception handling	Exits enclosing interaction
par	Parallel execution	Concurrent operations
seq	Weak sequencing	Maintains order within operands
strict	Strict sequencing	Enforces strict execution order
neg	Invalid scenario	Describes what should not happen
critical	Critical region	No interleaving allowed
ref	Reference	References another interaction

Three-Tier Design Integration

• Boundary Objects (边界对象): Manage dialogue between actor and system
  • Example: :AddAdvertUI
• Control Objects (控制对象): Manage overall object communication
  • Example: :AddAdvert
• Entity Objects (实体对象): Represent problem domain/data layer
  • Example: :Campaign, :Advert

Best Practices for Sequence Diagrams

1. Decide modeling level
2. Identify main elements involved
3. Consider alternative scenarios
4. Draw outline structure
5. Add detailed interactions
6. Check consistency with linked diagrams
7. Verify consistency with class diagrams

7.3 Collaboration/Communication Diagrams (协作/通信图)

Key Characteristics

• Shows object interaction without time dimension
• Focuses on links between objects
• Uses sequence numbers to indicate message order
• Equivalent to sequence diagrams but different visual representation

Message Labeling Syntax

Message Type	Syntax Example
Simple Message	4: addNewAdvert()
Nested Call with Return	3.1.2: name:= getName()
Conditional Message	[balance > 0] 5: debit(amount)
Synchronization	3.1a, 3.1b / 4:playVideo()

Message Types

1. Constructor Message: Creates new object (e.g., customer())
2. Destructor Message: Destroys object (e.g., obj1.destroy())
3. Read Message: Requests information (e.g., aBank1.openingHours())
4. Update Message: Updates object state (e.g., acustomer1.newCreditRating())
5. Collaborative Message: Requests assistance (e.g., aBank1.loanPlease())
6. Input/Output Message: GUI interactions (e.g., displayBalance())

Sequence Numbering

• Nested Style: Indicates control nesting
  • Example: 3, 3.1, 3.1.1, 3.1.2
• Shows hierarchical message flow

7.4 Interaction Overview Diagrams (交互概览图)

Purpose

• Variant of activity diagrams
• Shows flow of control in interactions
• Combines multiple interaction fragments

Key Elements

• Interaction Occurrences: References to other interactions (ref)
• Inline Interactions: Embedded sequence diagrams
• Decision Nodes: Show branching logic
• Initial/Final Nodes: Start and end points

Usage

• Break down complex interactions into manageable fragments
• Show high-level interaction flow
• Combine multiple sequence diagrams

7.5 Timing Diagrams (时序图)

Purpose

• Shows how time constraints affect interactions
• Displays state changes over time
• New feature in UML 2.0

Key Elements

• Lifeline States: Different states of objects over time
• State Transitions: Sloped lines show duration of change
• Time Constraints: Specify timing requirements (e.g., {t..t+3s})
• Messages: Show communication between lifelines

Visual Representation

• Horizontal axis: Time progression
• Vertical axis: Different states or lifelines
• Messages shown as arrows between lifelines

7.6 Model Consistency (模型一致性)

Critical Consistency Rules

1. Operation Allocation

   • Must match class diagram
   • Message signatures must match operation signatures

2. Object References

   • Sender must have reference to receiver
   • Either through association or parameter passing

3. Interaction Diagram Consistency

   • All forms must be consistent with each other
   • Messages must align with state machines

4. State Changes

   • Implicit changes in interactions must match explicit state machine transitions

5. Timing Consistency

   • Timing diagrams must align with sequence diagrams and state machines

Message Pathways

• Carefully analyze how objects obtain references
• Key for determining association design
• Enforced through CASE tools

7.7 When to Use Interaction Diagrams

Use Interaction Diagrams When:

• Capturing user requirements
  • Describe behavior of several objects within single use case
  • Show collaborations among objects
• Testing completeness
  • Validate state and activity diagrams against scenarios

Avoid Interaction Diagrams When:

• Defining single class behavior → Use state diagrams instead
• Describing behavior across many use cases → Use activity diagrams
• Modeling many threads → Consider activity diagrams

7.8 Development Workflow

Analysis Workflow

1. Start from use cases
2. Identify key objects and interactions
3. Create simple collaboration/sequence diagrams
4. Focus on problem domain

Design Workflow

1. Add boundary and control objects
2. Refine message details
3. Consider alternative responsibility allocations
4. Integrate with three-tier architecture

Key Guidelines

• Start simple, add detail progressively
• Maintain consistency across all diagrams
• Use appropriate diagram type for purpose
• Focus on clear communication of design intent