Updated 2. Software Architecture Specification (markdown)

2.-Software-Architecture-Specification.md

@@ -174,23 +174,39 @@ The controller is the main control unit. It is responsible for communicating wit
 <em>Figure 2 - Logic of the plugin</em>
 </p>
 
-In the figure above, you can see the new architecture design that depicts the structure of the standalone application (cf. Figure 2). As you can see in the illustration, the user only interacts with the graphical user interface. This then passes the input from the user to the controller and the controller displays the information in the GUI. The controller processes the requests with the help of the AutomationML engine, but not all functions were mapped for this because there would be too many. For example, it can be used to save and load models in AML format. To be able to process IODD and GSD model formats, the programme needs converters. These work with two interfaces and return an AutomationML file.
+In the figure above, you can see the new architecture design that depicts the structure of the standalone application (cf. Figure 2). As you can see in the illustration, the user only interacts with the graphical user interface. This then passes the input from the user to the controller and the controller displays the information in the GUI. The controller processes the requests with the help of the AutomationML engine, but not all functions were mapped for this because there would be too many. For example, it can be used to save and load models in AML format. To be able to process IODD and GSD model formats, the programme needs converters. These work with two interfaces and return an AutomationML file. However, due to the further development based on the project, the architecture became more and more unstructured and complex. As a result, MVC is no longer used as intended. This was further complicated by the use of a Microsoft Forms application. Ultimately, as can be seen in Figure 4, the architecture became increasingly unstructured and complex.
 
 # 5. System Design <a name="SD"/>
 
+The idea of making the plugin a standalone application is to run the plugin on another programme that provides the appropriate dependencies. This gives the impression of running the plugin directly (cf. Figure 3).
+
 <p align="center"> 
-<img src="https://user-images.githubusercontent.com/76038781/140761356-05e600c3-b11f-46a8-9bb2-355cdc1e82db.PNG" alt="System" /><br>
+<img src="https://user-images.githubusercontent.com/75857685/164975110-f0a6ca9e-4d92-42bc-97f1-6a1642ad37bf.png" alt="System" /><br>
-<em>Figure 3 - System class design</em>
+<em>Figure 3 - Programme Concept</em>
 </p>
 
-This figure is showing the complete software structure design. There was actually no change here, as the concept of the plug-in was taken over from the [old project](https://github.com/DekaAthlos/TINF19C-ModellingWizard). 
+The advantage of this solution is that the code of the plug-in remains largely intact. This makes it easier to adopt the ideas and insights of the old team. The programme on which the plug-in runs is shown in figure 4.
+
+<p align="center"> 
+<img src="https://user-images.githubusercontent.com/75857685/164975424-b665390c-47e4-4878-9cd5-3b8fa009832b.png" alt="System" /><br>
+<em>Figure 4 - Class design from the main application</em>
+</p>
+
+The "Program" field in the diagram is supposed to represent an executable file; if you click on it, "Form1" is called. This function then loads the "ModellingWizard", i.e. the plugin. This means that the GUI of the plugin is then displayed in "Form1".  
+
+<p align="center"> 
+<img src="https://user-images.githubusercontent.com/75857685/164975858-5380f170-3a2e-421f-b419-8a6f9790b425.png" alt="System" /><br>
+<em>Figure 5 - Class design from the ModellingWizard</em>
+</p>
+
+The current design of the plugin has changed a little, but not much (cf. Figure 5). The concept of the plugin and most of the code was taken over from the [old project](https://github.com/DekaAthlos/TINF19C-ModellingWizard). 
 
 <p align="center"> 
 <img src="https://user-images.githubusercontent.com/76038781/140761360-67adafbe-f4c9-4279-a80e-d0430b1b5cc9.png" /><br>
-<em>Figure 4 - MVC pattern</em>
+<em>Figure 6 - MVC pattern</em>
 </p>
 
-Still the MVC pattern is a small part of the whole system design. In this case the InputFromUser is obviously the user input. DeviceDesc (standing for Device Description), due to its two different C# program files, once maps the GUI and once the controller. DataMW is the class that takes care of the data management and creates an object of the type MWData, which can then export, store and process through the controller. The source code is located in the "app-source-code" branch under the "Source" folder. Click to open the [Source folder](https://github.com/H4CK3R-01/TINF20C_ModellingWizard_Devices/tree/app-source-code/SOURCE).
+Still the MVC pattern is a small part of the whole system design (cf. Figure 6). In this case the InputFromUser is obviously the user input. DeviceDesc (standing for Device Description), due to its two different C# program files, once maps the GUI and once the controller. DataMW is the class that takes care of the data management and creates an object of the type MWData, which can then export, store and process through the controller. The source code is located in the "app-source-code" branch under the "Source" folder. Click to open the [Source folder](https://github.com/H4CK3R-01/TINF20C_ModellingWizard_Devices/tree/app-source-code/SOURCE).
 
 | **Classname** | **Storage location** |
 | --- | --- |