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

Merge branch 'master' of https://github.com/H4CK3R-01/TINF20C_ModellingWizard_Devices.wiki

NormalParameter 2022-04-28 14:59:43 +02:00
commit f61f779cd5
3 changed files with 168 additions and 92 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

256
2.-Software-Architecture-Specification.md

@ -1,12 +1,21 @@
#### Table of Contents #### Table of Contents
* [1. Introduction](#I) * [1. Introduction](#I)
* [1.1 Glossar](#G) * [1.1 Glossary](#G)
* [2. System Overview](#S) * [2. System Overview](#S)
* [2.1 System Environment](#S1) * [2.1 System Environment](#S1)
* [2.2 Software Environment](#S2) * [2.2 Software Environment](#S2)
* [2.3 Quality Goals](#S3) * [2.3 Quality Goals](#S3)
* [2.3.1 Usability](#S4) * [2.3.1 Runtime quality attributes](#S4)
* [2.3.2 Bug fixing](#S5) * [2.3.1.1 Usability](#S5)
* [2.3.1.2 Functionality](#S6)
* [2.3.1.3 Performance](#S7)
* [2.3.1.4 Security](#S8)
* [2.3.1.5 Availability](#S9)
* [2.3.1.6 Interoperability](#S10)
* [2.3.2 Non-Runtime quality attributes](#S11)
* [2.3.1.1 Modifiability](#S12)
* [2.3.1.2 Portability and reusability](#S13)
* [2.3.1.3 Testability](#S14)
* [3. Quality Concept](#QC) * [3. Quality Concept](#QC)
* [3.1 Usability concept](#QC1) * [3.1 Usability concept](#QC1)
* [3.2 Code Quality](#QC2) * [3.2 Code Quality](#QC2)
@ -18,29 +27,35 @@
* [6.2 MOD.002: Controller functionalities](#SS2) * [6.2 MOD.002: Controller functionalities](#SS2)
* [7. Technical Concepts](#TC) * [7. Technical Concepts](#TC)
* [7.1 Persistence](#TC1) * [7.1 Persistence](#TC1)
* [7.2 User Interface](#TC2) * [7.2 Communication with other IT-Systems](#TC4)
* [7.3 Ergonomics](#TC3) * [7.3 Deployment](#TC5)
* [7.4 Communication with other IT-Systems](#TC4) * [7.4 Data Validation](#TC6)
* [7.5 Deployment](#TC5) * [7.5 Exception Handling](#TC7)
* [7.6 Data Validation](#TC6) * [7.6 Internationalization](#TC8)
* [7.7 Exception Handling](#TC7)
* [7.8 Internationalization](#TC8)
* [7.9 Testability](#TC9)
* [7.10 Availability](#TC10)
* [8. References](#R) * [8. References](#R)
# Changelog # Changelog
| Version | Date | Author | Comment | | Version | Date | Author | Comment |
| ------------- |-------------|-------------|-------------| | ------------- |-------------|-------------|-------------|
| V0.1 | 26.10.2020 | Lukas Ernst / Florian Kellermann | created | | V0.1 | 04.11.2021 | Lukas Ernst / Florian Kellermann | created |
| V0.2 | 05.11.2021 | Florian Kellermann | edited | | V0.2 | 05.11.2021 | Lukas Ernst | Add introduction and glossary details |
| V0.4 | 07.11.2021 | Lukas Ernst | Add runtime and non-runtime quality goals |
| V0.5 | 10.11.2021 | Lukas Ernst | Update quality concept and technical concept |
| V0.6 | 12.11.2021 | Lukas Ernst | Update usability concept |
| V0.7 | 16.11.2021 | Lukas Ernst | Add architectural concept |
| V0.8 | 26.03.2022 | Lukas Ernst | spicify architectural concept |
| V0.9 | 10.04.2022 | Lukas Ernst | Add system design |
| V1.0 | 13.04.2022 | Lukas Ernst | Update system design |
| V1.1 | 14.04.2022 | Lukas Ernst | Update subsystem specification |
| V1.2 | 20.04.2022 | Lukas Ernst | Correct descriptions and add links |
| V1.3 | 24.04.2022 | Lukas Ernst | Latest changes |
| V1.4 | 06.05.2022 | ? | Checked for correctness |
*** ***
# 1. Introduction <a name="I"/> # 1. Introduction <a name="I"/>
The aim of this project is to program a standalone application for Windows based on a plugin for the AutomationML editor. The graphical user interface should be improved and support the modelling of sensors according to IEC 60947-5 should be offered. Furthermore, it should be possible to create devices, add device interfaces and file attachments. The aim of this project is to program a standalone application for Windows based on a plugin for the AutomationML editor. The graphical user interface should be improved and support the modelling of sensors according to IEC 60947-5 should be offered. Furthermore, it should be possible to create devices, add device interfaces and file attachments. It should also be feasible to create a device manually, but also by reading in existing device description files with the aid of the DD2AML converter. The output should be an AutomationML package that complies with the rules for AML component models (AML-DDs). The programme is aimed at an industrial user group, as it is suitable for creating models, which should help in the design of systems.
## 1.1 Glossary <a name="G"/> ## 1.1 Glossary <a name="G"/>
@ -54,15 +69,17 @@ The aim of this project is to program a standalone application for Windows based
**GUI** Graphical User Interface **GUI** Graphical User Interface
**.NET** The .NET Framework is a software development and runtime environment developed by Microsoft for Microsoft Windows. **.NET** The .NET Framework is a software development and runtime environment developed by Microsoft for Microsoft Windows
**IODD** Means IO Device Description and describes sensors and actuators
**GSD** General Station Description, data format for Profibus and Profinet devices
# 2. System Overview <a name="S"/> # 2. System Overview <a name="S"/>
## 2.1 System Environment <a name="S1"/> ## 2.1 System Environment <a name="S1"/>
The standalone application can only be accessed via Windows, as this operating system is used as the platform. The application can be installed and the graphical user interface can be used via this platform. In contrast to the plug-in, the editor no longer needs to be used. The standalone application can only be accessed via Windows, as this operating system is used as the platform. The application can be installed and the graphical user interface can be used via this platform. In contrast to old programme or the plug-in, the editor and the "IODD" and the "GSD" converter no longer needs to be used.
Among others the IODD and GSD converter are used as neighbouring systems.
## 2.2 Software Environment <a name="S2"/> ## 2.2 Software Environment <a name="S2"/>
@ -72,13 +89,49 @@ For the standalone application to work, you need at least version 4.5 of the .Ne
In order to achieve the quality goals, different criteria are considered. In order to achieve the quality goals, different criteria are considered.
### 2.3.1 Usability <a name="S4"/> ### 2.3.1 Runtime quality attributes<a name="S4"/>
Usability is the most important aspect of the project besides the standalone application. To this end, a graphical user interface was created that allows the user to use it as easily as possible. Intuitive operation is very important, but an appealing design is also necessary to create the best possible user experience. This is the only way the application can successfully simplify work processes. (More information in the usability concept) These can be observed at execution time of the system.
### 2.3.2 Bug fixing <a name="S5"/> #### 2.3.1.1 Usability<a name="S5"/>
Another milestone to keep quality high is the elimination of errors that cause undesired behaviour or even fatal errors. Usability is the most important aspect of the project besides the standalone application. To this end, a graphical user interface was created that allows the user to use it as easily as possible. Intuitive operation is very important, but an appealing design is also necessary to create the best possible user experience. This is the only way the application can successfully simplify work processes (More information in the [Usability Concept](#QC1)).
#### 2.3.1.2 Functionality<a name="S6"/>
As the targets have been set relatively precisely, attention should be paid to their compliance and fulfilment. Furthermore, care should be taken to process the functions according to their importance, which means ensuring the standalone property first, then the usability and then the remaining functions.
#### 2.3.1.3 Performance<a name="S7"/>
The problem with programmes that have been developed many times and then by different teams is that they often have poor code quality and therefore a high RAM and memory load. On technically older systems, this can lead to problems such as crashes or slow feedback. This is also a problem of the plugin, there are single files with several thousand lines of code. So we should at least try not to make this worse. If we have enough time, we should adapt the code in general. You can find more information about this in the section [Code Quality](#QC2).
#### 2.3.1.4 Security<a name="S8"/>
It must be ensured that it is recognisable where and from whom the programme originated. It will not be possible to access the Internet with the programme, so confidentiality is automatic. But it should be downloaded from an official source, the releases can be found [here](https://github.com/H4CK3R-01/TINF20C_ModellingWizard_Devices/releases).
#### 2.3.1.5 Availability<a name="S9"/>
The programme and its code will be available on GitHub on a public repository. This means that anyone can access the programme at any time.
#### 2.3.1.6 Interoperability<a name="S10"/>
This is important because it must be ensured that users are not firmly bound to this standard or programme. After all, the main users will come from the industry and therefore place a lot of value on a uniform standard. More information can be found in the [Technical Concept](#TC).
### 2.3.2 Non-Runtime quality attributes<a name="S11"/>
These cannnot be observed at execution time of the system.
#### 2.3.1.1 Modifiability<a name="S12"/>
Since the programme is open source and publicly viewable, it can be extended by anyone. This is important if any use cases arise in the future.
#### 2.3.1.2 Portability and reusability<a name="S13"/>
Attention is paid to transferability to later projects, through the involvement and formation of libraries and the like, but the application case is very specific and difficult to transfer to other or new projects. Therefore not so important.
#### 2.3.1.3 Testability<a name="S14"/>
This is probably the second most important point after usability, care must be taken to ensure that the code is testable. On the one hand directly in the code, but also testing the binary is important. For this purpose, various test cases are described and worked through on the [Systemtestplan](https://github.com/H4CK3R-01/TINF20C_ModellingWizard_Devices/wiki/4.-Systemtestplan) page. Also check the [Systemtestreport](https://github.com/H4CK3R-01/TINF20C_ModellingWizard_Devices/wiki/5.-Systemtestreport) to learn more about the test results. The AML Component Checker should be validating all created AML files. Thereby, to keep quality high, errors that cause undesirable behavior or even fatal errors must be eliminated.
# 3. Quality Concept <a name="QC"/> # 3. Quality Concept <a name="QC"/>
@ -88,13 +141,13 @@ This part of the software architecture specification explains and breaks down th
The criteria for good usability are: The criteria for good usability are:
**Intuitiveness** : Intuitiveness is a key component of good usability which means that the user understands the application without a long training period. **Intuitiveness** : Intuitiveness is a key component of good usability which means that the user understands the application without a long training period. This point is also interesting for companies, as they then do not have to train their employees for so long. This is to be achieved by having important things at the top and not hidden in a drop-down selection. Furthermore, the design must be adopted from other well-known programmes.
**Design** : When designing the application, an appealing layout is important. It should be clearly recognisable which function is hidden behind which visual elements and how the user can navigate through the app. **Design** : When designing the application, an appealing layout is important. It should be clearly recognisable which function is hidden behind which visual elements and how the user can navigate through the app. It probably makes sense to be inspired by the design of the [AutomationML editor](https://www.automationml.org/wp-content/uploads/2021/04/AMLEditor552-1024x743.png), because then the switch to this programme would not be so difficult.
**Recognition value** : This means that similar functions should be realized with the same sequences. This makes it easier for the user to find his way around the functions and increases user friendliness. **Recognition value** : This means that similar functions should be realized with the same sequences. This makes it easier for the user to find his way around the functions and increases user friendliness. For example, when creating models or a wizard that guides you through the creation.
**Colour scheme** : A good colouration can be created by an attractive choice of colours and their coordinated contrasts. **Colour scheme** : A good colouration can be created by an attractive choice of colours and their coordinated contrasts. At the moment, matte colours are more in vogue and are preferred for designs. Many people find these more pleasant.
Implementation guideline: Implementation guideline:
@ -111,7 +164,7 @@ Based on the criteria just defined and the guidelines developed, the graphic int
Code quality is one of the most important aspects when it comes to software that is being developed further and may come from different developers. For this reason, we have made it our mission to address and improve the problem of code quality. To maintain a certain standard, we have agreed on certain conventions: Code quality is one of the most important aspects when it comes to software that is being developed further and may come from different developers. For this reason, we have made it our mission to address and improve the problem of code quality. To maintain a certain standard, we have agreed on certain conventions:
- Commenting on sections of code that are not clearly understandable in order to explain the implemented idea to others - Commenting on sections of code that are not clearly understandable in order to explain the implemented idea to others
- Programming paradigms and programming principles that make the code easy to understand - Programming paradigms and programming principles that make the code easy to understand, such as one main function per file and a sensible folder structure.
This means that the code is indented uniformly to improve readability and comprehension. Furthermore, the program is divided into modules that can then be imported and used. Otherwise, you run the risk of having to write duplicate code. In addition, it is our responsibility to write documentation that records which ideas have been implemented and how, so that the existing functions are easier to understand for future developments and can be built upon. This means that the code is indented uniformly to improve readability and comprehension. Furthermore, the program is divided into modules that can then be imported and used. Otherwise, you run the risk of having to write duplicate code. In addition, it is our responsibility to write documentation that records which ideas have been implemented and how, so that the existing functions are easier to understand for future developments and can be built upon.
@ -119,42 +172,70 @@ This means that the code is indented uniformly to improve readability and compre
## 4.1 Architectural Model <a name="AC1"/> ## 4.1 Architectural Model <a name="AC1"/>
![Couldn't Load Picture](https://user-images.githubusercontent.com/76038781/140762432-baca1fb5-f66b-41ab-9702-be7fc2cfcc0d.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 application 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).
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). <p align="center">
<img src="https://user-images.githubusercontent.com/76038781/140762432-baca1fb5-f66b-41ab-9702-be7fc2cfcc0d.png" alt="MVC Model" /><br>
<em>Figure 1 - MVC Architecture</em>
</p>
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. 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. The controller is the main control unit from the plug-in. 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. The change is that it will be a standalone application. This is ensured by integrating the AutomationML engine and the plug-in into a new programme via an import. The plugin is then started in its own view, so that the old code of the plugin is retained.
![Couldn't Load Picture](https://user-images.githubusercontent.com/76038781/140762427-8fb4c097-2c53-4c80-a07f-ed3f3d8c90d3.png) <p align="center">
<img src="https://user-images.githubusercontent.com/76038781/140762427-8fb4c097-2c53-4c80-a07f-ed3f3d8c90d3.png" /><br>
<em>Figure 2 - Logic of the plugin</em>
</p>
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. 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 and 5, the architecture became increasingly unstructured and complex.
# 5. System Design <a name="SD"/> # 5. System Design <a name="SD"/>
![Couldn't Load Picture](https://user-images.githubusercontent.com/76038781/140761356-05e600c3-b11f-46a8-9bb2-355cdc1e82db.PNG) 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).
This figure is showing the complete software structure design. <p align="center">
<img src="https://user-images.githubusercontent.com/75857685/164975110-f0a6ca9e-4d92-42bc-97f1-6a1642ad37bf.png" alt="System"/><br>
<em>Figure 3 - Programme Concept</em>
</p>
![Couldn't Load Picture](https://user-images.githubusercontent.com/76038781/140761360-67adafbe-f4c9-4279-a80e-d0430b1b5cc9.png) 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.
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. <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/164977846-df95b1ef-a8c2-4a91-b0a5-75ebd9c9b8d9.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 6 - MVC pattern</em>
</p>
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** | | **Classname** | **Storage location** |
| --- | --- | | --- | --- |
| About | SOURCE/About.xaml.xs | | About | [SOURCE/Plugin/About.xaml.cs](https://github.com/H4CK3R-01/TINF20C_ModellingWizard_Devices/blob/app-source-code/SOURCE/Plugin/About.xaml.cs) |
| AnimationClass | SOURCE/Animationclass.cs | | AnimationClass | [SOURCE/Plugin/Animationclass.cs](https://github.com/H4CK3R-01/TINF20C_ModellingWizard_Devices/blob/app-source-code/SOURCE/Plugin/AnimationClass.cs) |
| AutomationMLDataTables | SOURCE/AutomationMLDataTables.cs | | AutomationMLDataTables | [SOURCE/Plugin/AutomationMLDataTables.cs](https://github.com/H4CK3R-01/TINF20C_ModellingWizard_Devices/blob/app-source-code/SOURCE/Plugin/AutomationMLDataTables.cs) |
| ClassOfListFromReferenceFile | SOURCE/ClassOfListsFromReferencefile.cs | | ClassOfListFromReferenceFile | [SOURCE/Plugin/ClassOfListsFromReferencefile.cs](https://github.com/H4CK3R-01/TINF20C_ModellingWizard_Devices/blob/app-source-code/SOURCE/Plugin/ClassOfListsFromReferencefile.cs) |
| DeviceDescription | GUI: SOURCE/DeviceDescription.Designer.csLogic: SOURCE/DeviceDescription.cs | | DeviceDescription | GUI: [SOURCE/Plugin/DeviceDescription.Designer.cs](https://github.com/H4CK3R-01/TINF20C_ModellingWizard_Devices/blob/app-source-code/SOURCE/Plugin/DeviceDescription.Designer.cs) <br> Logic: [SOURCE/Plugin/DeviceDescription.cs](https://github.com/H4CK3R-01/TINF20C_ModellingWizard_Devices/blob/app-source-code/SOURCE/Plugin/DeviceDescription.cs) |
| ModellingWizard | SOURCE/ModellingWizard.xaml.cs | | ModellingWizard | [SOURCE/Plugin/ModellingWizard.xaml.cs](https://github.com/H4CK3R-01/TINF20C_ModellingWizard_Devices/blob/app-source-code/SOURCE/Plugin/ModellingWizard.xaml.cs) |
| MWController | SOURCE/MWController.cs | | MWController | [SOURCE/Plugin/MWController.cs](https://github.com/H4CK3R-01/TINF20C_ModellingWizard_Devices/blob/app-source-code/SOURCE/Plugin/MWController.cs) |
| MWData | SOURCE/MWData.cs | | MWData | [SOURCE/Plugin/MWData.cs](https://github.com/H4CK3R-01/TINF20C_ModellingWizard_Devices/blob/app-source-code/SOURCE/Plugin/MWData.cs) |
| MWDevice | SOURCE/MWDevice.cs | | MWDevice | [SOURCE/Plugin/MWDevice.cs](https://github.com/H4CK3R-01/TINF20C_ModellingWizard_Devices/blob/app-source-code/SOURCE/Plugin/MWDevice.cs) |
| Resources | SOURCE/Resources/ | | Resources | [SOURCE/Plugin/Resources/](https://github.com/H4CK3R-01/TINF20C_ModellingWizard_Devices/tree/app-source-code/SOURCE/Plugin/Resources) |
| SearchAMLComponentFile | SOURCE/SearchAMLComponentFile.cs | | SearchAMLComponentFile | [SOURCE/Plugin/SearchAMLComponentFile.cs](https://github.com/H4CK3R-01/TINF20C_ModellingWizard_Devices/blob/app-source-code/SOURCE/Plugin/SearchAMLComponentFile.cs) |
| SearchAMLLibraryFile | SOURCE/SearchAMLLibraryFile.cs | | SearchAMLLibraryFile | [SOURCE/Plugin/SearchAMLLibraryFile.cs](https://github.com/H4CK3R-01/TINF20C_ModellingWizard_Devices/blob/app-source-code/SOURCE/Plugin/SearchAMLLibraryFile.cs) |
# 6. Subsystem specification <a name="SS"/> # 6. Subsystem specification <a name="SS"/>
@ -162,70 +243,65 @@ Still the MVC pattern is a small part of the whole system design. In this case t
| **<MOD.001>** | **Graphical User Interface** | | **<MOD.001>** | **Graphical User Interface** |
| --- | --- | | --- | --- |
| System requirements covered: | /NF10/, /NF20/, /NF30/, /NF40/, /NF50/, /NF60/, /NF70/, /NF80/, /NF90/, /NF100/, /F10/, /F20/, /F60/, /F70/| | **System&nbsp;requirements&nbsp;covered:** | /NF10/, /NF20/, /NF30/, /NF40/, /NF50/, /NF60/, /NF70/, /NF80/, /NF90/, /NF100/, /F10/, /F20/, /F60/, /F70/ nicht fertig |
| Services: | The graphical user interface is taking input from the user and sending it to the controller by calling event functions. | | **Services:** | The graphical user interface is taking input from the user and sending it to the controller by calling event functions. |
| Interfaces: | --- | | **Interfaces:** | --- |
| External Data: | --- | | **External Data:** | --- |
| Storage Location: | SOURCE/DeviceDescription.Designer.cs | | **Storage Location:** | [SOURCE/Plugin/DeviceDescription.Designer.cs](https://github.com/H4CK3R-01/TINF20C_ModellingWizard_Devices/blob/app-source-code/SOURCE/Plugin/DeviceDescription.Designer.cs) |
| Modul documentation: | MOD.001: Graphical User Interface (GUI) | | **Modul documentation:** | [MOD.001: Graphical User Interface (GUI)](https://github.com/H4CK3R-01/TINF20C_ModellingWizard_Devices/wiki/MOD.001:-Graphical-User-Interface-(GUI)) |
## 6.2 MOD.002 Controller <a name="SS2"/> ## 6.2 MOD.002 Controller <a name="SS2"/>
| **<MOD.002>** | **Controller** | | **<MOD.002>** | **Controller** |
| --- | --- | | --- | --- |
| System requirements covered: | /NF100/, /F30/, /F40/, /F50/, /F80/ | | **System&nbsp;requirements&nbsp;covered:** | /NF100/, /F30/, /F40/, /F50/, /F80/ nicht fertig |
| Services: | Logic distribution is handled by the controller. It is reacting to the events triggered by the GUI and takes care of creating the respective objects. Also the input and output functions are implemented in the controller. | | **Services:** | Logic distribution is handled by the controller. It is reacting to the events triggered by the GUI and takes care of creating the respective objects. Also the input and output functions are implemented in the controller. |
| Interfaces: | Interface for IODD to AutomationML, Interface for GSD to AutomationML and Interface of AMLX packages. For export/import of amlx files there is another class referenced: SOURCE/MWData.cs | | **Interfaces:** | Interface for IODD to AutomationML, Interface for GSD to AutomationML and Interface of AMLX packages. For export/import of amlx files there is another class referenced: [SOURCE/Plugin/MWData.cs](https://github.com/H4CK3R-01/TINF20C_ModellingWizard_Devices/blob/app-source-code/SOURCE/Plugin/MWData.cs) |
| External Data: | --- | | **External Data:** | --- |
| Storage location: | SOURCE/DeviceDescription.cs | | **Storage location:** | [SOURCE/Plugin/DeviceDescription.cs](https://github.com/H4CK3R-01/TINF20C_ModellingWizard_Devices/blob/app-source-code/SOURCE/Plugin/DeviceDescription.cs) |
| Modul documentation: | MOD.002: Controller | | **Modul documentation:** | [MOD.002: Controller](https://github.com/H4CK3R-01/TINF20C_ModellingWizard_Devices/wiki/MOD.002:-Controller) |
# 7. Technical Concepts <a name="TC"/> # 7. Technical Concepts <a name="TC"/>
## 7.1 Persistence <a name="TC1"/> ## 7.1 Persistence <a name="TC1"/>
By using a package format, the system is persistent. In the plugin and later also in the stand-alone application AMLX packages can be edited and created. Since AutomationML is using the same format, it is possible to open these AMLX packages and use them in the editor. This functionality shall be kept when moving to a stand-alone application. By using the publicly available "AMLX" package standard, the system becomes persistent. This means that created or edited models can be reopened and edited in the AutomationML Editor. This function is particularly important in an international and industrial environment. Therefore, "IODD" and "GSD" files can also be converted.
## 7.2 User Interface <a name="TC2"/> ## 7.2 Communication with other IT-Systems <a name="TC4"/>
This is the section with the biggest changes in the project. The Graphical User Interface (or so-called GUI) is the connector between user and software. Like that the user can operate the AutomationML editor using the plugin and later the stand-alone application. It is crucial that the GUI is as simple as possible so that even a person with limited professional knowledge can handle the program and understand most of its functionality. The plug-in already had the problem that it was dependent on external programmes. Thus, "IODD" and "GSD" programme types had to be converted in order to be able to use them. The goal will now be to implement these programmes or converters directly in the standalone application. The advantage of this is that the user does not have to install external dependencies that may also cause errors. This means that, in the best case, there would only be interaction with the file system. This model can also be seen in the [Architectural Model](#AC1).
## 7.3 Ergonomics <a name="TC3"/> ## 7.3 Deployment <a name="TC5"/>
As said in 7.2, it is crucial for an ergonomic user interface to be intuitive, meaning that even a not so experienced user is able to understand and control most of the functionality of the program quiet easily. To allow this there are a few simple rules existent that are making sure the user finds the interface appealing and can navigate through it with ease. To make changes to the application, [Visual Studio 2019](https://my.visualstudio.com/Downloads?q=visual%20studio%202019&wt.mc_id=o~msft~vscom~older-downloads) must first be installed. In "Visual Studio 2019", the file "Application.sln" from the "Application" folder must then be opened.
## 7.4 Communication with other IT-Systems <a name="TC4"/> The application and the plug-in (ModellingWizard) are then visible in the Solution view.
Some of the AutomationML editor plugin use cases require external converter systems to be integrated. Two of these for example being the IODD and the GSD converter for AutomationML. These plugins enable for users to convert IODD and GSD files into AML type files for using the functionalities of the plugin. This must also be considered when changing to a standalone program. In order to be able to compile the application, the "AML.Engine" package in version 1.5.8 may have to be installed via the "NuGet" package manager.
## 7.5 Deployment <a name="TC5"/> [How NuGet works](https://docs.microsoft.com/de-de/nuget/quickstart/install-and-use-a-package-in-visual-studio)
At this point it is a plugin that must be used in combination with AutomationML. The plugin must be installed in the editor by using the plugin manager of the software to install the .dll file. During the process of the project the program shall be made usable as a standalone software application so there is no longer the need to use the AutomationML plugin manager. ## 7.4 Data validation <a name="TC6"/>
## 7.6 Data validation <a name="TC6"/>
All data checks are running in the background, invisible for the user. The controller is checking for missing information and incorrect entries, that must be specified as mandatory information. All data checks are running in the background, invisible for the user. The controller is checking for missing information and incorrect entries, that must be specified as mandatory information.
## 7.7 Exception handling <a name="TC7"/> ## 7.5 Exception handling <a name="TC7"/>
Exception handling is necessary to prevent errors caused by the user while using the program. So called &quot;try-catch&quot; blocks are used to &#39;catch&#39; these and prevent unwanted or incorrect behavior of the software. Exception handling is necessary to prevent errors caused by the user while using the program. So called &quot;try-catch&quot; blocks are used to &#39;catch&#39; these and prevent unwanted or incorrect behavior of the software. This way, the user is informed about what did not work and he/she may be able to fix the problem or at least report it to the developers
## 7.8 Internationalization <a name="TC8"/> ## 7.6 Internationalization <a name="TC8"/>
The whole system layout can be used for international purposes since the user manual and over all GUI is written in English and English is defined to be the international traffic language. On the other hand, there is no way to change the language so English is a mandatory knowledge for using the program. The whole system layout can be used for international purposes since the user manual and over all GUI is written in English and English is defined to be the international traffic language. On the other hand, there is no way to change the language so English is a mandatory knowledge for using the program.
## 7.9 Testability <a name="TC9"/>
View the System Test Plan to get further information on how the program can be tested. Also check the System Test Reports to learn more about the test results. The AML Component Checker should be validating all created AML files.
## 7.10 Availability <a name="TC10"/>
The program is only available on Github and furthermore Github is the only possible source.
##
##
# 8. References <a name="R"/> # 8. References <a name="R"/>
| Reference | Source |
| **Reference** | **Source** |
| ------------- |-------------|
| [1] | https://faq.arc42.org/questions/C-1-2/, 20.04.2022 |
| [2] | https://github.com/DekaAthlos/TINF19C-ModellingWizard/wiki/2.-Software-Architecture-Specification, 21.04.2022 |
| [3] | https://www.perforce.com/blog/alm/how-write-software-requirements-specification-srs-document, 21.04.2022 |
| [4] | https://books.google.de/books?id=7pVbAgAAQBAJ&lpg=PA1&ots=3l-6o0BDrw&dq=clean%20code%20robert%20martin&lr&hl=de&pg=PA1#v=onepage&q&f=false, 22.04.2022 |
| [5] | https://blog.iandavis.com/2008/12/what-are-the-benefits-of-mvc/, 22.04.2022 |
| [6] | https://www.youtube.com/watch?v=o_TH-Y78tt4&t=1667s, 22.04.2022 |
| [7] | https://www.jetbrains.com/help/resharper/Reference__Architecture_View.html, 23.04.2022 |

2
4.-Systemtestplan.md

@ -1 +1 @@
[Link to STP ](https://github.com/H4CK3R-01/TINF20C_ModellingWizard_Devices/blob/47d2ba67fc73ebc080f303f0e29ca2260d8c7d88/PROJECT/STP/TINF20C_STP_Team_1.pdf)

2
5.-Systemtestreport.md

@ -1 +1 @@
[Link to STR](https://github.com/H4CK3R-01/TINF20C_ModellingWizard_Devices/blob/47d2ba67fc73ebc080f303f0e29ca2260d8c7d88/PROJECT/STR/TINF20C_STR_Team_1.pdf)