[]{.cart-text} {.btn .cart .open-checkout} []{.btn-text-span .d-none .d-sm-inline-block .d-lg-none .d-hg-inline-block}{.btn .btn-secondary .checkout .open-checkout}
{.home} / UML{.type} / Modeling IT Systems{.type}
Use Case Sequence Diagram {#use-case-sequence-diagram .title}
The use case sequence diagram is a special use of UML sequence diagrams that we advocate (see Figure 4.13). We will discuss the sequence diagram in detail in Interaction View. In the use case sequence diagram, we work with the following elements:
Comment
The flow of the use case is described in a combination of textual description and sequence diagram:
Comments can describe the flow of the use case in a simplistic manner; UML generally allows the placement of comments in all diagrams.
Reference to Prototype
References to screen forms, lists, and other elements of the user interface can be placed within comments:
This creates a link between the use case sequence diagram and the prototype.
Actor “Somebody”
Actor “somebody” represents any actor from the use case diagram. “Somebody” is the origin of all events within the use case that go to the IT system:
Because a use case can have different actors we use the actor “somebody”. This way we don’t have to specify a real actor.
Query Event
A query event is an event that is sent to the IT system with the goal of reading information (see Query Events and Mutation Events).
Mutation Event
A mutation event is an event that is sent to the IT system with the goal of modifying information (again, see Query Events and Mutation Events).
Interaction Reference
An interaction reference shows that at this point the use case sequence diagram of another use case is called (see the explanation of include relationships in Use Case Diagrams).
IT System
The IT system represents the black box with all its objects and its entire functionality:
All events in the use case go to the IT system. In the external view we do not care which individual objects within the IT system are affected by the events.
Reading Use Case Sequence Diagrams
Figure 4.14 shows the use case sequence diagram of the use case boarding. A use case sequence diagram always belongs to a use case, because it describes the interaction flow of a use case. The flow becomes apparent from the comment at the left border. First, the boarding pass is read and verified (1) by sending the query event «Q» validity boarding pass (2) from the actor of the use case (3) to the IT system (4). How the event is treated internally cannot be seen in this diagram, because the IT system is viewed as a black box. The validity of the boarding pass is verified, which probably means that the information on the boarding pass that is read into the IT system is compared with the stored information. On the basis of the information that the IT system returns, users are able to see if the verification was successful or not. The result does not have its own arrow, but instead flows back through the query arrow (2).
If the boarding pass is OK (5), it can be recorded in the IT system that the passenger has boarded the plane. This happens through the mutation event «M» record boarding (6), which is sent to the IT system (4). Again, we cannot see what happens within the IT system. If the boarding pass is not OK (7), the display should show information about the ticket that belongs to this boarding pass. For this, again, a query event «Q» coupon details (8) coupon details, is sent to the IT system. This query results in the desired information, as long as it exists within the IT system. The display of information can be illustrated in an interface prototype. The reference [B27] (9) corresponds to a screen form in an interface prototype. Consequently, the entire use case boarding is described as a sequence of query and mutation events.
Read next
Constructing the External View []{.fa .fa-arrow-right}{.btn .btn-primary rel=“next”}
Return
[]{.fa .fa-arrow-left} Query Events and Mutation Events{.btn .btn-default rel=“prev”}
Computer Science Distilled{.btn .btn-landing-ref .btn-hg .btn-block .btn-secondary style=“font-size: 16px; position: relative”}
Do you remember anything at all from your computer science class? Quicksort, Graph traversal, Big’O and other stuff? Revise your memories with our new book on Computer Science.
Psst! Did I mention that we’re offering sexy discounts right now?
{width=“250”
height=“312”
srcset=“/images/content-public/logos/logo-2x.png?id=fee3b4b0a14ba60dc0fe368695d78be9 2x”}{.menu-brand}
- Premium Stuff
- Design Patterns
- AntiPatterns
- Refactoring
- Code Smells
- Refactoring techniques
- Composing Methods
- Moving Features between Objects
- Organizing Data
- Self Encapsulate Field
- Replace Data Value with Object
- Change Value to Reference
- Change Reference to Value
- Replace Array with Object
- Duplicate Observed Data
- Change Unidirectional Association to Bidirectional
- Change Bidirectional Association to Unidirectional
- Replace Magic Number with Symbolic Constant
- Encapsulate Field
- Encapsulate Collection
- Replace Type Code with Class
- Replace Type Code with Subclasses
- Strategy
- Replace Subclass with Fields
- Simplifying Conditional Expressions
- Simplifying Method
Calls
- Rename Method
- Add Parameter
- Remove Parameter
- Separate Query from Modifier
- Parameterize Method
- Replace Parameter with Explicit Methods
- Preserve Whole Object
- Replace Parameter with Method Call
- Introduce Parameter Object
- Remove Setting Method
- Hide Method
- Replace Constructor with Factory Method
- Replace Error Code with Exception
- Replace Exception with Test
- Dealing with Generalisation
- UML
- Introduction
- Basic Principles and Background
- Modeling Business Systems
- Business Processes and Business Systems
- One Model---Two Views
- External View
- The Elements of a View
- Use Case Diagrams
- Constructing Use Case Diagrams
- Activity Diagrams
- Constructing Activity Diagrams
- Sequence Diagrams
- Constructing Sequence Diagrams
- High-Level Sequence Diagrams
- Sequence Diagrams for Scenarios of Business Use Cases
- Internal View
- Package Diagram
- Constructing Package Diagrams
- Class Diagram
- Constructing Class Diagrams
- Activity Diagram
- Modeling IT Systems
- External View
- The User View or “I don’t care how it works, as long as it works.”
- The Elements of a View
- Use Case Diagram
- Query Events and Mutation Events
- Use Case Sequence Diagram
- Constructing the External View
- Structural View
- Objects and Classes
- Generalization, Specialization, and Inheritance
- Static and Dynamic Business Rules
- Elements of the View
- Class Diagram
- Constructing Class Diagrams
- The Behavioral View
- The Life of an Object
- The Elements of the View
- Statechart Diagram
- Constructing Statechart Diagrams
- Interaction View
- Seeing What Happens Inside the IT System
- Elements of the View
- Communication Diagram
- Sequence Diagram
- Constructing Communication Diagrams
- Constructing Sequence Diagrams
- Modeling for System
Integration
- Terminology of System Integration
- Messages in UML
- One Model---Two Views
- Process View
- The Business System Model as Foundation
- Elements of the View
- Activity Diagrams
- Sequence Diagram
- Constructing Diagrams in the Process View
- The Static View
- Elements of the View
- Class Diagram
- Constructing Class Diagrams
- Transforming Data from the IT System to the Message “passenger list”
- Transformation of UML Messages into Various Standard Formats
Log in Contact us{.userecho-public rel=“nofollow”}
{srcset=“/images/content-public/logos/logo-min-xs-2x.png?id=34fc05750336c33b7815e231a0f227df 2x”}{.navigation-brand}
Shop Now!{.btn .btn-md .btn-primary .btn-featured}
-
[Contact us]{.caption .d-none .d-xl-inline-block}{.userecho-private rel=“nofollow”}
-
Forum{.userecho-public rel=“nofollow”}
-
Contact us{.userecho-private rel=“nofollow”}
© 2007-2023 SourceMaking.com[ / ]{.d-none .d-md-inline}
All rights reserved.