[Class Report] System Development (2nd Year), Week 34

〜 UML Design: Drawing “Structure” with Class Diagrams and “Behavior” with Sequence Diagrams 〜

In Week 34, we moved from last week’s requirements definition into a hands-on design session using UML. This week’s goal was to “organize structure with class diagrams” and “visualize behavior with sequence diagrams.” It was a highly practical session aimed at boosting each team’s design capabilities.

■ Instructor’s Introduction: “Things become clear when you draw them”

Mr. Tanaka: “Design is hard to communicate with words alone. If you use class diagrams to show what exists, and sequence diagrams to show how things move, everyone on the team will share the same understanding.”

He illustrated the purpose and use of UML with a concise example on the whiteboard (major classes and a borrowing sequence for a library system).

■ Today’s Key Points (Short)

• Class diagrams: Define classes (attributes & operations), relationships (association / aggregation / inheritance), and multiplicity.
• Sequence diagrams: Show interactions over time, clarifying message order and responsibilities.
• Diagrams act as a “design contract”—teams should agree on them before moving to code.

■ Exercise ①: Creating Class Diagrams (90 minutes)

Procedure

1. Review the requirements (user stories & acceptance criteria).
2. Identify necessary entities (classes).
3. Define each class’s attributes (data) and methods/operations (behavior).
4. Specify relationships (association / dependency / inheritance / aggregation) and multiplicity (1, 0…*, etc.).
5. Review diagrams within each team and revise based on comments.

Example (Excerpt from a Library System)

• Book (title, author, is_available) + lend(), return_book()
• Member (name, member_id) + borrow(book), give_back(book)
• Library (books:list) + find_book(title), register_book(book)
• Member —(borrows)→ Book (Multiplicity: Member 1 — 0…* Book)

Student Insight:
“Separating attributes from operations makes the implementation methods much clearer.”
“Adding multiplicity helped us envision UI behavior as well.”

■ Exercise ②: Visualizing Key Scenarios with Sequence Diagrams (80 minutes)

Scenarios (chosen per team)

• Search for a book and borrow it (Search → Borrow)
• Return flow with overdue checking (Return → CheckOverdue)
• Calling an external API (e.g., weather) and displaying the result

Key Points for Drawing

• Line up lifelines (objects) and arrange responsibilities from left to right.
• Use arrows to show messages (synchronous / asynchronous), including return values and exception flows.
• Represent conditionals and loops with alt / loop frames.

Partial Example (Pseudo)

User -> Library: find_book(title)
Library -> Book: check availability
Book --> Library: available / not available
Library -> User: return list / "No match"

Student Feedback:
“Drawing the sequence diagram helped us naturally organize which UI button triggers which process.”
“It clarified exception handling (like out-of-stock) early on, which should reduce implementation errors.”

■ Review & Feedback (30 minutes)

Teams posted their class and sequence diagrams on the whiteboard for peer review. Key checkpoints included:

• Alignment between requirements and diagrams (no missing elements)
• Proper separation of responsibilities (Single Responsibility Principle)
• Clear representation of exceptions and abnormal flows
• Diagram specificity sufficient to implement code

Mr. Tanaka’s comments:
“Don’t cram all logic into Library.”
“Consider placing search-result caching in a separate class (CacheManager) for clearer responsibility boundaries.”

■ Instructor’s Closing Words

“Design diagrams are communication tools. By agreeing on ‘Is this correct?’ before writing code, you dramatically reduce wasted implementation time. You can redraw diagrams as many times as needed—the important thing is consensus.”

■ Homework (Preparation for Next Week)

1. Submit your team’s final class diagram (PNG or PDF) and one representative sequence diagram.
2. Create a file structure proposal (module breakdown) based on the class design (e.g., models/, services/, ui/).
3. Prepare a draft ER diagram (tables and primary keys).

■ Next Week: Database Design (ER Diagrams) and Mapping to Persistence

Next week, we will take the structures established in UML and translate them into database designs (ER diagrams). We will design tables and a simple migration plan. Understanding how class attributes persist in the database is a core practical skill. Today’s UML design work will form the foundation—come prepared!

In Week 34, students used UML to visualize both “what to build” and “how it behaves.” Through design diagrams, they experienced the importance of pre-implementation consensus and made solid preparations for the next stage: data design.