分析与设计阶段Class Diagram的区别及相关实施疑问

Great question—this is a common point of confusion since UML class diagrams serve very different purposes in analysis vs. design phases. Let’s break this down step by step.

What’s an Analysis Phase Class Diagram? #

Analysis class diagrams are all about business domain understanding, not code implementation. They focus on capturing core concepts, relationships, and high-level responsibilities from a user/business perspective, stripping away any technical details.

Here’s what they typically include:

• Domain entities: Core business objects (e.g., Customer, Order, Product) with only critical business attributes (no getters/setters, no private fields). For example, an Order might have orderNumber and orderDate—but not databaseId or validationStatus.
• High-level responsibilities: Methods framed as business actions, not technical operations. Instead of calculateTax(double rate), you’d see calculateTotal()—describing what the class does, not how it does it.
• Business relationships: Simple associations, aggregations, or generalizations reflecting real-world rules (e.g., "An Order belongs to one Customer", "A Product can be in multiple Orders").
• Often uses UML’s analysis class types: Entity (business objects), Boundary (interfaces with external systems/users), and Control (coordinates business processes) to clarify roles.

Key Differences Between Analysis and Design Class Diagrams #

Do You Need a Class Diagram for Every Sequence Diagram? #

No, you don’t. Sequence diagrams focus on dynamic interactions (who calls whom, in what order), while class diagrams capture static structure (what classes exist, their relationships).

Instead of pairing each sequence diagram with a class diagram, think of class diagrams as a consolidated view:

• Analysis phase: Use sequence diagrams to map out business workflows, then update a single (or small set of) analysis class diagrams to reflect the entities/controls involved in those workflows.
• Design phase: Sequence diagrams will show interactions between specific design classes, and the design class diagram will serve as the single source of truth for all those classes’ structure and relationships.

Design Phase: Should You Add Methods/Attributes First or Establish Relationships? #

There’s no hard rule, but a pragmatic approach is:

1. Start with relationships and class structure: First define which classes are needed (e.g., Order, OrderItem, PaymentProcessor) and their core relationships (e.g., Order is composed of OrderItems, Order depends on PaymentProcessor). This ensures you get the overall architecture right before diving into details.
2. Fill in methods based on interactions: Use your sequence diagrams to identify what methods each class needs to support the workflow (e.g., if the sequence diagram shows Order calling PaymentProcessor.processPayment(), add that method to the PaymentProcessor class).
3. Add attributes to support responsibilities: Once methods are defined, add the attributes each class needs to fulfill its role (e.g., Order needs totalAmount to support calculateTotal()).

This approach keeps you from getting bogged down in trivial details early on while ensuring the design aligns with the system’s functional requirements.

内容的提问来源于stack exchange，提问作者liuk997