Quality Requirements

In this chapter, the quality requirement presented in Quality Requirements are evaluated. Besides, other quality aspects are also introduced an evaluated.

raml2agl tool fulfills Transparency (REQ_001) by maintaining a clear mapping between the Service Class’s and the APP Class’s methods. Hence creating as well an Object Oriented interface that abstracts the Unix Web Socket communication and thus fulfilling Abstraction (REQ_002) as well.

The adoption of RAML as the interface modeling language speaks for the fulfillment Standardization (REQ_003). Moreover, raml2agl uses broadly adopted tools, such as Jinja2. Also, raml2agl follows standard coding styles such as the Kernel’s coding style and PEP8. Both broadly adopted tools and the use of standard coding styles, also contribute towards Standardization (REQ_003) fulfillment.

raml2agl allows the user to set the output directories and decide what components to generate. Additionally, by supporting RAML raml2agl enables the user to generate a wide variety of interfaces. These are two already-implemented customization mechanisms for the proposed MDD approach. Therefore fulfilling Flexibility (REQ_004).

As for Testability and Debugability (REQ_005), generates intermediate probing points with well-defined interfaces which allows the user to develop unit testing for the system’s main components. For instance, the AGL service developer can create unit testing for the Service Class, which would test the actual AGL Service’s purpose. Similarly, the AGL Service developer could interact with the RESTful interface directly using tools like Postman [12]. This will test a different aspect of the components interaction, which is the marshaling and unmarshaling of the JSON in the AGL Service side, as well as the mapping with the Service Class’s methods. In the APP Service side, a similar testing can be done to verify the marshaling and unmarshaling of the methods’ parameters into JSON.

By defining a standard interface also enables a decoupled development process, where AGL Service and AGL Application can be developed in parallel. Moreover, mocking [10] mechanisms can be easily implemented using the interface’s definition. For instance, the APP Service interface could be mocked using Google Test [24], thus enabling testing at AGL application level without the need of running in the actual system, which at the same time enables faster development.

Interestingly, the mocking and components unit tests can be also automatically generated out of the RAML model, also contributing towards Flexibility (REQ_004). Moreover, by having a deterministic mapping between the RAML model and the components’ behavior correctness can be verified once and guaranteed for everyone [33], thus minimizing the testing effort. Note that correct memory management is also considered part of the code’s behavior correctness as it’s one of the system’s constraints (TC3) as specified in Constraints. For instance, all the developed unit testing could be tested under memory management checking tools such as valgrind to validate its correctness. By doing so, the memory management correctness is verified without any more testing effort since the same unit tests are run, but on top of valgrind. In fact, this was done while testing raml2agl’s behavior.

[10]	Mock object. URL: https://en.wikipedia.org/wiki/Mock_object.

[12]	Postman. URL: https://www.getpostman.com/.

[24]	Google. Googletest. URL: https://github.com/google/googletest.

[33]	Collin O’Halloran. Model base code verification. Formal Methods and Software Engineering: 5th International Conference on Formal Engineering Methods, ICFEM 2003, Singapore, November 5-7, 2003, Proceedings, 2003.