Updated 2. Software Architecture Specification (markdown)
parent
6c9f6b4e90
commit
f4fb1c79e0
@ -104,7 +104,7 @@ It must be ensured that it is recognisable where and from whom the programme ori
|
|||||||
|
|
||||||
The programme and its code will be available on GitHub on a public repository. This means that anyone can access the programme at any time.
|
The programme and its code will be available on GitHub on a public repository. This means that anyone can access the programme at any time.
|
||||||
|
|
||||||
#### 2.3.1.5 Interoperability<a name="S10"/>
|
#### 2.3.1.6 Interoperability<a name="S10"/>
|
||||||
|
|
||||||
This is important because it must be ensured that users are not firmly bound to this standard or programme. After all, the main users will come from the industry and therefore place a lot of value on a uniform standard. More information can be found in the [Technical Concept](#TC).
|
This is important because it must be ensured that users are not firmly bound to this standard or programme. After all, the main users will come from the industry and therefore place a lot of value on a uniform standard. More information can be found in the [Technical Concept](#TC).
|
||||||
|
|
||||||
@ -116,11 +116,11 @@ These cannnot be observed at execution time of the system.
|
|||||||
|
|
||||||
Since the programme is open source and publicly viewable, it can be extended by anyone. This is important if any use cases arise in the future.
|
Since the programme is open source and publicly viewable, it can be extended by anyone. This is important if any use cases arise in the future.
|
||||||
|
|
||||||
#### 2.3.1.1 Portability and reusability<a name="S13"/>
|
#### 2.3.1.2 Portability and reusability<a name="S13"/>
|
||||||
|
|
||||||
Attention is paid to transferability to later projects, through the involvement and formation of libraries and the like, but the application case is very specific and difficult to transfer to other or new projects. Therefore not so important.
|
Attention is paid to transferability to later projects, through the involvement and formation of libraries and the like, but the application case is very specific and difficult to transfer to other or new projects. Therefore not so important.
|
||||||
|
|
||||||
#### 2.3.1.1 Testability<a name="S14"/>
|
#### 2.3.1.3 Testability<a name="S14"/>
|
||||||
|
|
||||||
This is probably the second most important point after usability, care must be taken to ensure that the code is testable. On the one hand directly in the code, but also testing the binary is important. For this purpose, various test cases are described and worked through on the [Systemtestplan](https://github.com/H4CK3R-01/TINF20C_ModellingWizard_Devices/wiki/4.-Systemtestplan) page. Also check the [Systemtestreport](https://github.com/H4CK3R-01/TINF20C_ModellingWizard_Devices/wiki/5.-Systemtestreport) to learn more about the test results. The AML Component Checker should be validating all created AML files. Thereby, to keep quality high, errors that cause undesirable behavior or even fatal errors must be eliminated.
|
This is probably the second most important point after usability, care must be taken to ensure that the code is testable. On the one hand directly in the code, but also testing the binary is important. For this purpose, various test cases are described and worked through on the [Systemtestplan](https://github.com/H4CK3R-01/TINF20C_ModellingWizard_Devices/wiki/4.-Systemtestplan) page. Also check the [Systemtestreport](https://github.com/H4CK3R-01/TINF20C_ModellingWizard_Devices/wiki/5.-Systemtestreport) to learn more about the test results. The AML Component Checker should be validating all created AML files. Thereby, to keep quality high, errors that cause undesirable behavior or even fatal errors must be eliminated.
|
||||||
|
|
||||||
|
Loading…
x
Reference in New Issue
Block a user