Table of Contents
- 1. Scope
- 2. Abbreviations
- 3. Module Requirements
- 4. Analysis
- 5. Design
- 6. Implementation
- 7. Module Tests
- 8. Summary
- 9. Appendix
Changelog
| Version | Date | Author | Comment |
|---|---|---|---|
| V0.1 | 21.10.2020 | Phillip Tran | created |
| V1.0 | 03.05.2021 | Phillip Tran | Fill document |
| V1.1 | 14.05.2021 | Phillip Tran | Added Issue-Links |
| V2.0 | 14.05.2021 | Phillip Tran | Completed Documentation |
1. Scope
This module documentation explains the GUI in more detail. It shows how the plugin is graphically structured and which features are implemented. The individual functions [1] are tested in advance and their results are documented here. If there are existing problems, they are also listed here and possible solutions are explained in more detail.
It can also serve as a programming guide, if further features should be implemented.
2. Abbreviations
- GUI - Graphical User Interface
- SRS - System Requirement Specification
- STP - System Test Plan
- STR - System Test Report
- AMLX - AML Package
- CAEX - Computer Aided Engineering Exchange
3. Module Requirements
3.1 User View
This Module should provide the user the following features (only features that have been edited or implemented):
- A separate window for the plugin
- A better graphical experience to the previous project [2]
- Using the entire space of the window
- Non-resizable rows (cause it is redundant)
- In general the design of all elements e.g. colors, shape, size...
- Link to the Manual
- Load Attributes of the Generic Data on startup
- Load new Standard-Libraries e.g. Electrical Connector Library
Optional:
- Auto-Update vendor and device name in Generic Data
- Additional visual changes
3.2 Requirements
The following requirements are implemented by this module: /NF10/, /NF20/, /NF30/, /NF40/, /NF50/, /NF60/, /NF70/, /NF80/, /NF90/, /NF100/ /F10/, /F20/, /F60/, /F70/, /BUG10/, /BUG20/, /BUG30/, /BUG40/, /BUG50/, /BUG90/, /BUG100/.
/NF10/, /NF30/, /NF40/, /NF50/, /NF60/, /NF70/, /NF80/, /NF90/, /F10/: These requirements are primarily just visual changes that should improve the usability of the GUI and give the user a better experience with the plugin. The main focus here is to make sure that all the space is used, the colors are rearranged and that the buttons can be used more intuitively. All the graphical changes have been implemented in the meantime. Other improvements (Enhancements) have also been incorporated into the program to further increase usability.
/NF20/, /BUG40/: This requirement is about loading the Generic Data of a new or opened file on startup. This is important to clarify that certain parameters in the Generic Data attributes are mandatory (marked in red). If these attributes are not filled in, an error message appears, but the user does not know which attributes are missing in which class this error message belongs to. This function has been fulfilled. It displays attributes of the Generic Data to the user when a new file or an open file is selected. There was a bug which was fixed by the requirement /NF20/. If the attributes of the Generic Data class were not loaded, an empty file was exported when saving.
/NF100/: This requirement is made for future developers on this project. Since the previous project [2] was unfortunately not well maintained, variable names were not meaningful and there are a lot of dead code blocks, it is very difficult to get familiar with the project and develop the program further. This requirement deals with this problem. In the meantime many names have been replaced by meaningful names and many dead code blocks have been removed.
/F20/: The last column of each table has a Checkbox called "Add to AML-File". This should be removed and every Class / Interface added should be automatically added to the File, without checking the Checkbox. This requirement has been realized. There is no need to check the "Add to AML-File"-Checkbox anymore. It will always add the Interface or Role Class to the AMLX File.
/F60/, /F70/: This requirement is about deleting rows of the tables for classes. The deletion has already been implemented, but it did not work properly. Only the content was deleted from the rows, the row itself was accordingly empty, but still existed. The deletion is now fully functional, and it can no longer happen that empty rows exist, since the user can only create new rows by dragging in classes or interfaces.
/BUG10/, /BUG20/, /BUG30/: This bug has a high priority because it restricts the usability of the plugin. There is an error message caught by the program, if you enter a new role name under Generic Data / Interfaces / Documents, then click on another field and then click again on one of the fields marked blue in Figure 1, you get an error. There is also an error that occurs when clicking on the triangle. So this is not an error message that was intended by the developer(s). This issue has been fixed by catching this error and handle the exception.
Figure 1 /BUG10/, /BUG20/ & /BUG30/
/BUG50/: This bug is triggered when opening a new file. The "Vendor Name" label as shown in Figure 2 is changed to the path of the opened file, which should not happen. This bug has been fixed in the meantime.
Figure 2 /BUG50/
/BUG90/: It turns out that there is a bug when saving the file. The explorer does not open consistently. So there were cases where the explorer did not open. This bug has been fixed. There are now two options for saving the file. "Save" opens an explorer where the location can be chosen. "Save & Close" also opens an explorer, but when saving, the plugin's interface data is reset. This allows the user to create more files now, without trying to figure out how to create a new empty file.
/BUG100/: There is another bug when you click on "Load Library", an explorer is opened and all standard libraries are cleared on the right side of the display. But this should not happen if the user closes the explorer without having selected new libraries, so when he cancels the process. This bug has also been fixed.
3.3 Module Context
This module provides a graphical interface to the Plugin. By adding interfaces, filling and editing the attributes and attaching images and icons, the graphical interface should give the user a simplified way to create an AMLX file. It is attempted to make the interface as practical as possible. To make this possible, for example, the standard class with the basic information is automatically loaded and the mandatory attributes are highlighted in color. If all information is correct, it will be passed to the controller [5], which will process the entered information.
4. Analysis
The graphical user interface must provide the user with a simple, intuitive way to create an AMLX file, as already explained in Chapter 3. This requires the ability for the user to interactively enter information and be supported by the graphical user interface. This support could be, for example, the possibility to drag libraries into the desired field or also to specify which attributes must be filled in. It must be checked whether the user has entered all the required data. If this is not the case, an appropriate and specific error message must be returned to the user, so that he knows what he must do to improve this error. If other problems occur because the user does something unexpected or something that is requested by the program, but corrupts the export of the file, a specific error message must also be returned to the user.
5. Design
The graphical user interface from the previous project was divided into three tabs. (Figure 3, 4, 5)
Figure 4 Interfaces Tab
Figure 5 Attachments Tab
The Generic Data Tab contains the Role Classes, which are important to store general information. The most important data is also stored there, such as the name of the device and the manufacturer name. In the Interfaces Tab interfaces are added, this could be for example an electrical interface that defines the pins of a USB socket in more detail. In the last tab it is possible to add further attachments to the file. For example a ComponentIcon or a ManufacturerIcon can be attached. This was the current state of the previous version. Our task is to completely renew the design, because the interface was only partially usable. There were a lot of errors when interacting with the objects, objects that covered other objects and the design didn't look so good. There is no exact design concept that was used in the implementation of this module. However, we made sure that the look and colors of each tab were consistent.
5.1 Risks
The graphical user interface was created using the .NET for Windows framework, more specifically the GUI toolkit called Windows Forms, which is tested and maintained by Microsoft. The risk is that the development depends on the utilizability of the toolkit. If Microsoft no longer supports the maintenance of Windows Forms there could be complications displaying the Plugin. As a result, it cannot be excluded that the display will work with 100% accuracy.
Another risk related to the fact that the program was programmed as a plugin is that it can only be used with the "AutomationML" application. If the plugin is no longer compatible with the AutomationML application, for various reasons, the plugin is unusable. This could happen, when there is a new version of AutomationML with new Standards for plugins.
A small, but still noteworthy risk are shapes that are not available, which thereby cannot be implemented. For example, buttons are linked to certain design-patterns. So it is not possible to customize the button as the developer wants. However, this is only a small risk, since WindowsForms offers quite a lot of design freedom.
6. Implementation
The graphical user interface is implemented with the GUI toolkit WindowsForm as already mentioned in chapter 5.1. This toolkit allows changes to be made directly in a graphical interface in visual studio. As you can see in Figure 3, you can simply change the properties of an object. It is also possible to bind functions to specific events for example, when the user clicks on a specific object. This way the functions are bound from the Controller-Module [5] to the GUI. Creating objects and modifying their properties creates automatically generated code, which is stored in the DeviceDescription.Designer.cs file. This also makes it possible to modify the code the way the developer prefers it. This means that the developer is not bound to the graphical interface, but can also modify the code manually. All the requirements related to this module have been implemented with WindowsForms.
Figure 6 WindowsForms Properties Menu
7. Module Tests
In this section nearly all requirements will be tested separately on their functionality. Some requirements are not tested, because they have no function to test on.
Further and more detailed Tests can be found here: [3] and [4]
7.1 Module Testplan
| Test-ID | Requirement-ID | Test Specification (Description) |
|---|---|---|
| 1 | NF10 | This test verifies that the GUI uses the entire space |
| 2 | NF20, BUG40 | This test verifies that the Generic Data Attributes are loaded on startup and that it doesn't safe an empty file, when the attributes haven't been loaded |
| 3 | NF30 | This test verifies that the application toolbar is directly visible in the interface |
| 4 | NF40 | This test verifies that the plugin opens in a proper size (not minimized) |
| 5 | NF60 | This test verifies that the attributes-tables aren't resizable |
| 6 | NF70 | This test verifies that the unnecessary grey field in the header tab has been removed |
| 7 | F10 | This test verifies that the link under help / manual forwards to the right manual |
| 8 | F20 | This test verifies that the "Add to AML-File" Column is removed and the functionality is still given |
| 9 | F60 | This test verifies that there are no empty rows (except the first one) possible in the class tables |
| 10 | F70 | This test verifies that the "delete"-button works properly |
| 11 | BUG10, BUG20, BUG30 | This test verifies that all errors coming from BUG10, BUG20 or BUG30 are handled by the program |
| 12 | BUG50 | This test verifies that the "Vendor Name"-label is not replace with the pathname of an opened file |
| 13 | BUG90 | This test verifies that the explorer opens constantly when the user tries to save a file |
| 14 | BUG100 | This test verifies that the libraries aren't deleted when the user cancels the process of loading new libraries |
7.2 Module Testreport
| Test-ID | PASS / FAIL | When failed: Observation | Tester |
|---|---|---|---|
| 1 | PASS | - | S. Jess |
| 2 | PASS | - | P. Tran |
| 3 | PASS | - | S. Jess |
| 4 | PASS | - | S. Jess |
| 5 | PASS | - | S. Jess |
| 6 | PASS | - | S. Jess |
| 7 | PASS | - | S. Jess |
| 8 | PASS | - | P. Tran |
| 9 | PASS | - | S. Jess |
| 10 | PASS | - | P. Tran |
| 11 | PASS | - | S. Jess / P. Tran |
| 12 | PASS | - | P. Tran |
| 13 | PASS | - | P. Tran |
| 14 | PASS | - | P. Tran |
8. Summary
This module was successfully implemented with all requirements. The GUI now has a new design that is more intuitive, user-friendly and cleaner. By testing the GUI, some bugs have appeared, which have been additionally fixed to make the user experience even better. Each error is handled by notifying the user with a specific message to clarify what problem has occured.
9. Appendix
9.1 References
[1] System Requirements Specification: https://github.com/DekaAthlos/TINF19C-ModellingWizard/wiki/1.-Software-Requirements--Specification
[2] Previous Project: https://github.com/Rajkumarpulaparthi/ModellingWizard
[3] System Test Plan: https://github.com/DekaAthlos/TINF19C-ModellingWizard/wiki/4.-Systemtestplan
[4] System Test Report: https://github.com/DekaAthlos/TINF19C-ModellingWizard/wiki/5.-Systemtestreport
[5] MOD.002: Controller: https://github.com/DekaAthlos/TINF19C-ModellingWizard/wiki/MOD.002:-Controller
9.2 Code
The source code to this module can be found here: DeviceDescription.Designer.cs
Author: Phillip Tran
