5.3 Static Structure (Class Diagrams)

Automatically Deriving Class Diagrams to Define the System’s Architecture and Logic Layout

After capturing dynamic behavior through Activity and Sequence Diagrams, the next logical step is to define the static structure — the enduring building blocks of the system. Class Diagrams provide this blueprint by modeling:

• The key domain entities (classes) and value objects
• Their attributes (data fields) and operations (methods/behaviors)
• Relationships between classes (associations, aggregations, compositions, generalizations/inheritance)
• Multiplicities (1..1, 1..*, 0..1, etc.)
• Visibility (public, private, protected), stereotypes (<<entity>>, <<boundary>>, <<control>> in MVC contexts), and interfaces

These diagrams serve as the architectural foundation: they guide database schema design, object-oriented implementation, code generation, and long-term maintainability. They answer: “What are the nouns and verbs of the system, and how are they structurally related?”

Visual Paradigm’s AI-Powered Use Case Modeling Studio can automatically derive an initial Class Diagram from:

• The detailed use case specifications (nouns in steps become candidate classes/attributes, verbs become operations)
• Sequence Diagrams (lifelines → classes, messages → operations/parameters)
• Activity Diagrams (actions involving data → attributes or associations)
• The overall problem domain and scope description

You trigger generation by selecting one or more use cases (or the entire model) and choosing “Generate Class Diagram” or “Derive Static Structure”. The AI proposes:

• Domain classes from recurring nouns (e.g., Reservation, Table, Diner)
• Attributes extracted from preconditions, postconditions, and flow details
• Operations inferred from verbs in flows and messages in sequences
• Associations based on interactions and data flow
• Initial multiplicities and roles
• Basic MVC layering (boundary, control, entity classes) when applicable

The resulting diagram is fully editable: add inheritance, interfaces, aggregations, qualifiers, constraints, notes, packages for layering, or stereotypes. Traceability links keep classes connected to originating use cases and flows.

Practical Examples

Example 1: GourmetReserve – Mobile Dining Reservation App

AI-Derived Class Diagram (core fragment):

• Classes:
  • Diner (entity) Attributes: dinerId: String, name: String, email: String, phone: String, loyaltyStatus: Enum(Gold, Silver, None) Operations: viewHistory(), applyPromoCode()
  • Restaurant Attributes: restaurantId: String, name: String, location: Address, operatingHours: TimeRange[], capacity: Integer Operations: getAvailableSlots(date, time, partySize)
  • Table Attributes: tableId: String, restaurant: Restaurant, capacity: Integer, location: String (e.g., “patio”) Operations: isAvailable(dateTime: DateTime): Boolean
  • Reservation (aggregate root) Attributes: reservationId: String, diner: Diner, table: Table, dateTime: DateTime, partySize: Integer, status: Enum(Confirmed, Pending, Cancelled), depositAmount: Money, createdAt: DateTime Operations: confirm(), cancel(withFee: Boolean), calculateDeposit()
  • Payment Attributes: paymentId: String, reservation: Reservation, amount: Money, status: Enum(Success, Failed, Refunded), transactionId: String Operations: process(), refund()
• Relationships:
  • Diner 1 → * Reservation (places)
  • Reservation 1 → 1 Table (books)
  • Reservation 1 → 1 Payment (requires)
  • Restaurant 1 → * Table (has)

Typical refinement:

• Add <<boundary>> stereotype to ReservationController (UI/service layer)
• Add composition diamond: Reservation composes Payment (Payment cannot exist without Reservation)
• Introduce Address value object as a separate class with street, city, zip

Example 2: SecureATM – Core Banking Domain

AI-Derived Classes & Relationships:

• Account Attributes: accountNumber: String, balance: Money, dailyLimit: Money, owner: Customer Operations: debit(amount), credit(amount), checkBalance()
• Customer Attributes: customerId: String, name, cardNumber, pinHash Operations: authenticate(pin)
• Transaction (abstract) Attributes: transactionId, timestamp, amount, account: Account Operations: log()
• WithdrawalTransaction extends Transaction Attributes: atmId: String Operations: dispense()
• ATM Attributes: atmId, location, cashLevels: Map<Denomination, Integer> Operations: replenish(denomination, count), dispense(amount)
• Relationships:
  • Customer 1 → * Account (owns)
  • Account 1 → * Transaction (records)
  • ATM 1 → * WithdrawalTransaction (performs)

Refinement example:

• Add <<entity>> stereotype to Account, Transaction
• Add constraint {dailyLimitReset: midnight} on Account.dailyLimit
• Introduce Card class associated with Customer (1:1)

Example 3: CorpLearn – E-Learning Platform

AI-Derived Fragment:

• Learner Attributes: learnerId, name, email, department Operations: enroll(course), viewProgress()
• Course Attributes: courseId, title, description, durationHours Operations: getRequiredAssessments()
• Assessment Attributes: assessmentId, course: Course, passingScore: Integer (default 80), timeLimit: Duration Operations: startAttempt(), submit(answers)
• AssessmentAttempt Attributes: attemptId, learner: Learner, assessment: Assessment, startTime, endTime, score: Integer, status: Enum(Passed, Failed, InProgress) Operations: calculateScore(), issueCertificate()
• Certificate Attributes: certificateId, attempt: AssessmentAttempt, issueDate, expiryDate Operations: generatePDF()
• Relationships:
  • Learner * → * Course (enrolls in)
  • Course 1 → * Assessment (contains)
  • Assessment 1 → * AssessmentAttempt (has)
  • AssessmentAttempt 1 → 0..1 Certificate (may produce)

Refinement example:

• Add generalization: MandatoryCourse and OptionalCourse extend Course
• Add package “Domain Model” and sub-package “Compliance” for Certificate-related classes

Best Practices for Class Diagram Generation & Refinement

• Start broad — Accept the AI’s domain classes first, then refine granularity.
• Apply layering — Use packages or stereotypes (<<boundary>>, <<control>>, <<entity>>) for MVC/DDD separation.
• Define multiplicities carefully — Validate against real business rules (e.g., one active reservation per table slot).
• Add invariants & constraints — Note business rules (e.g., {balance ≥ 0}).
• Reuse patterns — Recognize aggregates (Reservation + Payment), value objects (Money, Address), and services.
• Trace to requirements — Ensure every major class traces back to nouns/actions in use case flows.

By the end of Section 5.3, you will have a clear, structured Class Diagram that defines the system’s core architecture and serves as the foundation for implementation, database design (via ERD in 5.4), and long-term evolution. The AI provides a strong, domain-informed starting point — your expertise turns it into a precise, maintainable model aligned with business reality. With static structure defined, the next step is aligning persistent data through Entity-Relationship Diagrams.