Sistema de protección contra incendios .1 Generalidades

As predicted in the introduction, this section compares the service and test specification languages from section 5.1 and the proposed novel STD from section 5.2 to demonstrate their relative assets and weaknesses. Considering that, diverse requirements have been stated. To evaluate the specification languages with regard to the requirements, a rating will be applied to them in the upcoming Table 5.10 by using a three-level scale. The scale contains the following ratings:

• (+): the specification language fulfils the requirement completley.

• (o): the specification language fulfils only basic aspects of the requirement. • (-): the specification language does not fulfil the requirement.

The requirements on a novel specification language have been derived based on their potential application within the proposed TCF (see section 4.3). A major advantage of the TCF is that only an instance of the specification language has to be created manually. Based on this instance, a behaviour model is automatically built, test cases are automatically derived and generated and subsequently executed against the SUT.

5.3 Comparison of Service and Test Specification Languages

Therefore, high demands are placed on the specification language as it presents the foundation of the quality of testing.

The requirements stated in section 5.2 are as follows:

• Machine-readable and parsable by a machine.

• Usability by test developers who specify the considered value-added services. • Traceability of use cases to enable an easy transition from standard use case

description.

• Preciseness to avoid ambiguity within the specification.

• Support for functional specification (e.g. flow descriptions or rather use case

descriptions).

• Reusability aspects to simplify and fasten the definition process.

• Test Data integration and parameterisation (e.g. parameterise variables).

• SUT interface description to already specify the addressability of the value-added

service in order to achieve a fully automated process.

• Extension support to allow further changes and enhancements. • Compliance to value-added telecommunication services.

Table 5.10: Comparison of specification languages Characteristics Specification Language

Structured Use Case Models

RUCM UTML Proposed STD

Readability/Parsability + - + +

Usability o + + +

Traceability of use cases + + - +

Preciseness o o + +

Functional specification + + + +

Reusability aspects - - - +

Test Data - - + +

SUT interface description - - + +

Support for extensions - o o +

Compliance to services - - + +

Readability and parability of the specification language is best supported by UTML, the

Structured Use Case Models and the proposed STD as they rely on formal models, descriptions or metamodels. RUCM is natural-language-based and therefore not easily parsable. The aspect of Usability is fulfiled by RUCM, UTML and the proposed STD because the procedure within the compilation phase is well-defined. The Traceability of

use cases is supported by all approaches that are actually based on use case design. This

is the case in Structured Use Case Models, RUCM and the proposed STD. Regarding the

Preciseness, the Structured Use Case Models and RUCM have weaknesses as they are

either natural language-based or allow loose determinations. Every specification language is meant to provide a Functional specification and therefore this requirement is fulfilled by all four languages. A unique position feature of the proposed STD emerges regarding the aspect of Reusability, which is not supported by any other specification language. The

Test Data integration is supported by UTML as it is a typical test specification language.

5.4 Conclusion

parameterised within the approach. The same argument can be emphasised regarding the

SUT interface description which is also not supported by the Structured Use Case Models

approach and RUCM. The Support for extensions is not specified by RUCM and UTML, but it should be possible. The Structured Use Case Model is based on a defined metamodel and does not allow any further extensions. Finally, the Compliance to

services, especially value-added telecommunication services, is fulfilled by UTML and

the proposed STD. Both support the integration of SIP.

5.4 Conclusion

Different specification languages have been presented within this chapter in order to compare them against the proposed novel STD. The STD has been described with all its features, starting from the simple way it is compiled, its ability to be parsed and interpreted, its integration of reusable modules (CIs) and of course, its property to allow traceability of use cases. The language has been compared to other specification languages by means of stated requirements. It has been identified that all requirements are fulfilled by the novel STD.

Up to now, a solid basis has been defined to implement the TCF. However, new essential questions arise, for instance, regarding the structure and definition of the reusable test modules. Also the relationships between the CIs within an STD instance and the reusable test modules has to be clarified. Furthermore, an algorithm needs to be introduced which builds the formal behaviour models based on an STD instance. All of these questions will be discussed in the upcoming chapter.

6 Reusable Test Modules and Behaviour

Model Generation

“In most engineering disciplines, systems are designed by composing already existing components that might have been used in other systems” (Sommerville, 2012). In this chapter, this statement will be taken up for testing, or to put it more precisely, a novel concept of reusable test modules will be introduced. These reusable test modules are part of the proposed TCF and are used together with the STD in order to build behaviour models from which test cases can be derived later on (see section 4.3). The following Figure 6.1 illustrates a simplified flow chart based on the proposed TCF (see Figure 4.5) showing the generation of behaviour models based on STD instances.

Figure 6.1: Generation of Behaviour Models based on STD and reusable test modules

The main concern of this chapter is the introduction of the composition algorithm in the Automatic Composition Engine (ACE) which combines instances of the reusable test modules and generates behaviour models. The application of such an algorithm, however,

Start

Service Test

Description Behaviour Models

End Automatic Compositon Engine Test Modules Repository Test Data Pool

6 Reusable Test Modules and Behaviour Model Generation

requires a deep knowledge of its inputs (see Figure 6.1) such as the Service Test Description (STD) instance, a selection of reusable test modules from the Test Modules Repository (TMR) as well as test data from the Test Data Pool (TDP). Whereas the structure of the STD has already been discussed in chapter 5, the upcoming sections 6.1 and 6.2 deal with the reusable test modules. First, an appropriate modelling notation is selected in section 6.1 based on general requirements for model-based notations and specific requirements which take the concept behind the proposed TCF (see Figure 4.5) and the properties of value-added services into consideration. Furthermore, the section introduces the TU concept which allows a view on client- and server-based cores and in parallel enables the underlying semantics used in the selected modelling notation. Section 6.2 introduces the architecture component within the proposed TCF, the Test Modelling Environment (TME), which enables the modelling and definition of new reusable test modules. The test data integration is discussed in section 6.3 and illustrates how the abstract data types and concrete test templates for request and response messages of the given protocol SIP are stored. This concept can be reused for further applicaton layer protocols (such as HTTP). The main process and the major outcome of this chapter will be explained in section 6.4. The main task of this ACE algorithm is to produce a well- defined output, the behaviour models, based on the previously defined input, the STD instance. The STD instance has to exist in a parsable form to be interpreted by the ACE algorithm. After the algorithm has read the STD instance, the next step is to identify the appropriate reusable test module instances by parsing the specified

CommunicationInterfaces within the STD instance. Then, the parameterisation of the

reusable test module instances is performed by reading the Parameter field. Finally, the ACE algorithm realises the composition of the reusable test modules according to the

content specified in the Requirements of the STD instance. The different steps that have to be taken by the algorithm during the composition phase can be derived from the different categories of steps existing in the pi-calculus-based behavioural description. The result at the end is a list of behaviour models. Each behaviour model within this list is related to a specified Requirement within the STD instance.