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

~Connecting Use Cases: Actually Wiring DAO, Service, and UI Together~

In Week 37, we took the DAO layer → Service layer → UI layer we had designed and implemented in previous weeks, and combined them into a single use case.
It was a very hands-on session focused on creating the “app actually running”.

As the first real “app shape” began to appear, classrooms were full of cheers and groans (“another bug…!”) from each team—a high-energy class overall.

■ Teacher’s Introduction: “You only know if your design is right when you connect and run it”

Mr. Tanaka: “Even if each individual part (DAO, service) is correct, it’s common that things break once they’re wired together. Today is practice in integration.”

The key points were:

• Do the boundaries pass data correctly?
• Does separation of responsibilities hold up?
• Where do exceptions and errors stop, and where are they handled?

■ Exercise 1: Revisiting the Use Case (From Flow Diagram to Code)

Each team first showed the flow diagram for a “main use case” they had created as homework.

Example: Library System “Borrow Book” Use Case

1. UI → User enters “ID of the book to borrow”
2. Service → Checks whether the book is “borrowable”
3. DAO → INSERTs a new record into loans
4. DAO → Updates books.is_available to false
5. Service → Converts the result into a message for the UI
6. UI → Displays the result to the user

Mr. Tanaka emphasized:

“A pro codes with the flow diagram in hand.”

Everyone spread their diagrams on their desks and started coding.

■ Exercise 2: Connecting to the UI Layer (CLI / Web)

Each team chose their own UI style

• CLI (menu-based)
• Web (simple Flask / a learning HTTP framework)
• Chat-style UI (text dialogue control)

Sample Implementation (Excerpt from CLI: for learning)

print("=== Borrow a Book ===")
book_id = input("Book ID: ")

try:
    message = book_service.borrow(book_id)
    print("[SUCCESS]", message)
except Exception as e:
    print("[ERROR]", e)

Student A: “Once it’s wired up to the UI, it suddenly feels like I’m really building an app—super fun!”

■ Exercise 3: Implementing Service-Layer Logic

Students then fleshed out the logic for each use case.

Example: BooksService.borrow() (Pseudo-code)

def borrow(self, book_id):
    book = self.books_dao.get(book_id)
    if not book:
        raise ValueError("Book does not exist")

    if not book.is_available:
        raise ValueError("Cannot borrow: already checked out")

    self.loans_dao.create(member_id=self.current_user, book_id=book_id)
    self.books_dao.update_status(book_id, available=False)

    return f"{book.title} has been checked out"

What students noticed:

• When DAO and Service responsibilities are clearly separated, the code is easier to read
• If UI messages are unified in the service layer, everything feels more consistent
• Being aware of where exceptions are raised reduces bugs

■ Exercise 4: “Integration Test” Session

The highlight of the day was this time slot.

Teams exchanged apps with each other and ran the following tests:

• Normal cases
  • Borrow a book
  • Return a book
  • Search and see results displayed
• Error cases
  • Non-existent book ID
  • Trying to borrow a book that’s already checked out
  • Entering a string instead of a number in a form
  • Forcing a DB consistency error on purpose

Student B: “When we tested borrow → return → borrow again in sequence, the inventory count went wrong… turned out the root cause was a missing commit in the DAO!”

Student C: “The UI was supposed to show friendly error messages, but raw exceptions from the service layer were leaking straight through…”

These kinds of discoveries are exactly the value of integration.

■ Exercise 5: Setting Up Logging and Experiencing Debugging

Since integration almost guarantees problems, the teacher set out the following policy:

• Always log exceptions (don’t show raw ones to the UI)
• Log successful actions too: “who did what, and when”
• In the service layer, follow the flow “log → raise/handle exception → UI message”

Many bugs were found thanks to logs.

Student D: “Once I read the logs, I instantly saw it was a DAO argument order mistake!”
Student E: “I really felt how swallowing exceptions makes it impossible to find bugs…”

■ Teacher’s Closing Comment

“Finishing the parts and having the app actually run are two different problems.
By ‘connecting and running’ like today, you build real design and coordination skills.
Errors are treasure for growth. Don’t fear them—catch them, and fix them.”

■ Homework (For the Next Implementation Phase)

1. Submit a integration test report for one main use case per team (success cases and failure cases)
2. Create a simple sequence diagram of UI → Service → DAO call order
3. For today’s bugs, write down two “root causes” and two “preventive measures” per team

■ Next Week’s Preview: Strengthening Exception and Error Handling

Next week, based on the issues revealed during integration, we’ll systematically study:

• Error handling
• Input validation
• Exception design

Week 37 was a milestone class where the app finally began to move as a real system.
Students deepened their understanding of how design and implementation connect, and showed clear growth heading into the next improvement step.