5.2 Proposed Novel Service Test Description
5.2.4 Sample Specification with Service Test Description
The sample chat service introduced in section 5.1.1 will be applied. The service will be reused in a simplified form for the prototype validation in section 8.3, and a specification of the “Send Message” use case is given here for illustration. As discussed in the previous sections, first the architectural perspective has to be specified (see Table 5.8).
Table 5.8: STD architectural perspective of simplified sample chat service
Service ID Chat Service
Prose Description A chat communication should be provided. The service users are able to log in to the system and log out again. While being logged in, the service user can enter chat rooms and leave the chat rooms again. The service user can also send textual chat messages. The Administrator of the chat service can add new users to the system and is also capabale of erasing existing users from the system. The Administrator can also create new chat rooms and erase old chat rooms.
Roles • SIP phone: [admin]
• SIP phone: [sender] • SIP phone: [recipient] System Meta Information ServiceURI: sip:[email protected] Protocol: UDP Non-functional Properties None
As described in the section 5.2.2, within the architectural perspective of the STD, the
Service ID has to be set at first (“Chat Service”). The Prose Description describes the
main functionality the sample chat service has to deliver as precise as possible. Three different Roles have been identified for the service and all are acting as SIP phones. The “[sender]” and the “[recipient]” are Service Users (see Figure 5.3) whereas the “[admin]” is, of course, the Administrator. A further information regarding the service addressability is given through the service URI. Non-functional Properties are not specified for the sample chat service.
5.2 Proposed Novel Service Test Description
After the architectural perspective is defined, the behaviour has to be specified. To specify the “Send Message” use case, a Requirement is defined within the sample chat service STD instance (see Table 5.9).
Table 5.9: STD Requirement definition for “Send Message” from sample chat service Requirement ID Req03
Requirement Goal Service User [sender] sends a text message to another Service User [recipient] and gets informed whether the transmission was successful.
Precondition Req02
Participating Roles • SIP phone: [sender] • SIP phone: [recipient] Communication
Interfaces
• SIP UAS non-INVITE: [sender1] → channel a • SIP UAC non-INVITE: [sender2] → channel b • SIP UAC non-INVITE: [recipient1] → channel c Parameters var initMessage = [sender1] → r_Request;
var forwMessage = [recipient1] → s_Request; var okMessage = [sender2] → s_Request; var errorMessage = [sender2] → s_Request; timer t1 = [recipient1] → timerF;
initMessage =
{(Method, “MESSAGE”), (Text, “Hello Bob!”)} forwMessage =
{(Method, “MESSAGE”), (Text, initMessage.Text)} okMessage =
{(Method, “MESSAGE”), (Text, “ok”)} errorMessage =
{(Method, “MESSAGE”), (Text, “Message not received”)} Basic Flow 𝑃𝑃 ≝ 𝑎𝑎(𝑖𝑖𝑛𝑛𝑖𝑖𝑡𝑡𝑀𝑀𝑒𝑒𝑒𝑒𝑒𝑒𝑎𝑎𝑖𝑖𝑒𝑒). 𝑐𝑐̅〈𝑖𝑖𝑓𝑓𝑓𝑓𝑓𝑓𝑀𝑀𝑒𝑒𝑒𝑒𝑒𝑒𝑎𝑎𝑖𝑖𝑒𝑒〉. 𝑖𝑖𝑖𝑖 (𝑡𝑡1. 𝑡𝑡𝑖𝑖𝑚𝑚𝑒𝑒𝑓𝑓𝑡𝑡𝑡𝑡) 𝑡𝑡ℎ𝑒𝑒𝑛𝑛 𝑄𝑄 𝑒𝑒𝑙𝑙𝑒𝑒𝑒𝑒. 𝑏𝑏�〈𝑓𝑓𝑜𝑜𝑀𝑀𝑒𝑒𝑒𝑒𝑒𝑒𝑎𝑎𝑖𝑖𝑒𝑒〉. 0 Alternative Flow (AF1) 𝑄𝑄 ≝ 𝑏𝑏�〈𝑒𝑒𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑀𝑀𝑒𝑒𝑒𝑒𝑒𝑒𝑎𝑎𝑖𝑖𝑒𝑒〉. 0
Initially, the Requirement ID has to be set and a Requirement Goal is specified. The
Precondition field contains the value “Req02”. Although this Requirement is not
determined here, the specified behaviour within its respective Basic Flow has to happen before the Basic Flow of “Req03” begins. In this example, “Req02” indicates the entering
of both Service Users into a chat room. Notice that “Req02” itself includes a
Precondition, namely “Req01”, which describes the login process of both Service Users.
So, the Service Users have to be logged in to enter a chat room (“Req01” “Req02”) and they have to have entered a chat room before sending messages (“Req02” “Req03”). In the Participating Roles field, both Service Users “[sender]” and “[recipient]” are included. The Administrator does not participate within the “Send Message” Requirement. Three different CIs have been identified. The SUT requires two channels a and b to communicate with the initial sender of the text message. In channel
a, the SUT is acting as SIP UAS whereas in channel b, it is acting as SIP UAC. Regarding
the recipient of the text message, the SUT only requires one channel c where it is acting as SIP UAC. The Parameter field includes the definition of several variables all representing SIP MESSAGEs, either being sent from the sender to the SUT (“initMessage”), from the SUT to the sender (“okMessage”, “errorMessage”) or from the SUT to the recipient (“forwMessage”). Additionally, the timer F of the SIP UAC non-
INVITE CI is defined. Subsequently, the Basic Flow is defined. First, it denotes the SUT
to receive the SIP MESSAGE “initMessage” over channel a and then consequently sends the SIP MESSAGE “forwMessage” over channel c. In the next step, the state of the timer “t1” is checked. If it has not timed out, the SUT sends out the SIP MESSAGE “okMessage” over channel b and the Basic Flow terminates afterwards. Otherwise, if the timer has timed out, the Alternative Flow “AF1” is activated. Here, a different SIP MESSAGE “errorMessage” is sent by the SUT over channel b. Then, also the Alternative
Flow terminates.
To sum up, this section introduced the novel STD, a description language containing aspects of typical requirements specifications as well as relevant information of the test
5.2 Proposed Novel Service Test Description
environment. In contrast to the introduced specification languages in section 5.1, the STD fulfils all the relevant requirements stated in section 5.2. At first, the relevant data specified in both the architectural and behavioural perspective can be read and interpreted by a machine as it is existing either in a structured or formal manner. Although formality in languages usually means that the compilation of the language is difficult for the modeller or creator, the pi-calculus-based descriptions to specify the Basic Flows and
Alternative Flows are straightforward and can be defined in a very compact and intuitive
way. At the same time, the descriptions have a very precise meaning and do not allow any ambiguities. A further requirement mentioned was the possibility to trace the requirements within the language. This aspect is supported by the STD, as it is indeed possible to map the use cases defined in the “Structured Requirement” document to the
Requirements within the STD. Moreover, the STD itself supports tracing within an
instance through the Precondition field. Requirements that are based on each other can easily be specified. Another important aspect, the possibility to reuse certain aspects of behaviour, is also a very important part of the STD. Through Roles in combination with the CIs that are belonging to the SUT, sorts of reusable components can be derived. This concept is discussed in more detail in section 6.4. Of course, the concept will clarify as soon as the concept behind the reusable test modules is described in section 6.2. Further specified requirements are covered, such as the test data integration and parameterisation. This is a very relevant part of the STD and can be realised through the Parameters field within a specific Requirement. The SUT interface description, which is also specified as a major requirement, can be defined through the System Meta Information within the architectural perspective of an STD instance. If demanded, further fields can be added here. In general, the STD allows extensions without having to change the specification
language. For example, new Roles besides the already mentioned SIP phone and Web browser can be added. Of course, this also requires the identification of the corresponding
CIs and regarding the Test Creation Framework, the definition of the reusable test
modules. Finally, the compliance to value-added services is given as standard communication protocols are supported, such as SIP and RTP and also HTTP.