Refining the description of system functions using a Sequence diagram (continued "Squirrels")
In this article, we will explore how to detail (refine) the description of the automated function using a UML Sequence Diagram.
In this example, I am using the Enterprise Architect environment from an Australian company. [1].
Full UML specification can be found. [2].
To begin, let me explain that we will be detailing.
In We modeled the processes of the "fairy tale" subject area — lines about the squirrel from A.S. Pushkin's "The Tale of Tsar Saltan." We started with the Activity diagram. Then we developed a functional model using a Use-case diagram, a fragment of which is presented in Figure 1.
Figure 1. The relationship between requirement and function
Now we want to clarify information about the execution of this automated function:
- which interface components our user will interact with;
- what control components we will need;
- what we will be storing;
- what messages will be exchanged between the user and system components to execute the function.
The main elements of the Sequence diagram are the interacting objects with various stereotypes and the connections between them—interacting objects exchange certain information with each other (Figure 2).
Figure 2. Key elements of the Sequence diagram
Objects are arranged in a horizontal sequence, and messages are passed between them. The time axis is oriented from top to bottom.
The Actor element can be used to represent a user initiating a flow of events.
Each object has a dashed line called a "lifeline," where this element exists and potentially participates in interactions. The focus of control is indicated by a rectangle on the object's lifeline.
The messages exchanged between objects can be of several types; messages can also be configured to reflect operations and properties of the source and target elements.
Stereotyped elements such as boundaries (Boundary), control elements (Control), and entities (Entity) can be used to model the graphical user interface (GUI), controllers, and database elements, respectively.
A recurring flow of message exchanges can be denoted as a fragment with a type of "loop."
So, we plan to clarify the description of the function 'Add information about the new nut to the register.'
Let's agree on the following additional summaries and assumptions.
- Nut, kernel, and shell are all material values of the corresponding types (Figure 3).
Figure 3. Clarification of the class diagram - In the register, our user will enter information about any material values.
- Let's clarify the name of the register — 'Material Values Accounting Register.'
- Assuming that our user, working with the GUI 'Material Values Accounting Register', can add a new material value through the GUI 'Material Value Card.'
- The structure of data and GUI changes depending on the type of material value.
- When filling out the fields of the material value card, there is a validation of the entered data.
The diagram constructed considering these assumptions is shown in Figure 4.
Figure 4. Clarification of the function 'Add information about the new nut to the register.'
You can read about the application of other types of UML diagrams here:
List of sources
- Sparx Systems website. [Electronic resource] Access mode: Internet:
- OMG Unified Modeling Language (OMG UML) Specification. Version 2.5.1. [Electronic resource] Access mode: Internet:
Source: habr.com
