Skip to content

Commit

Permalink
chore: Update 06_runtime_view.adoc
Browse files Browse the repository at this point in the history
  • Loading branch information
GOLASOOO authored Feb 18, 2024
1 parent d2ab32d commit 44b19ba
Showing 1 changed file with 71 additions and 40 deletions.
111 changes: 71 additions & 40 deletions docs/src/06_runtime_view.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -2,64 +2,95 @@ ifndef::imagesdir[:imagesdir: ../images]

[[section-runtime-view]]
== Runtime View
Here we can see what the main workflow of main parts of the project.

=== General Game's life cycle
* This diagram shows how should the application behave for an expected normal case scenario.

[role="arc42help"]
****
.Contents
The runtime view describes concrete behavior and interactions of the system’s building blocks in form of scenarios from the following areas:
[plantuml,"Game's life cycle diagram",png]
----
@startuml Game's life cycle
actor Client
skinparam Style strictuml
skinparam SequenceMessageAlignment center
* important use cases or features: how do building blocks execute them?
* interactions at critical external interfaces: how do building blocks cooperate with users and neighboring systems?
* operation and administration: launch, start-up, stop
* error and exception scenarios
Client --> API : start game
loop One question
API --> QuestionRetriever : ask for question
QuestionRetriever --> QuestionDB : querying question
Remark: The main criterion for the choice of possible scenarios (sequences, workflows) is their *architectural relevance*. It is *not* important to describe a large number of scenarios. You should rather document a representative selection.
QuestionDB --> QuestionRetriever : return first question and all answers
QuestionRetriever --> API : return first question and all answers
.Motivation
You should understand how (instances of) building blocks of your system perform their job and communicate at runtime.
You will mainly capture scenarios in your documentation to communicate your architecture to stakeholders that are less willing or able to read and understand the static models (building block view, deployment view).
API --> Client : return first question and all answers
Client -> API : send chosen answer
API --> API : check answer is correct
API --> Client : inform user guessed right
end loop One question
.Form
There are many notations for describing scenarios, e.g.
* numbered list of steps (in natural language)
* activity diagrams or flow charts
* sequence diagrams
* BPMN or EPCs (event process chains)
* state machines
* ...
API --> Client : inform user guessed right last question
API --> API : update ranking
API --> Client : show ranking
@enduml
----

=== Sign Up
[plantuml,"Sign up diagram",png]
----
@startuml sign up
.Further Information
actor Client
See https://docs.arc42.org/section-6/[Runtime View] in the arc42 documentation.
skinparam Style strictuml
skinparam SequenceMessageAlignment center
****
Client --> API : enters credentials
API --> BD : check credentials unused
API --> BD : register user
BD --> Client : return user token
=== <Runtime Scenario 1>
@enduml
----

=== Login
[plantuml,"Login diagram",png]
----
@startuml login
* _<insert runtime diagram or textual description of the scenario>_
* _<insert description of the notable aspects of the interactions between the
building block instances depicted in this diagram.>_
actor Client
skinparam Style strictuml
skinparam SequenceMessageAlignment center
It is possible to use a sequence diagram:
Client --> API : enters credentials
API --> BD : check credentials correct
BD --> API : return user token
API --> BD : save SWT
API --> Client : return user token
[plantuml,"Sequence diagram",png]
@enduml
----
actor Alice
actor Bob
database Pod as "Bob's Pod"
Alice -> Bob: Authentication Request
Bob --> Alice: Authentication Response
Alice --> Pod: Store route
Alice -> Bob: Another authentication Request
Alice <-- Bob: another authentication Response

=== Question Generation
[plantuml,"Question generation diagram",png]
----
@startuml question generator
skinparam Style strictuml
skinparam SequenceMessageAlignment center
=== <Runtime Scenario 2>
QuestionGenerator --> WikiDataQS : querying correct answer
QuestionGenerator <-- WikiDataQS : return correct answer
=== ...
QuestionGenerator --> WikiDataQS : querying wrong answers
QuestionGenerator <-- WikiDataQS : return wrong answers
QuestionGenerator --> QuestionDB : store question
QuestionGenerator --> QuestionDB : store correct answer
QuestionGenerator --> QuestionDB : store wrong answers
@enduml
----

=== <Runtime Scenario n>

0 comments on commit 44b19ba

Please sign in to comment.