DHBW/TINF20C_ModellingWizard_Devices
1
0
Fork 0
Code Issues 4 Pull Requests Packages Projects Releases 7 Wiki Activity

Placeholder eingefügt

NormalParameter 2021-11-08 15:09:38 +01:00
parent 8d93562f5a
commit 76c44b43e0
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
2.-Software-Architecture-Specification.md

@ -119,23 +119,23 @@ This means that the code is indented uniformly to improve readability and compre
## 4.1 Architectural Model <a name="AC1"/>
![](RackMultipart20211105-4-tbt2na_html_e124a15acc23e9b1.png)The application was designed and developed according to a Model-View-Control (MVC) architecture pattern that resembles a cycle. The user can use the plugin by accessing the GUI. However, the actions he performs in the GUI are not processed in the GUI but in the controller and its subclasses. The controller executes the changes in the background, these are also called manipulations. Afterwards, the changes are updated on the user interface so that the user thinks that the changes were made directly in the GUI (cf. Figure 1).
![Couldn't Load Picture](RackMultipart20211105-4-tbt2na_html_e124a15acc23e9b1.png)The application was designed and developed according to a Model-View-Control (MVC) architecture pattern that resembles a cycle. The user can use the plugin by accessing the GUI. However, the actions he performs in the GUI are not processed in the GUI but in the controller and its subclasses. The controller executes the changes in the background, these are also called manipulations. Afterwards, the changes are updated on the user interface so that the user thinks that the changes were made directly in the GUI (cf. Figure 1).
Almost all the logic is contained in the controller, which thus forms the centre of the entire system architecture and contains the functionalities. There is basically only one layer that is accessible to the user, the GUI.
The controller is the main control unit. It is responsible for communicating with the user interface and the external systems that are added for conversions. This interface is the heart of the entire application and is responsible for the functionalities, but also for the integration of additional functions such as saving or loading AMLX packages from the AutomationML Engine. Thus, the concept builds on that of the plug-in, making it easier to adapt functions and ideas.
![](RackMultipart20211105-4-tbt2na_html_c572f91cfdd3da55.png)
![Couldn't Load Picture](RackMultipart20211105-4-tbt2na_html_c572f91cfdd3da55.png)
The architecture design in Figure 2 is the design created by the first development team when the application was first implemented. However, as the project developed further, the architecture became more and more unstructured and complex. As a result, MVC is no longer used as intended. This was further complicated using a Microsoft Forms application.
# 5. System Design <a name="SD"/>
![](RackMultipart20211105-4-tbt2na_html_34bab3433846f0d9.png)
![Couldn't Load Picture](RackMultipart20211105-4-tbt2na_html_34bab3433846f0d9.png)
This figure is showing the complete software structure design.
![](RackMultipart20211105-4-tbt2na_html_6cedf9e7fcc19487.png)
![Couldn't Load Picture](RackMultipart20211105-4-tbt2na_html_6cedf9e7fcc19487.png)
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.