{"id":9473,"date":"2026-09-28T09:40:49","date_gmt":"2026-09-28T09:40:49","guid":{"rendered":"https:\/\/www.learn-vp.com\/ja\/gallery\/mastering-uml-use-case-modeling-library-systems-vpascode\/"},"modified":"2026-10-09T04:18:42","modified_gmt":"2026-10-09T04:18:42","slug":"mastering-uml-use-case-modeling-library-systems-vpascode","status":"publish","type":"gallery","link":"https:\/\/www.learn-vp.com\/ja\/gallery\/mastering-uml-use-case-modeling-library-systems-vpascode\/","title":{"rendered":"Mastering UML Use Case Modeling for Library Systems with VPasCode"},"content":{"rendered":"
\n

\"PlantUML<\/p>\n

Designing the architecture for a complex system like a Library Management System<\/strong> requires a clear blueprint of how users interact with the software. In the world of software engineering, Use Case Diagrams<\/strong> are the gold standard for visualizing these interactions. They bridge the gap between technical requirements and user needs.<\/p>\n

This tutorial explores how to model a comprehensive library system using PlantUML<\/strong> within the VPasCode<\/strong> environment. We will break down the system into actors, use cases, and the critical relationships that bind them together, ensuring your system logic is sound before a single line of code is written.<\/p>\n

1. Identifying the Actors and System Scope<\/h2>\n

Before drawing lines and ovals, we must define the boundaries of our system and the entities that interact with it. In our example, the system boundary is the Library Management System<\/strong>.<\/p>\n

The Actors<\/h3>\n

Actors represent the roles of users or external systems that initiate actions. In a robust library system, we distinguish between human actors and external services:<\/p>\n

    \n
  • Member:<\/strong> The primary user who wants to find, borrow, and return books.<\/li>\n
  • Librarian:<\/strong> The administrator responsible for managing the catalog and handling specific member issues.<\/li>\n
  • Payment Service:<\/strong> An external system dependency required to process fines or payments securely.<\/li>\n
  • Notification Service:<\/strong> An external system dependency used to send alerts about overdue books.<\/li>\n<\/ul>\n

    2. Defining Use Cases and Functional Requirements<\/h2>\n

    Use cases describe specific functionalities the system must provide. Based on the system requirements, we identify the following core functions:<\/p>\n

      \n
    • Search Catalog:<\/strong> Allows members to find books by title, author, or ISBN.<\/li>\n
    • Borrow Book:<\/strong> The process of checking out a book for a specific period.<\/li>\n
    • Return Book:<\/strong> The process of bringing a book back to the library.<\/li>\n
    • Manage Catalog:<\/strong> Allows librarians to add, remove, or update book records.<\/li>\n
    • Pay Fine:<\/strong> Handles the transaction for overdue penalties.<\/li>\n
    • Send Overdue Notification:<\/strong> The automated alert system for late returns.<\/li>\n<\/ul>\n

      3. Modeling Relationships: Include vs. Extend<\/h2>\n

      The most critical part of a Use Case Diagram is defining the logic flow. We use two primary relationships: <<include>><\/strong> and <<extend>><\/strong>.<\/p>\n

      The <<include>> Relationship<\/h3>\n

      An include relationship signifies that a base use case must<\/em> perform the included behavior to be completed. It is a mandatory step.<\/p>\n

        \n
      • Borrow Book <<include>> Check Membership:<\/strong> You cannot borrow a book without verifying the member’s status first.<\/li>\n
      • Borrow Book <<include>> Check Book Availability:<\/strong> The system must verify the book is not already checked out.<\/li>\n
      • Return Book <<include>> Calculate Fine:<\/strong> Every return triggers a calculation to see if the book is late (even if the fine is zero).<\/li>\n<\/ul>\n

        The <<extend>> Relationship<\/h3>\n

        An extend relationship indicates that a base use case may<\/em> perform the extending behavior under specific conditions. It is optional or conditional logic.<\/p>\n

          \n
        • Return Book <<extend>> Send Overdue Notification:<\/strong> This only happens if the Calculate Fine<\/strong> step determines the book is actually overdue. If the book is returned on time, no notification is sent.<\/li>\n<\/ul>\n

          4. Implementation: Writing the PlantUML Code<\/h2>\n

          In VPasCode<\/strong>, you can define your entire system architecture using a simple text-based language. This approach allows for version control and rapid prototyping. The code below demonstrates how to define the system rectangle, the actors, and the complex relationships including the external service interactions.<\/p>\n

          @startuml\nrectangle \"Library Management System\" {\n  usecase \"Pay Fine\" as UC_PayFine\n  usecase \"Manage Catalog\" as UC_ManageCatalog\n  usecase \"Send Overdue Notification\" as UC_Notify\n}\n\n' Member Interactions\nMember --> UC_Search\nMember --> UC_Borrow\nMember --> UC_Return\nMember --> UC_PayFine\n\n' Librarian Interactions\nLibrarian --> UC_ManageCatalog\nLibrarian --> UC_Borrow\nLibrarian --> UC_Return\n\n' External Service Interactions\nPayment --> UC_PayFine\nNotification --> UC_Notify\n\n' Include Relationships (Mandatory Steps)\nUC_Borrow ..> UC_CheckMember : <>\nUC_Borrow ..> UC_CheckAvailability : <>\nUC_Return ..> UC_CalculateFine : <>\n\n' Extend Relationships (Conditional Logic)\nUC_Notify ..> UC_Return : <>\n\n' Note: The diagram logic implies that \"Send Overdue Notification\" extends \"Return Book\"\n' specifically when the \"Calculate Fine\" condition is met.\n\n@enduml<\/code><\/pre>\n