Added entries from TINF19C group
malte.horst
parent
7a4d6dfc0c
commit
f1ad5748ae
501
1.-Software-Requirements--Specification.md
Normal file
501
1.-Software-Requirements--Specification.md
Normal file
@ -0,0 +1,501 @@
|
||||
#### Table of Contents
|
||||
* [1. Goal](#Goal)
|
||||
* [2. Use Cases](#UC)
|
||||
* [2.1 <UC.001> “Create new device”](#UC1)
|
||||
* [2.2 <UC.002> “Create interface or load interface from Library”](#UC3)
|
||||
* [2.3 <UC.003> “View device data and device interface data”](#UC4)
|
||||
* [2.4 <UC.004> “Reloading and editing an AML device description”](#UC5)
|
||||
* [2.5 <UC.005> “Add Attachments for the Device”](#UC6)
|
||||
* [2.6 <UC.006> “Format output as CAEX version 3.0”](#UC7)
|
||||
* [3. Non-functional Requirements](#NF)
|
||||
* [3.1 /NF10/Overview](#NF1)
|
||||
* [3.2 /NF20/Load Attributes](#NF2)
|
||||
* [3.3 /NF30/Application Load Toolbar](#NF3)
|
||||
* [3.4 /NF40/Application Load Window Sizing](#NF4)
|
||||
* [3.5 /NF50/Rename Documents](#NF5)
|
||||
* [3.6 /NF60/Resizable Rows](#NF6)
|
||||
* [3.7 /NF70/Header Overview](#NF7)
|
||||
* [3.8 /NF80/Design of the Button’s](#NF8)
|
||||
* [3.9 /NF90/Design of the Tab’s](#NF9)
|
||||
* [3.10 /NF100/Code Quality](#NF10)
|
||||
* [4. Functional Requirements](#F)
|
||||
* [4.1 /F10/Link to Manual](#F1)
|
||||
* [4.2 /F20/Add Button at Interfaces](#F2)
|
||||
* [4.3 /F30/Mechanical and Hydraulic Interfaces](#F3)
|
||||
* [4.4 /F40/CAEX 3.0 Output](#F5)
|
||||
* [4.5 /F50/Parameter Requirements](#F6)
|
||||
* [4.6 /F60/Delete Empty Fields](#F7)
|
||||
* [4.7 /F70/Delete Button](#F8)
|
||||
* [4.8 /F80/Testability of AML device](#F9)
|
||||
* [5. Bug Fixes](#B)
|
||||
* [6. Enhancements](#Enhancements)
|
||||
* [7. References](#Ref)
|
||||
|
||||
# Changelog
|
||||
|
||||
| Version | Date | Author | Comment |
|
||||
| ------------- |-------------|-------------|-------------|
|
||||
| V0.1 | 29.10.2021 | Malte Horst | created|
|
||||
|
||||
***
|
||||
|
||||
# 1. Goal <a name="Goal"/>
|
||||
The Goal of this project is to create a standalone application from the existing plugin for the AutomationML Editor [[1](#1)]. The software is to be tested for quality defects applying the typical use cases, paying attention to the usability and the "look & feel" of the user interface. The new application should have a simplified but still practical interface. The old interface of the plugins needs to be reviewed and improved upon in the ongoing development.
|
||||
Another point is the support of additional model interfaces and the possibility to use AML interface libraries.
|
||||
For the file extraction it should be possible to choose between the versions 2.15 and 3.0 of the CAEX output format.
|
||||
|
||||
# 2. Use Cases <a name="UC"/>
|
||||
|
||||
|
||||
_Figure 1 UC Diagram_
|
||||
|
||||
## 2.1. <UC.001> “Create new device” <a name="UC1"/>
|
||||
|
||||
|Use Case’s Objective:|Creating a device by inserting the data manually into the user interface|
|
||||
|System Boundary:|Modelling Wizard for Devices|
|
||||
|Precondition:|The user needs to have the minimal required data for the device|
|
||||
|Postcondition on success:|The relevant data is displayed completely and correctly|
|
||||
|Involved Users:|Every user of the application|
|
||||
|Triggering Event:|When the user has the need to add a device|
|
||||
|
||||
## 2.2. <UC.002> “Create interface or load interface from Library” <a name="UC3"/>
|
||||
|
||||
|Use Case’s Objective:|Creating a device interface by inserting the data manually into the user interface. Or to add an interface from one of the existing libraries|
|
||||
|System Boundary:|Modelling Wizard for Devices|
|
||||
|Precondition:|The user needs to have the specific data for the device|
|
||||
|Postcondition on success:|The user has submitted the specific data completely and correctly|
|
||||
|Involved Users:|Each user of the AutomationML-Editor-Application with the Modelling Wizard for Devices Plugin|
|
||||
|Triggering Event:|When the user has the need to add a device interface|
|
||||
|
||||
## 2.3. <UC.003> “View device data and device interface data” <a name="UC4"/>
|
||||
|
||||
|Use Case’s Objective:|After at least one device was successfully added, the device data should be visible and editable on the user interface|
|
||||
|System Boundary:|Modelling Wizard for Devices Plugin|
|
||||
|Precondition:|The user added a device|
|
||||
|Postcondition on success:|The user added at least one device successfully|
|
||||
|Involved Users:|Each user of the AutomationML-Editor-Application with the Modelling Wizard for Devices Plugin|
|
||||
|Triggering Event:|When the user has the need to view device data and device interface data|
|
||||
|
||||
## 2.4. <UC.004> “Reloading and editing an AML device description” <a name="UC5"/>
|
||||
|
||||
|Use Case’s Objective:|Reloading a device to display and edit the device data on the user interface|
|
||||
|System Boundary:|Modelling Wizard for Devices Plugin|
|
||||
|Precondition:|There is an AMLX-package to reload|
|
||||
|Postcondition on success:|The AMLX-package is correct and complete and not damaged in any way|
|
||||
|Involved Users:|Each user of the AutomationML-Editor-Application with the Modelling Wizard for Devices Plugin|
|
||||
|Triggering Event:|When the user has the need to edit an AML device description|
|
||||
|
||||
## 2.5. <UC.005> “Add Attachments for the Device” <a name="UC6"/>
|
||||
|
||||
|
||||
|Use Case’s Objective:|It is possible to add an Attachment to the object, such as a Manufacture Icon|
|
||||
|System Boundary:|Modelling Wizard for Devices Plugin|
|
||||
|Precondition:|The user has loaded or added a device|
|
||||
|Postcondition on success:|The user has loaded or added at least one device successfully|
|
||||
|Involved Users:|Each user of the AutomationML-Editor-Application with the Modelling Wizard for Devices Plugin|
|
||||
|Triggering Event:|When the user has the need to add an Attach-ment on the Device|
|
||||
|
||||
## 2.6. <UC.006> “Format output as CAEX version 3.0” <a name="UC7"/>
|
||||
|
||||
|Use Case’s Objective:|It is possible to output the file in CAEX 3.0|
|
||||
|System Boundary:|Modelling Wizard for Devices Plugin|
|
||||
|Precondition:|The user has loaded or added a device|
|
||||
|Postcondition on success:|The user has loaded or added at least one device successfully|
|
||||
|Involved Users:|Each user of the AutomationML-Editor-Application with the Modelling Wizard for Devices Plugin|
|
||||
|Triggering Event:|When the user has the need to output the file in a newer or older version of CAEX|
|
||||
|
||||
# 3. Non-functional Requirements <a name="NF"/>
|
||||
In this chapter, the non-functional requirements are described and illustrated with figures.
|
||||
|
||||
## 3.1. /NF10/ Overview <a name="NF1"/>
|
||||
The entire space should be used to display the work area more clearly.
|
||||
As shown in Figure 2, the area highlighted with a red cross should also be used.
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Old Version</td>
|
||||
<td>
|
||||
<img src="https://user-images.githubusercontent.com/72601495/97447737-26805000-1930-11eb-8432-53e111255cac.png"/>
|
||||
|
||||
_Figure 2 NF10_1_ </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>New Version</td>
|
||||
<td><img src="https://user-images.githubusercontent.com/72601495/117690300-fc4efb00-b1ba-11eb-9397-56b48221e2c7.png"/>
|
||||
|
||||
_Figure 3 NF10_2_ </td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## 3.2. /NF20/ Load Attributes <a name="NF2"/>
|
||||
When a file is loaded the attributes of the element should be displayed directly.
|
||||
As you can see in Figure 4, the attributes are not displayed directly and you would have to press 2 clicks to display them.
|
||||
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Old Version</td>
|
||||
<td>
|
||||
<img src="https://user-images.githubusercontent.com/72601495/97448183-a9090f80-1930-11eb-8324-a3ad96ee80aa.png"/>
|
||||
|
||||
_Figure 4 NF20_1_ </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>New Version</td>
|
||||
<td><img src="https://user-images.githubusercontent.com/72601495/117690023-aa0dda00-b1ba-11eb-85be-7696fd4dcf6a.png"/>
|
||||
|
||||
_Figure 5 NF20_2_ </td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
## 3.3. /NF30/ Application Load Toolbar <a name="NF3"/>
|
||||
When you open the application for the first time, the right toolbar should not be on the right side as shown in Figure 4. It should be directly visible in the interface.
|
||||
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Old Version</td>
|
||||
<td>
|
||||
<img src="https://user-images.githubusercontent.com/72601495/97448497-000ee480-1931-11eb-9a9b-ca0a2596a89c.png"/>
|
||||
|
||||
_Figure 6 NF30_1_ </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>New Version</td>
|
||||
<td><img src="https://user-images.githubusercontent.com/72601495/117690300-fc4efb00-b1ba-11eb-9397-56b48221e2c7.png"/>
|
||||
|
||||
_Figure 7 NF30_2_ </td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## 3.4. /NF40/Application Load Window Sizing <a name="NF4"/>
|
||||
When you start the application for the first time, it will be displayed very small, see Figure 8, but it should be displayed in full screen mode.
|
||||
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Old Version</td>
|
||||
<td>
|
||||
<img src="https://user-images.githubusercontent.com/72601495/97448911-6e53a700-1931-11eb-86e4-b5e664c82480.png"/>
|
||||
|
||||
_Figure 8 NF40_1_ </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>New Version</td>
|
||||
<td><img src="https://user-images.githubusercontent.com/72601495/117690300-fc4efb00-b1ba-11eb-9397-56b48221e2c7.png"/>
|
||||
|
||||
_Figure 9 NF40_2_ </td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## 3.5. /NF50/Rename Documents <a name="NF5"/>
|
||||
The tab Documents from Figure 10 should be renamed to Attachments for better understanding.
|
||||
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Old Version</td>
|
||||
<td>
|
||||
<img src="https://user-images.githubusercontent.com/72601495/97450103-a4ddf180-1932-11eb-9121-b59f4bf12890.png"/>
|
||||
|
||||
_Figure 10 NF50_1_ </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>New Version</td>
|
||||
<td><img src="https://user-images.githubusercontent.com/72601495/117691541-4e445080-b1bc-11eb-9220-a90adf9a7610.png"/>
|
||||
|
||||
_Figure 11 NF50_2_ </td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## 3.6. /NF60/Resizable Rows <a name="NF6"/>
|
||||
The size of the fields can be adjusted in height, which is unnecessary because line breaks are not possible.
|
||||
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Old Version</td>
|
||||
<td>
|
||||
<img src="https://user-images.githubusercontent.com/72601495/97450803-67c62f00-1933-11eb-9071-42f998c19975.png" alt="imageNF50_1"/>
|
||||
|
||||
_Figure 12 NF60_1_ </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>New Version</td>
|
||||
<td><img src="https://user-images.githubusercontent.com/72601495/117629695-b6724280-b17a-11eb-88fd-75c7695d4f1c.png" alt="imageNF50_2"/>
|
||||
|
||||
_Figure 13 NF60_2_ </td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
## 3.7. /NF70/Header Overview <a name="NF7"/>
|
||||
An unnecessary grey field is displayed in the Header tab. This should be removed.
|
||||
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Old Version</td>
|
||||
<td>
|
||||
<img src="https://user-images.githubusercontent.com/72601495/97452349-eec7d700-1934-11eb-9220-adef4c45c89c.png" alt="imageNF50_1"/>
|
||||
|
||||
_Figure 14 NF70_1_ </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>New Version</td>
|
||||
<td><img src="https://user-images.githubusercontent.com/72601495/117691960-c9a60200-b1bc-11eb-9704-17eec8fdb0ac.png" alt="imageNF50_2"/>
|
||||
|
||||
_Figure 15 NF70_2_ </td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## 3.8. /NF80/Design of the Button’s <a name="NF8"/>
|
||||
In general, buttons are very difficult to recognize as such and do not have a uniform style.
|
||||
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Old Version</td>
|
||||
<td>
|
||||
<img src="https://user-images.githubusercontent.com/72601495/97452448-0b640f00-1935-11eb-8938-0fa6bc727e8c.png" alt="imageNF50_1"/>
|
||||
<img src="https://user-images.githubusercontent.com/72601495/97452429-069f5b00-1935-11eb-85e2-5954cc6d3364.png" alt="imageNF50_1"/>
|
||||
|
||||
_Figure 16 NF80_1_ </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>New Version</td>
|
||||
<td><img src="https://user-images.githubusercontent.com/72601495/117692596-76807f00-b1bd-11eb-989a-2687afe372e7.png" alt="imageNF50_2"/>
|
||||
<img src="https://user-images.githubusercontent.com/72601495/117692680-8dbf6c80-b1bd-11eb-8a6b-5055f95b2823.png" alt="imageNF50_2"/>
|
||||
_Figure 17 NF80_2_ </td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## 3.9. /NF90/Design of the Tab’s <a name="NF9"/>
|
||||
As shown in Figure 18, tabs are displayed differently and are not delimited by edges. This should be made uniform.
|
||||
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Old Version</td>
|
||||
<td>
|
||||
<img src="https://user-images.githubusercontent.com/72601495/97452607-34849f80-1935-11eb-9b35-88aa0de7552b.png" alt="imageNF50_1"/>
|
||||
|
||||
_Figure 18 NF90_1_ </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>New Version</td>
|
||||
<td><img src="https://user-images.githubusercontent.com/72601495/117693349-3cfc4380-b1be-11eb-9227-4c693d774c16.png" alt="imageNF50_2"/>
|
||||
|
||||
_Figure 19 NF90_2_ </td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## 3.10. /NF100/Code Quality <a name="NF10"/>
|
||||
The code quality of the previous project should be improved.[[1](#1)]
|
||||
|
||||
|
||||
# 4. Functional Requirements <a name="F"/>
|
||||
In this chapter, the functional requirements are described and illustrated with figures.
|
||||
## 4.1. /F10/ Link to Manual <a name="F1"/>
|
||||
The link under help/manual must be placed on a page that can be reached.
|
||||
|
||||
|
||||
|
||||
_Figure 20 F10_
|
||||
|
||||
New Manual can be found [here](https://github.com/DekaAthlos/TINF19C-ModellingWizard/wiki/6.-User-Manual)
|
||||
|
||||
## 4.2. /F20/ Add Button at Interfaces <a name="F2"/>
|
||||
The Add button, as in Figure 21 for the interface view, is not necessary. Interfaces should always be added to the AML file by default.
|
||||
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Old Version</td>
|
||||
<td>
|
||||
<img src="https://user-images.githubusercontent.com/72601495/97452959-92b18280-1935-11eb-99d3-397917755ed5.png" alt="imageNF50_1"/>
|
||||
|
||||
_Figure 21 F20_1_ </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>New Version</td>
|
||||
<td><img src="https://user-images.githubusercontent.com/72601495/117694602-9f097880-b1bf-11eb-96cc-557fc0abca35.png" alt="imageNF50_2"/>
|
||||
|
||||
_Figure 22 F20_2_ </td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## 4.3. /F30/Mechanical and Hydraulic Interfaces <a name="F3"/>
|
||||
For the interfaces, not only electrical interfaces, but also the other connectors and interfaces of AutomationMLComponentStandardRCL and AutomationML-ComponentBaseICL should be available, e.g. mechanical and hydraulic interfaces.
|
||||
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Old Version</td>
|
||||
<td>
|
||||
<img src="https://user-images.githubusercontent.com/72601495/97453069-ad83f700-1935-11eb-96e2-66f6c15269f6.png"/>
|
||||
|
||||
_Figure 23 F30_1_
|
||||
|
||||
<img src="https://user-images.githubusercontent.com/72601495/97714866-fa94d400-1ac1-11eb-9a56-8aba7ee370f8.png" width="350" height="350"/>
|
||||
<img src="https://user-images.githubusercontent.com/72601495/97714766-dafdab80-1ac1-11eb-9633-d439861f656f.png" width="350" height="350"/>
|
||||
|
||||
_Figure 24 F30_2_ </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>New Version</td>
|
||||
<td><img src="https://user-images.githubusercontent.com/72601495/117695155-38d12580-b1c0-11eb-86bc-fe8d91c0e255.png" width="350" height="350"/>
|
||||
<img src="https://user-images.githubusercontent.com/72601495/117695246-530b0380-b1c0-11eb-971c-f397d5862942.png" width="350" height="350"/>
|
||||
|
||||
_Figure 25 F30_3_ </td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## 4.4. /F40/CAEX 3.0 Output <a name="F5"/>
|
||||
The output format CAEX 3.0 should be implemented.
|
||||
|
||||
## 4.5. /F50/Parameter Requirements <a name="F6"/>
|
||||
As shown in Figure 26, other mandatory attributes should be highlighted in red. These are those required by the minimum rules for AML-DDs.
|
||||
|
||||
The following attributes are mandatory:
|
||||
Manufacturer,
|
||||
ManufacturerURI,
|
||||
Model,
|
||||
DeviceClass,
|
||||
ProductCode
|
||||
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Old Version</td>
|
||||
<td>
|
||||
<img src="https://user-images.githubusercontent.com/72601495/97453561-27b47b80-1936-11eb-898e-177d127d86fb.png" alt="imageNF50_1"/>
|
||||
|
||||
_Figure 26 F50_1_ </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>New Version</td>
|
||||
<td><img src="https://user-images.githubusercontent.com/72601495/117695998-1ee41280-b1c1-11eb-9169-344f5b5dbcc7.png" alt="imageNF50_2"/>
|
||||
|
||||
_Figure 27 F50_2_ </td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## 4.6. /F60/Delete Empty Fields <a name="F7"/>
|
||||
Newly added empty fields remain even though they are empty and can be collected. This should be prevented.
|
||||
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Old Version</td>
|
||||
<td>
|
||||
<img src="https://user-images.githubusercontent.com/72601495/97453641-38fd8800-1936-11eb-9825-4019033c5f43.png" alt="imageNF50_1"/>
|
||||
|
||||
_Figure 28 F60_1_ </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>New Version</td>
|
||||
<td><img src="https://user-images.githubusercontent.com/72601495/117696515-ad589400-b1c1-11eb-971e-51db95ebca75.png" alt="imageNF50_2"/>
|
||||
|
||||
_Figure 29 F60_2_ </td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## 4.7. /F70/Delete Button <a name="F8"/>
|
||||
The "Delete" button under Generic Data and Interfaces is currently not working. The function to remove elements should be implemented.
|
||||
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Old Version</td>
|
||||
<td>
|
||||
<img src="https://user-images.githubusercontent.com/72601495/97453741-516da280-1936-11eb-9e01-a09a6ec24a39.png" alt="imageNF50_1"/>
|
||||
|
||||
_Figure 30 F70_1_ </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>New Version</td>
|
||||
<td><img src="https://user-images.githubusercontent.com/72601495/117696515-ad589400-b1c1-11eb-971e-51db95ebca75.png" alt="imageNF50_2"/>
|
||||
|
||||
_Figure 31 F70_2_ </td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## 4.8. /F80/ Testability of AML device <a name="F9"/>
|
||||
A created AML device should be validated by the AML Component Checker.[[2](#2)]
|
||||
|
||||
# 5. Bug Fixes <a name="B"/>
|
||||
|
||||
[/BUG10/Generic Information Exception](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/5) <a name="B1"/>
|
||||
|
||||
[/BUG20/Electrical Interfaces Exception](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/6) <a name="B2"/>
|
||||
|
||||
[/BUG30/Generic Information Table Exception](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/7) <a name="B3"/>
|
||||
|
||||
[/BUG40/Nonfunctional Requirement NF20](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/14) <a name="B4"/>
|
||||
|
||||
[/BUG50/Vendor Name replaced with path](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/28) <a name="B5"/>
|
||||
|
||||
[/BUG60/Mandatory attributes are checked to late](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/30) <a name="B6"/>
|
||||
|
||||
[/BUG70/Open new file clears to early](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/31) <a name="B7"/>
|
||||
|
||||
[/BUG80/Changes names on old files](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/34) <a name="B8"/>
|
||||
|
||||
[/BUG90/Explorer opening is not consistent](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/35) <a name="B9"/>
|
||||
|
||||
[/BUG100/Loading libraries deletes to early](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/36) <a name="B10"/>
|
||||
|
||||
[/BUG110/Saves empty files](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/44) <a name="B11"/>
|
||||
|
||||
[/BUG120/Deletes all non amlx files](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/43) <a name="B12"/>
|
||||
|
||||
[/BUG130/Saving clears added "Role Class Libaries"](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/46) <a name="B13"/>
|
||||
|
||||
# 6. Enhancements <a name ="Enhancements"/>
|
||||
|
||||
[/EH10/Error message when file does not load](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/42) <a name="EH10"/>
|
||||
|
||||
[/EH20/Open attributes as default](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/41) <a name="EH20"/>
|
||||
|
||||
[/EH30/Import/Open foreign files](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/45) <a name="EH30"/>
|
||||
|
||||
[/EH40/Only show libraries when they can be used](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/40) <a name="EH40"/>
|
||||
|
||||
[/EH50/Standard library position change](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/39) <a name="EH50"/>
|
||||
|
||||
[/EH60/"Save" or "Save and Close File" Button](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/38) <a name="EH60"/>
|
||||
|
||||
[/EH70/Check for valid URL in ManufacturerURL field](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/37) <a name="EH70"/>
|
||||
|
||||
[/EH80/Dropdown buttons](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/33) <a name="EH80"/>
|
||||
|
||||
[/EH90/New version number](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/32) <a name="EH90"/>
|
||||
|
||||
[/EH100/Redundant save buttons](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/29) <a name="EH100"/>
|
||||
|
||||
[/EH110/Re-design AMLX File Structure](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/63) <a name="EH110"/>
|
||||
|
||||
# 7. References <a name="Ref"/>
|
||||
[1] https://github.com/Rajkumarpulaparthi/ModellingWizard <a name="1"/>
|
||||
|
||||
[2] https://amlcc.tarakos.de/Identity/Account/Login?ReturnUrl=%2F <a name="2"/>
|
||||
|
||||
[here] https://github.com/DekaAthlos/TINF19C-ModellingWizard/wiki/6.-User-Manual <a name="here"/>
|
||||
|
||||
Author: Timo Zaoral
|
||||
261
2.-Software-Architecture-Specification.md
Normal file
261
2.-Software-Architecture-Specification.md
Normal file
@ -0,0 +1,261 @@
|
||||
#### Table of Contents
|
||||
* [1. Introduction](#I)
|
||||
* [1.1 Glossar](#G)
|
||||
* [2. System Overview](#S)
|
||||
* [2.1 System Environment](#S1)
|
||||
* [2.2 Software Environment](#S2)
|
||||
* [2.3 Quality Goals](#S3)
|
||||
* [2.3.1 Usability](#S4)
|
||||
* [2.3.2 Bug fixing](#S5)
|
||||
* [3. Quality Concept](#QC)
|
||||
* [3.1 Usability concept](#QC1)
|
||||
* [3.2 Code Quality](#QC2)
|
||||
* [4. Architectural Concept](#AC)
|
||||
* [4.1 Architectural Model](#AC1)
|
||||
* [5. System Design](#SD)
|
||||
* [6. Subsystem specification](#SS)
|
||||
* [6.1 MOD.001: Graphical User Interface (GUI)](#SS1)
|
||||
* [6.2 MOD.002: Controller functionalities](#SS2)
|
||||
* [7. Technical Concepts](#TC)
|
||||
* [7.1 Persistence](#TC1)
|
||||
* [7.2 User Interface](#TC2)
|
||||
* [7.3 Ergonomics](#TC3)
|
||||
* [7.4 Communication with other IT-Systems](#TC4)
|
||||
* [7.5 Deployment](#TC5)
|
||||
* [7.6 Data Validation](#TC6)
|
||||
* [7.7 Exception Handling](#TC7)
|
||||
* [7.8 Internationalization](#TC8)
|
||||
* [7.9 Testability](#TC9)
|
||||
* [7.10 Availability](#TC10)
|
||||
* [8. References](#R)
|
||||
|
||||
# Changelog
|
||||
|
||||
| Version | Date | Author | Comment |
|
||||
| ------------- |-------------|-------------|-------------|
|
||||
| V0.1 | 26.10.2020 | Simon Jess | created |
|
||||
| V0.2 | 10.11.2020 | Simon Jess | last released version |
|
||||
| V0.3 | 15.03.2021 | Simon Jess | Remake of subsystem specifications |
|
||||
| V0.4 | 18.04.2021 | Simon Jess | Specify modules |
|
||||
| V0.5 | 28.04.2021 | Simon Jess | Add quality concept and system design + references to source code |
|
||||
| V0.6 | 05.05.2021 | Simon Jess | Add MVC pattern and correct and write description texts |
|
||||
| V1.0 | 18.05.2021 | Simon Jess | Last changes are commited |
|
||||
|
||||
***
|
||||
|
||||
# 1. Introduction <a name="I"/>
|
||||
|
||||
The goal of this project is to further develop and improve a plugin for the AutomationML editor. Main part is the improvement of the graphical user interface. To achieve this, the usability is one of the most important components. Furthermore, the existing bugs should be handled, that the user can use the plugin to creat AutomationML devices.
|
||||
|
||||
|
||||
## 1.1 Glossar <a name="G"/>
|
||||
|
||||
**.NET** The .NET Framework is a software development and runtime environment developed by Microsoft for Microsoft Windows.
|
||||
|
||||
**C#** High level language often used for programming
|
||||
|
||||
**GUI** Graphical User Interface
|
||||
|
||||
**AML** Automation mark-up language is an open standard data format for storing and exchanging plant planning data.
|
||||
|
||||
**AMLX** AML Package to store also not AML files in one package
|
||||
|
||||
**CAX** File format of AML Device files
|
||||
|
||||
|
||||
# 2. System Overview <a name="S"/>
|
||||
|
||||
## 2.1 System Environment <a name="S1"/>
|
||||
|
||||
The way to access and work with the plugin is via the AutomationML editor. There you can install the plugin and use the graphical interface. In the plugin you can create and edit AMLX packagesto use them in the AutomationML editor.
|
||||
|
||||
Among others the IODD and GSD converter are used as neighboring systems.
|
||||
|
||||
## 2.2 Software Environment <a name="S2"/>
|
||||
|
||||
That the plugin works you need at least version 4.5 of the .Net framework, because it was developed in C# using the .net framework. This version of the framework is available from Windows Vista or later. Furthermore, the plugin is only available in the AutomationML editor and is not a standalone software.
|
||||
|
||||
## 2.3 Quality Goals <a name="S3"/>
|
||||
|
||||
In order to achieve the quality goals, different criteria are considered. These include:
|
||||
|
||||
### 2.3.1 Usability <a name="S4"/>
|
||||
|
||||
Usability is the key aspect in the whole project. For this purpose, a GUI was created to enable the user to use it as easy as possible. Intuitive control is very important, but also an attractive design is necessary to create the highest possible user experience.High user experience is essential for a plugin to be successful in simplifying work steps. **(further information in the usability concept)**
|
||||
|
||||
### 2.3.2 Bug fixing <a name="S5"/>
|
||||
|
||||
Functions that are already implemented should be fixed, that the plugin works without any errors or bugs, which are not intended.Another milestone to keep the quality high is the fixing of bugs that cause unwanted behavior or even fatal errors.
|
||||
|
||||
# 3. Quality Concept <a name="QC"/>
|
||||
This part of the system architecture specification is an unusual component, which is specified here, in order to specify the problems, which usually arise with a further development of software as a matter of course. Among other things, it lists the concepts that have been designed to deal with these problems and improve the quality of the final product.
|
||||
|
||||
## 3.1 Usability concept <a name="QC1"/>
|
||||
|
||||
**The criteria for good usability are:**
|
||||
|
||||
**Color scheme**:
|
||||
A good coloration can be created by an attractive choice of colors and their coordinated contrasts.
|
||||
|
||||
**Design:**
|
||||
When designing the plugin, an appealing arrangement is important. It should be clearly recognizable which function is behind which visual elements and how the user can navigate through the plugin.
|
||||
|
||||
**Intuitiveness:**
|
||||
Intuitiveness is a key component of good usability which means that the user understands the plugin without a long training period.
|
||||
|
||||
**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.
|
||||
|
||||
**Implementation guideline:**
|
||||
|
||||
After carrying out the usability test, guidelines were developed, based on which the GUI improvements are to be made. Therefore, the GUI must meet the following guidelines:
|
||||
|
||||
* A consistent color palette should be used where elements with the same events have the same colors for recognition.
|
||||
|
||||
* Contrasts and frames should be used to emphasize input or fields of interaction and empty areas should be avoided to create an attractive and tidy design. The layout of the GUI should also match the style of the AML editor.
|
||||
|
||||
* The design and layout should be self-explanatory and reinforce the previous point in order to allow an intuitive use.
|
||||
|
||||
* The controls should be as close as possible to those of the AML editor, so that the user of the AML editor can find his way around faster.
|
||||
|
||||
**Based on the criteria just defined and the developed guidelines the graphical interface is adapted and optimized. Functionality is very important but should not negatively influence the usability. Nevertheless, compromises must be made in terms of viability.**
|
||||
|
||||
## 3.2 Code Quality <a name="QC2"/>
|
||||
|
||||
Code quality is one of the most important aspects when it comes to software that is being developed further and possibly by different developers. For this reason, we have made it our mission to address the problem of code quality and improve it.
|
||||
In order to adhere to a certain standard, we have followed some methodologies and criteria of the book [Clean Code by Robert Martin](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) [4]. <br>
|
||||
This includes, for example, commenting on sections of code that are not clearly understandable, in order to explain to others the idea that was implemented.
|
||||
But also the implementation of programming paradigms and programming principles that make code easy to understand are part of code quality and therefore a point that must be considered.
|
||||
|
||||
Therefore, in order to achieve a certain code quality, an attempt will be made to simplify and modularize existing functions so that they can be reused and do not have to be written twice, if it is possible. However, the main focus is on the documentation, which thought processes were implemented how, so that the already existing functions for future developments are ladder understandable.
|
||||
|
||||
|
||||
# 4. Architectural Concept <a name="AC"/>
|
||||
|
||||
## 4.1 Architectural Model <a name="AC1"/>
|
||||
|
||||
The plugin was designed and developed in a Model-View-Control (MVC) architecture pattern, which 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. The controller executes the changes, also called manipulations, in the background. The changes are then updated on the GUI, so that the user thinks that the changes were made directly in the GUI (compare figure 1).
|
||||
|
||||
|
||||
|
||||
|
||||
_Figure 1 – MVC Architecture [2]_
|
||||
|
||||
|
||||
Almost all the logic is contained in the controller, which thus forms the center 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 the communication with the GUI and the external systems added for conversions. This interface is the core of the whole plugin and is responsible for functionalities, but also the integration of additional functions like saving or loading AMLX packages. In the Modelling Wizard project, no additional model was used, but the controller also takes over the functions.
|
||||
|
||||
|
||||
_Figure 2 - Logic of the plugin_
|
||||
|
||||
The architecture design in Figure 2 is the design that was created by the first development team when the plugin was first implemented.
|
||||
However, through 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 3, the architecture has become more and more unstructured and complex.
|
||||
|
||||
# 5. System Design <a name="SD"/>
|
||||
|
||||
|
||||
_Figure 3 - System class design_
|
||||
|
||||
The MVC pattern is still a small part of the whole system design.
|
||||
Here the usercontrole is the user input, Devicedescirption maps due to its two different C# program files once the GUI and once the controller.
|
||||
MWData 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.
|
||||
|
||||
|
||||
|
||||
_Figure 4 - MVC pattern_
|
||||
|
||||
|
||||
| Classname| Storage location |
|
||||
| --- | --- |
|
||||
| About | [SOURCE/About.xaml.cs](https://github.com/DekaAthlos/TINF19C-ModellingWizard/blob/master/SOURCE/About.xaml.cs)|
|
||||
| AnimationClass | [SOURCE/AnimationClass.cs](https://github.com/DekaAthlos/TINF19C-ModellingWizard/blob/master/SOURCE/AnimationClass.cs) |
|
||||
| AutomationMLDataTables | [SOURCE/AutomationMLDataTables.cs](https://github.com/DekaAthlos/TINF19C-ModellingWizard/blob/master/SOURCE/AutomationMLDataTables.cs)|
|
||||
| ClassOfListFromReferencefile | [SOURCE/ClassOfListsFromReferencefile.cs](https://github.com/DekaAthlos/TINF19C-ModellingWizard/blob/master/SOURCE/ClassOfListsFromReferencefile.cs)|
|
||||
| DeviceDescription | GUI: [SOURCE/DeviceDescription.Designer.cs](https://github.com/DekaAthlos/TINF19C-ModellingWizard/blob/master/SOURCE/DeviceDescription.Designer.cs) <br> Logic: [SOURCE/DeviceDescription.cs](https://github.com/DekaAthlos/TINF19C-ModellingWizard/blob/master/SOURCE/DeviceDescription.cs)|
|
||||
| ModellingWizard | [SOURCE/ModellingWizard.xaml.cs](https://github.com/DekaAthlos/TINF19C-ModellingWizard/blob/master/SOURCE/ModellingWizard.xaml.cs) |
|
||||
| MWController | [SOURCE/MWController.cs](https://github.com/DekaAthlos/TINF19C-ModellingWizard/blob/master/SOURCE/MWController.cs)|
|
||||
| MWData | [SOURCE/MWData.cs](https://github.com/DekaAthlos/TINF19C-ModellingWizard/blob/master/SOURCE/MWData.cs)|
|
||||
| MWDevice | [SOURCE/MWDevice.cs](https://github.com/DekaAthlos/TINF19C-ModellingWizard/blob/master/SOURCE/MWDevice.cs) |
|
||||
| Resources | [SOURCE/Resources/](https://github.com/DekaAthlos/TINF19C-ModellingWizard/blob/master/SOURCE/Resources/) |
|
||||
| SearchAMLComponentFile | [SOURCE/SearchAMLComponentFile.cs](https://github.com/DekaAthlos/TINF19C-ModellingWizard/blob/master/SOURCE/SearchAMLComponentFile.cs)|
|
||||
| SearchAMLLibraryFile | [SOURCE/SearchAMLLibraryFile.cs](https://github.com/DekaAthlos/TINF19C-ModellingWizard/blob/master/SOURCE/SearchAMLLibraryFile.cs) |
|
||||
|
||||
|
||||
|
||||
# 6. Subsystem specification <a name="SS"/>
|
||||
|
||||
## 6.1 MOD.001: Graphical User Interface (GUI) <a name="SS1"/>
|
||||
|
||||
| <MOD.001> | Graphical User Interface |
|
||||
| ------------- |-------------|
|
||||
| **System requirements covered:** | /NF10/, /NF20/, /NF30/, /NF40/, /NF50/, /NF60/, /NF70/, /NF80/, /NF90/, /NF100/, /F10/, /F20/, /F60/, /F70/, /BUG10/, /BUG20/, /BUG30/, /BUG40/, /BUG50/, /BUG90/, /BUG100/ |
|
||||
| **Services:** |The graphical user interface, is designed to recognize input from the user and send it to the controller by calling event functions. |
|
||||
| **Interfaces:** | --- |
|
||||
| **External Data:** | --- |
|
||||
| **Storage location:** |[SOURCE/DeviceDescription.Designer.cs](https://github.com/DekaAthlos/TINF19C-ModellingWizard/blob/master/SOURCE/DeviceDescription.Designer.cs)|
|
||||
| **Modul documentation:** | [MOD.001: Graphical User Interface (GUI)](https://github.com/DekaAthlos/TINF19C-ModellingWizard/wiki/MOD.001:-Graphical-User-Interface-(GUI)) |
|
||||
|
||||
## 6.2 MOD.002: Controller<a name="SS2"/>
|
||||
|
||||
| <MOD.002> | Controller |
|
||||
| ------------- |-------------|
|
||||
| **System requirements covered:** | /NF100/, /F30/, /F40/, /F50/, /F80/, /BUG60/, /BUG70/, /BUG80/, /BUG110/, /BUG120/, /BUG130/ |
|
||||
| **Services:** |The controller is the logic distribution. It reacts to the events triggered by the GUI and takes care of creating the respective objects. Furthermore, 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 <br> For export/import of amlx files there is an other class referenced: [SOURCE/MWData.cs](https://github.com/DekaAthlos/TINF19C-ModellingWizard/blob/686d44f8960077b3c15d6680ecd5b0da67bc8233/SOURCE/MWData.cs)|
|
||||
| **External Data:** | --- |
|
||||
| **Storage location:** |[SOURCE/DeviceDescription.cs](https://github.com/DekaAthlos/TINF19C-ModellingWizard/blob/master/SOURCE/DeviceDescription.cs)|
|
||||
| **Modul documentation:**| [MOD.002: Controller](https://github.com/DekaAthlos/TINF19C-ModellingWizard/wiki/MOD.002:-Controller) |
|
||||
|
||||
|
||||
# 7. Technical Concepts <a name="TC"/>
|
||||
|
||||
## 7.1 Persistence <a name="TC1"/>
|
||||
|
||||
Persistence is given by the package format. AMLX packages can be created and edited by the plugin. This format is also used in AutomationML and therefore it is possible to open the AMLX packages and use them in the editor.
|
||||
|
||||
## 7.2 User Interface <a name="TC2"/>
|
||||
|
||||
The graphical user interface (GUI) is the interface between user and program logic. The GUI allows the user to add new devices to the AutomationML Editor using the Modelling Wizard plugin.
|
||||
|
||||
## 7.3 Ergonomics <a name="TC3"/>
|
||||
|
||||
It is important for an ergonomic GUI to be intuitive. There are simple rules to follow to make the user experience as good and appealing as possible. This includes making sure that the design is appealing and that it is created in such a way that the user intuitively understands how to use it.
|
||||
|
||||
## 7.4 Communication with other IT-Systems <a name="TC4"/>
|
||||
|
||||
In the plugin there are use cases, for which external converter systems are integrated. These include the IODD converter and the GSD converter for AutomationML. With the converters IODD and GSD files can be converted into AML files to realize the functions of the plugin.
|
||||
|
||||
## 7.5 Deployment <a name="TC5"/>
|
||||
|
||||
It is not a stand-alone software that can be used without AutomationML. The plugin must be installed in the AutomationML editor using the plugin manager of AutomationML to install the .dll file.
|
||||
|
||||
## 7.6 Data Validation <a name="TC6"/>
|
||||
|
||||
The data check takes place in the background by the controller. This includes incorrect entries and missing information, which must be specified as mandatory information.
|
||||
|
||||
## 7.7 Exception Handling <a name="TC7"/>
|
||||
|
||||
The exception handling must be done to prevent errors caused by the user while using the GUI. Therefore "try-catch" blocks are used to prevent unwanted behavior of the program.
|
||||
|
||||
## 7.8 Internationalization <a name="TC8"/>
|
||||
|
||||
Since the language for the plugin and the user manual is English, the tool can be used internationally. But it is not possible to change the language individually, therefore English is obligatory.
|
||||
|
||||
## 7.9 Testability <a name="TC9"/>
|
||||
|
||||
To get an overview of the tests, the system test plan provides further information and the system test report contains their results. Overall, created AML file should be validated by the AML Component Checker.
|
||||
|
||||
## 7.10 Availability <a name="TC10"/>
|
||||
|
||||
The program is only distributed on GitHub and GitHub is the only possible source.
|
||||
|
||||
|
||||
# 8. References <a name="R"/>
|
||||
| Reference | Source |
|
||||
| --- | --- |
|
||||
| [1] | [Clean Code by Robert C. Martin](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); 18.05.2021 |
|
||||
| [2] | „Wikipedia," 4 November 2020. [Online]. Available: https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller. |
|
||||
| [3] | SAS INF17C, Jahr 2019 |
|
||||
| [4] | Sourcecode - ReSharper architecture view|
|
||||
6888
4.-Systemtestplan.md
Normal file
6888
4.-Systemtestplan.md
Normal file
File diff suppressed because it is too large
Load Diff
4727
5.-Systemtestreport.md
Normal file
4727
5.-Systemtestreport.md
Normal file
File diff suppressed because it is too large
Load Diff
320
6.-User-Manual.md
Normal file
320
6.-User-Manual.md
Normal file
@ -0,0 +1,320 @@
|
||||
##### Table of Contents
|
||||
|
||||
* [1\. Introduction](#Intro)
|
||||
* [1.1 Overview](#Overview)
|
||||
* [1.2 Glossar](#Glossar)
|
||||
* [2\. Installation](#Installation)
|
||||
* [2.1 Software requirements](#Requirements)
|
||||
* [2.2 Installation process](#Installationprocess)
|
||||
* [2.2.1 AutomationML Editor](#AMLEditor)
|
||||
* [2.2.2 Modelling Wizard Plugin](#MLWP)
|
||||
* [3\. Graphical User Interface](#GUI)
|
||||
* [3.1 General Information](#GeneralInfo)
|
||||
* [3.1.1 Generic Data Tab](#GenericData)
|
||||
* [3.1.2 Interfaces Tab](#Interfaces)
|
||||
* [3.1.3 Attachments Tab](#Attachments)
|
||||
* [3.2 File Import](#FileImport)
|
||||
* [3.3 File Export](#FileExport)
|
||||
* [4\. Copyright](#Copyright)
|
||||
|
||||
# Changelog
|
||||
|
||||
| Version | Date | Author | Comment |
|
||||
| ------------- |-------------|-------------|-------------|
|
||||
| V0.1 | 17.04 | Tobias Roth | created |
|
||||
| V0.2 | 25.04 | Tobias Roth | fill document |
|
||||
| V0.3 | 07.05 | Tobias Roth | continue document |
|
||||
| V0.4 | 12.05 | Tobias Roth | finish document |
|
||||
| V1.0 | 20.05 | Tobias Roth | final document |
|
||||
|
||||
***
|
||||
|
||||
# 1. Introduction <a name="Intro"/>
|
||||
## 1.1 Overview <a name="Overview"/>
|
||||
Our main tasks were to improve the usability of the creation of AutomationML devices and interfaces, therefore this User Manual specifically targets these functions of the Modelling Wizard for Device Descriptions plugin.
|
||||
Precisely, the intention of the User Manual is to explain the usage of the Modelling Wizard plugin. It is written that also inexperienced users can understand how to use the plugin. It contains an instruction on how to install the Modelling Wizard plugin, how to generally use the User Interface and how to import and export files that are part of the AML Package.
|
||||
## 1.2 Glossar <a name="Glossar"/>
|
||||
|
||||
**AML** Automation mark-up language is an open standard data format for storing and exchanging plant planning data.
|
||||
|
||||
**AML Editor** Abbreviation for the AutomationML-Editor
|
||||
|
||||
**AMLX** AML Package
|
||||
|
||||
**CAEX** Computer-Aided Engineering Exchange
|
||||
|
||||
**C#** High level language often used for programming
|
||||
|
||||
**GSD** General-Station-Description
|
||||
|
||||
**GUI** Graphical User Interface
|
||||
|
||||
**IODD** Input/Output Device Description
|
||||
|
||||
**.NET** The .NET Framework is a software development and runtime environment developed by Microsoft for Microsoft Windows.
|
||||
|
||||
**ZIP** archive file format
|
||||
|
||||
***
|
||||
|
||||
# 2. Installation <a name="Installation"/>
|
||||
## 2.1 Software Requirements <a name="Requirements"/>
|
||||
|
||||
### Please note that the AML Editor is a .NET application, it can only be used on Windows operating systems. There are no Linux or MacOS distributions provided yet.
|
||||
|
||||
|
||||
To use our Modelling Wizard plugin, you need:
|
||||
|
||||
* the AutomationML Editor (You can find the latest version of the Editor [Here](https://www.automationml.org/o.red.c/dateien.html?cat=1))
|
||||
* the ModellingWizard.dll file (Allocated in our [Repository](https://github.com/DekaAthlos/TINF19C-ModellingWizard/tree/master/EXECUTABLE))
|
||||
|
||||
## 2.2 Installation process <a name="Installationprocess"/>
|
||||
### 2.2.1 AutomationML Editor <a name ="AMLEditor"/>
|
||||
|
||||
Download the latest version of the AML Editor by clicking on the link in [2.1 Software Requirements](#Requirements).
|
||||
|
||||
After downloading the AMl Editor, you will receive a .zip-folder. Open it and you will see the following files:
|
||||
|
||||
|
||||
|
||||
Continue by starting the setup.exe. After the setup.exe is started, the AML Editor Setup Wizard will be opened. Click on "Next".
|
||||
|
||||
In the next step, you have to agree the License Agreement by clicking on "I Agree", otherwise the installation can not be continued.
|
||||
|
||||
Now there will be some information given by the creators, but you can go to the next step by clicking on "Next".
|
||||
|
||||
To make sure you can follow this installation guide, **do not change the default installation folder**. The AML Editor will be installed under the Program Files on the Windows partition of your hard drive. Install the AML-Editor just for yourself and continue the installation.
|
||||
|
||||
|
||||
|
||||
In the next step the installation will be finished when you click on "Next". If there is a pop-up by your Windows OS, asking to make changes on a specific file on your C: folder, just click on "Yes".
|
||||
|
||||
Now the installation of the AML-Editor is finished and you can close the installation windows by clicking on "Close".
|
||||
|
||||
Use the windows search function and type "AutomationMLEditor". Start the program to check whether the installation was successfull or not.
|
||||
|
||||
|
||||
|
||||
If the application that has opened looks like this, the installation was completed successfully.
|
||||
|
||||
When either no program with the name "AutomationMLEditor" can be found or the application does not open properly like shown in the picture above, try to uninstall the AML-Editor (Programs and Features -> Uninstall) and start the installation process again.
|
||||
|
||||
***
|
||||
|
||||
### 2.2.2 Modelling Wizard Plugin <a name ="MLWP"/>
|
||||
Before starting the installation of the Modelling Wizard Plugin, go to the installation directory of the AML-Editor (default: **C:\Program Files\AutomationML\AutomationML Editor** or with your custom installation directory) and check if there is a folder like "Plugin". If not, please create one.
|
||||
|
||||
Now you have to select the "Plugin" folder in the AML-Editor Plugin Manager, otherwise the Modelling Wizard Plugin cannot be installed. Open the AML-Editor, navigate to "PlugIns" in the header bar and click on the "PlugIn-Manager".
|
||||
|
||||
|
||||
|
||||
In the PlugIn Manager, click on the gearwheel button  in the top right corner to open the settings for the manager.
|
||||
Now a new PlugIn Source can be selected. For this, click on the  "add" button and a new, fillable field will open. In the "Name" field, please enter something like "PlugIn". In the "Source" field, you have to enter the the file path of the AML-Editor Plugin folder. If you followed the installation of the [AML-Editor](#AMLEditor), write in the following default path (or change the path, if you installed the AML-Editor anywhere else):
|
||||
|
||||
**C:\Program Files\AutomationML\AutomationML Editor\Plugin**
|
||||
|
||||
Please check the check field  of the new source you just created. You can click on "OK" to confirm your entry if your new source looks like this:
|
||||
|
||||
|
||||
|
||||
The installation of the PlugIn folder is now finished, you can close the PlugIn Manager and the AML-Editor.
|
||||
|
||||
To install the Modelling Wizard Plugin, you need to download the ModellingWizard.dll from our [Repository](https://github.com/DekaAthlos/TINF19C-ModellingWizard/tree/master/EXECUTABLE). After clicking on the link, click on the file named "ModellingWizard.dll", a new page will be loaded and you can click on the "View Raw" or "Download" button. The download will be started.
|
||||
|
||||
In most cases, when the download is finished, your antivirus program or Windows Defender will give you a message that the file can be harmful or that it can do damage to your computer. You can ignore this message and save the file anyways, it is just an unusual file format that will be downloaded.
|
||||
|
||||
To continue the installation, open the folder where the .dll is located or open a  windows explorer and go to the  (*Downloads* Folder).
|
||||
|
||||
It should look like this:
|
||||
|
||||
|
||||
|
||||
Now open a second windows explorer and use this navigation path to jump into the *Plugin* folder of the AML Editor:
|
||||
|
||||
**C:\Program Files\AutomationML\AutomationML Editor\Plugin**
|
||||
|
||||
When you followed the [Installation for the AML Editor](#AMLEditor) this path will open the *Plugin* folder successfully.
|
||||
But if you selected another installation folder for the AML Editor, you have to search the folder by yourself.
|
||||
|
||||
To add the Modelling Wizard.dll file to the AML Editor, drag and drop the .dll file from your *Downloads* folder into the *Plugin* folder. It should look like this:
|
||||
|
||||
|
||||
|
||||
When you added the .dll file like shown above, you can close your open folders. Now start the AML Editor and go to "PlugIns" in the header bar.
|
||||
|
||||
|
||||
|
||||
Open the "PlugIn Manager"
|
||||
|
||||
|
||||
|
||||
Proceed with the following steps:
|
||||
|
||||
|
||||
|
||||
1 - Click on "available"
|
||||
2 - Scroll down and click on the "Modelling Wizard - owned by DHBW-Stuttart (v2.0.0.0) to select it"
|
||||
3 - Click on the "install" button
|
||||
|
||||
Now you can close the "PlugIn Manager" and the AML Editor to make sure that the Modelling Wizard will be installed properly. Open the AML Editor again and open "PlugIns" to check if the Modelling Wizard is installed. The installation was succesfull when it looks like this:
|
||||
|
||||
|
||||
|
||||
The Modelling Wizard can now be started. Click on the Modelling Wizard field to select it and click on "Start" to start the plugin.
|
||||
|
||||
|
||||
|
||||
The plugins main interface will open and the installation process is finished.
|
||||
|
||||
When you are not able to finish the installation with this guide because problems are occuring (e.g. the Modelling Wizard cannot be selected in the "PlugIn Manager"), try to delete the .dll file from the folder, download it and start the installation again.
|
||||
|
||||
***
|
||||
|
||||
# 3. Graphical User Interface <a name="GUI"/>
|
||||
|
||||
## 3.1 General Information <a name="GeneralInfo"/>
|
||||
This chapter explains how to use the user interface of the Modelling Wizard.
|
||||
In the plugin, you have three different tabs that contain information. The function of each tab and its possibilites will be explained in its own subsection.
|
||||
|
||||
|
||||
|
||||
General information of the device that will be created, is stored under the ["**Generic Data**"](#GenericData) tab.
|
||||
In the ["**Interfaces**"](#Interfaces) you have the option to add interfaces to define detailed information about the device.
|
||||
Under the ["**Attachments**"](#Attachments) tab, it is possible to add further attachments to the file.
|
||||
|
||||
While creating a file, you have the option to add the "Vendor Name" and the "Device Name" in the header bar of the Modeling Wizard plugin. If you import a file, these fields will be filled automatically. They are synchronised with the "Manufacturer" and "Model" fields in the Attributes table under the [Generic Data tab](#GenericData), that means if you fill the fields in the header bar, they are also going to be filled in the Attributes table.
|
||||
|
||||
|
||||
|
||||
In the header bar, you can select the "Standard Libraries" dropdown button. It will display all the libraries that can be loaded into the plugin. If there is a library that you need to add more information to your device, you can select it from the dropdown and make it available in the "Role Class Library" section.
|
||||
|
||||
|
||||
|
||||
***
|
||||
|
||||
### 3.1.1 Generic Data Tab <a name ="GenericData"/>
|
||||
|
||||
To add general information to the device, the Attributes table can be filled with information. The **red marked** fields are mandatory fields and must be filled with information. To display how it works, some dummy attributes are added to the device:
|
||||
|
||||
|
||||
|
||||
|
||||
Furthermore, it is possible to add **Role Class Libraries** to the Generic Information. The Role Class Libraries **will only be displayed** if you have selected the Generic Data tab. To add a Role Class Library, select the Role Class you want to add and then **drag and drop** it into the "Generic Information" table. The Generic Information table is located in the upper half of the Generic Data tab. In this case, the AdditionalDeviceDescription Class will be added to the device.
|
||||
|
||||
*Please note that the drag and drop function works better if you use the right mouse button*.
|
||||
|
||||
|
||||
|
||||
**Generic Information table**
|
||||
|
||||
|
||||
|
||||
To display the properties of the Role Class you just added to the device, select the Role Class in the Generic Information Table you drag and dropped it in and **double click** the new element that appears above the Attributes table. If any properties are saved, they will be displayed in the Attributes table.
|
||||
|
||||
|
||||
|
||||
The Header tab of the Attributes table contains information about the Role Class that is added to the device. By adding a Role Class, the header tab will be filled with information that is stored in the certain Role Class, but you can add more information aswell.
|
||||
|
||||
|
||||
|
||||
To delete a Role Class from your device, select the Role Class in the Generic Information table and press on the "Delete Button" that is placed on the top right side of the table. The Role Class will be deleted from the table and also from the file.
|
||||
|
||||
***
|
||||
### 3.1.2 Interfaces tab <a name ="Interfaces"/>
|
||||
The use of the Interfaces tab strongly corresponds to the use of the Generic Data tab. Here you can add Interfaces Class Libraries to the device. The Interface Class Libraries **will only be displayed** if you are under the Interfaces tab.
|
||||
|
||||
|
||||
|
||||
To add an Interface Class Library, follow the instructions under [3.1.1 Generic Data tab](#GenericData), they work the same way.
|
||||
|
||||
***
|
||||
### 3.1.3 Attachments tab <a name ="Attachments"/>
|
||||
The Attachments tab offers the possibility, to add attachments like images or PDFs to your device file. To do so, select the type of the attachment you want to add that will be displayed if you click on the the dropdown button. The following attachment types are included:
|
||||
|
||||
|
||||
|
||||
After selecting the type of the file you want to add, you can select a file from your computer with the "Select File" Button. If you want to select the file by giving it a certain path, e.g. the file is stored anywhere else, you can add a path in the "Add path" field. Here a file of the "Certificate" type will be attached.
|
||||
|
||||
|
||||
|
||||
After the file is attached, the type and the file path will be displayed in the table like you can see above. To delete an attachment, click on the "Delete" Button on the right side of the header bar of the table.
|
||||
***
|
||||
|
||||
## 3.2 File Import <a name="FileImport"/>
|
||||
Like already mentioned, the Modelling Wizard plugin offers the ability to import a file and display its properties. Please note that you are only able to open files that are saved in the AML (.aml; .amlx; .xml;) file type.
|
||||
To open a AML file, start the Modelling Wizard and select in the header bar bar "File" -> "Open".
|
||||
|
||||
|
||||
|
||||
After this, a windows explorer opens where you can select a file that will be display in the Modelling Wizard. To display the file, select it and click on "Open". In this example, a .amlx file from the manufacturer "Balluff" will be displayed.
|
||||
|
||||
|
||||
|
||||
After the import of the file, the vendor name (in this case Balluff) and the device name will be displayed in the header bar of the plugin.
|
||||
|
||||
|
||||
|
||||
Other attributes are displayed in the "Attributes table" (e.g. the URL of the manufacturer) under the "Generic Data" tab.
|
||||
|
||||
|
||||
|
||||
Furthermore, the interfaces and the attachments of the device that is created with the AML file can be seen in their "Interfaces" and "Attachments" tab.
|
||||
|
||||
**Error Handling**
|
||||
Meanwhile it is possible to import most of the AML files, nevertheless there are a few libraries that the Modelling Wizard plugin is not able to work with. If you try to import a file that contains such a library, the Modeling Wizard will put out a error message to inform you.
|
||||
|
||||
## 3.3 File Export <a name = "FileExport"/>
|
||||
In this section it will be shown how to save a file that is created with the Modelling Wizard plugin. The example file of [3.2 File Import](#FileImport) will be used to demonstrate how it works. If you want to create a new file, select "New" in the File dropdown button of the header bar.
|
||||
|
||||
|
||||
|
||||
**_Important Information_**: As already mentioned in [3.1.1 Generic Data Tab](#GenericData) following fields are mandatory fields and must be filled with information, otherwise you are not able to save a file:
|
||||
|
||||
|
||||
|
||||
|
||||
Those fields are listed in the "Attributes" table under the "Generic Data" tab. If they are not filled when you try to safe the file, you will get an error message.
|
||||
|
||||
If you want to save the file, go to the "File" button in the header bar. You will get 2 options:
|
||||
|
||||
**1 - Save**
|
||||
**2 - Save and Close File**
|
||||
|
||||
|
||||
|
||||
**Option 1 - Save:** Select a target location and save the file and all the data you filled in. After the save, you will be able to continue the editing of the file and add more information. Useful if you want to create temporary savings while creating a new file.
|
||||
|
||||
**Option 2 - Save and Close File:** Select a target location and save the file. After saving, all information that is currently displayed in the Modelling Wizard plugin will be deleted from the fields. This option is useful when you have finished editing a file and want to create a new one.
|
||||
|
||||
Please note that **all files that will be saved are automatically stored in the .amlx file type**. For this reason you are not able to select a file type by yourself while saving a file.
|
||||
|
||||
|
||||
# 4. Copyright <a name = "Copyright"/>
|
||||
## About the Modelling Wizard for Devices PlugIn
|
||||
|
||||
The Modelling Wizard for Devices is a plugin that can be used to create or modify devices and interfaces. It can also be used to import IODD and GSDML, CAEX 2.15 and CAEX 3.0 files that will be converted to the AMLX (.aml; .amlx; .xml;) package.
|
||||
|
||||
**Version 2.0.0.0**
|
||||
***
|
||||
Design and Software development by
|
||||
|
||||
**TINF17C DHBW Stuttgart**
|
||||
and
|
||||
**Master Student Raj Kumar Pulaparthi, Otto-von-Guericke University Magdeburg**
|
||||
and
|
||||
**TINF19C DHBW Stuttgart**
|
||||
This plugin was created as a group project in the class "Software Engineering".
|
||||
Later this plugin was developed as a sample tool that create vendor independent automation component, and included as a part of Master Thesis.
|
||||
***
|
||||
**TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION**
|
||||
The MIT License (MIT)
|
||||
Copyright © 2021 TINF19C DHBW Stuttgart
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files ('the Software'). to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sub license, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject the following conditions:
|
||||
|
||||
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFGRINGEMENT. IN NO EVENT SHALL THE AUTHOR OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF THE CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNENCTION WITH THE SOFTWARE OR THE USE OR THER DEALINGS IN THE SOFTWARE.
|
||||
***
|
||||
**© TINF19C DHBW Stuttgart 2021**
|
||||
This plugin uses third-party software for the convertions of IODD and GSDML. All rights are reserved by the corresponding copyright owner.
|
||||
***
|
||||
Author: Tobias Roth
|
||||
35
Home.md
35
Home.md
@ -1 +1,34 @@
|
||||
Welcome to the TINF20C_ModellingWizard_Devices wiki!
|
||||
# Welcome to the Modelling Wizard Wiki!
|
||||
|
||||
|
||||
|
||||
## About the Modelling Wizard
|
||||
|
||||
The Modelling Wizard for Devices is a plugin that can be used to create or modify devices and interfaces. It can also be used to import IODD and GSDML, CAEX 2.15 and CAEX 3.0 files that will be converted to the AMLX (.aml; .amlx; .xml;) package.
|
||||
|
||||
**Version 2.0.0.0**
|
||||
|
||||
## Goals
|
||||
|
||||
The general goal of this projects is to improve the already existing plugin, make it more user friendly and extend the amount of functionalities of the plugin. Precisely, there are following goals predefined:
|
||||
|
||||
* General revision of the user interface with the goal to make it more userfriendly
|
||||
* Support of CAEX 2.15 and CAEX 3.0 as output format
|
||||
* Input fields for all parameters required by the minimum rules for AML-DDs
|
||||
* Generic functionality for creating electrical, mechanical or hydraulical interfaces
|
||||
* Select and use the AML interface library for electrical interfaces
|
||||
* Support users with a detailed [User Manual](https://github.com/DekaAthlos/TINF19C-ModellingWizard/wiki/6.-User-Manual)
|
||||
|
||||
## Design and Software development by
|
||||
|
||||
* TINF17C DHBW Stuttgart
|
||||
* Master Student Raj Kumar Pulaparthi, Otto-von-Guericke University Magdeburg
|
||||
* TINF19C DHBW Stuttgart
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
177
MOD.001:-Graphical-User-Interface-(GUI).md
Normal file
177
MOD.001:-Graphical-User-Interface-(GUI).md
Normal file
@ -0,0 +1,177 @@
|
||||
#### Table of Contents
|
||||
* [1. Scope](#Scope)
|
||||
* [2. Abbreviations](#Abbreviations)
|
||||
* [3. Module Requirements](#ModuleRequirements)
|
||||
* [3.1 User View](#UserView)
|
||||
* [3.2 Requirements](#Requirements)
|
||||
* [3.3 Module Context](#ModuleContext)
|
||||
* [4. Analysis](#Analysis)
|
||||
* [5. Design](#Design)
|
||||
* [5.1 Risks](#Risks)
|
||||
* [6. Implementation](#Implementation)
|
||||
* [7. Module Tests](#ModuleTests)
|
||||
* [7.1 Module Testplan](#ModuleTestplan)
|
||||
* [7.2 Module Tesreport](#ModuleTestreport)
|
||||
* [8. Summary](#Summary)
|
||||
* [9. Appendix](#Appendix)
|
||||
* [9.1 References](#References)
|
||||
* [9.2 Code](#Code)
|
||||
|
||||
# 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 <a name="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](#Reference1)] 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 <a name="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 <a name="ModuleRequirements"/>
|
||||
## 3.1 User View<a name="UserView"/>
|
||||
This Module should provide the user the following features (only features that have been edited or implemented):
|
||||
|
||||
1. A separate window for the plugin
|
||||
2. A better graphical experience to the previous project [[2](#Reference2)]
|
||||
- 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...
|
||||
3. Link to the Manual
|
||||
4. Load Attributes of the Generic Data on startup
|
||||
5. Load new Standard-Libraries e.g. Electrical Connector Library
|
||||
|
||||
Optional:
|
||||
1. Auto-Update vendor and device name in Generic Data
|
||||
2. Additional visual changes
|
||||
|
||||
## 3.2 Requirements<a name="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](https://github.com/DekaAthlos/TINF19C-ModellingWizard/wiki/1.-Software-Requirements--Specification#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](#Reference2)] 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<a name="ModuleContext"/>
|
||||
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](#Reference5)], which will process the entered information.
|
||||
|
||||
# 4. Analysis <a name="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 <a name="Design"/>
|
||||
The graphical user interface from the previous project was divided into three tabs. (Figure 3, 4, 5)
|
||||
|
||||
|
||||
_Figure 3 Generic Data Tab_
|
||||
|
||||
|
||||
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 <a name="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 <a name="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](#Reference5)] to the GUI. Creating objects and modifying their properties creates automatically generated code, which is stored in the [DeviceDescription.Designer.cs](#Code) 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 <a name="ModuleTests"/>
|
||||
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](#Reference3)] and [[4](#Reference4)]
|
||||
|
||||
## 7.1 Module Testplan <a name="ModuleTestplan"/>
|
||||
| Test-ID | Requirement-ID | Test Specification (Description) |
|
||||
| ------------- |-------------|-------------|
|
||||
| 1 | [NF10](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/47) | This test verifies that the GUI uses the entire space |
|
||||
| 2 | [NF20, BUG40](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/14) | 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](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/48) | This test verifies that the application toolbar is directly visible in the interface |
|
||||
| 4 | [NF40](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/49) | This test verifies that the plugin opens in a proper size (not minimized) |
|
||||
| 5 | [NF60](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/51) | This test verifies that the attributes-tables aren't resizable |
|
||||
| 6 | [NF70](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/52) | This test verifies that the unnecessary grey field in the header tab has been removed |
|
||||
| 7 | [F10](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/55) | This test verifies that the link under help / manual forwards to the right manual |
|
||||
| 8 | [F20](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/56) | This test verifies that the "Add to AML-File" Column is removed and the functionality is still given |
|
||||
| 9 | [F60](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/59) | This test verifies that there are no empty rows (except the first one) possible in the class tables |
|
||||
| 10 | [F70](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/60) | This test verifies that the "delete"-button works properly |
|
||||
| 11 | [BUG10](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/5), [BUG20](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/6), [BUG30](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/7) | This test verifies that all errors coming from BUG10, BUG20 or BUG30 are handled by the program |
|
||||
| 12 | [BUG50](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/28) | This test verifies that the "Vendor Name"-label is not replace with the pathname of an opened file |
|
||||
| 13 | [BUG90](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/35) | This test verifies that the explorer opens constantly when the user tries to save a file |
|
||||
| 14 | [BUG100](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/36) | This test verifies that the libraries aren't deleted when the user cancels the process of loading new libraries |
|
||||
|
||||
## 7.2 Module Testreport <a name="ModuleTestreport"/>
|
||||
| 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 <a name="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 <a name="Appendix"/>
|
||||
|
||||
## 9.1 References <a name="References"/>
|
||||
[1] System Requirements Specification: https://github.com/DekaAthlos/TINF19C-ModellingWizard/wiki/1.-Software-Requirements--Specification<a name="Reference1"/>
|
||||
[2] Previous Project: https://github.com/Rajkumarpulaparthi/ModellingWizard<a name="Reference2"/>
|
||||
[3] System Test Plan: https://github.com/DekaAthlos/TINF19C-ModellingWizard/wiki/4.-Systemtestplan<a name="Reference3"/>
|
||||
[4] System Test Report: https://github.com/DekaAthlos/TINF19C-ModellingWizard/wiki/5.-Systemtestreport<a name="Reference4"/>
|
||||
[5] MOD.002: Controller: https://github.com/DekaAthlos/TINF19C-ModellingWizard/wiki/MOD.002:-Controller<a name="Reference5"/>
|
||||
|
||||
## 9.2 Code <a name="Code"/>
|
||||
The source code to this module can be found here: [DeviceDescription.Designer.cs](https://github.com/DekaAthlos/TINF19C-ModellingWizard/blob/master/SOURCE/DeviceDescription.Designer.cs)
|
||||
|
||||
Author: Phillip Tran
|
||||
167
MOD.002:-Controller.md
Normal file
167
MOD.002:-Controller.md
Normal file
@ -0,0 +1,167 @@
|
||||
#### Table of Contents
|
||||
* [1. Scope](#Scope)
|
||||
* [2. Abbreviations](#Abbreviations)
|
||||
* [3. Module Requirements](#ModuleRequirements)
|
||||
* [3.1 User View](#UserView)
|
||||
* [3.2 Requirements](#Requirements)
|
||||
* [3.3 Module Context](#ModuleContext)
|
||||
* [4. Analysis](#Analysis)
|
||||
* [5. Design](#Design)
|
||||
* [5.1 Risks](#Risks)
|
||||
* [6. Implementation](#Implementation)
|
||||
* [7. Module Tests](#ModuleTests)
|
||||
* [7.1 Module Testplan](#ModuleTestplan)
|
||||
* [7.2 Module Tesreport](#ModuleTestreport)
|
||||
* [8. Summary](#Summary)
|
||||
* [9. Appendix](#Appendix)
|
||||
* [9.1 References](#References)
|
||||
* [9.2 Code](#Code)
|
||||
|
||||
# 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 <a name="Scope"/>
|
||||
This module documentation explains the Controller in more detail. It shows how the plugin is working in the backend for example how files are imported/exported and which features are implemented. The individual functions [[1](#Reference1)] 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 <a name="Abbreviations"/>
|
||||
* **AMLX** - AML Package
|
||||
* **CAEX** - Computer Aided Engineering Exchange
|
||||
* **URI** - Uniform Resource Identifier
|
||||
|
||||
# 3. Module Requirements <a name="ModuleRequirements"/>
|
||||
## 3.1 User View<a name="UserView"/>
|
||||
This Module should provide the user the following features (only features that have been edited or implemented):
|
||||
|
||||
1. An opportunity to create an AMLX File
|
||||
* Add Role Classes
|
||||
* Add Interfaces
|
||||
* Add Attachments (like ComponentIcon or ManufacturerIcon)
|
||||
2. Export the created AMLX File
|
||||
3. Import other AMLX Files
|
||||
4. Load new Libraries
|
||||
|
||||
## 3.2 Requirements<a name="Requirements"/>
|
||||
The following requirements are implemented by this module: /NF100/, /F30/, /F40/, /F50/, /F80/, /BUG60/, /BUG70/, /BUG80/, /BUG110/, /BUG120/, /BUG130/, /BUG140/.
|
||||
|
||||
**/NF100/:** This requirement is made for future developers on this project. Since the previous project [[2](#Reference2)] 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.
|
||||
|
||||
**/F30/:** This requirement is about adding new interfaces from another type. It is already possible to add electrical interfaces to the AMLX file. Now it should be possible to add more interfaces of type hydraulic and mechanical. So the user can not only create electrical devices, but also create an AMLX file for hydraulic and mechanical components. This requirement has been implemented, but still cannot be applied concretely, because the libraries are missing. The libraries are important to load the correct attributes for the respective devices. Custom attributes should not be allowed, because this would violate the general rules for unique devices and interfaces.
|
||||
|
||||
**/F40/:** This requirement is about exporting the file in the correct CAEX version. In the previous project [[2](#Requirement2)] this was version 2.0. The latest version and the one to be implemented is 3.0. CAEX is a neutral data format for storing hierarchical object information. The versions differ in their standards. Version 3.0 is standardized in IEC 62424:2016 and DIN EN 62424:2017-12. This requirement has been implemented.
|
||||
|
||||
**/F50/:** This requirement is about mandatory parameter requirements. It is important that some attributes are entered before the AMLX file can be exported. The following parameters from the Generic Data are mandatory: Manufacturer, ManufacturerURI, Model, DeviceClass and ProductCode. These should be marked in red in the attribute table. In addition, it should be checked whether these fields have really been entered. If this is not the case, the user should be informed. This requirement was also implemented. It now checks whether the fields are filled in or not. If one of these fields is not filled in, an error message is returned to the user. It also checks if the ManufacturerURI is a URI.
|
||||
|
||||
**/F80/:** This requirement is about the [AML Component Checker](https://amlcc.tarakos.de/). The file is to be checked against the AMLX standards. It is checked whether the structure of the file fits and whether all libraries are present.
|
||||
|
||||
**/BUG60/:** This bug is triggered when there is no "Device Name" or "Vendor Name" set, and you try to save the file. The explorer opens and after a location is chosen the program informs the user that the file misses data and can not be saved. This should be checked earlier, before opening the save dialog. This bug has been fixed.
|
||||
It now checks if the "Device Name" and the "Vendor Name" is not null before opening the save dialog.
|
||||
|
||||
**/BUG70/:** This bug is triggered when trying to open a file. If the user opens a new file but cancels the process, the Plugin-Interface gets cleared, and it throws an error. The error is generated because, it checks for a path and tries to pass it to a function, but if you cancel the process the path is null. This bug has been fixed as well. Now it is possible to cancel the opening process without getting a cleared Interface and without throwing an error.
|
||||
|
||||
**/BUG80/:** This bug is triggered when trying to overwrite an old already saved file. If the user opens an old file and changes nothing, then tries to save the file, a new file is generated. You have no option to overwrite the file, because it always appends an .amlx to the file name. The bug has been fixed, and it is now possible to overwrite files. If an .amlx appendix has already been attached, then no new .amlx appendix is attached.
|
||||
|
||||
**/BUG110/:** This bug is triggered when trying to save a file. If the user clicks on save and cancels the process, then tries to save it again it saves an empty file. This bug has been fixed.
|
||||
|
||||
**/BUG120/:** This bug is triggered when trying to save a file. If the user opens an amlx file in the directory of the file a temporary file with .aml appendix is created. After saving the file a new amlx file is created and the temporary aml file is deleted. The problem is that the logic behind this deletes all files in the directory not ending with .amlx instead of just deleting the temporary .aml file.
|
||||
|
||||
**/BUG130/:** This bug is about the role class libraries. If the user adds multiple Role Class Libraries and saves the file, closes it and opens it again, only the first and the last library is shown. Also all Attributes have the same Attributes table of the first library.
|
||||
|
||||
|
||||
_Figure 1_ Save file
|
||||
|
||||
|
||||
_Figure 2_ After opening a file
|
||||
|
||||
## 3.3 Module Context<a name="ModuleContext"/>
|
||||
This module provides the backend of the Plugin. It is responsible for ensuring that the data in the graphical user interface [[5](#Reference5)] is all correct and also that all the required data is in place. The data entered is then processed by the controller and put into the correct structure. If any information for creating an AMLX file is missing, the user will be informed about it via a specific error message. Images are attached as an external file in the AMLX container. Interfaces, role class and all associated libraries are stored in the root-aml file. Afterwards the file can be exported. The controller is also responsible for allowing the import of AMLX files. If this is not possible the user will be informed.
|
||||
|
||||
# 4. Analysis <a name="Analysis"/>
|
||||
The main task of the controller is the import and export of an AMLX file. The data for this is transmitted from the graphical user interface to the controller. The controller must then process the data and then create a root-aml file. When exporting, the following things must be taken into consideration: The libraries must be exported, all data must be exported, so that there is no data loss and the data must also be validated. When importing, it is important to be able to map the majority of all files. It is important that the libraries of a file are recognized and that it is included in the correct tab so that it can be processed correctly. In addition, there must be no loss of data, which means that images and all interfaces must also be imported correctly. If there are problems with the export, the user must be informed. This is usually done via an error message from the user interface.
|
||||
|
||||
# 5. Design <a name="Design"/>
|
||||
There are 3 important functions of the module: Importing a file, exporting a file and validating the data from the graphical user interface.
|
||||
|
||||
Validate data: The Validate Data must verify that all the data entered is correct. Thus, fields that are mandatory must logically be filled in. If they are not, a corresponding error message must be issued. In addition, it must be checked whether fields also have the correct data types. For example, a URI must have a certain syntax to be considered valid. Attributes that are not present, i.e. that were additionally entered by the user, may not be transferred, because the libraries are responsible for providing the attributes to the RoleClasses / Interfaces. If all data is correct and complete, the file can be exported.
|
||||
|
||||
Export: When exporting, all files are brought into the CAEX 3.0 structure by the program and the libraries are also entered into the root-aml file. Attachments, such as ComponentIcons and ManufacturerIcons are then added to the container with reference to the image.Once the export is complete, a confirmation message will appear.
|
||||
|
||||
Import: The import loads the file with the interfaces and libraries. The file is scanned for data and how to classify it. For example, the BaseClass is loaded into the GenericData tab, the interfaces into the Interfaces tab, and the attachments into the Attachments tab. Again, the data is checked to see if it conforms to the standards. If there are complications during the import, an error message is displayed.
|
||||
|
||||
## 5.1 Risks <a name="Risks"/>
|
||||
The export is based on the libraries of CAEX. This decides the standard of the file and its structure. If the CAEX version is no longer maintained and gets outdated, there could be complications with the export. This danger is currently still quite small, since the newest standard is the version 3.0 and it was also task to implement this. However, if there are problems with importing CAEX 3.0 files in future AutomationML versions, the plugin would be unusable.
|
||||
|
||||
Libraries are very important for import and export. If these are not available, it can happen that files are not loaded correctly, or they are even no longer usable. In addition, it can happen that devices cannot be created because certain libraries are missing.
|
||||
|
||||
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.
|
||||
|
||||
# 6. Implementation <a name="Implementation"/>
|
||||
The controller module contains a lot of different functions that allow to execute certain actions on triggered events from the graphical user interface. However, these are not that important, so they will not be discussed in detail. The most important functions are those that represent the main functions.
|
||||
|
||||
Data validation:
|
||||
* saveToolStripMenuItem_Click(): The most important data validation function is the saveToolStripMenuItem_Click() function. This validates the data and checks if all necessary data is present. If they are not present, a corresponding error message is output. If all data is correct, the data is passed to the export function.
|
||||
|
||||
Export:
|
||||
* CreateDevice(): This function is responsible for converting the data into the correct data structure. In this function also for example URIs are converted into the correct data formats and images are attached into the container. The export file starts first of all to read the libraries from the data and to add them to the file. Then the generic data is inserted into the file. The name of the file is also taken from the generic data (Device Name & Vendor Name). Afterwards all interfaces, which were integrated, are attached to the file. If necessary, further libraries are included in the file. Finally, the other attachments are appended. When the file is finished, it is saved in the specified path as an .amlx file.
|
||||
|
||||
Import:
|
||||
* openToolStripMenuItem_Click(): This function is responsible for importing files. First of all, it checks if the file has the correct structure or if any data is corrupt. If this is the case, a corresponding error message is returned. If the data is in the correct structure, the information is read from the file. These are arranged directly by the function into the three tabs. This means that libraries are loaded and can be seen on the right in the graphical interface, the base data in the generic data tab, the interfaces in the interfaces tab and the attachments in the attachments tab.
|
||||
|
||||
# 7. Module Tests <a name="ModuleTests"/>
|
||||
In this section all requirements will be tested separately on their functionality.
|
||||
|
||||
Further and more detailed Tests can be found here: [[3](#Reference3)] and [[4](#Reference4)]
|
||||
|
||||
## 7.1 Module Testplan <a name="ModuleTestplan"/>
|
||||
| Test-ID | Requirement-ID | Test Specification (Description) |
|
||||
| ------------- |-------------|-------------|
|
||||
| 1 | [F30](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/57) | This test verifies that it is possible to add Mechanical and Hydraulic Interfaces |
|
||||
| 2 | [F40](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/58) | This test verifies that the CAEX output version of the exported AMLX-file is 3.0 |
|
||||
| 3 | [F50](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/12) | This test verifies that the mandatory attributes are highlighted and checked before exporting a file |
|
||||
| 4 | [F80](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/13) | This test verifies if it can pass the [AMLX Component Checker](https://amlcc.tarakos.de/) |
|
||||
| 5 | [BUG60](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/30) | This test verifies that the "Device Name" and "Vendor Name" is given before the save dialog opens |
|
||||
| 6 | [BUG70](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/31) | This test verifies that the current file is only cleared when the whole opening process has been finished |
|
||||
| 7 | [BUG80](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/34) | This test verifies that it is possible to overwrite files |
|
||||
| 8 | [BUG110](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/44) | This test verifies that it doesn't save an empty file after canceling the first save process |
|
||||
| 9 | [BUG120](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/43) | This test verifies that it doesn't clear the content of the directory on save |
|
||||
| 10 | [BUG130](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/46) | This test verifies if the added Role Class Libraries are all added to the AMLX file |
|
||||
|
||||
## 7.2 Module Testreport <a name="ModuleTestreport"/>
|
||||
| Test-ID | PASS / FAIL | When failed: Observation | Tester |
|
||||
| ------------- |-------------|-------------|-------------|
|
||||
| 1 | PASS | - | S. Jess |
|
||||
| 2 | PASS | - | S. Jess |
|
||||
| 3 | PASS | - | P. Tran |
|
||||
| 4 | FAIL | [LINK TO ISSUE](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/13) | P. Tran |
|
||||
| 5 | PASS | - | P. Tran |
|
||||
| 6 | PASS | - | P. Tran |
|
||||
| 7 | PASS | - | P. Tran |
|
||||
| 8 | PASS | - | P. Tran |
|
||||
| 9 | PASS | - | S. Jess |
|
||||
| 10 | FAIL | [LINK TO ISSUE](https://github.com/DekaAthlos/TINF19C-ModellingWizard/issues/46) | J. Schmidt |
|
||||
|
||||
# 8. Summary <a name="Summary"/>
|
||||
Most of the module requirements have been implemented successfully. The new CAEX version 3.0 has been implemented, so it is possible to export the AMLX also in this version. Many bugs were found here as well, which were also fixed. However, not all requirements were implemented, because the bug was not found despite debugging for days. The solutions are noted in the issue (F80). Also the import of foreign AMLX files, which have a different structure than the export structure of this plugin, works to some extent. Further enhancements were also implemented in this module to improve the usability of the program.
|
||||
|
||||
# 9. Appendix <a name="Appendix"/>
|
||||
|
||||
## 9.1 References <a name="References"/>
|
||||
[1] System Requirements Specification: https://github.com/DekaAthlos/TINF19C-ModellingWizard/wiki/1.-Software-Requirements--Specification<a name="Reference1"/>
|
||||
[2] Previous Project: https://github.com/Rajkumarpulaparthi/ModellingWizard<a name="Reference2"/>
|
||||
[3] System Test Plan: https://github.com/DekaAthlos/TINF19C-ModellingWizard/wiki/4.-Systemtestplan<a name="Reference3"/>
|
||||
[4] System Test Report: https://github.com/DekaAthlos/TINF19C-ModellingWizard/wiki/5.-Systemtestreport<a name="Reference4"/>
|
||||
[5] MOD.001: GUI: https://github.com/DekaAthlos/TINF19C-ModellingWizard/wiki/MOD.001:-Graphical-User-Interface-(GUI)<a name="Reference5"/>
|
||||
|
||||
## 9.2 Code <a name="Code"/>
|
||||
The source code to this module can be found here: [DeviceDescription.cs](https://github.com/DekaAthlos/TINF19C-ModellingWizard/blob/master/SOURCE/DeviceDescription.cs) and [MWData.cs](https://github.com/DekaAthlos/TINF19C-ModellingWizard/blob/master/SOURCE/MWData.cs)
|
||||
|
||||
Author: Phillip Tran
|
||||
10
_Sidebar.md
Normal file
10
_Sidebar.md
Normal file
@ -0,0 +1,10 @@
|
||||
|
||||
* [Home](https://github.com/DekaAthlos/TINF19C-ModellingWizard/wiki)
|
||||
* [1. Software Requirements Specification](https://github.com/DekaAthlos/TINF19C-ModellingWizard/wiki/1.-Software-Requirements--Specification)
|
||||
* [2. Software Architecture Specification](https://github.com/DekaAthlos/TINF19C-ModellingWizard/wiki/2.-Software-Architecture-Specification)
|
||||
* [3. Module Documentation](https://github.com/DekaAthlos/TINF19C-ModellingWizard/wiki/MOD.001:-Graphical-User-Interface-(GUI))
|
||||
* [3.1 MOD.001: Graphical User Interface (GUI)](https://github.com/DekaAthlos/TINF19C-ModellingWizard/wiki/MOD.001:-Graphical-User-Interface-(GUI))
|
||||
* [3.2 MOD.002: Controller](https://github.com/DekaAthlos/TINF19C-ModellingWizard/wiki/MOD.002:-Controller)
|
||||
* [4. Systemtestplan](https://github.com/DekaAthlos/TINF19C-ModellingWizard/wiki/4.-Systemtestplan)
|
||||
* [5. Systemtestreport](https://github.com/DekaAthlos/TINF19C-ModellingWizard/wiki/5.-Systemtestreport)
|
||||
* [6. User Manual](https://github.com/DekaAthlos/TINF19C-ModellingWizard/wiki/6.-User-Manual)
|
||||
Loading…
x
Reference in New Issue
Block a user