[SysML] #8. Understanding SysML UseCase Diagram

쉬운 목차

Understanding SysML UseCase Diagram

When designing the complex functionality of a system, it is important to understand exactly how the functions interact and respond to external demands. SysML’s use case diagrams are a powerful tool to help you do just that.

What Use Case Diagrams Do

A use case diagram provides a visual representation of the services a system must provide and the interactions between the stakeholders who will use those services. Simply put, this diagram focuses on the ‘What’ and ‘Who’ of the system. For example, let’s say you’re designing an automotive system. Use cases could be “speed control,” “emergency braking,” “temperature control,” etc., and the stakeholders would be drivers, passengers, mechanics, etc.

Importance in the Early Stages

Creating use case diagrams is very important, especially in the early stages of developing the system’s concept of operations (ConOps). This step requires clearly defining how the system will work in practice and what the users’ expectations are. Through this process, designers can understand the basic behavior of the system and proceed with more detailed design based on this.

Use case diagrams allow system designers to analyze system-level use cases, derive them into subsystem- and component-level use cases, and assign them during the architecture design phase. These processes are essential for the structural design and functional distribution of the system.

This image shows dependencies using in SysML in order to help Understanding SysML UseCase Diagram — This is a UseCase Diagram drawn with Enterprise Architect. If you want to get more information about UseCase Diagram, this article may be helpful.

The core role and purpose of SysML UseCase Diagram

The SysML UseCase Diagram is one of the most important early design tools in systems engineering. The main purposes for using this diagram are:

Clarifying system boundaries

Defining the boundaries of a system is essential to clearly distinguish between what functions the system should perform and what it should not. For example, a healthcare management system includes functions such as patient management, scheduling systems, and access to medical records, but excludes other unrelated tasks.

Understand your interactions with users

Use case diagrams help you visually represent and understand the interactions between your system and users. This helps system designers more accurately understand user needs and the services the system should provide.

Strengthening communication with stakeholders

By simplifying and presenting complex system functionality in a form that even non-experts can understand, it plays an important role as a communication tool between systems engineering teams and other stakeholders. Clear communication during the early design stages is key to project success.

Requirements elaboration through use cases

Each use case represents one or more system requirements. This helps clarify the problem the system must solve and the services it must provide. This process is a very important step in the system design and verification process.

Basic structure and understanding of SysML UseCase Diagram

Diagram types and headers

Diagram types : In SysML and UML, use case diagrams are usually abbreviated as “uc”. This abbreviation indicates the type of diagram, and modeling tools use it to distinguish between diagrams.
Diagram header : The header of the diagram follows the format “uc [model element type] model element name [diagram name]”. For example, if the header is “uc [package] Safety Management System [User Interaction]”, this represents the ‘User Interaction’ use case diagram within the ‘Safety Management System’ package.

Diagram frame and content

Diagram frame : A diagram frame tells you what type of model element the diagram represents. This specifies what scope the diagram contains: a package, model, model library, or view.
Content : The content of the diagram describes the actors (users or other systems) interacting within the system, the use cases (functions the system performs), and the relationships between them. For example, an ‘online shopping system’ may include use cases such as “product search”, “purchase”, and “payment”, and actors such as “customer” and “administrator”.

Key features and understanding of SysML use cases

Use cases describe how the system is used to achieve the goals of various users. It provides a user-centric way to describe the functionality of the system.

What is a use case?

A use case is a specification of the sequence of tasks that a system or subsystem can perform. It provides valuable services through interaction with external objects, including variant sequences and error sequences. For example, in an ‘online ticket reservation’ system, use cases could be ‘ticket search’, ‘reservation’, ‘payment’, etc.

Classification through generalization

Use cases can form generalization relationships with other use cases that share common characteristics. This allows for more systematic management by organizing use cases hierarchically. For example, the ‘Payments’ use case can be broken down into ‘Card Payments’, ‘Cash Payments’, etc.

Expand and include use cases

Extensions of use cases and containment relationships are used to decompose complex system functionality into smaller, more manageable units. For example, the ‘Payment’ use case might include a separate use case called ‘Payment Confirmation’.

Elaboration of use cases

Use cases can be detailed with textual descriptions or diagrams, including preconditions, postconditions, default and alternative flows, etc. This detailing provides the development team with clear guidance on how the system should behave.

Naming conventions for use cases

Use case names are expressed as verb phrases that reflect the actor’s goals. For example, the use case ‘Confirm Reservation’ represents the goal of the user checking the status of their reservation.

The Importance of Use Case Specifications

The use case specification generated for each use case details how the system and its actors work together to achieve the goal. This provides much more information than a simple use case name and is essential to ensuring the successful execution of your project.

Understanding the basic structure of SysML UseCase Diagram

The SysML UseCase Diagram contains the components and relationships essential to effectively visualize the use cases of a system. Here are the key structural elements of these diagrams:

UseCase notation

Use cases represented as ellipses : Use cases are usually represented as ellipses (ellipses), with the name of the use case displayed inside the oval. Use case names often use verb phrases to clearly indicate the action the system should perform. For example, the use case “Ticket Reservation” represents the process of a user booking a ticket in an online ticket sales system.

generalization and specialization

Representation of generalization relationships : Generalization relationships are shown as solid lines with hollow triangular arrowheads, which point to the generalized use case (supertype). The other end of the solid line represents specialized use cases (subtypes). This structure means that a subtype inherits all relationships and behavior from its supertype.
Role of subtypes : Subtypes can provide more specific definitions by overriding inherited behavior or adding new relationships and behaviors. For example, the “Online Payments” use case could be a specialization of the general use case of “Payments” to include requirements and behaviors specific to online transactions.

Understanding Types of Use Cases in the UseCase Diagram

Base Use Cases

The primary use case represents the goals of the main actors interacting with the system. They represent the core functions of the system and are directly linked to key actors. For example, “updating customer information” might be a primary use case for a customer service system.

Included Use Cases and Inclusion Relationships

Definition and notation of inclusion relationship: Includes other use cases that must be performed during the execution of the primary use case. This relationship is indicated by a dotted line, an open arrowhead, and the «include» keyword.
Purpose of use: Containment relationships are expressed through contained use cases that are responsible for repetitively required behavior in the primary use case. For example, “payment processing”, which is a common requirement across all order processing operations, can be set up as an included use case.

Extending Use Cases and Extending Relationships

Definition and notation of extension relationships: Use cases where a base use case can be optionally extended. This relationship is indicated by a dotted line, an open arrowhead, and the keyword «extend».
Selective execution and trigger conditions: Extended use cases selectively execute when certain conditions are met. For example, “Apply Discount Coupon” could be an optional feature that extends the “Purchase Product” use case.

Effective use of use case diagrams

When initially designing a use case model, it is best to focus on the base use cases and add embedded use cases that represent commonly required behaviors and extended use cases that represent optional behaviors after they are more clearly understood. This approach keeps the use case diagram clean and helps all stakeholders clearly understand which features are required and which are optional.

Understanding the role and notation of ‘Actor’ in SysML UseCase Diagram

The SysML UseCase Diagram is a way to represent ‘Actors’, the entities that interact with the system, clearly representing the users of the system and how they use the system. Actors are classified and represented as follows:

Actor notation

Simple stick figures : This representation provides a visual representation of a human user. It is primarily used when human users interact directly with the system.
Rectangle and “actor” keyword : Used to represent a non-human actor. It is used when an external system or other entity interacts with the system, and these expressions clearly indicate the interface with the system.

Classification through generalization

If actors share common characteristics, they can be organized hierarchically using generalization relationships. For example, under a general actor called “Customer” you could have specialized actors such as “Member Customer” and “Non-Member Customer”. This structure makes it clear how different types of users will use the system and their requirements.

Relationship between UseCase and Actor

Primary and secondary actors : Actors that directly invoke or participate in a use case are called ‘primary actors’. For example, a customer invoking the “purchase product” use case in an online shopping system. On the other hand, actors who participate indirectly in a use case are classified as ‘auxiliary actors’. For example, a banking system responsible for payment processing could be a secondary actor in the “purchase goods” use case.
Interaction between actors and use cases : The relationship between actors and use cases emerges through actors invoking or participating in use cases during system operation. This relationship is represented visually in the following way:
Association : A solid line connecting an actor and a use case, indicating how the actor interacts with that use case. Association lines provide a path for actors to directly invoke or participate in a use case.
Links between instances during system operation : Association between actors and use cases means that links may exist between actors and use cases during the operation of the system. It represents the dynamic interaction of the system, showing how the system is used and how it meets user needs.

System Boundaries: Understanding the scope and interfaces of a system in a UseCase Diagram

System boundaries are used in UseCase Diagrams to define the scope of a system and visually separate the services it provides and the interactions between external actors. This border plays important roles:

How to express system boundaries

The system boundary is represented by a rectangle surrounding the use cases, and the name of the system is specified as a noun phrase at the top of the rectangle. This rectangle should not be confused with a diagram frame; it clearly represents the functional scope of the system.

System perimeter in ConOps

During Concept of Operations (ConOps) development, the system boundary is established with the name of the system being designed; at this stage, the system is considered a ‘black box’. The main goal is to define the services that the system will provide to actors in its environment.

System boundaries in architectural design

During the architecture design phase, the system is structurally decomposed into subsystems and components. This process creates a new use case diagram for each subsystem or component, and the system boundary is renamed to the name of the subsystem or component being worked on.

The importance of system boundaries

The system boundary clarifies the functional scope of the system, the services it provides and its interfaces with the outside world. This makes it easier for developers and stakeholders to understand what services the system provides and how external actors interact with the system.

UseCase Specification: Clearly defining system requirements

The UseCase Specification is a document that describes the functional requirements of the system in detail and plays a critical role in the success of the project. The specification for each use case includes the following key elements:

Use case name : Use cases are named using verb phrases and are often named from the actor’s perspective. For example, ‘purchase a product’, ‘create an account’, etc. intuitively reflect the actions of an actor interacting with the system.
Range : Scope specifies the entity (e.g. organization, system, subsystem, or component) that owns the use case. This clarifies the scope of the document by specifying specifically which part of the system the use case covers.
Primary and supporting (secondary) actors : The primary actor is the actor that directly invokes the use case and activates the functionality of the system. Support actors are responsible for helping execute a use case or providing necessary services. For example, a payment processing system might be a supporting actor in the ‘Purchase a product’ use case.
Preconditions and Postconditions : Preconditions specify conditions that must be met before the use case begins, and postconditions specify the results that must be satisfied after the use case is executed. These conditions provide the criteria for successful execution of the use case.
trigger : A trigger is an event that starts a use case; it can be a user request or a specific system event. This clarifies the starting point for executing use cases.
Key Success Scenarios and Scaling (Alternative Branches) : Critical success scenarios describe the sequence of steps that a use case would execute normally, while extensions (alternative branches) suggest alternative paths that might occur depending on unforeseen conditions or choices. This shows how the use case would be handled in different situations.

UseCase Specification Writing Guide: Effective Requirements Definition

Narrative-centered approach

When writing a use case specification, you should first focus on a narrative that describes how actors interact with the system. This approach is important for clearly and accurately communicating the interactions between the system and its actors. Narratives in story format make complex technical content easier to understand.

Screenwriting

Each use case consists of one or more scenarios, which represent a sequence of tasks that the system can perform. Critical success scenarios present a nominal execution path for a use case; error and exception sequences may be included as additional scenarios. This makes it clear how the system should respond to unexpected situations.

The importance of segmentation

Avoid use cases that are too broad or high-level, and ensure that each use case includes exactly one key success scenario. This helps keep your use cases clear and manageable. Additional execution paths should be for error or exception handling, ensuring that each part of the design is clearly defined.

Visual representation

After you clearly organize your narrative in text format, use modeling tools to represent it visually. SysML activity diagrams are useful for graphically representing use case specifications and make complex scenarios visually easier to understand.

Effective system design using scenario builder

Scenario Builder is an essential tool for systematically defining and documenting the details of use cases during system design and development. Let’s take a closer look at the key steps in using this tool and their importance.

Detailed description definition : It details the operating principles and requirements of the system. This step helps clarify project goals and understand the interactions between actors and systems. By specifying the details, the project team has a clear understanding of the system requirements.
Scenario creation : Create one or more scenarios based on real-world use cases to describe how the system should react under different conditions and situations. These scenarios play an important role in identifying potential problems and finding solutions early in the design process.
Define preconditions and postconditions : Clarify the state of the system before each scenario begins and after it is completed. These conditions establish whether the system is performing as expected and are important for preventing errors.
Define constraints : It specifies the constraints under which the system must operate. For example, response time, detection range of sensors, etc. are important factors that can affect system design and implementation.
Create diagram : Create a diagram to visually represent the generated scenario. These diagrams are very useful in understanding and explaining how complex systems work.
Sync and Track : Keep all information up to date and track individual steps by linking them with other elements of the system. This helps ensure project consistency and ensures all requirements are met.

Practical Example

In automotive electronic systems, let’s consider the design of an ’emergency braking system’. Using Scenario Builder you can:

DEFINITION OF DETAILED DESCRIPTION : Describes in detail how the car should react in an emergency situation.
Scenario Creation : For example, create a scenario when an obstacle suddenly appears ahead.
Define preconditions and postconditions : Define the vehicle state before and after obstacle detection.
Constraint Definition : Specifies system response time, sensor detection range, etc.
Create a diagram : Visually represent the operating principles of an emergency braking system based on a scenario.
Synchronization and Tracking : Keeps all steps up to date and tracks connections with other elements of the system.

Refine your use case: Leverage different behavioral modeling methods

Use case models and text definitions are very important to clearly describe the functional requirements of the system. However, when you want to model the behavior of your system in more detail, you can utilize various behavioral formalisms, such as:

Interaction model

Suitable for scenarios where message-based interactions are central. This model helps to clearly express the message exchange and sequence of events between objects. Using sequence diagrams and communication diagrams, you can visually represent the dynamic interactions between participating objects.

Activity model

It is suitable for scenarios where control logic is important, the flow of inputs and outputs must be managed, and include data transformation algorithms. Activity diagrams allow you to comprehensively express the sequence of tasks, conditional flow, parallelism, etc. This is a great way to clarify each step in a complex scenario.

State machine model

This is useful when the interactions between actors and systems are asynchronous or the order of events is unclear. Use state machine diagrams to define changes in the state of a system or object and the resulting actions. This model clearly models complex state transitions and event processing, allowing the system’s response to be systematically described.

Real example

When modeling an ’emergency braking system’ in an automotive electronic system, you can use an interaction model to represent the exchange of messages between sensors and control systems as a sequence diagram, or an activity model to represent the flow of braking operations as an activity diagram. . Additionally, the state machine model allows the various states and transitions of the braking system to be depicted in detail.

If you are interested in other articles about the basic Knowledge of SysML with EA, please refer to the links below!

[SysML] #1. Understanding SysML Diagrams

[SysML] #2. Understanding SysML Package Diagram

[SysML] #3. Understanding Dependencies of Pkg Diagram

[SysML] #5. Understanding SysML Requirement Diagram

[SysML] #6. Understanding Relations In Req Diagram

[SysML] #7. How to draw a Req Diagram with EA

[SysML] #9. How to draw a UseCase Diagram with EA

[SysML] #10. Understanding SysML bdd Diagram

[SysML] #11. Understanding SysML ibd Diagram

[SysML] #12. Understanding Part Property of Block

[SysML] #13. Understanding Reference Property of Block