What is a use case?<\/strong><\/h4>\n\n\n\nA 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.<\/p>\n\n\n\n
Classification through generalization<\/strong><\/h4>\n\n\n\nUse 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.<\/p>\n\n\n\n
Expand and include use cases<\/strong><\/h4>\n\n\n\nExtensions 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’.<\/p>\n\n\n\n
Elaboration of use cases<\/strong><\/h4>\n\n\n\nUse 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.<\/p>\n\n\n\n
Naming conventions for use cases<\/strong><\/h4>\n\n\n\nUse 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.<\/p>\n\n\n\n
The Importance of Use Case Specifications<\/strong><\/h4>\n\n\n\nThe 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.<\/p>\n\n\n\n
<\/p>\n\n\n\n
\n\n\n\n<\/p>\n\n\n\n
<\/span>Understanding the basic structure of SysML UseCase Diagram<\/strong><\/span><\/h3>\n\n\n\nThe 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:<\/p>\n\n\n\n
UseCase notation<\/strong><\/h4>\n\n\n\n\n- Use cases represented as ellipses : <\/strong>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 \u201cTicket Reservation\u201d represents the process of a user booking a ticket in an online ticket sales system.<\/li>\n<\/ul>\n\n\n
\n
![\"\"](\"https:\/\/i0.wp.com\/www.autosyseng.com\/wp-content\/uploads\/2024\/04\/image-49.png?resize=172%2C119&ssl=1\" "\\"\\"")
<\/figure><\/div>\n\n\ngeneralization and specialization<\/strong><\/h4>\n\n\n\n\n- Representation of generalization relationships : <\/strong>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.<\/li>\n\n\n\n
- Role of subtypes : <\/strong>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.<\/li>\n<\/ul>\n\n\n
\n
![\"\"](\"https:\/\/i0.wp.com\/www.autosyseng.com\/wp-content\/uploads\/2024\/04\/image-50.png?resize=225%2C327&ssl=1\" "\\"\\"")
<\/figure><\/div>\n\n\n
\n\n\n\n<\/p>\n\n\n\n
<\/span>Understanding Types of Use Cases in the UseCase Diagram<\/strong><\/span><\/h3>\n\n\n\nBase Use Cases<\/strong><\/h4>\n\n\n\nThe 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, \u201cupdating customer information\u201d might be a primary use case for a customer service system.<\/p>\n\n\n\n
<\/p>\n\n\n\n
Included Use Cases and Inclusion Relationships<\/strong><\/h4>\n\n\n\n\n- 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 \u00abinclude\u00bb keyword.<\/li>\n\n\n\n
- 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, \u201cpayment processing\u201d, which is a common requirement across all order processing operations, can be set up as an included use case.
<\/li>\n<\/ul>\n\n\n\nExtending Use Cases and Extending Relationships<\/strong><\/h4>\n\n\n\n\n- 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 \u00abextend\u00bb.<\/li>\n\n\n\n
- Selective execution and trigger conditions: Extended use cases selectively execute when certain conditions are met. For example, \u201cApply Discount Coupon\u201d could be an optional feature that extends the \u201cPurchase Product\u201d use case.
<\/li>\n<\/ul>\n\n\n\n
![\"\"](\"https:\/\/i0.wp.com\/www.autosyseng.com\/wp-content\/uploads\/2024\/04\/image-52.png?resize=603%2C284&ssl=1\" "\\"\\"")
<\/figure><\/div>\n\n\n<\/p>\n\n\n\n
Effective use of use case diagrams<\/strong><\/h4>\n\n\n\nWhen 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.<\/p>\n\n\n\n
<\/p>\n\n\n\n
\n\n\n\n<\/p>\n\n\n\n
<\/span>Understanding the role and notation of \u2018Actor\u2019 in SysML UseCase Diagram<\/strong><\/span><\/h3>\n\n\n\nThe 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:<\/p>\n\n\n\n
Actor notation<\/strong><\/h4>\n\n\n\n\n- Simple stick figures : <\/strong>This representation provides a visual representation of a human user. It is primarily used when human users interact directly with the system.<\/li>\n\n\n\n
- Rectangle and \u201cactor\u201d keyword : <\/strong>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.<\/li>\n<\/ul>\n\n\n\n
Classification through generalization<\/strong><\/h4>\n\n\n\nIf actors share common characteristics, they can be organized hierarchically using generalization relationships. For example, under a general actor called \u201cCustomer\u201d you could have specialized actors such as \u201cMember Customer\u201d and \u201cNon-Member Customer\u201d. This structure makes it clear how different types of users will use the system and their requirements.<\/p>\n\n\n\n
<\/p>\n\n\n
\n
![\"\"](\"https:\/\/i0.wp.com\/www.autosyseng.com\/wp-content\/uploads\/2024\/04\/image-53.png?resize=185%2C376&ssl=1\" "\\"\\"")
<\/figure><\/div>\n\n\nRelationship between UseCase and Actor<\/strong><\/h4>\n\n\n\n\n- Primary and secondary actors : <\/strong>Actors that directly invoke or participate in a use case are called \u2018primary actors\u2019. For example, a customer invoking the \u201cpurchase product\u201d use case in an online shopping system. On the other hand, actors who participate indirectly in a use case are classified as \u2018auxiliary actors\u2019. For example, a banking system responsible for payment processing could be a secondary actor in the \u201cpurchase goods\u201d use case.<\/li>\n\n\n\n
- Interaction between actors and use cases : <\/strong>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:<\/li>\n\n\n\n
- Association : <\/strong>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.<\/li>\n\n\n\n
- Links between instances during system operation : <\/strong>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.<\/li>\n<\/ul>\n\n\n\n
<\/p>\n\n\n\n
\n\n\n\n<\/p>\n\n\n\n
<\/span>System Boundaries: Understanding the scope and interfaces of a system in a UseCase Diagram<\/strong><\/span><\/h3>\n\n\n\nSystem 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:<\/p>\n\n\n\n
How to express system boundaries<\/strong><\/h4>\n\n\n\nThe 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.<\/p>\n\n\n\n
System perimeter in ConOps<\/strong><\/h4>\n\n\n\nDuring 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.<\/p>\n\n\n\n
System boundaries in architectural design<\/strong><\/h4>\n\n\n\nDuring 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.<\/p>\n\n\n\n
The importance of system boundaries<\/strong><\/h4>\n\n\n\nThe 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.<\/p>\n\n\n\n
<\/p>\n\n\n\n
\n\n\n\n<\/p>\n\n\n\n
<\/span>UseCase Specification: Clearly defining system requirements<\/strong><\/span><\/h3>\n\n\n\nThe 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:<\/p>\n\n\n\n
\n- Use case name : <\/strong>Use cases are named using verb phrases and are often named from the actor’s perspective. For example, \u2018purchase a product\u2019, \u2018create an account\u2019, etc. intuitively reflect the actions of an actor interacting with the system.<\/li>\n\n\n\n
- Range : <\/strong>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.<\/li>\n\n\n\n
- Primary and supporting (secondary) actors : <\/strong>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.<\/li>\n\n\n\n
- Preconditions and Postconditions : <\/strong>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.<\/li>\n\n\n\n
- trigger : <\/strong>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.<\/li>\n\n\n\n
- Key Success Scenarios and Scaling (Alternative Branches) : <\/strong>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.<\/li>\n<\/ul>\n\n\n\n
<\/p>\n\n\n\n
<\/span>UseCase Specification Writing Guide: Effective Requirements Definition<\/span><\/h3>\n\n\n\nNarrative-centered approach<\/strong><\/h4>\n\n\n\nWhen 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.<\/p>\n\n\n\n
Screenwriting<\/strong><\/h4>\n\n\n\nEach 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.<\/p>\n\n\n\n
The importance of segmentation<\/strong><\/h4>\n\n\n\nAvoid 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.<\/p>\n\n\n\n
Visual representation<\/strong><\/h4>\n\n\n\nAfter 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.<\/p>\n\n\n\n
<\/p>\n\n\n\n
\n\n\n\n<\/p>\n\n\n\n
<\/span>Effective system design using scenario builder<\/strong><\/span><\/h3>\n\n\n\nScenario Builder is an essential tool for systematically defining and documenting the details of use cases during system design and development. Let\u2019s take a closer look at the key steps in using this tool and their importance.<\/p>\n\n\n\n
\n- Detailed description definition : <\/strong>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.<\/li>\n\n\n\n
- Scenario creation : <\/strong>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.<\/li>\n\n\n\n
- Define preconditions and postconditions : <\/strong>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.<\/li>\n\n\n\n
- Define constraints : <\/strong>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.<\/li>\n\n\n\n
- Create diagram :<\/strong> Create a diagram to visually represent the generated scenario. These diagrams are very useful in understanding and explaining how complex systems work.<\/li>\n\n\n\n
- Sync and Track : <\/strong>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.<\/li>\n<\/ol>\n\n\n\n
<\/span>Practical Example<\/strong><\/span><\/h3>\n\n\n\nIn automotive electronic systems, let’s consider the design of an ’emergency braking system’. Using Scenario Builder you can:<\/p>\n\n\n\n
\n- DEFINITION OF DETAILED DESCRIPTION<\/strong> : Describes in detail how the car should react in an emergency situation.<\/li>\n\n\n\n
- Scenario Creation<\/strong> : For example, create a scenario when an obstacle suddenly appears ahead.<\/li>\n\n\n\n
- Define preconditions and postconditions<\/strong> : Define the vehicle state before and after obstacle detection.<\/li>\n\n\n\n
- Constraint Definition<\/strong> : Specifies system response time, sensor detection range, etc.<\/li>\n\n\n\n
- Create a diagram<\/strong> : Visually represent the operating principles of an emergency braking system based on a scenario.<\/li>\n\n\n\n
- Synchronization and Tracking<\/strong> : Keeps all steps up to date and tracks connections with other elements of the system.<\/li>\n<\/ol>\n\n\n\n
<\/p>\n\n\n\n
\n\n\n\n<\/p>\n\n\n\n
<\/span>Refine your use case: Leverage different behavioral modeling methods<\/strong><\/span><\/h3>\n\n\n\nUse 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:<\/p>\n\n\n\n
Interaction model<\/strong><\/h4>\n\n\n\nSuitable 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.<\/p>\n\n\n\n
Activity model<\/strong><\/h4>\n\n\n\nIt 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.<\/p>\n\n\n\n
State machine model<\/strong><\/h4>\n\n\n\nThis 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.<\/p>\n\n\n\n