Date: Fri, 29 Mar 2024 13:33:41 +0000 (UTC) Message-ID: <2003263883.1.1711719221054@b9d2bebf3662> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_0_1613086557.1711719221035" ------=_Part_0_1613086557.1711719221035 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
A sequence diagram is an interaction diagram that shows how processes op= erate with one another and in what order.
Most developers would find the syntax fairly familiar. The following exa= mple demonstrates some basic syntaxes.
The above diagram is generated from the follow text:
// Opti= onally declare a participant (see Participant) @Lambda BookLibService // Sync message; <br> // Use `A->B: message` for async messages BookLibService.Borrow(id) { // Nested message User =3D Session.GetUser() { // Self message loadUserProfile() } // Alt fragment; also try `while`, `par` (see Fragments) if(User.isActive) { // Try/Catch/Finally fragment try { BookRepository.Update(id, onLoan, User) // Creation message with return message receipt =3D new Receipt(id, dueDate) } catch (BookNotFoundException) { ErrorService.onException(BookNotFoundException) } finally { Connection.close() } } // separte return message return receipt }
The participants can be defined implicitly as in the first example on th= is page. The participants are rendered in order of appearance in the diagra= m source text. Sometimes you might want to show the participants in a diffe= rent order than how they appear in the first message. It is possible to spe= cify the participant=E2=80=99s order of appearance by doing the following:<= /p>
B A A.method() A->B: Event
We can group the participants with group
keyword.
group G= roupName { A B } C
We can change the shape of the participant representation with ann=
otations
.
@Actor = A @Database B @Boundary C @Control D @Entity E @EC2 F @ECS G @RDS H @S3 I @IAM J @Lambda K
It is possible to add stereotypes to participants using <<=
code> and
>>
.
<<= ;Callable>> B <<Service>> A A.method() A->B: Event
ADVANCED= span>
By default, the =E2=80=9Cclient=E2=80=9D of the interaction is not shown=
in the diagram. However, you can specify a =E2=80=9Cclient=E2=80=9D with t=
he @Starter
keyword. Specifically, if the starter=E2=80=99s na=
me is =E2=80=9CUser=E2=80=9D or =E2=80=9CActor=E2=80=9D, we will use a Stic=
kman icon. @Starter
must be put after you have declared all pa=
rticipants and before any messages.
<<= ;Callable>> B <<Service>> A @Starter(User) A.method() A->B: Event
A message is shown as a line from the sender MessageEnd to the receiver = MessageEnd.
See Unified Modeling Language v2.5.1, section 17.4.4.1.
Message type |
DSL |
Line and arrowhead (Spec) |
|
---|---|---|---|
Async |
A->B: Async message |
solid line with open arrowhead |
|
Sync |
A.method() |
filled arrowhead |
|
Reply |
|
dashed line with either an open or filled arrowhead |
|
Object creation |
new ClassName() |
dashed line with an open arrowhead |
|
Object deletion |
NOT SUPPORTED= YET |
Must end in a DestructionOccurrenceSpecification |
|
Lost |
NOT SUPPORTED= YET |
A small black circle at the arrow end of the message |
|
Found |
NOT SUPPORTED= YET |
A small black cirle at the starting end of the message |
The loop operand will be repeated a number of times. This is expressed b= y the notation:
while(c= ondition) {} for(enumerator) {} forEach(enumerator) {}
See the example below:
loop("E= very minute") { Alice->Bob: Great! }
The alt operand represents a choice of behavior. At most one of the oper= ands will be chosen. This is expressed by the notions:
if (con= dition1) { ... } else if (condition2) { ... } else { ... }
if (x) = { A.m1() } else if (y) { A.m2() } else { A.m3() }