From 668b401a67f64eeaaca1c4533732809d5e3fa80e Mon Sep 17 00:00:00 2001 From: Carlos Sanchez <108028059+baraganio@users.noreply.github.com> Date: Mon, 8 Apr 2024 00:04:50 +0200 Subject: [PATCH] Update 06_runtime_view --- docs/src/06_runtime_view.adoc | 80 ++++++++++------------------------- 1 file changed, 22 insertions(+), 58 deletions(-) diff --git a/docs/src/06_runtime_view.adoc b/docs/src/06_runtime_view.adoc index e10f375b..c9e002f6 100644 --- a/docs/src/06_runtime_view.adoc +++ b/docs/src/06_runtime_view.adoc @@ -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. - -**** - -=== - - -* __ -* __ - -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 ---- - -=== - -=== ... - -===