Modeling Data Races Using UML/MARTE Profile

Transcription

1 Modeling Data Races Using UML/MARTE Profile Akshay KC Ashalatha Nayak Balachandra Muniyal Department of Information and Communication Department of Computer Science Department of Information and Communication Technology and Engineering Technology MIT, Manipal University MIT, Manipal University MIT, Manipal University Manipal, , India Manipal, , India Manipal, , India Abstract Unified Modeling Language(UML) is a standard language for modeling in the domain of Object Oriented Software Development. However, it lacks the modeling construct for real time systems. The UML profile for Modeling and Analysis of Real Time Embedded Systems (MARTE) has been recently standardized by Object Management Group (OMG) to provide the necessary constructs. It provides support for Model Driven Engineering (MDE) of real time systems. The goal of this paper is to present the UML/MARTE profile in identifying a concurrency issue known as data race. The proposed approach leads to a supporting tool for automated detection of data races in which UML Sequence diagram is used to specify the temporal ordering of messages. Index Terms UML, MARTE profile, Data Race, Concurrency, Sequence Diagram I. INTRODUCTION A model represents an abstract view of the system. Model based software development is a process of developing the system by depicting the system as a model and specifying its respective properties[1]. In recent years, most of the organizations follow the model based software development. Some organizations use the model based development in the design and implementation phase whereas few other organizations follow model based development in design phase only[2]. Models can also be used in the requirements engineering phase with a method called as Rapid-Control- Prototyping which is a process of developing the prototypes for the requirements gathered. Model based software development has been regarded as an efficient software development methodology in identifying the missing requirements especially during the development of innovative or creative projects[2]. Unified Modeling Language(UML) is a standard language for modeling in the domain of Object Oriented Software Development which is a combination of the techniques from data modeling, object modeling, dynamic modeling and business modeling[3]. UML can be considered as a general purpose visual modeling language to visualize, specify, construct and document software system[4]. It can be used with all phases throughout the software development lifecycle. Hence there are different types of diagrams which are made use at different phases of software development lifecycle such as usecase diagram in requirements engineering phase, deployment and component diagram in architecture design phase, sequence, activity and collaboration diagram in design phase etc. Depending on the type of diagram, UML has its own standard way of visualizing and documenting the architecture of the system. UML is extensible with two mechanisms: profiles and stereotypes. Profiles[5] are a special kind of packages which provide the extended modeling mechanism, defined through stereotypes. is one of the extensibility mechanism which allows the designers to extend the vocabulary of UML in order to introduce new model elements[6]. MARTE is one such profile to extend the meaning of UML diagrams representing the real time Embedded systems architecture by providing respective stereotypes. UML is used to represent both static and dynamic aspects of a system. UML sequence Diagram is a kind of interaction diagram which depicts the interaction between different participating components or objects of the system. Every scenario of a use case can be represented using a sequence diagram. In turn, a use case which is considered as a collection of scenarios could be represented by separate sequence diagrams, where each sequence diagram depicts a single scenario or collectively all the scenarios of a single use case can be depicted by a single sequence diagram. Sequence diagram can be interpreted in a self-explanatory way along two dimensions as vertical and horizontal. The vertical dimension shows the messages passed between the objects on the time order in which they occur whereas horizontal dimension provides the objects between which the message transfer takes place. So for representing interaction between the components of a concurrent system, a sequence diagram is suitable to depict the messages between the collaborating objects of the system. Concurrency is a property of systems where more than one activity or computation is being carried out simultaneously, possibly by interacting with each other[7]. Due to this, the number of execution paths of the system could be very large indicating a very high usage involving simultaneous occurrences of system resources. In such cases, situation arise wherein two or more components or elements of the system request for the same resource at the same time. This phenomena is called data race which in turn might result in deadlocks or starvation. Data race condition[8] is an unpredictable state which occurs in distributed models where multiple threads or processes access a shared resource without any access order. But, among them, one of the access would be to write a data into the shared resource. A race exists between two events if they conflict i.e one reads and other one writes into the same memory location simultaneously. If a data race condition is present in any system, then it is necessary to identify or detect it. In that context, a real time case study is investigated here to check the existence of data race by incorporating UML/MARTE profile. The goal is to show that the data race can be detected early in the development phase by developing a systematic methodology to automate the data race detection problem. This paper is organized as follows. Section II provides the relevant related works and its comparison to the proposed work. The research gap which is identified from the literature survey is depicted in Section III. Section IV presents the background on MARTE architecture to solve the proposed methodology. The methodology and the experimental results are detailed in Section V followed by future work and conclusion in Section VI. II. RELATED WORK In the context of concurrent systems, a number of works exist that are related to monitoring temporal properties of concurrent systems. Such works have been the basis for detecting concurrency errors such as deadlock, starvation, data race, memory leak etc. These approaches either make use of the implementation/source code of the system under test or formal languages [9], [10], [11], [12]. The approach put forward by Lei et. al [11] is based on UML activity diagram, which identifies data races by searching the timing overlaps of threads entering and exiting the critical section. Here, the program under test is designed according to the model and tested against random test cases based on path analysis of the model. The execution traces are collected and then they are reverse engineered to event sequences. These runtime event sequences are then tested to verify the presence of possible data race. To implement the scenario a tool named toc4j has been proposed. However, the task of reengineering has been carried out for the legacy systems in their approach taking only the source code /14/$31.00 c 2014 IEEE 238

2 Yan Chen et.al, in their paper[9], have put forward an idea to detect the data races. Data race condition graph has been used to identify the data races. Like the happens-before relation, this paper introduces another relation called race-dependence relation which is used to represent the data race scenarios. It is used to detect the data races during the testing of concurrent programs. But the races cannot be identified during the early phase of software development in their approach. Demathieu et al in their paper[13] probe how the UML/MARTE profile can be used for representing the real time concepts by taking a case study of a fictive system Josefil Challenge. Here, the task is to evaluate whether the profile is applicable to Thales system. Thales system develops the aerospace, security and military applications. The Josefil Challenge is to develop a robotics system which follows model-driven engineering practices, the goal of which is to provide a framework for benchmarking different kinds of design approaches to distributed real-time and embedded systems. The initial UML diagrams are converted to UML/MARTE models after applying the MARTE profile. Also, the Software Resource Modeling and Hardware Resource Modeling are mapped to MARTE profile. However in the experimental setup, some inconsistencies are found in the MARTE definitions which are said to be reported to the OMG/MARTE task force. A framework for executing UML models and its underlying model transformations with respect to MARTE standards has been discussed in the paper by Mraidha et. al[14]. The framework gives the methodology showing how the MARTE profile can be mapped onto the real time scenarios by using ACCORD UML framework to exploit the models. ACCORD UML aims at providing Model Driven Architecture (MDA)-compliant methodology and related tools to the users. Using iterative method, authors have implemented the MARTE profile for the real time embedded system like cruise control system. MARTE profile has been used in detecting the concurrency problems like deadlocks and starvation[15]. Here the information relevant to starvation and deadlock has been extracted from the UML/MARTE metamodel. The extracted information is then fed into genetic algorithm with a certain fitness function tailored to deadlock and starvation detection respectively. The extension of the above mentioned work is to detect the data race condition[16] in concurrent systems. To detect the data races genetic algorithm has been used by tailoring the fitness equation. A prototype tool called Concurrency Fault Detector is built to detect the data races. It takes as input, the UML/MARTE sequence diagram, the execution time interval during which the system is to be analyzed, and the type of concurrency error targeted i.e data races, deadlocks or starvation. If a data race exists then it outputs all the possible sequences resulting in data race along with the time units, depicting threads acting on the shared resources. As described above, it is observed that there are approaches [14], [13] to provide details about MARTE profile. But the existing approaches provide only the general view of MARTE profile without getting into design aspects of concurrent systems. However there are works which surveyed the issues of concurrent systems incorporating MARTE profile and genetic algorithm[15], [16]. Nonetheless the evaluation of fitness function of genetic algorithm becomes expensive and exhaustive for complex systems. Moreover the termination criterion is not clear even though it gives out many solutions. III. MOTIVATION Based on the above survey it is observed that MARTE profile has been used exclusively in the context of genetic algorithms. So, the main goal of the proposed work is to investigate MARTE profiles in the presence of data races using dynamic diagrams such as UML Sequence diagrams. UML sequence diagrams are very useful in depicting the data race conditions using the appropriate profiles and stereotypes. It helps to detect the data race in a system early in the development phase by making necessary specifications using MARTE profile. In view of the above, the motivation on the proposed research are identified as below: The works surveyed by Chen et al [9] detect the presence of data race either in implementation phase or testing phase. It would be very expensive if the data race is detected due to the design fault. So, use of MARTE profile helps to overcome such glitches. The works which make use of formal languages[11], [12] lack the alignment with the software development lifecycle (SDLC). They provide the general view for the complete development but cannot be merged with the different phases of software development methodology. However UML specifications are strictly aligned with the phases of the SDLC. The existing works [9], [12], [10], [11] are static in nature since there is manual task of detecting the data race. The dynamic nature of the system is not modeled explicitly by making use of any behavioural diagrams such as sequence diagram. Concurrently executing methods are not able to identify and distinguish between the valid and non valid execution paths by the existing approaches. A valid sequence would be the path which preserves the order of execution of the corresponding operations. An invalid sequence would be the path which does not have any meaning of execution. The invalid execution sequences are to be filtered so that the number of executable paths to check for the data race scenario have to be reduced. IV. MARTE ARCHITECTURE Unified Modeling Language is meant for modeling the real world scenarios of general purpose systems. It provides specialization mechanism called Profiles, to handle specific domains. The UML profile for MARTE is the specialization of UML to model the real-time applications and platforms[14]. These profiles introduce new semantics to the sequence diagrams by extending the classes and their attributes. MARTE profile provides the concepts that support modeling features of real-time applications at a high level of abstraction, and at the same time MARTE defines its own semantics for those concepts that makes them extensible to build executable models. Thus UML/MARTE profile extends the capabilities of UML real-time and embedded systems development to incorporate design and analysis wherein modeling constructs include mechanisms to model information pertaining to concurrency [17]. As shown in Figure 1, the MARTE Architecture is roughly divided into four major packages: MARTE Foundation contains the basis for realtime and embedded system modeling. It defines time concepts and modeling elements for concurrent resources. MARTE design model specializes the foundation, allowing modeling of various features of real-time and embedded systems. MARTE analysis model allows the annotation of models for system analysis purposes. MARTE annexes provides information about additional specification languages provided by MARTE such as the Value Specification Language (VSL), the Clocked Value Specification Language (CVSL) and the Clock Constraint Specification Language (CCSL). It can be seen that MARTE profile is modular in structure, which allows users to choose the appropriate sub-profiles needed for their applications. The Software Resource Modeling (SRM) subprofile in MARTE design model presents mechanisms for designing multitasking applications. In the SW Concurrency package of SRM sub-profile, concurrently executing entities competing for resources are depicted with the SwConcurrentResource stereotype. Table I shows SW Concurrency package along with its associated attributes. As aforementioned, concurrency is also depicted in standard UML but the mentioned stereotype enhances concurrent execution modeling due to its associated attributes, such as priorityelements, which is used to determine the priority of the associated thread. The Generic Quantitative Analysis Modeling (GQAM) sub-profile in MARTE 2014 International Conference on Advances in Computing,Communications and Informatics (ICACCI) 239

3 Sub Profile HLAM RtServices concpolicy Reader Writer Describes the services for real time constraints. Used to define real time constraints Determines the type of concurrency policy used for the real-time service Real-Time service for reading the data Real-Time service for Writing the data TABLE IV: Sw Interaction package and its attributes Fig. 1: MARTE Architecture TABLE I: SW Concurrency package and its attributes Package Describes the entities for SW Concurrency Concurrency Represents the concurrently executing SwConcurrentResource entities Determines the priority of priorityelements the associated thread Analysis model defines stereotype gastep which is used when decisions about the allocation of system resources have to be undertaken. Its tags include priority (the priority of the action on the host processor), interocctime (interval between multiple initiations of the action) and exectime (the execution time of the action) as furnished in Table II. Execution times can be specified as maximum and minimum time ranges for exectime attribute. The High-Level TABLE II: Generic Quantitative Analysis Modeling sub-profile and its attributes Sub profile GQAM sastep priority interocctime exectime factorizes common constructs used when decisions about the allocation of system resources Determines the priority of the action on the host processor interval between multiple initiations of the action the execution time of the action Application Modeling sub-profile introduces RtService, a specialized service with specific real-time constraints. It contains several attributes such as, concpolicy, to determine the type of concurrency policy used for the real-time service along with the attributes such as reader and writer. This can be seen from Table III. The SRM sub-profile also has SW Interaction package which provides the shareddatacomresource stereotype to define specific resource for sharing the common area of memory among concurrent resources. As depicted in Table IV, the attribute waitingqueuepolicy is used to define the waiting queue of the processes contending for the resource. TABLE III: High-Level Application Modeling package and its attributes Sub- Profile Deals with SRM:SW Interaction communication and synchronization resources defines specific resources used to share the same shareddatacomresource area of memory among concurrent resources Defines the algorithm to waitingqueuepolicy manage the resource waiting queue V. EXPERIMENTAL SETUP To design a sequence diagram with MARTE profile, Eclipse Juno Model Development Tool (MDT)[18] has been used. Eclipse Juno MDT is a modeling editor for designing the UML models. But the extended platform called Papyrus[19] has to be installed on top of Eclipse to enable MARTE profile. Once the installation is completed, the model design can be carried out as described below. A. Modeling using Papyrus in Eclipse Modeling in Papyrus is similar to any other UML designing tool. Papyrus modeling editor is chosen to start the design work using Papyrus. To create a model using Papyrus, Papyrus Model is selected during the creation of the project. An editor will be opened with the palette containing all the required components to draw the corresponding diagram chosen by the user. The filename is created under the parent folder in the project explorer. When the created filename is expanded, there will be three basic components which are present automatically when the model is initially created. The <.di> file contains the graphical representation or design of the model. The <.notation> file contains the details of the diagram and also the references to the model elements whereas <.uml> file represents the elements of the model. After drawing the required diagram in the Papyrus editor, the MARTE profile is applied to the diagram. To draw the MARTE profile requirements the corresponding objects and their properties are selected by choosing the required profile and stereotype. When the stereotype is expanded in the Applied s window the attributes of the particular stereotype can be defined. B. Case Study An ATM system is taken here to illustrate the methodology. For an ATM system, there can be different use cases depicting the requirements of the system such as login, withdraw amount, deposit amount, check balance, get mini statement or check transaction history etc as shown in Figure 2. Among these usecases, withdraw amount use case is considered as a scenario to model the sequence diagram along with MARTE profile. Assume a scenario in withdraw amount usecase wherein two people are withdrawing amount from the same joint account simultaneously. Presume that the first deduction is a International Conference on Advances in Computing,Communications and Informatics (ICACCI)

4 Fig. 2: Use case diagram for ATM Machine withdrawal from an ATM for $100 and that the second deduction is $10 in another ATM. Assume the account has a total of $105 as the balance amount. Obviously, one of these transactions cannot correctly complete without sending the account into a low balance state. It can be happening in either of two ways: Sequential Transaction: One person is given access to the account and the system verifies whether sufficient fund is available or not. If amount is available then the withdrawal operation is carried out. Accordingly the second person is given access after the first person completes the transaction. Simultaneous Transaction: There might be a possibility that both of them are trying to withdraw money simultaneously from different ATM s. Both clients performing the withdrawal would first check whether the deduction is possible, then compute the new total balance, and finally execute the actual deduction. According to sequential transaction process, the transaction of bankclient1 and bankclient2 are executed one after another. Consider bankclient2 transaction happens initially, $10 is subtracted to get a new balance of 95. Then the ATM withdrawal of bankclient1 comes along and fails because $95 is less than $100. Suppose, the two transactions are initiated at the same time. Both transactions verify that sufficient amount exists in the account i.e $105 is more than both $100 and $10. Then, bankclient1 withdrawal process subtracts $100 from $105, yielding $5. The bankclient2 transaction then does the same, subtracting $10 from $105 and getting $95. The withdrawal process then updates the user s new total available funds to $5. Now the amount transaction also updates the new total, resulting in $95 providing the inconsistent balance amount. When two processes are acting simultaneously on a resource, there might be a possibility of inconsistent update. In the sequence diagram depicted in Figure 3, scenarios corresponding to two bankclients are shown. However, the execution of the processes might happen asynchronously. The behavior of the scenario described above is modeled using UML sequence diagram in Figure 3. It depicts the simultaneous transaction occurring between two bankclients. To detect the inconsistent activity, if any, properties shown in Figure 3 are not adequate. So, the sequence diagram is mapped on to MARTE profile which is shown in Figure 4. It can be observed that stereotypes have been used which emphasizes the meaning of the objects or the components used in the system. The concurrencyresource stereotype defined under SW Concurrency package is shown in Figure 4. The stereotype depicts the concurrently executing entities trying to get an access for resource. It extends the modeling of concurrent execution due to its attributes like priorityelements, which is used to specify the priority of the corresponding thread. C. XML Output When a sequence diagram is developed in Papyrus editor, a <.uml> file is generated. This file contains the XML schema of the sequence diagram with MARTE. The <.uml> file contains the Fig. 3: Sequence Diagram for withdraw amount usecase Fig. 4: MARTE profile augmented Sequence Diagram for withdraw amount usecase specific elements of the sequence diagram such as the model name, lifelines, messages and their types, details of interaction such as combined fragments etc. D. Parsing <.uml> file The auto generated <.uml> file is given as input to the parser. It starts checking if the input file exists, otherwise the algorithm is terminated. Next, the algorithm begins to parse the elements of input file. When the parser starts reading the model elements of the <.uml> file, it considers every model element as element fragment. Then it checks the definition of element fragment for any embedded child element definition. If the child element is present then the identified child element is denoted as a node. Each node will have its own attributes. Based on the tag names of the nodes the corresponding attributes are retrieved. Once the attributes of the elements are retrieved from the <.uml> file, they are stored into a file data structure. The tag names such as uml:model, packagedelement, operand, lifeline, message, etc mentioned along with the start tag is considered as element fragment. When the parser reads these element fragment, it checks for the corresponding child elements. E. Reading the Combined Fragment When the prototype parser parses the <.uml> file it reads the messages sequentially. Suppose a combined fragment is encountered during parsing, it checks the type of combined fragment. There are different types of combined fragments such as seq, par, opt, alt, etc [4]. The designed prototype tool parses only the par fragment International Conference on Advances in Computing,Communications and Informatics (ICACCI) 241

5 So, during parse process if par fragment is encountered then the operands present inside the par fragment is identified. For example, two operands denoted in <.uml> file as IntereactionOperand and InteractionOperand0 are bankclient1 and bankclient2. The algorithm to parse the combined fragment is given in Algorithm 1. Algorithm 1 Combined Fragment parsing algorithm to identify and retrieve the messages from combined fragment Precondition: The combined fragment is present in the model. Postcondition: All the interaction operands and their respective messages are retrieved from the par fragment. Input: Model elements of par fragment Output: Array of all messages in par fragment Local: mid, Denotes the message-id of j th message in i th interaction operand. m[ ], Denotes an array which contains the names of all the messages in i th interaction operand. msg[ ], Denotes an array which holds all messages of all the interaction operands in the par fragment. 1: Identify innermost par fragment and denote it as cfrag 2: Find the number of operands, N, in the cfrag 3: for i 0 to N in step of 1 do 4: Retrieve the oprname of each identified operand i 5: end for 6: for i 0 to N in step of 1 do 7: Retrieve the message id, mid ij from each inner fragment of operand i,j 0 tom 8: end for 9: for i 0 to N in step of 1 do 10: for j 0 to M in step of 1 do 11: get message name for mid j 12: store the name in an array, m i [j] 13: msg[mcount++] m i [j] mcount gives the total number of messages in par fragment 14: end for 15: end for 16: call permutation algorithm The message-id s of the messages present in the respective fragments of the operand i have to be retrieved. The retrieved message-id s are denoted as mid ij where i represents the number of operands, i 0 to N, and N denotes the number of operands in the designated par fragment while j represents the number of message-id s, j 0 to M where M denotes the total number of messages present in the operand i. For every message-id retrieved with respect to each operand, the message names corresponding to the message-id s have to fetched. These message names are stored in a array m i[j], i.e. the fetched message names will be stored in the array. To generate the scenarios from the message names identified, another array of size i*j=k, is chosen. The message names which are stored in m i[j] are to be put into the array msg[k]. Once the number of operands and identifying names within the par fragment are fetched, the next parsing is to find the message calls in each of the operands. To find message calls of an operand, the message-id needs to be extracted. When the parser starts parsing the par segment each element in par is considered as a fragment. So every fragment will have an attribute called message which provides the message-id for each message in the respective fragment of the operand. The message-id of every fragment is thus retrieved and stored into an array referred in Algorithm 2 as msg. After the retrieval process, it is also required to fetch the names of the messages whose message-id s are stored into array msg. This is how a message-id gets associated to message name for further parsing. In this way, all the messages in the combined fragment are retrieved according to the operands. Subsequently, the process is repeated if any nested combined fragment is encountered during further processing. For example, the messages retrieved from the combined fragment depicted in Figure 4 is listed in Table V TABLE V: Messages and their respective operands from the sequence diagram of Figure 4 Operand Name InterctionOperand InteractionOperand0 Message Name b1.withdraw amount b1.update balance b2.withdraw amount b2.update balance F. Finding valid Messages Considering the scenario depicted in Figure 4, the update process is a write operation on bankclient1 and bankclient2. Let M 11, M 12 denote withdraw and update operation of bankclient1 respectively and M 21, M 22 denote the corresponding operations of bankclient2 i.e M 11: bankclient1.withdraw amount() M 12:banckclient1.update balance() M 21: bankclient2.withdraw amount() M 22: bankclient2.update balance() Considering M 11, M 12, M 21 and M 22 there can be a total of 4! possible interleaving execution sequences. Of these 4! execution sequences, 6 of them would be valid interleaving sequences. A valid sequence would be the path which preserves the order of execution of the corresponding operations. An invalid sequence would be the path which does not have any meaning of execution. The algorithm to check the valid path is given in Algorithm 2. This algorithm finds all possible combinations of the identified scenarios. From the all possible combinations the valid paths are detected by employing the method mentioned below. Algorithm 2 Permutation algorithm to find the valid scenarios of the messages retrieved from combined fragment Precondition:The model element of the MARTE sequence diagram must be parsed and stored in an intermediate data structure. Postcondition: Only the valid scenarios are retrieved from the par fragment. Input: Model elements of par fragment Output: List of all valid scenarios of the messages in par fragment Local: msg[ ], Denotes an array which holds all messages of all the interaction operands in the par fragment 1: for i 0 to mcount in step of 1 do 2: print msg[i] 3: end for 4: i 0, j 0 where i and j are counters or index values to access the messages of par fragment which are stored in msg[ ] 5: while i<n do where N is the total number of messages present in the par fragment. 6: while TRUE do 7: j i +1 8: temp = msg[j] msg[i] depicts each message of different interaction operands in par fragment 9: msg[j] = msg[j+1] 10: msg[j+1] = temp 11: j++; i++ 12: break 13: end while To print all the messages of msg[ ] after every single swap 14: for k 0 to mcount in step of 1 do 15: print msg[k] 16: end for 17: end while Loop ends when permutations are finished considering all the messages in the array The execution scenarios where M 12 or M 22 occurring before M 11 or M 21, are invalid sequences. For example, {M 12, M 22, M 11, M 21 } International Conference on Advances in Computing,Communications and Informatics (ICACCI)

6 is a invalid sequence as < M 12, M 22 > are the operations occurring after < M 11, M 21 > respectively in their corresponding operands. The sequence of execution of messages is thus invalid as it does not preserve the original ordering of operands. Similarly, the remaining sequences are found to be invalid by automating the above method as per Algorithm 2. Of the six valid paths, four of them are likely to cause potential data race scenarios which can be listed as:{m 11, M 21, M 12, M 22}, {M 11, M 21, M 22, M 12}, {M 21, M 11, M 22, M 12}, {M 21, M 11, M 12, M 22}. The remaining two valid path scenarios do not involve the occurrence of data race conditions. These are sequential cases of execution paths {M 11,M 12,M 21,M 22} and {M 21,M 22,M 11,M 12}. G. Analysing and Detecting the Data Race As discussed in the previous section there are six valid path scenarios if the number of messages in the par fragment is four. Of the six valid scenarios, there might be few paths resulting in data race. To find whether a particular scenario leads to data race or not, the properties of the operation provided by MARTE profile are examined. Table VI provides the details about the different values set to the attributes of MARTE profile stereotypes. As shown in TABLE VI: of attribute values for bankclient1 and bankclient2 gastep RtService s bankclient1 Time Period bankclient2 Time Period min max min max exectime p1 q1 p2 q2 interocct m M concpolicy reader writer reader writer Remarks For p1<p2 and p2<q1, it is simultanoeus exectuion For p2>q1, it is sequential execution showing the ideal case. Denotes the time within which the operation interleaving takes place Denotes the read operation Denotes the write operation Figure 4, when bankclient1.update balance() operation is invoked bankclient2.update balance() operation also tries to write the data onto the same account resource. Such a scenario might result in inconsistent update through the values of the attribute exectime. If the minimum and maximum values of the participating objects overlap then it is considered that ongoing transaction is inconsistent. Let p i denote the minimum exectime of bank Client i and q i denote maximum exectime for executing operations of bankclient i. There can be two possibilities of checking for data race as described below: 1) For a sequential execution p2>q1 i.e the minimum exectime of bankclient2 must be greater than the maximum exectime of bankclient1. As the execution time of banckclient1 and bankclient2 will not overlap, they try to write data into the resource in a sequential order which derives a consistent result. 2) For a simultaneous execution p1>p2 and p2<q1 i.e the minimum exectime of bankclient2 should be within the exectime range of bankclient1. In this case the result will be inconsistent. Since both clients are trying to write data onto a same resource at the same time duration while each of these process is a write operation there exists the data race condition. With the flexibility to declare time constraints explicitly, it is possible to avoid the possible occurrence of data race conditions prior to the implementation of the system. MARTE profile provides the constructs to express the complex time constraints as shown in Figure 4. There are six different cases of valid scenarios as furnished in Table VII. All six listed scenarios are likely to cause potential data races. The first scenario, {M 11, M 21, M 12, M 22} with M 12 and M 22 as write operations, denotes two possibilities of execution depending on the execution time specified for the corresponding operation. Suppose < p1, q1 > represent the range of execution time of update balance operation of bankclient1 and <p2, q2> represent the range of execution time of update balance operation of bankclient2. First possibility is that p2 of M 22 is greater than q1 of M 12 which means there is no overlapping of execution times between M 12 and M 22 indicating sequential execution of messages. Scenario- Id TABLE VII: Test scenarios Message format for scenario {M 11,M 21, M 12,M 22 } {M 11,M 21, M 22,M 12 } {M 21,M 11, M 22,M 12 } {M 21,M 11, M 12,M 22 } {M 11,M 12, M 21,M 22 } {M 21,M 22, M 11,M 12 } p1<p2 and p2<q1 The scenario is consistent if p1<p2 and p2>q1 p2<p1 and p1<q1 The scenario is consistent if p1<p2 and p2>q1 p2<p1 and p1<q2 The scenario is sequential if p2<p1 and p1>q2 p1<p2 and p2<q1 The scenario is consistent if p1<p2 and p2>q1 Sequential but inconsistent if p1<p2 and p2<q1. Sequential but inconsistent if p2<p1 and p1<q2 Second possibility is that if p1<p2 and p2<q1 then there is overlapping of execution times of M 12 and M 22 which is an indication of inconsistent execution. Suppose both M 12 and M 22 are write operations with overlapping means that there are two write operations happening simultaneously on the same shared resource. This is a phenomenon of data race which is possible to trace by the proposed approach. Similarly, analysis can be done for each of the scenarios. So based on the time constraints specified for the operations it is possible to identify the potential data races that are likely to be caused during the execution of those programs. VI. CONCLUSION In this paper, we presented a case study on modeling a real time system using MARTE profile. The details of the experiment are illustrated using key features of MARTE profile to specify real-time behavior. The modeling of the real time systems using MARTE appears promising as it is possible to explicitly set the required attributes and properties of the participating concurrent objects. For simplifying the use of scenario based specifications, a UML sequence diagram was used in the present approach. However, for describing multiple scenarios it is required to extend the approach with complete system specifications that includes interaction overview diagram 2014 International Conference on Advances in Computing,Communications and Informatics (ICACCI) 243

7 which focuses on the flow of control with each node as a sequence diagram. It is also required to extend the proposed approach for the run time verification of Java programs. For this purpose, the UML diagrams can be used as automatic test oracles that specify the expected temporal ordering of message interaction in Java programs. REFERENCES [1] J. Sztipanovits, Model-Based Software development, ESMD-SW Workshop, NASA, March [2] M. Broy, H. Krcmar, J. Zimmermann, and S. Kirstan. (2011, March) Model Based Software development - Its real benefit. [Online]. Available: en/model-based-software-development-its-real-benefit.html?cmp id= 71&news id= r [3] J. Rumbaugh, I. Jacobson, and G. Booch, The Unified Modeling Language User Guide. Addison-Wesley, [4] OMG. (2011, March) UML Specification available at. [Online]. Available: [5] Profiles in UML. [Online]. Available: Profile %28UML%29 [6] s in UML. [Online]. Available: %28UML%29 [7] Concurrency. (2012). [Online]. Available: Concurrency (computer science) [8] RaceCondition. (2012). [Online]. Available: wiki/race condition [9] Y. Chen, Y. H. Lee, W. Wong, and D. Guo, A Race Cndition Graph for Concurrent Program Behaviour, Proceedings of 3rd International Conference on Intelligent System and Knowledg Engineering, pp , [10] C. Flanagan and S. N. Freund, Detecting Race Conditions in Large Programs, Compaq System Research Center, Tech. Rep., [11] B. Lei, L. Wang, and X. Li, UML activty diagram based testing of Java Concurrent Programs for Data Race and Inconsistency, Proceedings of 1st International Conference on Software Testing, Verification and Validation, pp , April [12] S. Kulikov, N. Shafiei, F. van Breugel, and W. Visser. Detecting Data Races with Java Path Finder. [Online]. Available: franck/research/drafts/race.pdf [13] S. Demathieu, F. Thomas, C. Andre, S. Gerard, and F. Terrier, First Experiments using the UML profile for MARTE, 11th IEEE Symposium on Object Oriented Real-Time Distributed Computing(ISORC), pp , [14] C. Mraaidha, Y. Tanguy, C. Jaouvray, F. Terrier, and S. Gerard, An Execution Framework for MARTE-based Models, 13th IEEE International Conference on Engineering of Complex Computer Systems, pp , [15] M. Shousha, L. C. Briand, and Y. Labiche, A UML/MARTE Model Analysis Method for Uncovering Scenarios Leading to Starvation and Deadlocks in Concurrent Systems, IEEE transactions on Software Engineering, vol. 38, no. 02, March/April [16] L. C. Briand, Y. Labiche, and M. Shousha, A UML/MARTE Model Analysis Method for Detection of Data Races in Concurrent Systems, Model Driven Engineering Languages and Systems: Springer Publications, vol. 5795, pp , [17] UML Profile for MARTE: Modeling and Analysis of Real-Time Embedded Systems, June [Online]. Available: org/spec/marte/1.1 [18] Eclipse. [Online]. Available: [19] Papyrus UML. [Online]. Available: home/publigen/content/templates/show.asp?l=en&p=55&vticker= alleza&itemid= International Conference on Advances in Computing,Communications and Informatics (ICACCI)