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

Insert SAS File

Florian Kellermann 2021-11-05 09:07:21 +01:00
parent 4a277ffbd1
commit 2455a62cd6
1 changed files with 124 additions and 138 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

262
2.-Software-Architecture-Specification.md

@ -33,223 +33,209 @@
| 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 |
| V0.1 | 26.10.2020 | Lukas Ernst / Florian Kellermann | created |
***
1.
# Introduction
# 1. Introduction <a name="I"/>
The aim of this project is to program a standalone application for Windows based on a plugin for the AutomationML editor. The graphical user interface should be improved and support for the modelling of sensors according to IEC 60947-5 should be offered. Furthermore, it should be possible to create devices, add device interfaces and file attachments.
The 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.
## Glosar
## 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.
**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
**C#** High level language often used for programming
# 2. System Overview <a name="S"/>
## 2.1 System Environment <a name="S1"/>
**GUI** Graphical User Interface
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.
**.NET** The .NET Framework is a software development and runtime environment developed by Microsoft for Microsoft Windows.
Among others the IODD and GSD converter are used as neighboring systems.
## 2.2 Software Environment <a name="S2"/>
1.
# System Overview
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.
1.
## System Environment
## 2.3 Quality Goals <a name="S3"/>
The standalone application can only be accessed via Windows, as this operating system is used as the platform. The application can be installed and the graphical user interface can be used via this platform. In contrast to the plug-in, the editor no longer has to be used.
Among others the IODD and GSD converter are used as neighbouring systems.
1.
## Software Environment
For the standalone application to work, you need at least version 4.5 of the .Net framework, as C# was developed using it. This version of the framework is available from the &quot;Windows Vista&quot; operating system variant. You do not need any further software, as this is a standalone application.
1.
## Quality Goals
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)**
1.
### Usability
### 2.3.2 Bug fixing <a name="S5"/>
Usability is the most important aspect of the project besides the standalone application. To this end, a graphical user interface was created that allows the user to use it as easily as possible. Intuitive operation is very important, but an appealing design is also necessary to create the best possible user experience, because this is the only way the application can successfully simplify work steps. (more information in the usability concept)
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.
1.
### Bug fixing
# 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.
Another milestone to keep quality high is the elimination of errors that cause undesired behaviour or even fatal errors.
## 3.1 Usability concept <a name="QC1"/>
1.
# Quality Concept
**The criteria for good usability are:**
This part of the software architecture specification explains and breaks down the problems that usually arise during the further development of software. This includes concepts for dealing with these problems and thus improving the quality of the final product.
**Color scheme**:
A good coloration can be created by an attractive choice of colors and their coordinated contrasts.
1.
## Usability Concept
**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.
The criteria for good usability are:
**Intuitiveness:**
Intuitiveness is a key component of good usability which means that the user understands the plugin without a long training period.
**Intuitiveness** : Intuitiveness is a key component of good usability which means that the user understands the application without a long training period.
**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.
**Design** : When designing the application, an appealing layout is important. It should be clearly recognisable which function is hidden behind which visual elements and how the user can navigate through the app.
**Implementation guideline:**
**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.
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:
**Color scheme** : A good coloration can be created by an attractive choice of colors and their coordinated contrasts.
* A consistent color palette should be used where elements with the same events have the same colors for recognition.
Implementation guideline:
* 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.
After conducting the usability test, guidelines were developed on the basis of which the GUI improvements will be made. Therefore, the GUI must meet the following guidelines:
* The design and layout should be self-explanatory and reinforce the previous point in order to allow an intuitive use.
- A consistent colour palette should be used, where elements with the same events have the same colours for recognition. Matte and colour-coordinated palettes should be used here.
- Contrasts, borders as well as roundings should be used to emphasise inputs or interaction fields. Blank areas should be created to give an attractive and uncluttered design. Another advantage is that the user will then find his way around more easily. The layout of the GUI should say goodbye to the style of the AML editor, as this is no longer up to date.
- The design and layout should be self-explanatory and reinforce the previous point to allow 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 guidelines developed, the graphic interface is adapted and optimised. Functionality is very important, but should not negatively affect usability. Nevertheless, compromises have to be made in terms of feasibility, as the basic concept of AutomationML should be presupposed.
**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.**
1.
## Code Quality
## 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 may come from different developers. For this reason, we have made it our mission to address and improve the problem of code quality. In order to maintain a certain standard, we have agreed on certain conventions:
Code quality is one of the most important aspects when it comes to software that is being developed further and 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.
- Commenting on sections of code that are not clearly understandable in order to explain the implemented idea to others
- Programming paradigms and programming principles that make the code easy to understand
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.
This means that the code is indented uniformly to improve readability and comprehension. Furthermore, the programme is divided into modules that can then be imported and used. Otherwise you run the risk of having to write duplicate code. In addition, it is our responsibility to write documentation that records which ideas have been implemented and how, so that the existing functions are easier to understand for future developments and can be built upon.
1.
# Architectural Concept
# 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).
![grafik](https://user-images.githubusercontent.com/72601083/98341992-075c7f00-2010-11eb-8ca8-804dd3b36d0b.png)
_Figure 1 – MVC Architecture [2]_
1.
## Architectural Model
![](RackMultipart20211105-4-1334yiq_html_e124a15acc23e9b1.png)The application was designed and developed according to a Model-View-Control (MVC) architecture pattern that resembles a cycle. The user can use the plugin by accessing the GUI. However, the actions he performs in the GUI are not processed in the GUI but in the controller and its subclasses. The controller executes the changes in the background, these are also called manipulations. Afterwards, the changes are updated on the user interface so that the user thinks that the changes were made directly in the GUI (cf. Figure 1).
Almost all the logic is contained in the controller, which thus forms the 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.
The controller is the main control unit. It is responsible for communicating with the user interface and the external systems that are added for conversions. This interface is the heart of the entire application and is responsible for the functionalities, but also for the integration of additional functions such as saving or loading AMLX packages from the AutomationML Engine. Thus, the concept builds on that of the plug-in, making it easier to adapt functions and ideas.
![Screenshot 2020-11-10 100640](https://user-images.githubusercontent.com/72601083/98653045-cc728800-233c-11eb-94a1-b395c25000c3.png)
_Figure 2 - Logic of the plugin_
![](RackMultipart20211105-4-1334yiq_html_c572f91cfdd3da55.png)
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.
The architecture design in Figure 2 is the design created by the first development team when the application was first implemented. However, as the project developed further, the architecture became more and more unstructured and complex. As a result, MVC is no longer used as intended. This was further complicated by the use of a Microsoft Forms application.
# 5. System Design <a name="SD"/>
1.
# System Design
![Klassendiagramm neu](https://user-images.githubusercontent.com/72601083/116784736-26efd400-aa96-11eb-97e3-7c3f26713e48.png)
_Figure 3 - System class design_
![](RackMultipart20211105-4-1334yiq_html_34bab3433846f0d9.png)
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.
This figure is showing the complete software design.
![MVC Modell](https://user-images.githubusercontent.com/72601083/117198636-8da02500-ade9-11eb-9f97-2496133f2c78.png)
![](RackMultipart20211105-4-1334yiq_html_6cedf9e7fcc19487.png)
_Figure 4 - MVC pattern_
Still the MVC pattern is a small part of the whole system design. In this case the InputFromUser is obviously the user input. DeviceDesc (standing for Device Description), due to its two different C# program files, once maps the GUI and once the controller. DataMW is the class that takes care of the data management and creates an object of the type MWData, which can then export, store and process through the controller.
| Classname| Storage location |
| **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) |
| About | SOURCE/About.xaml.xs |
| AnimationClass | SOURCE/Animationclass.cs |
| AutomationMLDataTables | SOURCE/AutomationMLDataTables.cs |
| ClassOfListFromReferenceFile | SOURCE/ClassOfListsFromReferencefile.cs |
| DeviceDescription | GUI: SOURCE/DeviceDescription.Designer.csLogic: SOURCE/DeviceDescription.cs |
| ModellingWizard | SOURCE/ModellingWizard.xaml.cs |
| MWController | SOURCE/MWController.cs |
| MWData | SOURCE/MWData.cs |
| MWDevice | SOURCE/MWDevice.cs |
| Resources | SOURCE/Resources/ |
| SearchAMLComponentFile | SOURCE/SearchAMLComponentFile.cs |
| SearchAMLLibraryFile | SOURCE/SearchAMLLibraryFile.cs |
1.
# Subsystem specification
## MOD.001: Graphical User Interface (GUI)
# 6. Subsystem specification <a name="SS"/>
| **\&lt;MOD.001\&gt;** | **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 taking input from the user and sending it to the controller by calling event functions. |
| Interfaces: | --- |
| External Data: | --- |
| Storage Location: | SOURCE/DeviceDescription.Designer.cs |
| Modul documentation: | MOD.001: Graphical User Interface (GUI) |
## 6.1 MOD.001: Graphical User Interface (GUI) <a name="SS1"/>
## MOD.002 Controller
| <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)) |
| **\&lt;MOD.002\&gt;** | **Controller** |
| --- | --- |
| System requirements covered: | /NF100/, /F30/, /F40/, /F50/, /F80/, /BUG60/, /BUG70/, /BUG80/, /BUG110/, /BUG120/, /BUG130/ |
| Services: | Logic distribution is handled by the controller. It is reacting to the events triggered by the GUI and takes care of creating the respective objects. Also the input and output functions are implemented in the controller. |
| Interfaces: | Interface for IODD to AutomationML, Interface for GSD to AutomationML and Interface of AMLX packages. For export/import of amlx files there is another class referenced: SOURCE/MWData.cs |
| External Data: | --- |
| Storage location: | SOURCE/DeviceDescription.cs |
| Modul documentation: | MOD.002: Controller |
## 6.2 MOD.002: Controller<a name="SS2"/>
1.
# Technical Concepts
| <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) |
## Persistence
By using a package format, the system is persistent. In the plugin and later also in the stand-alone application AMLX packages can be edited and created. Since AutomationML is using the same format, it is possible to open these AMLX packages and use them in the editor. This functionality shall be kept when moving to a stand-alone application.
# 7. Technical Concepts <a name="TC"/>
## User Interface
## 7.1 Persistence <a name="TC1"/>
This is the chapter with the biggest changes in the project. The Graphical User Interface (or so-called GUI) is the connector between user and software. Like that the user can operate the AutomationML editor using the plugin and later the stand-alone application. It is crucial that the GUI is as simple as possible so that even a person with limited professional knowledge can handle the program and understand most of its functionality.
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.
## Ergonomics
## 7.2 User Interface <a name="TC2"/>
As said in it is crucial for an ergonomic user interface to be intuitive, meaning that even a not so experienced user is able to understand and control most of the functionality of the program quiet easily. To allow this there are a few simple rules existent that are making sure the user finds the interface appealing and can navigate through it with ease.
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.
## Communication with other IT-Systems
## 7.3 Ergonomics <a name="TC3"/>
Some of the AutomationML editor plugin use cases require external converter systems to be integrated. Two of these for example being the IODD and the GSD converter for AutomationML. These plugins enable for users to convert IODD and GSD files into AML type files for using the functionalities of the plugin. This must also be considered when changing to a standalone program.
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.
## Deployment
## 7.4 Communication with other IT-Systems <a name="TC4"/>
At this point it is a plugin that must be used in combination with AutomationML. The plugin must be installed in the editor by using the plugin manager of the software to install the .dll file. During the process of the project the program shall be made usable as a standalone software application so there is no longer the need to use the AutomationML plugin manager.
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.
## Data validation
## 7.5 Deployment <a name="TC5"/>
All data checks are running in the background, invisible for the user. The controller is checking for missing information and incorrect entries, that must be specified as mandatory information.
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.
## Exception handling
## 7.6 Data Validation <a name="TC6"/>
Exception handling is necessary to prevent errors caused by the user while using the program. So called &quot;try-catch&quot; blocks are used to &#39;catch&#39; these and prevent unwanted or incorrect behavior of the software.
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.
## Internationalization
## 7.7 Exception Handling <a name="TC7"/>
The whole system layout can be used for international purposes since the user manual and over all GUI is written in English and English is defined to be the international traffic language. On the other hand, there is no way to change the language so English is a mandatory knowledge for using the program.
The exception handling must be done to prevent errors caused by the user while using the GUI. Therefore &quot;try-catch&quot; blocks are used to prevent unwanted behavior of the program.
## Testability
## 7.8 Internationalization <a name="TC8"/>
View the System Test Plan to get further information on how the program can be tested. Also check the System Test Reports to learn more about the test results. The AML Component Checker should be validating all created AML files.
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.
## Availability
## 7.9 Testability <a name="TC9"/>
The program is only available on Github and furthermore Github is the only possible source.
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"/>