Chapter 6: Refining the Requirements Model
Overview
This chapter focuses on component-based development (基于组件的开发) and advanced object-oriented modeling techniques including composition, aggregation, and generalization.
1.0 Component-Based Development
1.1 What is Component-Based Development?
Component-based development involves:
- Assembling software from pre-existing components
- Building components for others to use
1.2 Object-Orientation Contributions
Object-oriented programming supports component-based development through:
- Encapsulation (封装): Hides internal details, making components reusable in different systems
- Generalization hierarchies (泛化层次): Enables creation of specialized classes when needed
- Composition and aggregation structures (组合和聚合结构): Used to encapsulate components
2.0 Composition and Aggregation
2.1 Key Concepts
Both composition and aggregation are special types of association representing whole-part relationships (整体-部分关系).
2.2 Aggregation (聚合)
Definition: Any whole-part relationship where parts can exist independently.
Key Characteristics:
- Parts can exist without the whole
- When the whole is destroyed, parts continue to exist
- Parts can belong to multiple wholes simultaneously
Example: Class-Student relationship
- Students can be in several classes
- If a class is cancelled, students are not destroyed
- Students continue to exist independently
2.3 Composition (组合)
Definition: A ‘stronger’ whole-part relationship with existential dependency.
Key Characteristics:
- Each part belongs to only one whole at a time
- When the whole is destroyed, all parts are destroyed
- Parts depend on the whole for their existence
Examples:
- Invoice-InvoiceItem: Invoice items always belong to one invoice; if invoice is deleted, all items are deleted
- Meal-Ingredient: Ingredients belong to one meal; if you drop dinner, ingredients are lost
- TextBook-Chapter-Section: Chapters exist only within books; sections exist only within chapters
2.4 UML Notation
- Aggregation: Empty diamond (◇)
- Composition: Filled diamond (◆)
3.0 Generalization (Inheritance)
3.1 When to Use Generalization
Add generalization structures when:
- Two classes are similar in most details but differ in some aspects
- Classes may differ in:
- Behavior (operations or methods)
- Data (attributes)
- Associations with other classes
3.2 Key Concepts
Inheritance is also called generalization because it represents “is-a” relationships (是一个关系).
Example: Fruit hierarchy
- Fruit is a generalization of Apple, Orange, Mango
- Apple “is-a” fruit, inheriting all fruit properties
3.3 Abstract vs Concrete Classes
Abstract Classes (抽象类)
- Cannot be instantiated (不能实例化)
- Used to indicate common attributes and methods of all subclasses
- Makes designs adaptable and reusable
- In UML: Class name and abstract methods are italicized
Concrete Classes (具体类)
- Can be instantiated (可以实例化)
- Implement all abstract methods from parent classes
3.4 Class Hierarchy Characteristics
- Moving down: Classes become more specific and concrete
- Moving up: Classes become more general (less specific)
- Superclass design: Should contain common features of all subclasses
4.0 Combining Relationships
4.1 Complex Models
Real-world systems often combine:
- Generalization with composition/aggregation
- Multiple relationship types in single diagrams
Example: Agate advertising model
- Campaign contains multiple Adverts (composition)
- Advert has NewspaperAdvert and TelevisionAdvert subclasses (generalization)
- Each advert type composes different elements (AdvertCopy, AdvertGraphic, etc.)
5.0 Composition vs Inheritance Decision Guide
5.1 Use Composition When:
- Relationship is “has-a” (拥有关系)
- One object contains another
- Parts depend on the whole for existence
- Example: Car has-a Windscreen
5.2 Use Inheritance When:
- Relationship is “is-a” (是一个关系)
- One class is a specialized version of another
- Subclass inherits properties and behaviors
- Example: Triangle is-a Shape
6.0 Practice Applications
6.1 Analysis Guidelines
When creating class diagrams:
- Identify entity classes with appropriate attributes
- Determine relationships: association, composition, aggregation, or inheritance
- Add multiplicity to show relationship cardinalities
- Use composition for existential dependencies
- Use aggregation for loose whole-part relationships
- Use inheritance for specialization hierarchies
6.2 Key Decision Questions
- For Composition vs Aggregation: “Can the part exist without the whole?”
- For Composition vs Inheritance: “Is this a ‘has-a’ or ‘is-a’ relationship?”
- For Abstract Classes: “Are there common features that should never be instantiated directly?”
Summary
This chapter introduces essential object-oriented modeling techniques:
- Component-based development enables software reuse
- Composition and aggregation model whole-part relationships with different dependency levels
- Generalization creates inheritance hierarchies for code reuse and specialization
- Abstract classes define common interfaces without concrete implementations
- Combining these techniques creates flexible, maintainable system designs