Developer Documentation added

docs/developer/index.md

@@ -0,0 +1,76 @@
+# A Developer's Guide
+
+This guide is to help developers get familiar with the project. 
+
+## Software Overview
+
+* [Slides](https://odin.cps.digit.au.dk/into-cps/dtaas/assets/DTaaS-overview.pdf)
+* [Video](https://odin.cps.digit.au.dk/into-cps/dtaas/assets/videos/DTaaS-overview.mkv)
+* [Research paper draft](https://arxiv.org/abs/2305.07244)
+
+## Operating Softwares
+
+Ideally, developers should work on Ubuntu/Linux. Other operating systems are not supported inherently and may require additional steps.
+
+## Code Editing
+Any popular code editors can be used to work on the project. VS Code, Sublime Text are a few examples. 
+
+## Development Workflow
+
+To manage collaboration by multiple developers on the software, a simple [Fork, Branch, PR](https://gun.io/news/2017/01/how-to-github-fork-branch-and-pull-request/) development workflow is in place. Each developer should follow these steps:
+
+1. Have an updated fork of the main repository on their account. This should also be added to codeclimate. 
+1. Clone your personal fork onto your computer.
+    ```
+    git clone https://github.com/<yourgithubusername>/DTaaS.git
+    ```
+1. Work on your issue/feature on your personal computer. 
+
+1. Once changes are made, they should be tested on personal systems or the [integration server](https://github.com/INTO-CPS-Association/DTaaS/wiki/DTaaS-Integration-Server) .
+
+1. Any updates/additions to the software should first be committed to your personal fork.
+
+    1. To check status of your changes:
+        ```
+        git status
+        ```
+    2. Add the changes to the commit:
+        ```
+        git add --all *
+        ```
+    3. Finally, commit these to the repository on your PC.
+        ```
+        git commit -m <commit message>
+        ```
+1. Push any commits onto your fork of the repository
+    ```
+    git push
+    ```
+
+1. Any issues taht arise codeclimate should also be resolved. 
+1. Once changes are verified, a PR should be made to the appropriate branch of the main repository.
+1. Any issues raised in the PR review should be resolved. 
+1. Finally, the PR will be merged.
+
+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.
+
+While any new issues introduced in your code would be shown in the PR page itself, to address any specific issue, you can visit the Issues or Code section of the CodeClimate page.
+
+It is highly recommended that any code you add does not introduce new quality issues. If they are introduced, they should be fixed immediately using the appropriate suggestions from CodeClimate, or in worst case, adding a ignore flag (To be used with caution).
+
+## Testing
+For information about testing and workflow related to that, please see the [testing folder](docs\developer\testing).
+
+## License
+
+This software is owned by [The INTO-CPS Association](https://into-cps.org/) and is available under [the INTO-CPS License](LICENSE.md).
+
+The DTaaS software platform uses [Træfik](https://github.com/traefik/traefik), [ML Workspace](https://github.com/ml-tooling/ml-workspace), [Grafana](https://github.com/grafana/grafana), [InfluxDB](https://github.com/influxdata/influxdb) and [RabbitMQ](https://github.com/rabbitmq/rabbitmq-server) open-source components. These software components have their own licenses.

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

@@ -0,0 +1,46 @@
+classDiagram
+    class FilesResolver {
+    -filesService: IFilesService
+    +listDirectory(path: string): Promise<Project>
+    +readFile(path: string): Promise<Project>
+    }
+
+    class FilesServiceFactory {
+    -configService: ConfigService
+    -gitlabFilesService: GitlabFilesService
+    -localFilesService: LocalFilesService
+    +create(): IFilesService
+    }
+
+    class GitlabFilesService {
+    -configService: ConfigService
+    -parseArguments(path: string): Promise<domain: string; parsedPath: string>
+    -sendRequest(query: string): Promise<Project>
+    -executeQuery(path: string, getQuery: QueryFunction): Promise<Project>
+    +listDirectory(path: string): Promise<Project>
+    +readFile(path: string): Promise<Project>
+    }
+
+    class LocalFilesService {
+    -configService: ConfigService
+    -getFileStats(fullPath: string, file: string): Promise<Project>
+    +listDirectory(path: string): Promise<Project>
+    +readFile(path: string): Promise<Project>
+    }
+
+    class ConfigService {
+    +get(propertyPath: string): any
+    }
+
+    class IFilesService{
+    listDirectory(path: string): Promise<Project>
+    readFile(path: string): Promise<Project>
+    }
+
+    IFilesService <|-- FilesResolver: uses
+    IFilesService <|.. GitlabFilesService: implements
+    IFilesService <|.. LocalFilesService: implements
+    IFilesService <|-- FilesServiceFactory: creates
+    ConfigService <|-- FilesServiceFactory: uses
+    ConfigService <|-- GitlabFilesService: uses
+    ConfigService <|-- LocalFilesService: uses

docs/developer/system/architecture.md

@@ -0,0 +1,45 @@
+# System  Architecture
+![Alt text](architecture.png)
+##  User Requirements
+
+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
+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
+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
+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
+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
+execution phase. This functionality is required for ondemand saving and re-spawning of DTs.
+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.
+
+##  System Components
+
+The figure shows the system architecture of the the DTaaS software platform. The main domains of this architecture are:
+
+1. [Website](https://github.com/INTO-CPS-Association/DTaaS/tree/feature/distributed-demo/client#readme) - The users interact with the software platform using a website. This is the Client side (frontend) for Digital Twin as a Service (DTaaS) software. The software provides a React single page web application for the Digital Twin support platform.
+
+2. [Gateway](https://github.com/astitva1905/DTaaS/tree/feature/distributed-demo/servers/config/gateway#the-gateway-server) - This is the single point of entry for direct access to the platform services. The gateway is responsible for controlling user access to the microservice components.
+
+3. [Library Microservice](https://github.com/astitva1905/DTaaS/tree/feature/distributed-demo/servers/lib#readme) - The microservices are complementary and composable; they fulfil core requirements of the system. The service mesh enables discovery of microservices, load balancing and authentication functionalities. There are microservices for catering to author, store, explore, configure, execute and scenario analysis requirements.
+
+The detailed C4 architecture is shown below, which includes all the atomic components of the system:
+
+![Detailed C4 architecture](c4.png)
+
+

docs/developer/testing/intro.md

@@ -0,0 +1,42 @@
+# Testing
+
+## What is Software Testing?
+Software testing is a procedure to investigate the quality of a software product in different scenarios. It can also be stated as the process of verifying and validating that a software program or application works as expected and meets the business and technical requirements that guided design and development.
+
+### Why Software Testing?
+Software testing is required to point out the defects and errors that were made during different development phases. Software testing also ensures that the product under test works as expected in all different cases – stronger the test suite, stronger is our confidence in the product that we have built. One important benefit of software testing is that it facilitates the developers to make incremental changes to source code and make sure that the current changes are not breaking the functionality of the previously existing code.
+
+### What is TDD?
+TDD stands for “Test Driven Development”. It is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards. The goal of TDD can be viewed as specification and not validation. In other words, it’s one way to think through your requirements or design before your write your functional code.
+
+### What is BDD?
+BDD stands for “Behaviour Driven Development”. It is a software development process that emerged from TDD. It includes the practice of writing tests first, but focuses on tests which describe behavior, rather than tests which test a unit of implementation. This provides software development and management teams with shared tools and a shared process to collaborate on software development. BDD is largely facilitated through the use of a simple domain-specific language (DSL) using natural language constructs (e.g., English-like sentences) that can express the behavior and the expected outcomes. Mocha and Cucumber are built around the concepts of BDD.
+
+# Testing workflow
+
+We follow a testing workflow in accordance with [The Test Pyramid](https://martinfowler.com/articles/practical-test-pyramid.html#TheTestPyramid), starting with isolated tests and moving towards complete integration for any new feature changes. The different types of tests (in the order that they should be performed) are explained below:
+
+TODO -> DOnt link. 
+## [Unit Tests](https://martinfowler.com/articles/practical-test-pyramid.html#UnitTests) 
+
+Unit testing is a level of software testing where individual units/ components of a software are tested. The objective of Unit Testing is to isolate a section of code and verify its correctness.
+
+Ideally, each test case is independent from the others. Substitutes such as method stubs, mock objects, and spies can be used to assist testing a module in isolation.
+
+### Benefits of Unit Testing
+* Unit testing increases confidence in changing/ maintaining code. If good unit tests are written and if they are run every time any code is changed, we will be able to promptly catch any defects introduced due to the change. 
+* If codes are already made less interdependent to make unit testing possible, the unintended impact of changes to any code is less.
+* The cost, in terms of time, effort and money, of fixing a defect detected during unit testing is lesser in comparison to that of defects detected at higher levels.
+
+## [Integration tests](https://martinfowler.com/articles/practical-test-pyramid.html#IntegrationTests) 
+
+Integration testing is the phase in software testing in which individual software modules are combined and tested as a group. In DTaaS, we use an [integration server](https://github.com/INTO-CPS-Association/DTaaS/wiki/DTaaS-Integration-Server) for software development as well as such tests. 
+
+## Feature Tests
+
+A Software feature can be defined as the changes made in the system to add new functionality or modify the existing functionality. Each feature is said to have a characteristics that is designed to be useful, intuitive and effective. It is important to test a new feature when it has been added. We also need to make sure that it does not break the functionality of already existing features. Hence feature tests prove to be useful.
+
+## [End-to-End tests](https://martinfowler.com/articles/practical-test-pyramid.html#End-to-endTests)
+
+Testing any code changes through the end user interface of your software is essential to verify if your code has the desired effect for the user. [End-to-End tests in DTaaS](https://github.com/INTO-CPS-Association/DTaaS/blob/feature/distributed-demo/client/test/README.md) a functional setup. For more information [visit here](https://github.com/INTO-CPS-Association/DTaaS/blob/feature/distributed-demo/client/test/README.md). 
+