Fakultat fur Elektrotechnik, Informatik und MathematikHeinz Nixdorf Institut und Institut fur InformatikFachgebiet SoftwaretechnikWarburger Straße 10033098 Paderborn

Protocols for SoftwareComponents: Specification and

Analysis

Seminar Thesis

Submitted to the Software Engineering Research Groupin Partial Fulfillment of the Requirements for the

Seminar

Model-Driven Quality

byVinay Akkasetty Gopal

Peter-Hille-Weg 1133098 Paderborn

Lecturer:Jun.-Prof. Dr.-Ing. Steffen Becker

Thesis Supervisor:Dipl.-Inform. Stefan Dziwok

Paderborn, September 2013

Contents

1 Introduction 11.1 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Running Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Document Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Fundamentals 42.1 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 MechatronicUML Component Model . . . . . . . . . . . . . . . 52.3 SOFA 2 Component Model . . . . . . . . . . . . . . . . . . . . . . 6

3 Protocol Specification 93.1 Real-Time Coordination Protocols of MechatronicUML . . . . . 93.2 Behavior Protocols of SOFA 2.0 . . . . . . . . . . . . . . . . . . . . 12

3.2.1 Behavior as a Language . . . . . . . . . . . . . . . . . . . . 123.2.2 Behavior Protocols . . . . . . . . . . . . . . . . . . . . . . . 13

3.3 Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4 Protocol Analysis 164.1 Protocol Analysis in MechatronicUML . . . . . . . . . . . . . . 16

4.1.1 Refinement Check . . . . . . . . . . . . . . . . . . . . . . . 164.1.2 Compositional Verification . . . . . . . . . . . . . . . . . . . 17

4.2 Protocol Analysis in SOFA 2 . . . . . . . . . . . . . . . . . . . . . 174.3 Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5 Conclusion 20

Bibliography 21

ii

Abstract

Today’s software systems are trusted upon to carry out the most safety crit-ical tasks with accuracy and efficiency. For the development of such softwaresystems the architectural design is very integral in realizing the correct system.The component based architecture design is one such paradigm for building thesesoftware systems. In a component based system, the interaction between compo-nents forms the integral part of the system behavior. Several approaches provideformalisms to specify and analyse interaction. But the approaches are not com-pared for their efficiency in specifying and analysing interaction. To improve theapproaches they should be compared for its capabilities like ease of modeling pro-tocol, techniques and tools for analysis. This paper compares two different modeldriven approaches namely MechatronicUML and SOFA 2.0 for its interactionspecification and analysis capabilities. They both provide protocols to specifyinteraction. The modeling constructs, analysis techniques and tools provided bythe approaches to model protocols are compared to find out the capabilities thatMechatronicUML lacks and the improvements that would make it better ap-proach.

1 Introduction

In everyday life, people do not even realize that they are surrounded by systemsthat run on software for providing services required by them. This unawareness ismainly because the software employed works safely and accurately. So, softwarehas earned the trust of humans in performing safety critical tasks. Designing suchsoftware systems starts with structuring the system into units and combiningthose units to a whole system. Each unit of the system fulfils a small part of therequired functionality of the whole system. All units collaborating together fulfilthe complete functionality of the system. This collaboration requires exchange ofinformation, which is called interaction between units. Further, interaction canalso take place between two or more autonomous systems, for e.g., software systemof two cars, in order to achieve a common goal. So interaction design is at twolevels: sub-system and system level.

Allen and Garlan [AG97] lists the high-level interaction as one of the impor-tant issue at the design stage. Interaction design is an important part of theoverall architectural design because it is the only thing that tells whether unitsfit together. Hence, specifying interactions and analysing them for correctness isessential before implementing a software system. Formal methods are always un-ambiguous and automatically verifiable, which should be leveraged for the task ofarchitectural design. There are several techniques to specify interactions, one suchtechnique is “protocols”. There are several approaches that provide formalismsfor protocol specification and analysis. However, the approaches are not comparedfor its capabilities. Comparing approaches helps in improving their capabilities tospecify protocols and thus improving the efficiency of the user of the approach. Inthis paper, two model driven approaches that provide formalisms and techniquesfor protocol specification and analysis are compared:

• MechatronicUML [BBD+12] is a model-driven approach used for design-ing software for advanced mechatronic systems. It is being developed atthe Software Engineering Group of University of Paderborn. Mechatron-icUML provides several formalisms for modeling different aspects of thesystem, like structure, interaction, behavior, and deployment. Particularly,it provides Real-Time Coordination Protocols for modeling interactions. Italso provides formal techniques for the verification of the system behavior.The domain of this approach is the software development of real-time, in-teractive, distributed, self-adaptive mechatronic systems [BBD+12].

• SOFA 2 (SOFtware Appliances) [Sof13] is a component system that allows tomodel applications as hierarchical components. SOFA is mainly developed

1

1. Introduction

at Charles University in Prague. Some of the important features SOFA sup-ports are: dynamic architecture, multiple communication styles, behaviorvalidation. In SOFA, the interaction is modeled using Behavior Protocols.SOFA uses an ADL (Architecture Description Language) based design tostructure the design. The domain of SOFA is business information systems.SOFA also provides a formal verification technique for behavior verification.

1.1 Objective

In this paper, I compare MechatronicUML and SOFA 2.0 for its capabilities inprotocol specification and analysis. The comparison is based on the aspects likeease of modeling the interaction, modeling constructs available for different aspectsof interaction and different techniques and tools for verifying the correctness ofinteraction specification. Along with this, I also present the similarities betweenboth approaches. Finally, the objective is to find out, from this comparison,the specific capabilities that MechatronicUML can improve when compared toSOFA.

1.2 Running Example

The following example scenario is considered for the purpose of demonstrating theinteraction between software components and use of protocols for specifying theinteractions. In this scenario, a software system called “Cross Country DrivingAssistance (CCDA)” assists the driver of a car during a cross country drive inEurope. Each time when the car is about to cross the border, say about 50km from the border, the CCDA system automatically alerts the driver with thecheapest refuelling options. Once inside a country, the system should providethe driver with that country specific driving information like road signs, signals,traffic rules, speed limits, etc. Figure 1.1 illustrates this scenario: the CCDAsystem alerts the driver of the car to refuel before crossing over to Germany whenit is 50 km away from the international border because fuel is cheaper in Austria.Also when the car enters Germany, the road rules of Germany are loaded andshown to the driver.

A system like CCDA contains several components and these components willinteract with each other to fulfil the mentioned functionalities. In the next chaptersof this paper, the CCDA system is used as an ongoing example. The interactionbetween components of the CCDA system are modeled and analyzed using theapproaches MechatronicUML and SOFA 2.0, respectively, for the purpose offinding the differences between the approaches. The two important properties ofthe CCDA system that the interaction design should fulfil are:

• Always, correct road rules are displayed to the driver. Displaying incorrectrules would result in accident or legal problems like revoking of driver’slicence.

2

1.3 Document Structure

Fuel

Station

International Border

Germany Austria

50 KM

Alert! Refuel in the coming fuel station. Fuel is cheaper here.

Loading Germany road rules

Figure 1.1: Scenario Illustration

• Never, a cheap refuelling option is missed. Otherwise, the trip would becomeexpensive.

1.3 Document Structure

Chapter 2 provides the fundamental concepts regarding protocols, defines specifi-cation and analysis, and presents the component models of MechatronicUMLand SOFA 2. Chapter 3 explains the process of protocol specification in bothapproaches and at the end it provides the comparison between them. Similarly,Chapter 4 explains the process of protocol analysis in both approaches and com-pares them at the end of the chapter. Chapter 5 gives the final conclusion of thepaper, my own opinion, and an outlook on future work.

3

2 Fundamentals

In this chapter, the basic concepts required for the further understanding of thispaper are presented. Section 2.1 introduces the concept of protocols. It also pro-vides definitions for different protocol-based development processes like specifica-tion and analysis (correctness of refinement and verification). After that, Sections2.2 and 2.3 introduce the component models of MechatronicUML and SOFA2.0 respectively.

2.1 Protocols

In the context of software design, a software system is composed of separate enti-ties where each entity encapsulates a service for other entities to use through anexternal interface. In object-oriented programming, these encapsulated entitiesare called objects and in component-oriented programming software components.Objects / components communicate by sending and receiving requests and re-sponses (also known as messages or method / operation invocations). For twoobjects / components to communicate effectively, both of them should agree uponthe order and format of the requests and responses. These requests and responsesare defined in the external interfaces. The specification of interfaces (also knownas service definition) and in what manner it will be employed forms the basis of acontract [Mey88] between communicating parties for successful cooperation. Thiscontract is called a protocol. Florijn [Flo95] defines a protocol as “the conditionsunder which a particular interface operation can be performed”. Along with thelegal ordering of operations, a protocol specifies the constraints on data that is ex-changed and the synchronization constraints under which messages by senders areaccepted by receivers [Flo95]. In this paper, the protocol mechanism is classifiedinto two parts:

• Protocol Specification is all about describing the protocols in a suitablelanguage or formalism. According to Florijn [Flo95], lacking suitable specifi-cation constructs lead to separate design documents for different aspects likeconditions, constraints, and synchronization. This further leads to inconsis-tencies between design documents and it can become tedious to maintaindifferent versions of design documents. The two major ways of specifyingprotocols are (1) as a state transition system where the transitions representmessages or method invocation and states represent the abstract state ofservice [Flo95] and (2) as a regular expressions generating the valid requestsequences [PV02].

4

2.2 MechatronicUML Component Model

• Protocol Analysis includes the checking of the communication behaviorof components specified by protocols for fulfilling the properties specifiedin the requirements. One of the technique used to check the correctness ofprotocols is model checking. In model checking certain properties for e.g.,no deadlock, are specified in temporal logic formulas for e.g., LTL, TCTL[ACD93]. These properties are checked for protocols to see whether it holdsor not. This process is called verification. Different approaches employ dif-ferent model checkers for verification. Another important part of analysisis the refinement check. Refinement is a process of applying a protocol tothe ports of components that uses the protocol for communication. Thisessentially mean that the component will comply to the communication be-havior specified by the protocol. Refinement includes several changes fore.g., synchronizations with the internal behavior of the component. So oncea protocol is verified for certain verification properties, the component hasto be reverified for the same properties when that protocol is applied to thecomponent. This essentially leads to a large number of states to deal with,which may lead to the state explosion problem [BBD+12]. An alternativeapproach is to check only the refinement changes (refinement check).

2.2 MechatronicUML Component Model

The MechatronicUML component model [BBD+12] defines the structure ofthe system. A component is an encapsulated entity and interacts with the outerworld via its interfaces. The interfaces of a component are exposed by its port.In MechatronicUML, based on the direction of information flow, the ports areclassified into in-ports, out-ports and in/out ports where in-ports can only receiveinformation, out-ports can only send information and in/out ports can do both.Based on the kind of information processed by ports, they are classified into dis-crete, continuous, and hybrid ports. The discrete ports can process only discreteasynchronous messages and has a discrete behavior specification. Continuous portscan only process signals and its behavior is not specified in MechatronicUMLbut only the data type of the signal is specified. The hybrid ports combine prop-erties of both discrete and continuous ports where it sends or receives discretizedsignal values.

MechatronicUML components are classified into atomic and structured types.Atomic components are the components that have direct behavior specification,which involves internal behavior and the external behavior exposed via ports.Based on the behavior specification, atomic components are classified into discreteatomic components and continuous atomic components. Discrete atomic compo-nents have a discrete component behavior specification where the interaction hap-pens by only exchanging the messages. Continuous atomic components have theirinternal behavior specified by control engineering tools like Matlab/Simulink. InMechatronicUML, the behavior of both component and its ports are specified

5

2. Fundamentals

in Real-Time Statecharts [BBD+12].

Structured components are the components that are composed of other com-ponents, called component parts. Component parts can be atomic or structuredcomponents. The structured components lack its own behavior specification, buthave a combined behavior specification of its parts. Structured components areclassified into discrete and hybrid types. If all of its embedded parts are typedover to discrete atomic or discrete structured components, then that structuredcomponent is a discrete structured component. If one of its embedded part istyped over to continuous atomic or hybrid structured component, then that is ahybrid structured component.

Figure 2.1 shows the MechatronicUML component model for the CCDAsoftware introduced in Section 1.2. The component CarSoftware is a structuredcomponent composed of three atomic components, namely CCDA, Database, andLocationCalculator. The Database component contains the data for fuel pricesand road rules. Database provides this data to CCDA when asked for it. TheLocationCalculator monitors the distance to border and notifies the CCDA com-ponent if the distance is less than or equal to 50 km. The CCDA componentinteracts with Database and LocationCalculator via its discrete ports InfoReqand LocDetailsIn respectively. The port InfoReq is an in/out port, because itsends request for data and receives data as response. The port LocDetailsIn isan in-port where it receives only notification message when the distance to bor-der is less than 50 km. The port PosDataIn of LocationCalculator is a hybridport that continuously receives position data from another component. Chapter 3presents how the interaction between these atomic components are specifies usingprotocols.

2.3 SOFA 2 Component Model

As described by Plasil and Visnovsky [PV02] the SOFA component model is ahierarchy of components. A component is instantiated from its “component type”called template. The instantiated template is called component. The template(T) of a component is specified by a frame (F) and an architecture (A), which isrepresented as a T = <F,A >pair. The interfaces of T are defined by frame (F)and all instances of T will get these interfaces. The frame is implemented by thearchitecture (A) and there can be many architectures implementing F. Basically Adescribes the structure of the implementation by instantiating components directlyunder A and by specifying the interconnections between those components.

In SOFA, components are classified into primitive and composed [SCM10]. Acomposed component is built from other primitive and composed components,subcomponents. Primitive components does not contain any subcomponents andtheir implementation/structure is provided by an underlying implementation lan-guage [PV02]. In F, the interfaces are instantiated from its interface types. In-terfaces provided by the component are called provides-interfaces and required by

6

2.3 SOFA 2 Component Model

CarSoftware

CCDA : CCDADB : Database

LC : LocationCalculator

InfoReq InfoProv

LocDetailsIn

LocDetailsOut

PosDataIn

PosDataIn

Figure 2.1: MechatronicUML Component Model for CCDA Scenario

the component are called requires-interfaces. Interconnections between subcom-ponents are called interface ties. There are four kinds of interface ties, dependingon whether the tie is between: (i) a requires-interface and a provides-interface oftwo subcomponents then it is called binding, (ii) a provides-interface of a com-ponent and a provides-interface of its subcomponent then it is called delegating,(iii) a requires-interface of a subcomponent and a requires-interface of its parentcomponent then it is called subsuming. If the interface is not employed by any ofthe ties then it is called exempting.

The SOFA component model is specified by SOFA CDL (Component DefinitionLanguage) [PV02] (based on CORBA IDL). Figure 2.2 shows the modeling of theCCDA software introduced in Section 1.2 using the SOFA component model. Thecomposed component CarSoftware is composed of three primitive components,namely CCDASoftware, LocationCalculator, and Database. The componentLocationCalculator monitors and notifies CCDASoftware when distance to bor-der is less than 50 km. The component Database provides the data regardingfuel prices and country specific road rules to CCDASoftware. The CCDASoftware

has a binding interface tie with both LocationCalculator, and Database. Fig-ure 2.3 shows the definition of two interfaces ILocationInfo and ICountryInfo.These interfaces are required by CCDASoftware. As shown in Figure 2.3 the framedefinition of CCDASoftware specifies that it requires both interfaces.

7

2. Fundamentals

DatabaseDatabase

LocationCalculatorLocationCalculatorCCDASoftwareCCDASoftware

provideInfo

requestInfo

requestLocationInfo provideLocationInfo

CarSoftwareCarSoftware

getCoordinates

getCoordinates

Client

DB

LC

CF

Figure 2.2: SOFA 2 Component Model for CCDA Scenario

Frame CCDASoftware {

requires:

ILocationInfo requestLocationInfo;

ICountryInfo requestInfo;

};

interface ILocationInfo {

int GetDistanceToBorder();

string GetCurrentCountry();

string GetNextCountry();

int GetCoordinates();

boolean InBorderArea();

};

interface ICountryInfo {

string GetRoadRules(in string country);

int GetFuelPrices(in string countries);

string GetNearestFuelStation(in int cordinates);

};

Figure 2.3: Interfaces for CCDA Scenario and Frame of CCDASoftwareComponent

8

3 Protocol Specification

As explained in Section 2.1, protocol specification is an important aspect of theprotocol mechanism. This chapter explains protocol specification in Mechatron-icUML (Section 3.1) and SOFA 2 (Section 3.2) using the example scenario intro-duced in Section 1.2. Finally, in Section 3.3, both approaches are compared fortheir specification capabilities.

3.1 Real-Time Coordination Protocols ofMechatronicUML

In MechatronicUML, interaction/communication between components is spec-ified by Real-Time Coordination Protocols (RTCP), such that for every connectorbetween discrete ports of component model there shall be a RTCP describing thecommunication [DBHT12]. An RTCP essentially separates the communicationbehavior from the internal behavior of the component. The communicating part-ners are represented by roles in an RTCP. An RTCP has to be instantiated forspecifying a concrete communication through role instances. According to Dzi-wok et al [DBHT12], the protocol specification is a complex and error-prone taskbecause of the difficulty in ensuring that there will be no safety critical situation.A set of general, reusable solutions are defined in Dziwok et al [DBHT12], suchthat these solutions can be adapted into protocols of specific communication re-quirements. These general solutions are called Real-Time Coordination Patterns(pattern for short).

For the CCDA scenario, the pattern Limit Observation [DBHT12] providesus the solution for specifying the communication between the atomic compo-nents CCDA and LocationCalculator. Figure 3.1 shows the protocol LocationObservation adapted from the pattern Limit Observation. The name of theprotocol is shown in the ellipse and the roles are named provider and observer.These roles are connected by a role connector. The provider monitors the dis-tance to the approaching border and notifies the observer, when the distancelimit is violated.

The messages exchanged by roles are specified in Message Interfaces [BBD+12].Figure 3.1 shows the message interface interface provider-to-observer thatcontains the message types observerborderDistanceLimitViolated(current co

untry, next country, distance to border) and borderDistancelimitRedee-

med(Current country). This interface is the sender message interface of the roleprovider and receiver message interface of role observer. The roles provider

9

3. Protocol Specification

Location Observation

observerprovider

interface_provider-to-observer

borderDistanceLimitViolated(current_country, next_country, distance_to_border)

borderDistancelimitRedeemed(Current_country)

Figure 3.1: Protocol Location Observation and its Message Interface

and observer are of types out-role and in-role as they have only a sender anda receiver message interface respectively. The role-cardinality of both roles is 1,which means both roles can communicate with exactly one instance of the otherrole. This type of role is called single-role. If the upper bound of the cardinalityis greater than 1 then that role is called multi-role.

Request Information

providerrequestor

interface_requestor-to-provider

requestRoadRules(country)

requestFuelPrices(current_country, next_country)

requestNearestFuelStation(location_coordinates)

interface_provider-to-requestor

roadRules(ruleList)

fuelPrices(priceList)

nearestFuelStation(stationAddress)

Figure 3.2: Protocol Request Information and its Message Interfaces

Another pattern, Request Information, is adapted into a protocol to specifythe communication between components CCDA and Database. This protocol isshown in Figure 3.2. In this case, both roles requester and provider are singleand in/out-roles. The interface requester-to-provider is the sender inter-face of the role requester and receiver interface of provider and vice versa for

10

3.1 Real-Time Coordination Protocols of MechatronicUML

the interface interface provider-to-requester. The role requester asks forinformation like country-specific road rules, fuel prices and the location of thenearest fuel station. The role provider replies with the appropriate information.

Role Behavior Specification

Each role of an RTCP will have its own behavior specification specified by aReal-Time Statechart (statechart for short). The Real-Time Statecharts are state-based models used for defining behavior. A more detailed description of Real-TimeStatecharts and its modelling elements can be found in [BBD+12]. The concurrentexecution of all role instances of an instantiated RTCP determines the behavior ofthe RTCP [BBD+12]. In the role statechart, communication between roles happenby the exchange of asynchronous message events. Message events are typed overmessage types defined in the sender and receiver interfaces of that roles. Furtherroles can specify its own variables, operations and side effects, which the statechartof that role can use in its transition guards.

observer

provider

OutsideBorderArea

MeasuringLimit

c0 ≤ 602

/ [distance ≤ 50]

borderDistanceLimitViolated() 1

/ [distance > 50]

borderDistancelimitRedeemed()

OutsideBorderAreaOutsideBorderArea

Waiting 2borderDistanceLimitViolated() /

1borderDistancelimitRedeemed() /

var: int distance; cl: c0;

InsideBorderArea / [distance > 50] borderDistancelimitRedeemed()

/ [distance ≤ 50] borderDistanceLimitViolated()

InsideBorderArea borderDistancelimitRedeemed() /

borderDistanceLimitViolated() /

Figure 3.3: Behavior of Roles of Location Observation Protocol

Figure 3.3 provides the statecharts for the roles provider and observer of pro-tocol Location Observation. The provider is initially in the MeasuringLimit

state for 60 sec and checks the distance between the current location and anyapproaching border. If the distance is less than or equal to 50 km, then theprovider raises the message borderDistanceLimitViolated() and changes to

11

3. Protocol Specification

InsideBorderArea state. This change triggers the transition in the observer

statechart where it changes from the initial Waiting state to InsideBorderArea

state. Once the border is crossed or the car moves away from the border by morethan 50 km, the provider raises the message borderDistancelimitRedeemed()

with current country as its parameter and changes to the OutsideBorderArea

state. This change again triggers the transition in observer changing its state toOutsideBorderArea. The provider continues to stay in the OutsideBorderArea

state until the distance limit is violated. So the provider continuously monitorsthe distance and send messages to the observer whenever the distance limit isviolated or redeemed.

3.2 Behavior Protocols of SOFA 2.0

In SOFA 2.0, the communication behavior is specified by behavior protocol. Thebehavior protocols of SOFA mainly specify the possible sequences of method callsthat are defined in the interfaces of the component. This possible way of methodcall sequence is expressed by regular expressions. A behavior protocol is an regularexpression formed by combining method calls with certain symbols and operators.The symbols and operators specify whether a method call is sent or received,whether a method call is a request or a response and whether a method call canbe invoked or not. Thus a behavior protocol specifies the legal sequence of methodcalls on the interfaces of a component.

3.2.1 Behavior as a Language

In SOFA 2.0, method calls on interfaces are called events. An event is syntacticallywritten as <event prefix><connection name>.<local event name><eventsuffix>. The event prefix symbols are !, ?, and τ which symbolizes whether anevent is emitted, absorbed or an internal-event respectively. An event suffix spec-ifies whether an event is a request (↑) or a response (↓). The operators providenotation for describing concurrency and communication[PV02]. The operatorsincludes the sequence operator ;, the repetition operator *, the alternative oper-ator +, and the or-parallel operator ‖, and-parallel operator |, and compositionoperator b [PPK07] (For more detailed explanation of operators refer [PV02] and[PPK07]).

The sequences of events are called traces. Plasil and Visnovsky [PV02], uses thenotation of agents for components and connections for interface ties between thecomponents. Agents are of two kinds, namely primitive and composed. Primitiveagents does not contain any other agents in it and all its connections are external.Composed agents are formed by the composition of other agents. The hierarchyof agents is called system. The root of the system is an agent without any externalconnections. The set of all possible event sequences (traces) on a set of connections(V) of an agent (A) in any run of the system (Σ) is called behavior of A on V in

12

3.2 Behavior Protocols of SOFA 2.0

Σ [PV02]. The set of traces is called language of agent A on V (V comprises allAs connections) [PV02].

3.2.2 Behavior Protocols

Plasil and Visnovsky [PV02] states that the language (set of traces) of an agentcan be infinite and unrestricted. This language (set of traces) is approximatedby regular language which is expressed by behavior protocol. So, a behaviorprotocol is a regular expression that generates a language (set of traces) of an agent(component). In SOFA, protocols can be of three types namely frame protocol,architecture protocol and interface protocol. If a protocol contains events only fromexternal interfaces of the component’s frame, then that protocol is called frameprotocol [PV02]. If the component is composed, then the parallel composition ofall frame protocols of the subcomponents is called architecture protocol [PV02]. Ifthe protocol is made up of events only from one particular interface then it is ainterface protocol [PV02].

!requestLocationInfo.InBorderArea ;

?requestLocationInfo.InBorderArea ;

(

)

!requestLocationInfo.GetDistanceToBorder

!requestLocationInfo.GetNextCountry ;

?requestLocationInfo.GetNextCountry ;

!requestInfo.GetFuelPrices ;

?requestInfo.GetFuelPrices ;

(!requestLocationInfo.GetCoordinates ;

?requestLocationInfo.GetCoordinates ;

!requestInfo.GetNearestFuelStation ;

?requestInfo.GetNearestFuelStation ;)

!requestLocationInfo.GetCurrentCountry

+

+

Figure 3.4: Frame Protocol of the CCDASoftware Component

For the CCDA software, Figure 3.4 shows the frame protocol of the compo-nent CCDASoftware. This frame protocol specifies that the component (agent)CCDASoftware emits the request InBorderArea to find out whether the car iswithin the 50 km range of border. After receiving the response, if in border areathen CCDASoftware emits the requests GetNextCountry and GetFuelPrices. Ifthe fuel is cheaper in this country, then it emits GetCoordinates and GetNearestF-

uelStation to find out the nearest available fuel station. If the price is not cheaperit alternatively emits GetCurrentCountry. If car is not in the border area it emits

13

3. Protocol Specification

the request GetDistanceToBorder to find out the distance to the approachingborder.

3.3 Comparison

In this section, the similarities and differences between the MechatronicUMLand SOFA 2.0 for protocol specification are presented. The similarities includethe following:

• The interface specification of both approaches provide a way to specify pro-vided and required interfaces of a component. In MechatronicUML, thisis done by specifying sender and receiver message interfaces. In SOFA, byspecifying provides and requires interfaces.

• Both approaches provide modeling constructs for asynchronous message ex-change. In MechatronicUML, messages that trigger transition are shownon the transition arrow of Real-Time Statechart. On the transition arrow,the raise (send) message events are to the left of a backslash (\) and trigger(receive) message events are to the right of the backslash. In SOFA theemit (send) message events are depicted by ! symbol and absorb (receive)message events by ? symbol.

• Both approaches separate the specification of communication behavior fromthe internal behavior of a component. In MechatronicUML, this sepa-ration is achieved by specifying separate statecharts for role and internalbehavior. In SOFA, by specifying separate behavior protocols for frame andarchitecture.

The differences are:

• MechatronicUML provides a visual approach where the most of the con-structs or model entities are expressed graphically. MechatronicUMLuses several shapes and symbols to represent different modeling constructs.In contrast, behavior protocols of SOFA are regular expressions that areformed by message events and symbols.

• In MechatronicUML, roles/ports can be only sender, only receiver or bothsender/receiver. In SOFA it is not possible to specify whether a componentcan only emit, only absorb or can emit/absorb events.

• Timing requirements are modeled using clocks, message delays, and invari-ants in MechatronicUML. SOFA provides no explicit constructs to modeltiming requirements.

• In MechatronicUML, certain properties of message exchange betweenroles of a protocol, like message loss and buffer size can be specified. Incontrast, it is not possible to specify these properties on communication.

14

3.3 Comparison

• Message events, whether sent or received, are distinguished as request or re-sponse in SOFA. The request message event is appended with a suffix ↑ (uparrow) and the response message event with ↓ (down arrow). Mechatron-icUML does not provide constructs for request and response modeling.

• The parallel composition (b) operator of SOFA provides a formal definitionfor composing two behavior protocols. There is no formal definition forcomposing behavior of two protocols in MechatronicUML.

15

4 Protocol Analysis

This chapter explains protocol analysis in MechatronicUML (Section 4.1) andSOFA 2 (Section 4.2). Finally, in Section 4.3, both approaches are compared fortheir analysis capabilities.

4.1 Protocol Analysis in MechatronicUML

In MechatronicUML, there are two kinds of properties: safety and boundedliveness of the system [BBD+12]. These properties are specified in a formal logiccalled Timed Computational Tree Logic (TCTL) [ACD93]. The RTCPs shouldfulfil these properties specified by the system developer. Model checkers (e.g.UPPAAL [BDL04]) are used to verify these properties, which explore the wholestate space of the RTCP. The state space is derived from the role statecharts[BBD+12].

For the protocol Location Observation (specified in Section 3.1), the proper-ties that need to be fulfilled are shown in Figure 4.1. The properties state thatthere will never be a deadlock and whenever the provider is in OutsideBorderArea

or InsideBorderArea state, the observer is also in the same state as the provider.

AG not deadlock

AG (provider.OutsideBorderArea implies observer.OutsideBorderArea )

AG (provider.InsideBorderArea implies observer.InsideBorderArea )

Figure 4.1: Verification Properties of Protocol Location Observation

4.1.1 Refinement Check

As described in Section 2.1, when a role behavior is adapted to a component, itinvolves changes like synchronizing with internal behavior or other role behaviorthat is adapted to other ports of the component. These changes are called re-finement changes. Since RTCP is a reusable solution, it can be used for solvingcommunication problems between different components. So every time when averified RTCP role behavior is adapted to a component, it has to be ensured thatthe resulting behavior specification still adheres to the properties of the RTCP.

16

4.2 Protocol Analysis in SOFA 2

Heinzemann et al [HH11] provides the formal definition of refinement and intro-duces a refinement check procedure to formally check refinement changes on anabstract role. The inputs for the refinement check are timed story charts of thetwo roles to be checked. The output is either an OK if the roles satisfy the refine-ment definition, or a counter-example consisting of a path of the refined behaviorthat does not satisfy the refinement [HH11].

4.1.2 Compositional Verification

Becker et al [BBD+12] defines the compositional verification approach used inMechatronicUML. In this approach, RTCPs and components are verified in-dependently of each other. Then, RTCPs are applied to components by refiningthe role behavior (see Section 4.1.1). This preserves the verification propertiesof RTCP. Compositional verification approach solves the problem of infinite statespace when verifying the complete model of the system [Sch08]. By this approach,the verification of the whole system is reduced into several smaller verificationsteps that deal with smaller state spaces. Becker et al [BBD+12] presents a fourstep process for this approach:

• Step 1: Verify all RTCPs used for specifying the communication betweencomponents of the system in isolation.

• Step 2: After verifying all RTCPs, compose their role statecharts whilepreserving the verified properties.

• Step 3: Then, all the roles that are assigned to specific components aregrouped together. The role behavior is refined to adapt it to the port of theconcerning component, such that the verification properties of the RTCPare preserved.

• Step 4: Verify the internal behavior of the components in isolation.

4.2 Protocol Analysis in SOFA 2

The verification approach employed in SOFA is the behavior compliance. [PPK07]defines behavior compliance as - whether the two components equipped with itsframe protocols can communicate without errors or not. The two kinds of compli-ance are horizontal and vertical compliance. Horizontal compliance is evaluatedbetween components at same level of nesting, in which the frame protocols oftwo components are parallel composed to generate traces with communication er-rors. Vertical compliance is evaluated between component and its subcomponentsby employing horizontal compliance between the architecture protocol and theinverted frame protocol of the component. The inverted frame protocol is con-structed by replacing all accept or absorb with emit events and emit with absorbevents [PPK07].

17

4. Protocol Analysis

This verification of horizontal and vertical compliance at all levels of the com-ponent nesting ensures that no communication in the system will result in errors.The tool Static Protocol Checker [MPK05] used for static checking of protocolcompliance, takes two protocols as its input arguments and creates parse treesfor each of them. It then combines the parse trees by parallel composition whichprovides the state space of the composed protocols. A state space formed by de-picting each event execution as transition between the before execution and afterexecution states. The advantage of parse trees is that its size is dependent onexpression length and not on the number of states. Based on the parse trees asymbolic representation technique called Parse Tree Automata [MPK05] is usedto effectively handle the state explosion problem. [PPK07] describes another toolcalled runtime protocol checker to check whether a component obeys its frameprotocol in a particular run of the system. Here the frame’s interfaces are addedwith interceptors which will notify the checker when the events occur on thoseinterfaces.

Another method for verifying behavior compatibility is given by Kofron [Kof07].In this method behavior protocols are translated into Promela [Hol03] code. ThePromela code is then fed into Spin model checker [Hol03] to verify the behaviorcompatibility. Also possible to check is the LTL (Linear Temporal Logic) proper-ties specified for a protocol. Kofron [Kof07] presents an algorithm for translatingbehavior protocols into Promela code.

4.3 Comparison

In this section, the similarities and differences between the MechatronicUMLand SOFA 2.0 for protocol analysis are presented. The similarities include thefollowing:

• Both approaches handle the state space explosion problem in its own way.In MechatronicUML, this is achieved by compositional verification tech-nique where the role and component behavior are verified separately effec-tively reducing the state space. In SOFA, this is achieved by verifying frameand architecture protocols. Also, SOFA uses the Parse Tree Automata tech-nique to reduce the state space of verification.

• Both approaches provide a way to explore the state space. In Mechatron-icUML, statecharts are transformed into timed automata models which arethen explored for verifying the properties. In SOFA, protocols are convertedinto parse trees which are then transformed into state transition models forstate exploration.

The differences are:

• In MechatronicUML, the verification properties are specified in TCTL.The behavior is checked for only these specified properties. Whereas in

18

4.3 Comparison

SOFA, the verification properties are specified in LTL. Along with the ver-ifying LTL properties specified for a protocol, it is also possible to checkwhether a component obeys its frame protocol and compliance between twoprotocols.

• MechatronicUML offers only one method for verification that is trans-forming statechart into timed automata and then verify the TCTL proper-ties. SOFA offers several methods of model checking:

– Protocols are transformed into Promela models that are then checkedin the Spin model checker.

– Horizontal and vertical compliance are checked using Static and Dy-namic Protocol checkers. Here, the protocols are composed and thenconverted into state transition models for finding errors.

• The verification goal in MechatronicUML is to check whether a propertyis satisfied or violated for a protocol. In SOFA, the goal is to check thecompatibility between protocols of components.

19

5 Conclusion

Both, MechatronicUML and SOFA 2, provides well-defined solutions for in-teraction specification and analysis. Even though their respective domains aredifferent, they can be used to model interaction in different domains. The CCDAscenario introduced in Section 1.2 and modeled using both approaches shows thatboth approaches can efficiently handle most of the scenario requirements. As aconclusion to the comparison done in Sections 3.3 and 4.3, I propose a few im-provements to the MechatronicUML:

• Possibility to model the protocol and behavior textually.

• Constructs to express the purpose of the message events, like whether amessage event is a request or response.

• Formal definition for combining two protocols. This involves composingstatecharts of roles of protocols.

• Possibility to check the compatibility between components, that is, whetherthey can collaborate with each other.

• Possibility to check whether a component obeys its interfaces.

• Along with timed automata method of verification, several other methodsof verification using other model checkers like Spin model checker.

By comparing these two approaches and improving them from the results ofcomparison, will benefit the users of these two approaches. The typical usersinclude software architects of business information domain and communicationengineers of interactive real time system domain.

As a future work of this thesis, a metric oriented comparison, for e.g., Goal-Question-Metric (GQM), of the approaches will provide more concrete differ-ences. Also, to improve MechatronicUML further it should be comparedwith other approaches like AUTOSAR (http://www.autosar.org) and MARTE(http://www.omgmarte.org) using the GQM methods.

20

Bibliography

[ACD93] Rajeev Alur, Costas Courcoubetis, and David Dill. Model-checking indense real-time. Inf. Comput., 1993.

[AG97] Robert Allen and David Garlan. A formal basis for architectural con-nection. ACM Trans. Softw. Eng. Methodol., 6(3):213–249, July 1997.

[BBD+12] Steffen Becker, Christian Brenner, Stefan Dziwok, Thomas Gewering,Christian Heinzemann, Uwe Pohlmann, Claudia Priesterjahn, Wil-helm Schafer, Julian Suck, Oliver Sudmann, and Matthias Tichy. Themechatronicuml method process, syntax, and semantics. Technical Re-port tr-ri-12-326, Software Engineering Group, Heinz Nixdorf InstituteUniversity of Paderborn, August 2012.

[BDL04] Gerd Behrmann, Re David, and Kim G. Larsen. A tutorial on uppaal.pages 200–236. Springer, 2004.

[DBHT12] Stefan Dziwok, Kathrin Broker, Christian Heinzemann, and MatthiasTichy. A catalog of real-time coordination patterns for advancedmechatronic systems. Technical Report tr-ri-12-319, University ofPaderborn, Germany, Paderborn, Germany, February 2012.

[Flo95] Gert Florijn. Object protocols as functional parsers. In Proceed-ings of the 9th European Conference on Object-Oriented Programming,ECOOP ’95, pages 351–373, London, UK, UK, 1995. Springer-Verlag.

[HH11] Christian Heinzemann and Stefan Henkler. Reusing dynamic commu-nication protocols in self-adaptive embedded component architectures.In Proceedings of the 14th International Symposium on ComponentBased Software Engineering (CBSE-2011), June 2011.

[Hol03] Gerard Holzmann. Spin model checker, the: primer and reference man-ual. Addison-Wesley Professional, first edition, 2003.

[Kof07] Jan Kofron. Checking software component behavior using behaviorprotocols and spin. In Proceedings of the 2007 ACM symposium onApplied computing, SAC ’07, pages 1513–1517, New York, NY, USA,2007. ACM.

[Mey88] Bertrand Meyer. Object-Oriented Software Construction. Prentice-Hall, Inc., Upper Saddle River, NJ, USA, 1st edition, 1988.

21

Bibliography

[MPK05] Martin Mach, Frantisek Plasil, and Jan Kofron. Behavior protocolsverification: Fighting state explosion. International Journal of Com-puter and Information Science, March 2005.

[PPK07] Pavel Parizek, Frantisek Plasil, and Jan Kofron. Model checking of soft-ware components: Combining java pathfinder and behavior protocolmodel checker. In PathFinder and Behavior Protocol Model Checker,Proceedings of SEW06, IEEE CS, 2007.

[PV02] Frantisek Plasil and Stanislav Visnovsky. Behavior protocols forsoftware components. IEEE Transactions on Software Engineering,28:1056–1076, 2002.

[SCM10] Projects at d3s. http://nenya.ms.mff.cuni.cz/thegroup/SOFA/

sofa.html, November 2010.

[Sof13] Sofa 2 project. http://sofa.ow2.org, March 2013.

22