{"id":9538,"date":"2026-10-08T06:16:57","date_gmt":"2026-10-08T06:16:57","guid":{"rendered":"https:\/\/www.learn-vp.com\/id\/gallery\/uml-use-case-inheritance-abstract-vs-concrete-visual-paradigm\/"},"modified":"2026-10-09T04:18:32","modified_gmt":"2026-10-09T04:18:32","slug":"uml-use-case-inheritance-abstract-vs-concrete-visual-paradigm","status":"publish","type":"gallery","link":"https:\/\/www.learn-vp.com\/id\/gallery\/uml-use-case-inheritance-abstract-vs-concrete-visual-paradigm\/","title":{"rendered":"UML Use Case Inheritance: Abstract vs Concrete Scenarios in Visual Paradigm"},"content":{"rendered":"
\n

\"C4<\/p>\n

In the realm of systems engineering and software architecture, modeling complex business processes requires a balance between high-level abstraction and specific implementation details. One of the most powerful, yet often misunderstood, concepts in Use Case modeling is Inheritance<\/strong>. This tutorial explores how to effectively use abstract use cases to create flexible, reusable system models, specifically focusing on the “Verify Visitor Identity” scenario depicted in the provided diagram.<\/p>\n

We will break down the architecture of this diagram, explain the semantic difference between the abstract parent and its concrete children, and discuss how to leverage these concepts in your Visual Paradigm projects.<\/p>\n

The Architecture of the Diagram<\/h2>\n

The diagram provided illustrates a classic hierarchy of use cases. At the top, we see a parent use case, and below it, two child use cases connected by a specific relationship. This structure is not merely decorative; it represents a strict logical relationship known as Generalization<\/strong> (or Inheritance).<\/p>\n

The Parent: An Abstract Foundation<\/h3>\n

The top node, Verify Visitor Identity<\/em>, is rendered as a teal oval with italicized text<\/em>. In UML and Visual Paradigm syntax, this styling is the universal indicator that the use case is Abstract<\/strong>.<\/p>\n

    \n
  • Meaning:<\/strong> An abstract use case defines a general goal or a set of behaviors that are common to a family of use cases. It represents a concept that cannot be directly executed by an actor.<\/li>\n
  • Why it exists:<\/strong> In our example, a security guard or a system cannot simply “Verify Visitor Identity” as a single, atomic action. The system requires specific details on how<\/em> that verification occurs.<\/li>\n
  • Constraint:<\/strong> Because it contains incomplete information, you cannot instantiate an abstract use case. You cannot assign a specific actor to perform the action Verify Visitor Identity<\/em> directly without specifying the method.<\/li>\n<\/ul>\n

    The Children: Concrete Implementations<\/h3>\n

    Beneath the abstract parent are two orange ovals: Verify Visitor Fingerprint<\/strong> and Verify Visitor ID Card<\/strong>. These are Concrete<\/strong> use cases.<\/p>\n

      \n
    • Inheritance:<\/strong> By inheriting from the parent, these child use cases automatically acquire the general behavior of verifying identity. They do not need to redefine the rules for “who” is verifying or “what” the general outcome is.<\/li>\n
    • Specialization:<\/strong> These nodes add specific details (the “how”) to the abstract concept. One specifies biometric data (fingerprint), while the other specifies document-based data (ID card).<\/li>\n
    • Execution:<\/strong> These are the actual steps a user can perform. An actor can interact with the system to verify a fingerprint or verify an ID card.<\/li>\n<\/ul>\n

      The Generalization Relationship<\/h2>\n

      The line connecting the parent to the children is the Generalization<\/strong> relationship. Visually, it is represented by a solid line ending in a large, hollow triangular arrowhead pointing toward the parent.<\/p>\n

      This relationship implies an “Is-A”<\/strong> relationship. In the context of our diagram:<\/p>\n

        \n
      • A “Verify Visitor Fingerprint” use case Is-A<\/strong> “Verify Visitor Identity” use case.<\/li>\n
      • A “Verify Visitor ID Card” use case Is-A<\/strong> “Verify Visitor Identity” use case.<\/li>\n<\/ul>\n

        This structure allows for polymorphism in the system design. If the system requirements change such that all<\/em> verification methods must now include a timestamp and a photo log, you can add that behavior to the abstract parent Verify Visitor Identity<\/em>. Both the fingerprint and ID card children will automatically inherit these new requirements without needing individual modification.<\/p>\n

        Implementing Abstract Use Cases in Visual Paradigm<\/h2>\n

        When building this model in Visual Paradigm, you must explicitly define the nature of the use cases. The visual cue (italics) is generated automatically based on the object’s properties.<\/p>\n

        To achieve the diagram shown above, follow these logical steps within the tool:<\/p>\n

          \n
        1. Create the Parent:<\/strong> Add a new Use Case named “Verify Visitor Identity”.<\/li>\n
        2. Mark as Abstract:<\/strong> Right-click the use case and select Properties<\/em> (or press Ctrl+1). In the Use Case Properties dialog, check the box labeled Abstract<\/strong>. You will immediately see the name change to Verify Visitor Identity<\/em>.<\/li>\n
        3. Create Children:<\/strong> Add “Verify Visitor Fingerprint” and “Verify Visitor ID Card”. Ensure these are NOT<\/strong> marked as abstract.<\/li>\n
        4. Link Them:<\/strong> Select the “Generalization” tool from the toolbar. Draw a line from the child use cases (the source) to the parent use case (the target). The arrowhead should point to the abstract parent.<\/li>\n<\/ol>\n

          Why Use Abstraction in Business Modeling?<\/h2>\n

          It might seem redundant to create an abstract node that cannot be executed. However, this abstraction is crucial for scalability and clarity in complex business systems.<\/p>\n

          Imagine a high-security facility with 50 different ways to verify identity (Face ID, Iris Scan, Retina Scan, RFID, etc.). If you model all 50 as separate, flat use cases, your diagram becomes a messy web of disconnected lines. By creating an abstract Verify Visitor Identity<\/em> node, you create a “bucket” or a “category” that logically groups all these specific methods. This simplifies the view for stakeholders who are more interested in the types<\/em> of verification available rather than the minutiae of every single one.<\/p>\n

          Extending the Model: <> and <><\/h2>\n

          As mentioned in the context of the example, once you have established these base use cases, you can further structure them. The abstract nature of the parent allows you to define common behaviors that might be shared across all children, or behaviors that vary depending on the specific child.<\/p>\n

          For instance, you might have a <> relationship from the abstract parent to a use case called Log Security Event<\/em>. This means that every<\/strong> way of verifying identity must also log the event. Alternatively, you might use <> to add optional behaviors, such as Verify Visitor ID Card<\/em> <> Call Security Guard<\/em> (only if the card is invalid).<\/p>\n