PR Review changes, Mermaid Config in MkDocs

docs/developer/index.md

@@ -54,10 +54,6 @@ To manage collaboration by multiple developers on the software, a simple [Fork,
 
 Remember that every commit should be meaningful and satisfies the requirements.
 
-Additionally, please go through the two workflows specified in the diagram below:
-
-![Alt text](workflow.png)
-
 ## Code Quality
 
 Quality checks are performed by CodeClimate to ensure the best possible quality of code to add to our project.

docs/developer/servers/lib/lib-sequence.mmd

@@ -2,7 +2,7 @@ sequenceDiagram
     actor Client
     actor Traefik
 
-    box Aqua RAMS
+    box LightGreen RAMS
     participant FR as FilesResolver
     participant FSF as FilesServiceFactory
     participant CS as ConfigService 
@@ -14,86 +14,86 @@ sequenceDiagram
     participant FS as Local File System DB
     participant GAPI as GitLab API DB
 
-    Client -> Traefik : HTTP request
-    Traefik -> FR : GraphQL query
+    Client ->> Traefik : HTTP request
+    Traefik ->> FR : GraphQL query
     activate FR
 
-    FR -> FSF : create()
+    FR ->> FSF : create()
     activate FSF
 
-    FSF -> CS : getConfiguration("MODE")
+    FSF ->> CS : getConfiguration("MODE")
     activate CS
 
-    CS --> FSF : return configuration value
+    CS -->> FSF : return configuration value
     deactivate CS
 
     alt MODE = Local
-    FSF -> FR : return filesService (LFS)
+    FSF ->> FR : return filesService (LFS)
     deactivate FSF
 
-    FR -> IFS : listDirectory(path) or readFile(path)
+    FR ->> IFS : listDirectory(path) or readFile(path)
     activate IFS
 
-    IFS -> LFS : listDirectory(path) or readFile(path)
+    IFS ->> LFS : listDirectory(path) or readFile(path)
     activate LFS
 
-    LFS -> CS : getConfiguration("LOCAL_PATH")
+    LFS ->> CS : getConfiguration("LOCAL_PATH")
     activate CS
 
-    CS --> LFS : return local path
+    CS -->> LFS : return local path
     deactivate CS
 
-    LFS -> FS : Access filesystem
+    LFS ->> FS : Access filesystem
     alt Filesystem error
-        FS --> LFS : Filesystem error
-        LFS -> LFS : Throw new InternalServerErrorException
-        LFS --> IFS : Error
+        FS -->> LFS : Filesystem error
+        LFS ->> LFS : Throw new InternalServerErrorException
+        LFS -->> IFS : Error
     else Successful file operation
-        FS --> LFS : Return filesystem data
-        LFS -> IFS : return Promise<Project>
+        FS -->> LFS : Return filesystem data
+        LFS ->> IFS : return Promise<Project>
     end
     deactivate LFS
     else MODE = GitLab
-        FSF -> FR : return filesService (GFS)
+        FSF ->> FR : return filesService (GFS)
         %%deactivate FSF
 
-    FR -> IFS : listDirectory(path) or readFile(path)
+    FR ->> IFS : listDirectory(path) or readFile(path)
     activate IFS
 
-    IFS -> GFS : listDirectory(path) or readFile(path)
+    IFS ->> GFS : listDirectory(path) or readFile(path)
     activate GFS
 
-    GFS -> GFS : parseArguments(path)
-    GFS -> GFS : executeQuery()
+    GFS ->> GFS : parseArguments(path)
+    GFS ->> GFS : executeQuery()
 
-    GFS -> CS : getConfiguration("GITLAB_API_URL", "GITLAB_TOKEN")
+    GFS ->> CS : getConfiguration("GITLAB_API_URL", "GITLAB_TOKEN")
     activate CS
 
-    CS --> GFS : return GitLab API URL and Token
+    CS -->> GFS : return GitLab API URL and Token
     deactivate CS
 
-    GFS -> GAPI : sendRequest()
+    GFS ->> GAPI : sendRequest()
     alt GitLab API error
-        GAPI --> GFS : API error
-        GFS -> GFS : Throw new Error("Invalid query")
-        GFS --> IFS : Error
+        GAPI -->> GFS : API error
+        GFS ->> GFS : Throw new Error("Invalid query")
+        GFS -->> IFS : Error
     else Successful GitLab API operation
-        GAPI --> GFS : Return API response
-        GFS -> IFS : return Promise<Project>
+        GAPI -->> GFS : Return API response
+        GFS ->> IFS : return Promise<Project>
     end
     deactivate GFS
     end
 
     alt Error thrown
-    IFS -> FR : return Error
+    IFS ->> FR : return Error
     deactivate IFS
-    FR -> Traefik : return Error
-    Traefik -> Client : HTTP error response
+    FR ->> Traefik : return Error
+    Traefik ->> Client : HTTP error response
     else Successful operation
-    IFS -> FR : return Promise<Project>
+    IFS ->> FR : return Promise<Project>
     deactivate IFS
-    FR -> Traefik : return Promise<Project>
-    Traefik -> Client : HTTP response
+    FR ->> Traefik : return Promise<Project>
+    Traefik ->> Client : HTTP response
     end
 
     deactivate FR

docs/developer/system/architecture.md

@@ -5,28 +5,28 @@
 The DTaaS software platform users expect a single platform
 to support the complete DT lifecycle. To be more precise, the platform users expect the following features:
 
-1. Author – create different assets of the DT on the
+1. **Author** – create different assets of the DT on the
 platform itself. This step requires use of some software
 frameworks and tools whose sole purpose is to author
 DT assets.
-1. Consolidate – consolidate the list of available DT assets
+1. **Consolidate** – consolidate the list of available DT assets
 and authoring tools so that user can navigate the library
 of reusable assets. This functionality requires support
 for discovery of available assets.
-3. Configure – support selection and configuration of
+3. **Configure** – support selection and configuration of
 DTs. This functionality also requires support for validation of a given configuration.
-4. Execute – provision computing infrastructure on demand to support execution of a DT.
-5. Explore – interact with a DT and explore the results
+4. **Execute** – provision computing infrastructure on demand to support execution of a DT.
+5. **Explore** – interact with a DT and explore the results
 stored both inside and outside the platform. Exploration
 may lead to analytical insights.
-6. Save – save the state of a DT that’s already in the
+6. **Save** – save the state of a DT that’s already in the
 execution phase. This functionality is required for ondemand saving and re-spawning of DTs.
-7. What-if analysis – explore alternative scenarios to (i)
+7. **What-if analysis** – explore alternative scenarios to (i)
 plan for an optimal next step, (ii) recalibrate new DT
 assets, (iii) automated creation of new DTs or their
 assets; these newly created DT assets may be used to
 perform scientifically valid experiments.
-8. Share – share a DT with other users of their organisation.
+8. **Share** – share a DT with other users of their organisation.
 
 ##  System Components
 
@@ -41,7 +41,7 @@ The figure shows the system architecture of the the DTaaS software platform. The
 ## C4 architecture Level 1
 ![Alt text](c4l1.png)
 
-## C4 architecture Level 3 
+## C4 architecture Level 2
 ![Detailed C4 architecture](c4l3.png)
 
 

docs/developer/system/client.md

@@ -6,6 +6,4 @@ This is the Client side (frontend) for Digital Twin as a Service (DTaaS) softwar
 
 ## Client Architecture
 
-```mermaid
-
-```
+![Client architecture](package-diagram.png)

mkdocs.yml

@@ -78,6 +78,11 @@ markdown_extensions:
       alternate_style: true   
   - mdx_math:
       enable_dollar_delimiter: True
+  - pymdownx.superfences:
+      custom_fences:
+        - name: mermaid
+          class: mermaid
+          format: !!python/name:pymdownx.superfences.fence_code_format
 
 plugins:
   - open-in-new-tab