Use case diagram
A use case diagram is a behavioral diagram in the Unified Modeling Language (UML) that provides a graphical representation of the functional requirements of a system, illustrating the interactions between external entities known as actors and the system's use cases, which specify units of useful functionality. Part of the UML standard, which was developed by Grady Booch, Ivar Jacobson, and James Rumbaugh and standardized by the Object Management Group (OMG), it serves primarily to capture and communicate high-level system behavior during the requirements analysis phase of software and systems engineering.[1] The diagram consists of key elements including ovals representing use cases, stick figures for actors (which can be human users, other systems, or hardware devices), and lines denoting associations between them.[2] Relationships such as include (for mandatory sub-functionality shared across use cases), extend (for optional or conditional extensions), and generalization (for inheritance-like hierarchies among use cases or actors) further refine the model's structure, enabling a clear depiction of how the system responds to stimuli from its environment. Unlike more detailed behavioral diagrams like sequence or activity diagrams, use case diagrams focus on "what" the system does rather than "how," making them essential for stakeholder alignment and traceability to implementation.[3] In practice, use case diagrams support iterative development methodologies by facilitating the identification of system boundaries and non-functional requirements indirectly through scenarios.[4] They are widely adopted in object-oriented analysis and design, often integrated with tools like Enterprise Architect or Visual Paradigm, and remain a core component of the UML 2.5.1 specification, ensuring consistency in modeling distributed and complex systems.Overview
Definition
A use case diagram is a behavioral diagram defined in the Unified Modeling Language (UML) that provides a graphical representation of the functional specifications of a system, illustrating the interactions between external entities known as actors and the system's use cases to demonstrate observable behaviors of value. It captures the high-level requirements by focusing on what the system should accomplish from an external viewpoint, without specifying the internal implementation details or processes. The primary role of a use case diagram is to model system functionality in terms of end-user goals, enabling stakeholders to understand and validate the system's intended behaviors early in the development process.[2] By depicting use cases as units of useful functionality performed in collaboration with actors, the diagram highlights the external perspective on the system's capabilities, distinguishing it from structural diagrams like class diagrams that focus on internal components and relationships.[2] At its core, the basic structure of a use case diagram includes a system boundary that encloses the use cases representing the system's services, with actors positioned outside this boundary to signify their role in initiating or participating in those use cases through defined relationships. This structure emphasizes the black-box view of the system, prioritizing functional requirements and external interactions over sequence of events or data flows seen in other UML behavioral diagrams such as activity or sequence diagrams.[2]History and Standards
The concept of use cases originated in the late 1980s through the work of Ivar Jacobson, a Swedish computer scientist at Ericsson, who developed textual and visual modeling techniques for specifying system behaviors from a user's perspective. In 1987, Jacobson presented these ideas at the OOPSLA conference, laying the groundwork for use case methodology in object-oriented analysis. This approach was further formalized in his 1992 book, Object-Oriented Software Engineering: A Use Case Driven Approach, which introduced use cases as a core practice for capturing functional requirements in software development.[4][5][6] The use case diagram emerged as part of the Unified Modeling Language (UML) in the mid-1990s, driven by the collaboration of Jacobson with Grady Booch and James Rumbaugh—known as the "Three Amigos"—at Rational Software. Their efforts unified various object-oriented modeling notations, incorporating Jacobson's use cases into a standardized graphical representation. UML version 1.0 was submitted to the Object Management Group (OMG) in January 1997, with version 1.1 adopted as the first official standard in November 1997, where use case diagrams were defined as a key behavioral diagram for depicting system interactions with actors.[7][8][9] UML evolved through subsequent revisions to enhance expressiveness and clarity in use case modeling. The major update in UML 2.0, released in July 2005, refined use case diagrams by improving support for relationships and stereotypes, making them more suitable for complex systems. Further iterations culminated in UML 2.5.1, adopted by OMG in December 2017, which remains the current standard and details use case diagrams in its superstructure specification under behavioral diagrams (sections 15–18). These standards are maintained by the OMG to ensure interoperability in software engineering practices.[10][11][12]Components
Actors
In use case diagrams, actors represent external entities that interact with the system, such as human users, other software systems, hardware devices, or even abstract entities like time that trigger events. These actors embody roles rather than specific individuals or instances, allowing them to encapsulate the perspective from which the system is utilized or affected. According to the Unified Modeling Language (UML) 2.5 specification, an actor is defined as a kind of classifier that specifies a coherent set of roles that users of an entity can play when interacting with the entity, and actors may be connected to use cases through associations to denote interactions. Actors are graphically depicted as simple stick figures in UML notation, consisting of a head, body, and limbs to symbolize human-like roles, though alternative icons may be used for non-human actors like systems or devices to enhance clarity. This representation emphasizes their external nature, distinguishing them from internal system elements. The stick figure notation has been standard since early UML versions and facilitates quick identification in diagrams.[13] Actors are classified into primary, secondary, and generalized types based on their interaction patterns with use cases. Primary actors are those that initiate a use case to achieve a goal and directly benefit from its outcome, representing the main stakeholders driving system functionality. For instance, a "Customer" in an e-commerce system acts as a primary actor by initiating actions like placing an order. Secondary actors, also known as supporting actors, do not initiate use cases but provide essential services or resources to enable them, often appearing on the right side of diagrams for convention. An example is a "Payment Gateway" external API that processes transactions on behalf of the e-commerce system. Generalized actors involve inheritance relationships, where a more specific actor (e.g., "Registered Customer") inherits properties from a general one (e.g., "Customer"), allowing reuse and specialization of roles without redundancy. These type distinctions, while not formally mandated in UML, are widely adopted in practice to clarify responsibilities and improve diagram readability.[14][15] In the diagram, actors are positioned outside the system boundary—a rectangle enclosing the use cases—to underscore their external status, and they connect to relevant use cases via solid lines called associations, which may include multiplicity or stereotypes to specify interaction details. This placement and connection mechanism highlights how actors drive or support system behavior without delving into internal implementation. For example, in an automated teller machine (ATM) system, the "Bank Customer" primary actor associates with use cases like "Withdraw Cash," while the "Bank Information System" secondary actor associates with "Validate Account" to provide backend support.[15][14]Use Cases
In UML use case diagrams, a use case represents a unit of useful functionality provided by the system, encapsulating a sequence of actions that yields an observable result of value to one or more actors.[11] This functionality is specified from an external perspective, focusing on what the system does rather than how it achieves the result internally. Use cases are characterized as atomic units of behavior, though they may incorporate sub-use cases through relationships to handle variations or common steps.[11] They are typically named using a verb-noun phrase to clearly indicate the action and its target, such as "Withdraw Cash" for an ATM system or "Place Order" in an e-commerce application.[16] This naming convention ensures clarity and aligns with the goal-oriented nature of use cases, as originally emphasized by Ivar Jacobson in his foundational work on object-oriented analysis. Within the use case diagram, use cases are positioned inside the system boundary to denote the functionalities offered by the system as a black box, abstracting away implementation details like algorithms or data structures.[11] This placement highlights the system's external interface, where interactions with actors occur via associations that connect actors to the relevant use cases. The scope of use cases is limited to functional requirements, describing the observable behaviors and outcomes without addressing non-functional aspects such as performance, security, or usability metrics.[11] This focus ensures that use cases serve as a high-level model for requirements elicitation, prioritizing the "what" over the "how" or "how well."[16]System Boundary
In UML use case diagrams, the system boundary is depicted as a rectangular box that encloses all the use cases of the system under consideration, with the name of the system typically placed in the top-left corner of the rectangle.[17] This graphical element serves as a visual delimiter, clearly distinguishing the internal functionalities represented by the use cases from the external environment, thereby defining the scope of the system being modeled.[18] The primary purpose of the system boundary is to establish the conceptual limits of the subject—often the system itself—by grouping related use cases within it while positioning actors and other external elements outside.[17] Only the use cases that pertain to the system's observable behaviors are placed inside this boundary; actors, which interact with the system but are not part of it, remain external to reinforce the separation between the system and its surroundings.[18] This enclosure does not imply formal ownership in the model but rather indicates the applicability of the enclosed use cases to the specified subject.[17] In more complex diagrams, variations may include multiple system boundaries to represent subsystems or modular components, each enclosing a subset of use cases relevant to that subsystem while maintaining the overall system's scope.[19] Such boundaries can be styled with adjustable opacity or dividing lines for clarity, but they remain non-UML model elements used solely for diagrammatic organization.[17]Relationships
Association
In use case diagrams, an association represents the fundamental relationship between an actor and a use case, depicted as a solid line connecting the actor's symbol to the use case oval, signifying direct interaction or communication between them. This notation, as specified in the UML standard, indicates that the actor either initiates the use case or participates in its execution, without implying any specific sequence or conditionality.[20] Semantically, the association conveys that instances of the actor can invoke or engage with the use case to achieve a system goal, modeling the structural link in behavioral terms rather than detailed flow. It is the simplest form of relationship in use case modeling, often bidirectional by default to reflect mutual communication, though an open arrowhead may be added at the use case end to denote unidirectional initiation by the actor if the interaction direction is explicitly constrained. Multiplicity can be annotated at the ends of the line (e.g., 1..* for multiple actor instances per use case), but basic associations typically omit such details unless needed for clarity.[15][20] For basic usage, no stereotypes such as <Include and Extend
In use case diagrams, the include and extend relationships enable the modularization of use cases by allowing common or optional behaviors to be factored out and reused, promoting clarity and reducing duplication in the model. These relationships are directed dependencies between use cases, distinct from associations with actors, and are essential for representing complex system interactions without inflating individual use case descriptions. The include relationship specifies that the behavior of one use case (the included use case) is inserted into another use case (the base use case), making the included behavior mandatory for the base to complete successfully. This is particularly useful for factoring out common subprocesses shared across multiple use cases, such as authentication steps that appear in various login scenarios. Semantically, the base use case depends on the included use case to execute its full behavior sequence, and the inclusion occurs at a specific point defined in the base use case's flow. The notation consists of a dashed arrow pointing from the base use case to the included use case, labeled with the stereotype <Generalization
In UML use case diagrams, generalization is a taxonomic relationship that enables inheritance between classifiers, specifically allowing one actor or use case to specialize another, forming an "is-a" hierarchy. This relationship is graphically represented by a solid line terminating in a hollow triangle arrowhead at the more general (parent) element, similar to generalization in class diagrams. For instance, a "VIP Customer" actor may generalize a "Customer" actor, indicating that the VIP Customer is a specialized type of Customer.[22] When applied to actors, generalization means the child actor inherits all associations and relationships of the parent actor, including connections to use cases. This inheritance allows the child actor to participate in all use cases associated with the parent without needing explicit links, promoting model reuse while maintaining clarity in roles. For example, if a "Customer" actor is associated with a "Place Order" use case, a specializing "Wholesale Customer" actor automatically inherits that association and may add further specializations. However, generalization between actors and use cases is not permitted, as it would violate the separation of concerns in the diagram.[13] For use cases, the generalization relationship indicates that the child use case inherits the behavior, properties, and associations of the parent use case, potentially refining or overriding aspects of that behavior to provide more specific functionality. The child use case thus represents a specialized variant, inheriting any actor associations from the parent. This supports abstraction by allowing common behaviors to be defined once in the parent and specialized as needed, such as a "Process Credit Card Payment" use case generalizing from a broader "Process Payment" use case. In practice, use case generalization is employed to model hierarchical refinements but is used judiciously, as overuse can introduce complexity and reduce the diagram's readability in simpler systems.[4][18]Notation
Graphical Symbols
The graphical symbols in use case diagrams, as defined in the Unified Modeling Language (UML) standard, provide a standardized visual vocabulary for depicting actors, use cases, system boundaries, and relationships between them. These symbols ensure consistency and clarity in representing system interactions without relying on textual descriptions alone. Actors are visually represented either as a simple stick figure—a humanoid icon with a circle for the head, lines for the body and limbs—to denote human or external entities interacting with the system, or as a rectangle containing the actor's name with the stereotype keyword<<actor>> placed above it. This dual notation accommodates both intuitive and formal representations, with the stick figure being the conventional choice for clarity in most diagrams.
Use cases, which encapsulate units of system functionality, are symbolized by an oval or ellipse shape, with the name of the use case inscribed inside the boundary. This elliptical form distinguishes use cases from other diagram elements and emphasizes their role as behavioral units observed from the actor's perspective.
The system boundary, defining the scope of the system under consideration, is depicted as a large rectangle that encloses all relevant use cases, with the system's name positioned in a dedicated compartment at the top of the rectangle. This boundary symbol clearly delineates the internal use cases from external actors, which are placed outside the rectangle.
Relationships between elements employ distinct line styles for differentiation: associations (direct interactions between actors and use cases) are shown with solid lines, optionally including arrows to indicate navigability; generalizations (inheritance-like relationships) are represented with solid lines ending in a hollow triangle arrowhead pointing to the parent use case; include relationships (mandatory sub-use cases) are shown by a dashed line with an open arrow from the including use case to the included use case, labeled <<include>>; extend relationships (optional extensions) are represented by a similar dashed line with an open arrow from the extending use case to the base use case, labeled <<extend>>. These line conventions highlight the nature of the dependencies without overlapping with the semantics detailed in other sections.[2]