Syntactical view Sample Clauses

Syntactical view. The syntactical view of the application describes how the services are accessed. A syntactical description includes a description of the messages involved in the access of a certain service, a description of the communication protocols used, the operational modes of the applications (e.g. different QoS, emergency modes, etc.), and non-functional and quality properties related to message, communication protocols and operational modes. The syntactical view of a service is often mixed with its structural view since service syntaxes are always related to structural elements. For example, messages are related to service interfaces and operational modes are related to the jobs that execute the service. In this kind of applications the syntax of a service is defined by the signals/messages that are exchanged by service-users and services and by the order in which these signals and messages are sent from service-users to services and vice versa. To show an example of modelling the syntax of a service we will use the example of an application server. The structure of this server is depicted in Figure 5-12. As depicted in the figure, the server admits three different kinds of messages: a StartConnection message, a Data message and a CloseConnection message. The server also uses two messages to answer the clients: Ack and Nack. The protocol is defined using a UML2 state machine diagram that is pointed by the “operationalMode” property of the <<RtUnit>> stereotype (Figure 5-13). We also add a property to the server in other to keep track of its current state. Figure 5-12. Structure of an application server. Figure 5-13. State machine diagram of the application server protocol. From a syntactical point of view, clients have to be aware of the structure of the messages they must send to the server in order to interact with it. Messages, as already has been shown, are modelled using UML2 signal elements. Figure 5-14 shows the messages involved in the current example. Figure 5-14. Messages involved in the application server example. In Figure 5-14, UML signal had been stereotyped using <<RtFeature>> from the XXXXX XXXX sub-profile. The <<RtFeature>> stereotype adds timing constraints that must be accomplished at the interfaces that produce/consume each of the messages (i.e. different deadline descriptions, deadline miss ratios, priorities and arrival patterns). Table 5-1 shows all the properties of the <<RtFeature>> stereotype in the HLAM sub-profile.