Skip to content

Commit

Permalink
Update 06_runtime_view
Browse files Browse the repository at this point in the history
  • Loading branch information
baraganio authored Apr 7, 2024
1 parent 597fe01 commit 668b401
Showing 1 changed file with 22 additions and 58 deletions.
80 changes: 22 additions & 58 deletions docs/src/06_runtime_view.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -3,63 +3,27 @@ ifndef::imagesdir[:imagesdir: ../images]
[[section-runtime-view]]
== Runtime View


[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:
* 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
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.
.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).
.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
* ...
.Further Information
See https://docs.arc42.org/section-6/[Runtime View] in the arc42 documentation.
****

=== <Runtime Scenario 1>


* _<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.>_

It is possible to use a sequence diagram:

[plantuml,"Sequence diagram",png]
=== User plays a game
When the game is started, the app will call the createquestion service that is in charge of provide generated questions from wikidata information.
[plantuml,"Start a game",png]
----
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
actor a as "User"
participant q as "Game GUI"
participant w as "CreateQuestions service"
database d as "Database"
a -> q: Start the game
loop number of questions
q -> w: Ask for a question
w -->q: Returns the question
q -> d: Store the question
q -> a: Returns the question
a -> q: Pick an answer
q -> a: Shows if the answer was valid or not
a -> q: Asks for next question
end
q -> a: Show the game stats
q -> d: Store the game with questions, answers and stats
----

=== <Runtime Scenario 2>

=== ...

=== <Runtime Scenario n>

0 comments on commit 668b401

Please sign in to comment.